Critical RCE in React and Next.js expands web app exposure

At a glance

What this is: This is a vulnerability alert about a critical remote code execution issue in React and Next.js that can expose server-side application control.

Why it matters: It matters because framework-level RCE in internet-facing applications can bypass normal web-layer assumptions and force IAM, cloud, and application teams to coordinate containment, patching, and privilege review.

👉 Read Hadrian's vulnerability alert on CVE-2025-55182 in React and Next.js

Context

Critical remote code execution in a widely used web framework is not just an application security issue. When an internet-facing stack can be driven into server-side execution, the governance problem extends to cloud access, secrets exposure, service identity, and the speed at which teams can isolate affected workloads. In practice, the question is not whether a vulnerability exists, but how quickly an exposed application can be reached and abused before remediation lands.

For IAM and NHI practitioners, the identity angle appears when application compromise becomes a path to credentials, tokens, service accounts, or downstream APIs. Web application flaws often become privilege problems because the compromised runtime inherits access that was never meant for attackers. That makes this kind of alert relevant to application security, workload identity, and secrets management rather than just patch management.

Key questions

Q: What should teams do first when a critical RCE affects an internet-facing web framework?

A: Contain the vulnerable service before assuming patching alone is enough. Isolate exposed workloads, block unnecessary egress, and rotate any secrets the runtime could access. If the application can reach internal APIs, metadata services, or secret stores, treat the host as a potential pivot point and verify whether the exploit was already used.

Q: Why do macOS malware campaigns often become an identity and access problem?

A: Because many campaigns abuse session authority, user approval, or privileged execution to reach their objective. Once a malicious app inherits a trusted workflow, it can steal screenshots, open shells, or capture data without further authentication. That makes the real failure the grant of authority, not only the malware payload itself.

Q: What do security teams get wrong about patching RCE flaws quickly?

A: They often assume the patch closes the entire risk immediately. In reality, any secret or session token exposed before remediation may still be valid, and the attacker may have already established persistence or exfiltrated data. Patching must be paired with credential rotation, log review, and runtime containment.

Q: Which controls matter most after a server-side exploit in a shared web platform?

A: Accountability shifts to the teams that own runtime isolation, secret management, and application privilege design. Least privilege, short-lived credentials, and verified secret rotation are the controls that limit blast radius. Without them, a single framework flaw can become a cloud, data, and IAM incident at the same time.

Technical breakdown

How React and Next.js RCE changes the attack surface

Remote code execution means an attacker can make the server run instructions of their choosing. In a React or Next.js environment, that can affect the application runtime, build pipeline, or server-side rendering path depending on where the flaw sits. Once code execution is available, the issue stops being a simple input validation bug and becomes a platform control problem because the attacker can interact with local files, environment variables, internal services, and authentication material already present in the process context.

Practical implication: treat exposed instances as potentially compromised until patched and isolated.

Why server-side execution often becomes an identity problem

Application servers commonly run with embedded access to APIs, databases, object storage, and internal admin functions. If an attacker gains execution on that host, the identity boundary can collapse because the runtime may hold bearer tokens, signing keys, or service account credentials that were intended only for trusted code. In modern stacks, this is why a web exploit can rapidly become a secrets exposure event, a lateral movement path, or a cloud privilege escalation issue.

Practical implication: review which secrets and service identities are reachable from the affected runtime.

Containment depends on runtime controls, not patching alone

Patch deployment is essential, but it does not by itself remove the abuse window. Teams still need host isolation, egress limits, secret rotation, and telemetry for suspicious process behaviour because an attacker may have already executed code before the fix lands. In practice, the strongest response combines rapid version remediation with revocation of any credentials exposed to the vulnerable application path.

Practical implication: pair patching with credential rotation and network containment in the same change window.

Threat narrative

Attacker objective: The attacker aims to run arbitrary code on the server and turn application access into control over data, credentials, or downstream services.

1. Entry occurs through a critical remote code execution flaw in the exposed React or Next.js application.
2. Escalation follows if the attacker uses the server process to access local secrets, internal APIs, or privileged runtime context.
3. Impact comes from code execution inside the application boundary, which can lead to data theft, service tampering, or broader compromise.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation — Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.

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

NHI Mgmt Group analysis

Critical framework RCE is a blast-radius problem, not just a patching problem. Once a common web framework can be driven into server-side execution, the defender has to assume the application boundary has already failed. That changes how teams think about containment, because the runtime may expose secrets, internal services, and service identities that were never meant to be attacker reachable. For practitioners, patch speed matters, but blast-radius reduction matters just as much.

