CVE-2025-55182 exposure in React Server apps raises patch urgency

At a glance

What this is: This is an analysis of active exploitation of CVE-2025-55182 in React Server and Next.js apps, with practical indicators for identifying vulnerable exposure and attack activity.

Why it matters: It matters to IAM practitioners because vulnerable application paths can become the entry point for privilege abuse, secrets exposure, and downstream identity compromise when runtime trust is weaker than patch velocity.

👉 Read Expel's analysis of CVE-2025-55182 exploitation in React Server apps

Context

Server-side application vulnerabilities become an identity risk when they expose processes, tokens, or internal trust boundaries that attackers can abuse after initial code execution. In this case, the primary problem is not only remote code execution, but the speed at which public exposure, proof-of-concept weaponisation, and broad scanning collapse the time available to patch React Server and Next.js deployments.

For identity and access programmes, the relevance is indirect but real. An exploitable application tier can become a pivot point into service accounts, secrets, orchestration layers, and cloud workloads, especially where runtime controls and asset inventory are incomplete. That makes this more than a vulnerability management story, and the starting position is typical of internet-facing app risk rather than an isolated edge case.

Key questions

Q: What breaks when a server-side framework vulnerability is not patched quickly?

A: The main failure is that the application runtime becomes the attacker’s execution path before defenders can separate legitimate from malicious requests. Once code executes inside the server process, the attacker can pivot into secrets, internal services, and downstream systems that were assumed to be trusted. Fast patching matters because exposure windows shrink rapidly once proof-of-concepts circulate.

Q: Why do old application frameworks increase identity and secrets risk?

A: Old frameworks often survive alongside old deployment patterns, long-lived API keys, and fragile CI/CD secrets. As patch support fades, teams keep compensating with manual processes, which increases the chance that privileged machine identities remain active longer than intended. That is where application lifecycle becomes an identity governance problem.

Q: How do security teams know if exploitation is happening in ingress traffic?

A: Look for request patterns that match internal framework behaviour rather than normal client traffic. In this case, suspicious headers, serialized payload fragments, internal status flags, and unexpected function-constructor references are stronger signals than IP-based blocking. That approach helps when multiple actors are using the same exploit path.

Q: Who is accountable when a vulnerable application framework is exposed to the internet?

A: Accountability usually spans engineering, platform, and security operations. Engineering owns patching and release validation, platform teams manage exposure and deployment controls, and security teams verify risk acceptance only after reachability, version state, and monitoring are all confirmed.

Technical breakdown

How React Server request handling becomes an execution path

React Server Components and Next.js process specially structured requests that are meant to separate client traffic from server-side behaviour. In CVE-2025-55182, the exploit path abuses deserialisation and request parsing so attacker-controlled input can reach server execution logic. Once the application interprets crafted payloads as trusted framework data, the attacker no longer needs to break the web layer in a traditional sense. The code runs as a child of the application process, which means the attack inherits the runtime context of node.exe and whatever local privileges that process already has.

Practical implication: patch every exposed React Server and Next.js deployment before relying on detection.

Why ingress logs matter more than atomic indicators

When exploitation spreads quickly, hashes and IP addresses stop being durable hunting leads because many different actors reuse the same vulnerable path. The better signal is request structure. Suspicious headers such as next-action and Rsc-action-id, together with payload fragments like $@, then followed by function constructors, and internal-style flags such as resolved_model, indicate the attacker is trying to impersonate trusted server-side traffic. That makes the application gateway and ingress logs a more reliable source of truth than a static indicator list.

Practical implication: build detections from request semantics and internal protocol misuse, not just blocklists.

What child-process execution tells defenders about blast radius

This vulnerability behaves like webserver exploitation because the attacker’s payload is spawned from the application process itself. That means the first successful execution step is often already inside a trusted runtime boundary, which compresses the distance between initial compromise and post-exploitation activity. If the application can reach local files, cloud metadata, deployment secrets, or internal services, the exploit can move from code execution into credential discovery and lateral access. The technical issue is therefore not only remote code execution, but runtime trust collapse.

Practical implication: review what the application process can reach before and after patching to limit post-exploit access.

Threat narrative

Attacker objective: The attacker’s objective is to gain arbitrary code execution inside exposed applications and use that foothold to expand into connected systems or sensitive data.

1. Entry occurs when attackers send crafted React Server or Next.js requests that trigger vulnerable deserialisation and request handling paths.
2. Escalation follows when attacker-controlled code executes as a child process of node.exe, inheriting the application runtime context.
3. Impact comes when that runtime context is used to discover secrets, access internal services, or establish a broader foothold for follow-on compromise.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Gravity SMTP CVE-2026-4020 API Keys Exposure — CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime exploitation in application frameworks is now an identity-adjacent risk because the first trusted boundary is often the process that holds secrets. When attacker code runs inside the same runtime as the application, the real question becomes what identities, tokens, and internal services that process can reach. That shifts the governance discussion from application patching alone to blast-radius control across secrets, service accounts, and workload permissions.

