What is Claude Mythos, and why does it matter for security?

Claude Mythos is a frontier AI model designed to autonomously discover and chain zero-day vulnerabilities across major operating systems and browsers. Mythos threatens to collapse the window between vulnerability discovery and weaponization from weeks to hours — a shift widely expected to be permanent. Advances in AI have lowered the skill barrier for autonomously discovering and exploiting software vulnerabilities at a scale and speed beyond human capability. This means that the volume and sophistication of CVEs entering the ecosystem are set to increase sharply.

Even though Claude Mythos Preview is not yet accessible to the general public, it has already found thousands of zero-days across every major OS and browser. As AI-driven discovery increases the volume of CVEs, organizations that rely solely on static scanning or pipeline tools will be overwhelmed by findings they cannot meaningfully prioritize. Organizations must prepare for a new reality once Mythos, or tools like it, are more widely available.

For SRE, DevOps, security teams, and AI builders, the question is no longer if your environment contains vulnerabilities — it’s whether you can tell which ones are actually exploitable before an adversary does.

Why traditional vulnerability scanners can’t keep up with AI-driven threats

Traditional security tools — code scanners, static analysis, pipeline checks — can’t see what’s running in production. They generate thousands of results that accurately identify vulnerabilities but fail to evaluate which are exploitable or represent the most risk, leading to alert fatigue and slow risk mitigation, while potentially leaving the biggest risks exposed or undetected.

But there’s a deeper problem: vulnerability exposure is not static. Servers are reconfigured. New application code is pushed to production multiple times a day. Containers spin up and down. Dependencies change with every deployment. A vulnerability that was unexploitable this morning may become reachable by afternoon — and vice versa. Point-in-time scanning tools produce a snapshot that begins aging the moment it’s generated. In a world where Mythos-class models accelerate CVE discovery by orders of magnitude, tools that generate thousands of uncontextualized, static findings are a liability.

A periodic report tells you what was true hours ago. Organizations need continuous, runtime-aware scanning that keeps pace with your environment as it evolves.

Why do AI‑driven threats make runtime vulnerability detection essential?

This is where the runtime security approach fundamentally changes the equation. Rather than cataloging everything that could be risky, runtime security anchors every vulnerability finding in live production context: What is running, what is reachable, and what has real business impact.

Here’s how Dynatrace implements runtime vulnerability detection with built-in risk assessments for the Mythos era:

1. Filter vulnerabilities to only running components. Dynatrace OneAgent, embedded directly in the runtime environment, continuously monitors which libraries and components are actively loaded and executing. If a dependency exists in your repository but is never invoked in production, it’s automatically deprioritized. Only vulnerabilities in running code are surfaced, which is why customers report seeing significantly fewer vulnerabilities compared to earlier-in-pipeline scanning tools.
2. Deprecate unreachable (non-exploitable) vulnerabilities. A running library isn’t necessarily an exploitable one. Dynatrace performs deep code-level reachability analysis, tracing actual execution paths and real traffic patterns to determine whether the specific vulnerable function can be reached. If no active call chain invokes it, the finding is deprioritized, enabling teams to focus on vulnerabilities that represent higher risk of exploitation.
3. Prioritize based on real-time business impact. For confirmed, reachable vulnerabilities, the question becomes: what’s at stake? This is where  Dynatrace’s real-time topology and dependency graph — Smartscape^® — becomes essential. Smartscape automatically discovers every process, service, host, and application across your environment and maps how they depend on one another. Think of it as a living dependency graph of your production landscape, continuously updated with every deployment and infrastructure change, making sure the impact-radius analysis is current and not based on a stale inventory.

Smartscape instantly maps which business services are affected, which are internet-exposed, and which connect to revenue-critical workflows, enabling teams to triage on actual business criticality rather than raw CVSS scores alone.

As Mythos-era CVE volumes surge, your teams will receive a focused, continuously updated list of exploitable, business-critical risks.

The Dynatrace platform advantage for AI-driven security

In addition to Smartscape, Dynatrace is underpinned by additional core technical differentiators that make it uniquely positioned for the Mythos era:

• Grail — A unified data lakehouse that stores and correlates all observability and security data at scale without index limitations, giving RVA the foundation to analyze runtime context across the entire environment.
• Dynatrace Intelligence — The AI layer powering automated causal analysis, workflow execution, and remediation routing. As CVE volumes scale, human-speed triage becomes unsustainable, making automated, context-aware prioritization and remediation routing — enabled through third-party integrations — the only viable path forward.
• Dynatrace Vulnerability Feed — A patented, proprietary vulnerability feed that goes beyond standard public CVE databases. The feed rapidly ingests vulnerabilities disclosed through channels such as GitHub Security Advisories and OSV.dev — assessing them against your production runtime. Coverage specifically includes AI frameworks and open-source components relevant to agentic workloads: the fastest-growing attack surface.