The identity risk appears when application privileges are inherited, not explicitly granted. Web runtimes often run with broad access to databases, queues, object storage, and internal APIs. If those permissions are tied to the host or deployment rather than to narrowly scoped workload identity, an RCE becomes an identity compromise. That is why IAM, PAM, and workload identity controls need to be part of application vulnerability response, not separate conversations.

Server-side exploitability exposes a hidden trust assumption in modern DevOps pipelines. Teams often assume that code running in production is already trusted and therefore safe to bind to secrets and backend access. A critical RCE breaks that assumption instantly. The better governance model is to treat application runtime as a revocable identity surface with explicit least privilege and fast secret invalidation.

Runtime secrets are the real prize in many framework exploits. Attackers rarely stop at executing a single command when the compromised process can read tokens, signed keys, or cloud credentials. That creates a direct link between application security and NHI governance, because service accounts and API keys become the bridge from one vulnerable host to broader environment access. Practitioners should design for secret exposure, not just code execution.

Framework-level vulnerabilities reward organisations that already practice service isolation. If an application is segmented, uses short-lived credentials, and keeps high-value secrets out of the runtime, an RCE is still serious but less likely to become enterprise-wide compromise. That makes workload identity design, secret minimisation, and egress control the controls that determine whether a vulnerability becomes an incident.

What this signals

A critical framework flaw is a reminder that web application security and identity governance are now tightly coupled. When application runtimes carry secrets and backend permissions, vulnerability response must include credential revocation, service identity review, and workload segmentation, not just code rollout.

Runtime identity exposure window: the period between exploitability and credential invalidation is often where the real damage happens. Teams that can shorten that window with short-lived credentials, segmented permissions, and rapid telemetry correlation will reduce the chance that an RCE becomes an enterprise access incident.

For identity teams, the practical shift is to treat application runtimes as governed identities with lifecycle controls. That means knowing which secrets are attached, who owns them, how quickly they can be rotated, and which internal systems they can reach if the web tier is compromised.

For practitioners

• Isolate affected deployments immediately Quarantine internet-facing React and Next.js workloads that match the vulnerable build path, then verify whether the application can reach internal services, metadata endpoints, or secrets stores from the runtime. If it can, treat the host as a potential pivot point until the exposure window is closed.
• Rotate secrets tied to the application runtime Assume any token, API key, signing secret, or cloud credential accessible to the vulnerable process may be exposed. Rotate those credentials in the same window as patching, and invalidate sessions or back-end trust relationships that depend on them.
• Reduce privilege on web application identities Move away from broad deployment-level access and scope service identities to the smallest set of backend actions the application needs. Where possible, separate build, runtime, and administrative credentials so a single exploit cannot inherit all three trust domains.
• Add telemetry for post-exploit behaviour Look for unusual child processes, outbound connections, file access, and requests to secret-bearing endpoints from the affected service. Correlate this with patch timing so you can distinguish a clean remediation from an exploit that already ran.

Key takeaways

• Critical RCE in a common web framework can quickly become an identity and secrets exposure problem, not just an application bug.
• The real risk is blast radius, because compromised runtimes often hold access that attackers can reuse against internal systems and cloud services.
• Teams should pair patching with secret rotation, privilege reduction, and runtime isolation to keep a code flaw from becoming a broader incident.

Key terms

• LLM Remote Code Execution: A condition where a large language model integration causes arbitrary code to run on the host or backend system. The model is usually not the direct vulnerability. The failure appears when attacker-shaped model output is parsed, trusted, and handed to a dangerous execution path.
• Runtime Secret Visibility: Runtime secret visibility is the ability to observe when and where secrets are accessed while systems are actively running. It matters because static inventories alone do not show whether a tool, workflow, or workload is reading credentials in memory, files, or logs.
• Workload Identity: The identity assigned to a software workload — such as a containerised application, serverless function, or microservice — enabling it to authenticate to other services without storing static credentials.

What's in the full analysis

Hadrian's full vulnerability alert covers the operational detail this post intentionally leaves for the source:

• Affected component and exploit conditions for the React and Next.js issue, including what versions and deployment patterns are most exposed.
• Practical detection and validation steps for determining whether a deployment is reachable through the vulnerable execution path.
• Implementation detail on how defenders should think about runtime secrets, backend permissions, and containment after exposure.
• Related vulnerability context that helps teams compare this issue with other framework-level RCE patterns.

👉 Hadrian's full post covers the exploit context, exposure implications, and remediation considerations in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners connect application exposure to identity controls across cloud and platform teams.