Atomic indicators lose value quickly when exploitation becomes commodity within days. Expel’s reporting shows why hunting by hash or source IP is insufficient once proof-of-concepts are circulating broadly. Security teams need detections that reflect protocol misuse and internal-state abuse, because attackers can rotate infrastructure faster than many defenders can update signatures.

Application runtime compromise exposes a hidden privilege problem inside modern delivery pipelines. The code itself is rarely the end state; the real risk is what the process can inherit through environment variables, mounted secrets, cloud metadata access, and delegated API permissions. That makes secret minimisation and runtime scoping part of vulnerability response, not a separate hygiene exercise.

Asset discovery is a control, not a support task, when framework vulnerabilities spread this fast. Organisations that cannot rapidly enumerate React Server and Next.js usage will miss less common implementations and embedded dependencies. A vulnerability management programme that cannot see the full application estate will always lag the attacker’s view of exposure.

Framework exploitation should be treated as a governance failure when patch status and exposure status diverge. The named concept here is runtime trust collapse: a condition where a trusted server process becomes the attacker’s execution vehicle before controls can distinguish legitimate from malicious behaviour. Practitioners should treat this as a signal to map process privilege, secret access, and detection coverage together.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• The same visibility gap that obscures third-party OAuth access also applies to workload pathways, so NHI Lifecycle Management Guide becomes the next step for inventory and offboarding discipline.

What this signals

Runtime trust collapse: when framework code can execute attacker input inside a trusted process, identity and secrets controls must be designed for compromise inside the boundary, not only at the boundary. That means runtime scoping, credential minimisation, and egress control become more important than assuming the application tier is inherently safe.

Teams should expect framework exploitation to keep collapsing the time between disclosure and active attack, which makes exposure management and detection engineering a single problem. If the organisation cannot enumerate where a vulnerable framework runs, it cannot credibly claim to control its identity-adjacent blast radius.

For practitioners

• Patch exposed React Server and Next.js instances first Prioritise internet-facing systems, then audit less common applications and embedded implementations that use the same framework components. Treat unpatched exposure as a critical remediation queue item, not a routine vulnerability ticket.
• Scan cloud and on-prem estates for vulnerable framework usage Use vulnerability scanners across hosted and on-prem environments to identify applications running React Server or Next.js, including shadow deployments and inherited dependencies that are not obvious from the primary application inventory.
• Create ingress detections for protocol misuse Alert on suspicious headers such as next-action and Rsc-action-id, and on payload patterns including $@, resolved_model, then with function constructors, and serialized command references in request bodies.
• Review post-exploit reach from the application process Map what node.exe or the equivalent application runtime can access, including secrets, local files, metadata services, and internal APIs, then reduce that access to the minimum required for operation.

Key takeaways

• CVE-2025-55182 shows how a framework flaw can turn a trusted application process into the attacker’s execution vehicle.
• The exploit changes the defender’s problem from signature hunting to rapid asset discovery, ingress log analysis, and runtime blast-radius reduction.
• Identity teams should care because application compromise often becomes secrets exposure and service-account abuse before it becomes a broader breach.

Key terms

• Release Trust Collapse: A failure mode where teams assume the package publisher, signing path, and build pipeline are trustworthy when one or more of those identities has been compromised. The result is that malicious code can inherit legitimacy and pass controls that only inspect artefacts, not the trust chain behind them.
• Ingress Log Hunting: The practice of searching inbound request logs for protocol misuse, suspicious headers, and payload structures that indicate exploitation. It is especially useful when attackers share the same vulnerability but use different infrastructure, making static indicators less reliable.
• Framework Exposure Inventory: A complete view of where a software framework is deployed, including embedded, inherited, and less obvious implementations. Without this inventory, organisations cannot reliably patch, monitor, or prove coverage when a framework vulnerability is under active exploitation.

What's in the full analysis

Expel's full analysis covers the operational detail this post intentionally leaves for the source:

• Specific ingress log examples that show how the exploit appears in real traffic patterns
• The vendor's guidance on identifying less common React Server and Next.js implementations across environments
• Notes on how scanners and monitoring were used to track exposure and remediation status
• Reference links to additional third-party deep dives and live tracking resources

👉 Expel's full post covers ingress patterns, scanning guidance, and active exploitation indicators in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps security and identity practitioners connect runtime exposure to access control and lifecycle decisions.