Why open source vulnerabilities will surge in the Mythos era

This last point is particularly relevant in the Mythos era. Open source software is where AI-powered discovery tools will generate findings fastest — open source codebases are fully scannable with no license barriers, and GitHub Security Advisories and OSV.dev are precisely where the Dynatrace feed is deepest. When a Mythos-era OSS vulnerability is disclosed, it flows into the feed within hours and is assessed against your production runtime immediately.

As CVE volumes surge, Dynatrace customers will receive a focused, continuously updated list of exploitable, business-critical risks that reflects what’s true in production right now, not what was true at the last scan.

Why security teams should act now

Up until 2025, AI was largely seen in security circles as a risk factor: a source of new vulnerabilities. People with little to no programming experience were suddenly able to publish AI-generated applications at scale, many of which contained fundamental security flaws.

By late 2025, however, AI models had advanced to the point where they could not only introduce vulnerabilities, but actively discover them. Their ability to identify active, exploitable weaknesses in code has been improving rapidly ever since.

Claude Mythos represents a step-change in this evolution. It goes beyond discovering isolated issues to chain vulnerabilities, identifying multiple low-impact flaws that, on their own, may not pose significant risk, but when combined into a sequence of three, four, or more, can be weaponized into highly sophisticated attacks.

Now, before Mythos is publicly available, is the time to prepare. It is critical for organizations to leverage platforms that find critical vulnerabilities that other tools have missed. In a large volume of noise, teams will need to focus on real production risk exposure; not an endless list of unworkable attacks.

By combining runtime observability with security intelligence, Dynatrace cuts through noise and allows faster, more confident remediation through Dynatrace Intelligence and AI-powered agentic workflows.

The Mythos era doesn’t have to mean more chaos. It can be the catalyst for better prioritization through meaningful signals, pressures for faster action, and stronger security posture.

The post How Anthropic Claude Mythos is reshaping the vulnerability landscape appeared first on Dynatrace news.

TL;DR:

A critical flaw in React’s Flight protocol (CVE-2025-55182) allows attackers to run code on servers using React Server Components. In short, if your organization uses React Server Components, Next.js, or related frameworks, attackers could potentially take control of your servers, making this a top priority for immediate action.

What’s at risk?

• Vulnerable: React Server Components, Next.js, React Router, Waku, and several related frameworks.
• Impacted: Any organization running affected versions in production.
• Exploits: Proof-of-concept code is publicly available and active scanning is underway.
• Remediation: Upgrade to patched versions now to prevent remote code execution.

Real-world scenario:

Imagine a production server running an unpatched version of Next.js. An attacker sends a crafted payload, triggering remote code execution, and gaining unauthorized access to your infrastructure. The window between disclosure and exploitation is shrinking—don’t wait to act.

Immediate steps:

• Audit your environment for affected frameworks (e.g. leveraging Dynatrace Runtime Vulnerability Analytics).
• Upgrade dependencies to patched versions.
• Use Dynatrace Runtime Vulnerability Analytics to verify remediation.
• Monitor continuously for new threats.

What is React2Shell (CVE-2025-55182)?

A critical vulnerability called React2Shell has been discovered in React’s Flight protocol that could allow attackers to execute arbitrary code on servers running React Server Components. CVE-2025-55182 affects multiple popular frameworks, including Next.js, React Router, and Waku, with exploitation possible under default configurations. While no verified public exploits exist yet, the severity and widespread nature of this vulnerability make immediate patching essential. Organizations using React Server Components should prioritize upgrading to patched versions to protect their applications from potential remote code execution attacks.

How to fix React2Shell vulnerability (CVE-2025-55182): patching guide

To address this vulnerability, it is recommended to upgrade to the patched versions of the affected packages.

Upgrade react-server-dom-* packages to one of the following versions, or higher:

• 19.0.1
• 19.1.2
• 19.2.1

Upgrade Next.js to one of the following versions, or higher:

• 15.0.5
• 15.1.9
• 15.2.6
• 15.3.6
• 15.4.8
• 15.5.7
• 16.0.7

Technical details of the React2Shell vulnerability

CVE-2025-55182 is an unsafe deserialization vulnerability in React’s Flight protocol, affecting server component payloads. This flaw allows attackers to craft malicious payloads that, when processed by the server, can lead to unauthenticated remote code execution. Exploitation is possible under the default configuration of several popular frameworks, making the vulnerability critical and widely exploitable.

Which React and Next.js versions are vulnerable?

The following packages are vulnerable to CVE-2025-55182 because they implement parts of React’s Flight protocol, which handles server component payloads and is the source of the unsafe deserialization flaw:

Frameworks that implement React Server Components and rely on these packages are also affected. These include: Next.js, React Router, Waku, @parcel/rsc, @vitejs/plugin-rsc, and rwsdk.

The react and react-dom libraries are not impacted because they do not include the Flight protocol or any server-side component handling. Environments that render React exclusively on the client, or that do not integrate frameworks, bundlers, or plugins supporting React Server Components, remain outside the scope of this vulnerability.

The related vulnerability, CVE-2025-66478, was initially published for Next.js and marked as critical. It was later rejected and classified as a duplicate of CVE-2025-55182, because the root cause lies in Next.js depending on vulnerable React packages that implement the Flight protocol.

While the dependency link is correct, Next.js does not rely on the npm ecosystem to resolve these React Server Component packages. Instead, Next.js includes compiled versions of the react-server-dom-* packages directly in its repository. This means that upgrading React in isolation will not remediate the vulnerability for Next.js users because the vulnerable code is embedded within Next.js itself.

The following Next.js versions are affected:

What are the related RSC vulnerabilities?

On December 11, 2025, two additional vulnerabilities were discovered in React Server Components, affecting the react-server-dom-* and Next.js packages:

• Denial of Service – High Severity: CVE-2025-55184 and CVE-2025-67779
• Source Code Exposure – Medium Severity: CVE-2025-55183

For the Denial of Service vulnerability, there are two CVE numbers due to an incomplete fix for the first CVE.

We recommend updating the affected packages to the latest patch version, as outlined below:

Are there working exploits for React2Shell vulnerability?

Proof-of-concept exploits for React2Shell (CVE-2025-55182) have been developed and made publicly available. The vulnerability has also been added to the CISA Known Exploited Vulnerabilities (KEV) catalog, confirming active exploitation. Additionally, the vulnerability reporter has published several exploit variants on GitHub:

lachlan2k/React2Shell-CVE-2025-55182-original-poc.

const payload = { 
    '0': '$1', 
    '1': { 
        'status':'resolved_model', 
        'reason':0, 
        '_response':'$4', 
        'value':'{"then":"$3:map","0":{"then":"$B3"},"length":1}', 
        'then':'$2:then' 
    }, 
    '2': '$@3', 
    '3': [], 
    '4': { 
        '_prefix':'console.log(7*7+1)//', 
        '_formData':{ 
            'get':'$3:constructor:constructor' 
        }, 
        '_chunks':'$2:_response:_chunks', 
    } 
} 
  

The root cause of this vulnerability lies in how React’s Flight protocol processes incoming data. The data is processed as chunks, as seen above, which can reference each other, denoted by the $ symbols. The exploit takes advantage of this behavior along with a bug caused by missing attribute checks, which allows access to properties such as constructor. The fix for the attribute check can be seen in the patch here.

The crafted payload chains internal gadgets to create a Promise-like object with an attacker-controlled “.then” property. During deserialization, these Promise-like objects are automatically resolved, which results in code execution.

The vulnerability is actively being scanned in the wild, significantly increasing the risk for organizations running vulnerable versions of affected packages. Given the critical nature of React2Shell and the existence of working exploits, immediate remediation is strongly advised.

Detecting React2Shell (CVE-2025-55182) with Runtime Vulnerability Analytics

You can use Dynatrace Runtime Vulnerability Analytics to detect if vulnerable React Server Component packages or Next.js packages are present by filtering for CVE-2025-55182 in the app.

Bottom Line: If you’re running React Server Components or Next.js in production, review your dependencies immediately and upgrade to patched versions.

Searching for React2Shell vulnerable components (CVE-2025-55182) with DQL

You can also use Smartscape to manually search for vulnerable software components.

fetch dt.entity.software_component
  | fieldsAdd vulnerable =  if(in(entity.name, {
      "react-server-dom-parcel:19.0",
      "react-server-dom-parcel:19.1.0",
      "react-server-dom-parcel:19.1.1",
      "react-server-dom-parcel:19.2.0",
      "react-server-dom-webpack:19.0",
      "react-server-dom-webpack:19.1.0",
      "react-server-dom-webpack:19.1.1",
      "react-server-dom-webpack:19.2.0",
      "react-server-dom-turbopack:19.0",
      "react-server-dom-turbopack:19.1.0",
      "react-server-dom-turbopack:19.1.1",
      "react-server-dom-turbopack:19.2.0"
      }), true)

  // Make sure to check if the found next version is vulnerable   
  | fieldsAdd potentially_vulnerable = 
      startsWith(entity.name, "next:14.3.0") or
      startsWith(entity.name, "next:15") or
      startsWith(entity.name, "next:16")
 
  | filter
      vulnerable == true or
      potentially_vulnerable == true

Important note: When using this manual search method (as opposed to Runtime Vulnerability Analytics), you’ll need to:

• Manually and reactively search for affected versions whenever an incident occurs
• Work without the additional context and guidance that RVA provides, such as:
  • Davis Security Score
  • Public internet exposure analysis
  • Exploit availability information

How to detect React2Shell (CVE-2025-55182) exploitation activity

If you have logs containing process execution events, you can detect the common attack patterns (tactics, techniques, and procedures or TTPs) that adversaries use when exploiting vulnerabilities like CVE-2025-55182.

The Dynatrace platform can ingest data from any source that provides this information. The following example (with an alternate for Windows systems) uses Tetragon as the data source. By combining these logs with Smartscape attributes, you get full context for detecting exploitation activity—which helps reduce false positives and speeds up investigations.

// Adjust timeframe accordingly
fetch logs, 
  from: -14d,
  scanLimitGBytes: -1

// We use Tetragon as an example, any source for process execution could be used
| filter log.source == "Container Output"
| filter k8s.workload.name == "tetragon"
| parse content, "JSON:content"

// Filter on process start events
| filter isNotNull(content[process_exec])

// Add fields for further processing
| fieldsAdd k8s.pod.uid = content[process_exec][process][pod][uid]
| fieldsAdd process.parent.executable.path = content[process_exec][parent][binary]
| fieldsAdd process.parent.executable.name = splitString(process.parent.executable.path, "/")[-1]
| fieldsAdd process.executable.path = content[process_exec][process][binary]
| fieldsAdd process.executable.name = splitString(process.executable.path, "/")[-1]
| fieldsAdd process.cmd_line = concat(process.executable.path, " ", content[process_exec][process][arguments])
| fieldsRemove k8s.deployment.name

// Filter on node instances
| filter in(lower(process.parent.executable.name), {
    "node",
    "bun"
  })

// Filter for common shell processes
| filter in(lower(process.executable.name), {
    "ash",
    "bash",
    "bash-static",
    "busybox",
    "csh",
    "dash",
    "fish",
    "ksh",
    "lksh",
    "mksh",
    "mksh-static",
    "posh",
    "rksh",
    "rksh93",
    "sash",
    "static-sh",
    "sh",
    "tcsh",
    "yash",
    "zsh" 
  }) and iAny(contains(lower(process.cmd_line), array(
    "cat",
    "curl",
    "dig",
    "env",
    "head",
    "hostid",
    "hostname",
    "id",
    "ifconfig",
    "ip",
    "install",
    "less",
    "mkfifo",
    "more",
    "nc",
    "ncat",
    "netcat",
    "netstat",
    "nslookup",
    "perl",
    "ping",
    "pwd",
    "route",
    "socat",
    "shred",
    "ss",
    "stat",
    "tail",
    "tee",
    "uname",
    "wget",
    "who",
    "whoami",
    "/dev/tcp",
    "/dev/udp",
    "/etc/passwd",
    "/etc/shadow"
  )[], caseSensitive: false)) or in(lower(process.executable.name), {
    "cat",
    "curl",
    "dig",
    "env",
    "head",
    "hostid",
    "hostname",
    "id",
    "ifconfig",
    "ip",
    "install",
    "less",
    "mkfifo",
    "more",
    "nc",
    "ncat",
    "netcat",
    "netstat",
    "nslookup",
    "perl",
    "ping",
    "pwd",
    "route",
    "socat",
    "shred",
    "ss",
    "stat",
    "tail",
    "tee",
    "uname",
    "wget",
    "who",
    "whoami"
  })

// Get smartscape data for affected entity
| join [
    smartscapeNodes "K8S_POD"
],
on: { k8s.pod.uid },
kind: leftOuter,
fields: {
  k8s.node.name,
  k8s.namespace.name,
  k8s.workload.name,
  k8s.workload.kind,
  k8s.pod.name,
  id_classic
}

fetch logs
| filter winlog.eventid == "1"
| parse content, """
    LD CR LF
    'RuleName: 'LD:RuleName CR LF
    'UtcTime: 'LD:UtcTime CR LF
    'ProcessGuid:' LD:ProcessId CR LF
    'ProcessId: 'LD:PorcessId CR LF
    'Image: 'LD:Image CR LF
    'FileVersion: 'LD:FileVersion CR LF
    'Description: 'LD:Description CR LF
    'Product: ' LD:Product CR LF
    'Company: ' LD:Company CR LF
    'OriginalFileName: ' LD:OriginalFileName CR LF
    'CommandLine: ' LD:CommandLine CR LF
    'CurrentDirectory: ' LD:CurrentDirectory CR LF
    'User: ' LD:User CR LF
    'LogonGuid: ' LD:LogonGuid CR LF
    'LogonId: ' LD:LoginId CR LF
    'TerminalSessionId: ' LD:TerminalSessionId CR LF
    'IntegrityLevel: ' LD:IntegrityLevel CR LF
    'Hashes: ' LD:Hashes CR LF
    'ParentProcessGuid: ' LD:ParentProcessGuid CR LF
    'ParentProcessId: ' LD:ParentProcessId CR LF
    'ParentImage: ' LD:ParentImage CR LF
    'ParentCommandLine: ' LD:ParentCommandLine CR LF
    'ParentUser: ' LD:ParentUser
    """

| filter iAny(endsWith(ParentImage, array(
    "node.exe",
    "bun.exe")[], caseSensitive: false))
| filter iAny(contains(CommandLine, array(
    "-enc",
    "-EncodedCommand",
    "-w hidden",
    "-windowstyle hidden",
    "Test-NetConnection"
  )[], caseSensitive: false)) or in(lower(OriginalFileName), {
    "cmd.exe",
    "powershell.exe",
    "pwsh.exe",
    "arp.exe",
    "at.exe",
    "bash.exe",
    "bitsadmin.exe",
    "certutil.exe",
    "csript.exe",
    "dsget.exe",
    "dsquery.exe",
    "find.exe",
    "findstr.exe",
    "hostname.exe",
    "ipconfig.exe",
    "nbtstat.exe",
    "net.exe",
    "net1.exe",
    "netsh.exe",
    "netstat.exe",
    "nslookup.exe",
    "ntdsutil.exe",
    "reg.exe",
    "rundll32.exe",
    "sc.exe",
    "schtasks.exe",
    "systeminfo.exe",
    "tasklist.exe",
    "tracert.exe",
    "ver.exe",
    "wevtutil.exe",
    "whoami.exe",
    "wmic.exe",
    "wscript.exe"
  })

How to detect suspicious React2Shell (CVE-2025-55182) requests

Most React2Shell exploits work by sending special HTTP headers. 

• In Next.js apps, this header is next-action. 

• In other apps, it may be rsc-action-id. 

Some public exploit PoCs also exfiltrate data using query parameters during redirects. In Next.js, these values appear in the x-action-redirect response header. 

Capturing these headers with Dynatrace OneAgent

Dynatrace OneAgent can record these headers as custom request attributes. For setup and configuration instructions, go to Capture request attributes based on web request data.

Use the following settings: 

1. For next-action or rsc-action-id 
   1. Data source: HTTP request header 
   2. Capture on: Server side 
2. For x-action-redirect 
   1. Data source: HTTP response header 

We recommend setting multi-value capture to “All distinct values.” 

If real-time updates are disabled in Dynatrace, make sure to restart all affected processes so the changes can take effect. 

Capturing headers with OpenTelemetry

If you’re using OpenTelemetry instead of OneAgent, you can also capture the same request and response headers. (See: https://opentelemetry.io/docs/zero-code/java/agent/instrumentation/http/) 

Detect suspicious requests using DQL

In both cases, you can use the following DQL queries to fetch all the requests that use one of the relevant headers. 

fetch spans

// Filter for relevant spans coming from a nodejs agent or via OpenTelemetry,
// which are a server span for a POST request
| filter (dt.openpipeline.source == "oneagent" AND dt.agent.module.type == "nodejs") OR
    dt.openpipeline.source == "/api/v2/otlp/v1/traces"
| filter span.kind == "server"
| filter http.request.method == "POST"

// update the values on the right hand side to use the name of the request attribute configured
| fieldsRename request_attribute.next_action_header = `request_attribute.next-action header`
| fieldsRename request_attribute.rsc_action_id_header = `request_attribute.rsc-action-id header`
| fieldsRename request_attribute.x_action_redirect_header = `request_attribute.x-action-redirect header`

// Collect all spans with one of the relevant headers set
| filter
    isNotNull(`http.request.header.next-action`) OR
    isNotNull(request_attribute.next_action_header) OR
    isNotNull(`http.request.header.rsc-action-id`) OR
    isNotNull(request_attribute.rsc_action_id_header)

// Collect all unique action IDs from each request into a single field
| fieldsAdd action_id = arrayDistinct(
    arrayRemoveNulls(
      arrayConcat(
        array(
          `http.request.header.next-action`,
          `http.request.header.rsc-action-id`
        ),
        arrayFlatten(array(request_attribute.next_action_header)),
        arrayFlatten(array(request_attribute.rsc_action_id_header))
      )
    )
  )
| expand action_id

// Collect action redirect response header values
| fieldsAdd action_redirect = arrayDistinct(
    arrayRemoveNulls(
      arrayConcat(
        array(`http.response.header.x-action-redirect`),
        arrayFlatten(array(request_attribute.x_action_redirect_header))
      )
    )
  )

// Count usage for each action ID per process group
| summarize {
    count = count(),
    actor.ips = arrayDistinct(arrayRemoveNulls(collectDistinct(client.ip))),
    traces = collectDistinct(trace.id),
    action_redirects = arrayDistinct(arrayRemoveNulls(arrayFlatten(collectDistinct(action_redirect))))
  },
  by: {
    action_id,
    dt.entity.process_group
  }

| fieldsAdd dt.process_group.name = entityName(dt.entity.process_group)

Review the results for requests that use suspicious action IDs. Many public exploit PoCs set the next-action header to a static value, such as “x”.

You can also review the x-action-redirect header values for suspicious values.

Detecting Crypto Miners After React2Shell Exploitation

Attackers exploiting the React2Shell vulnerability commonly deploy cryptocurrency miners on compromised systems. These miners consume significant CPU resources, meaning an affected application or service will often show abnormally high CPU usage shortly after exploitation. 

To proactively hunt for this activity, you can correlate observability data (such as CPU metrics) with vulnerability data in a single DQL query. This approach helps identify workloads that are both: 

1. Vulnerable to React2Shell, and 
2. Exhibiting sudden or sustained CPU spikes consistent with crypto-mining behavior. 

Below is an example query pattern you can use. Adjust the metrics, thresholds, and entity types to fit your environment and detection strategy. 

timeseries sum(dt.kubernetes.container.cpu_usage, default: 0, rollup: sum, rate: 1m), nonempty: true, by:{dt.entity.container_group_instance}

| join [
    fetch dt.entity.software_component
      | fieldsAdd vulnerable =  if(in(entity.name, {
          "react-server-dom-parcel:19.0",
          "react-server-dom-parcel:19.1.0",
          "react-server-dom-parcel:19.1.1",
          "react-server-dom-parcel:19.2.0",
          "react-server-dom-webpack:19.0",
          "react-server-dom-webpack:19.1.0",
          "react-server-dom-webpack:19.1.1",
          "react-server-dom-webpack:19.2.0",
          "react-server-dom-turbopack:19.0",
          "react-server-dom-turbopack:19.1.0",
          "react-server-dom-turbopack:19.1.1",
          "react-server-dom-turbopack:19.2.0"
          }), true)
    
    // Make sure to check if the found next version is vulnerable   
    | fieldsAdd potentially_vulnerable = 
        startsWith(entity.name, "next:14.3.0") or
        startsWith(entity.name, "next:15") or
        startsWith(entity.name, "next:16")
    
    | filter
        vulnerable == true or
        potentially_vulnerable == true
    
    | fieldsAdd dt.entity.process_group_instance = belongs_to[dt.entity.process_group_instance]
    | expand dt.entity.process_group_instance

    | join [
       fetch dt.entity.process_group_instance
      | fieldsAdd dt.entity.container_group_instance = belongs_to[dt.entity.container_group_instance]   
    ],
    on: { left[dt.entity.process_group_instance] == right[id]},
    fields: { dt.entity.container_group_instance }
], 
on: { dt.entity.container_group_instance }

Take action now

CVE-2025-55182 poses a critical threat to organizations using React Server Components in production, as public exploits are already available and actively being used.

Here’s what you should do immediately:

1. Audit your environment. Identify all applications using React Server Components, Next.js, or related frameworks.
2. Upgrade dependencies. Apply the patched versions listed in the mitigation section above.
3. Verify remediation. Use Dynatrace Runtime Vulnerability Analytics or similar tools to confirm vulnerable packages have been eliminated.
4. Monitor continuously. Implement ongoing vulnerability scanning to catch issues before they become incidents.

The combination of critical severity, default exploitability, and widespread framework adoption makes this vulnerability a top priority for security and development teams. Take action today to protect your applications and infrastructure.

The post CVE-2025-55182: React2Shell Critical Vulnerability — what it is and what to do appeared first on Dynatrace news.

What is the NGINX vulnerability IngressNightmare?

Recently, researchers discovered a series of vulnerabilities in the Ingress NGINX Controller for Kubernetes, referred to as #IngressNightmare. These vulnerabilities, identified as CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, and CVE-2025-1974, allow unauthenticated remote code execution (RCE) and unauthorized access to secrets stored across all namespaces in a Kubernetes cluster. This could be further exploited to result in a complete cluster takeover due to the privileged nature of such controllers. The highest-scored vulnerability, CVE-2025-1974, carries a critical CVSS v 3.1 base score of 9.8.

The Ingress NGINX Controller is widely used to expose Kubernetes applications externally, making it a critical component for many organizations. Based on the researcher’s analysis, 43% of cloud environments could be affected by this combination of vulnerabilities.

How does an exploit of the IngressNightmare vulnerabilities work?

An attacker can achieve remote code execution (RCE) by chaining multiple flaws in the NGINX implementation if the admission webhook of the ingress-nginx controller is accessible to the attacker without authentication.

1. First, an attacker can upload a file to the NGINX instance itself, which stores large files in a temporary directory. To prevent immediate clean-up, the Content-Length header is manipulated to make the process think the file upload is not completed yet. This allows an attacker to upload any file to the filesystem and to keep it around for long enough for the next steps to execute.
2. The second flaw that is being exploited is the process of the ingress controller to test arbitrary admission templates via the nginx NGINX -t command. This command is vulnerable to injections in multiple variations, which allows an attacker to invoke a set of directives. One of these directives is the ssl_engine directive that allows the loading of a shared library into the running process.

Putting one and two together, with the ability to upload any file to a temporary directory and keeping it around for long enough to invoke a directive to load the file as a shared library, an attacker can inject arbitrary code and take over the deployment. From there it is only a matter of time for them to find additional secrets mounted in this usually highly privileged controller and take over the whole Kubernetes cluster.

What is affected by the NGINX vulnerability?

Any publicly exposed deployment of the ingress-nginx controller in version v1.12.0 or <1.11.5 could potentially be affected by these vulnerabilities. Kubernetes has released patches for version 1.11.6 and 1.12.1 that remediate all found vulnerabilities.

Detecting vulnerable instances of ingress-nginx

Using DQL you can quickly generate a list of ingress-nginx instances including versions being used, cluster and namespace information, and IP addresses being used by the service. Please see the sample queries appendix for an example query to get started.

Furthermore, using the DQL function ipIsPublic, it’s possible to filter directly on services having public IPs, which can be an indicator of attackers’ reachability. Check out the Network functions topic in the Dynatrace docs to learn more about the command.

Detecting post-exploitation activity using Kubernetes audit logs

One reason the severity of this vulnerability is so critical is because of the comprehensive permissions granted to the service account used by ingress-nginx. A ClusterRole called ingress-nginx is configured along with other components. As you can see in the following example, the ClusterRole grants permissions to list, secrets, configmaps, and other resources:

<...> 
rules: 
- apiGroups: 
 - "" 
 resources: 
 - configmaps 
 - endpoints 
 - nodes 
 - pods 
 - secrets 
 - namespaces 
 verbs: 
 - list 
 - watch 
<...>

An attacker that successfully triggers a remote code execution could use these permissions to access possibly sensitive data. Using DQL it’s possible to query Kubernetes audit logs about recent activities of the service account. You can find an example query in the sample queries appendix.

This can potentially surface signs of compromise, like:

• Abnormal user agents like curl, kubectl and others
• Requests to get or list all secrets or configmaps of the entire cluster (for example, no namespace is defined in the requests)

Sample queries appendix: Identify affected instances and analyze access patterns

Use the following queries to find affected instances of Ingress NGINX Controller for Kubernetes.

Sample query to list instances of ingress-nginx in the environment

fetch dt.entity.cloud_application 
| fieldsFlatten cloudApplicationLabels 
| fieldsFlatten kubernetesAnnotations 
| fieldsFlatten balanced_by 
| filter matchesValue(cloudApplicationLabels[`app.kubernetes.io/name`], "*ingress-nginx*") 
| expand balanced_by.dt.entity.kubernetes_service 
 
| join [ 
  fetch dt.entity.kubernetes_service 
  | fieldsFlatten kubernetesAnnotations 
  | fieldsAdd cloudNetworkServiceType 
  | fieldsAdd ipAddress 
  | expand ipAddress 
  | fieldsFlatten kubernetesLabels 
 ], 
  kind:leftOuter,  
  on:{left[balanced_by.dt.entity.kubernetes_service] == right[id]} 
 
| fieldsFlatten clustered_by 
 
| join [ 
  fetch dt.entity.kubernetes_cluster 
 ],  
  kind:leftOuter,  
  prefix: "k8scluster.",  
  on:{left[clustered_by.dt.entity.kubernetes_cluster] == right[id]} 
 
| summarize  
  {count = count(),  
  ipAddresses=collectDistinct(right.ipAddress)},  
 by: { 
  version = `cloudApplicationLabels.app.kubernetes.io/version`,  
  workload.name = `cloudApplicationLabels.app.kubernetes.io/name`,  
  namespace.name = `right.kubernetesAnnotations.meta.helm.sh/release-namespace`,  
  cluster.name = `k8scluster.entity.name`} 
 
| sort version desc

Sample query to analyze access patterns of the service account

fetch logs, from: -7d 
 
| parse content, "JSON{JSON{STRING+:log}(flat=true):properties}(flat=true)", 
 parsingPrerequisite: ( 
  azure.resource.type == "MICROSOFT.CONTAINERSERVICE/MANAGEDCLUSTERS" and  
  log.source == "kube-audit") 
| fieldsAdd content=coalesce(properties, content) 
 
| parse content, "JSON{ 
  STRING+:kind, 
  STRING+:apiVersion, 
  STRING+:level, 
  STRING+:auditID, 
  STRING+:stage, 
  STRING+:requestURI, 
  STRING:verb, 
  JSON:user, 
  JSON_ARRAY{ipaddr}(typed=true):sourceIPs, 
  STRING+:userAgent, 
  JSON:objectRef, 
  JSON:responseStatus, 
  TIMESTAMP('yyyy-MM-ddTHH:mm:ss.SZ'):requestReceivedTimestamp, 
  TIMESTAMP('yyyy-MM-ddTHH:mm:ss.SZ'):stageTimestamp, 
  JSON:annotations 
 }(flat=true)" 
 
| filter  
  apiVersion == "audit.k8s.io/v1" and 
  user[username] == "system:serviceaccount:ingress-nginx:ingress-nginx" and 
  in(verb, {"list", "get"}) and 
  in(objectRef[resource], {"configmaps", "secrets"}) 
 
| summarize {  
  count = count(),  
  start_time = takeMin(timestamp), 
  end_time = takeMax(timestamp), 
  resources = collectDistinct(objectRef[resource]), 
  verbs = collectDistinct(verb) 
 }, by: {  
  user[username], 
  user[uid], 
  userAgent 
 }

How to remediate clusters affected by the NGINX vulnerability

If your Kubernetes cluster is impacted, it’s recommended to upgrade the ingress-nginx controller to a patched version to mitigate the vulnerability. Follow these links to upgrade to one of the following secure releases:

• v1.12.1 or later (Helm chart version 4.12.1 or later)
• v1.11.5 or later (Helm chart version 4.11.5 or later)

If upgrading isn’t immediately possible, make sure the admission webhook is not exposed to the public internet. At a minimum, it should be restricted to private access—ideally limited solely to the control plane (API server).

Next steps for mitigating IngressNightmare

The IngressNightmare vulnerabilities—especially CVE-2025-1974 with its critical CVSS score of 9.8—highlight the high stakes of Kubernetes security. This vulnerability enables unauthenticated remote code execution via a trusted component, making even default configurations risky, as any pod can access the vulnerable webhook internally.

To mitigate the threat, teams should immediately upgrade ingress-nginx to a patched version or enforce strict network access controls.

Given Kubernetes is a backbone in many production environments, ingress components should be treated as critical, high-value assets, with continuous monitoring through a platform like Dynatrace that can detect it in runtime environments and help promptly respond to potential exploitation.

The post NGINX vulnerability: Quickly detect and mitigate IngressNightmare vulnerabilities with Dynatrace appeared first on Dynatrace news.