React Server Components RCE vulnerability advisory

A critical authentication-bypass flaw in the Next.js middleware layer — tracked as CVE-2025-29927 — reopened a hard question for every team building on React Server Components (RSC): what happens when the one chokepoint you trusted to gate access to your server-rendered application logic can be walked around with a single forged HTTP header? In vulnerable deployments, an unauthenticated attacker can set x-middleware-subrequest on a normal request and cause Next.js to skip middleware execution entirely — silently disabling the authorization checks, bot filtering, and route protection that many teams implement at that layer. Chained with an exposed admin route, an insecure Server Action, or a vulnerable dependency reachable once auth is bypassed, that gap becomes a direct path to full remote code execution on the server process rendering your React tree. That escalation chain is why security teams have been referring to this, loosely but not inaccurately, as the "React Server Components RCE" issue of 2025 — and why it deserves a proper advisory rather than a footnote.

What's actually vulnerable

Next.js's App Router uses a single middleware.ts file that runs before a request reaches a route handler or a React Server Component. Teams commonly use it to enforce authentication, redirect unauthenticated users, apply feature flags, or gate access to internal tooling — logic that, in a traditional server framework, would live behind a dedicated auth layer.

The x-middleware-subrequest header exists internally so Next.js can recognize when middleware is re-invoking itself (to avoid infinite loops during internal rewrites). CVE-2025-29927 arises because Next.js trusted that header when it arrived from the outside, not just from its own internal subrequests. An attacker who sets it directly on an inbound request can trick the framework into believing middleware has already run, causing it to be skipped outright. Every check that lived exclusively in middleware — session validation, role checks, IP allow-listing — simply never executes.

On its own, this is an authorization bypass. Its severity comes from what it exposes: internal API routes, admin dashboards, feature-flagged Server Actions, and any RSC payload that assumed middleware had already filtered out anonymous traffic. Several public write-ups demonstrated that once past the gate, attackers could reach Server Actions or internal endpoints with insufficient defense-in-depth of their own, turning an auth bypass into arbitrary command execution on the host.

Affected versions and components

The vulnerability affects self-hosted Next.js applications (both App Router and, to a lesser extent, hybrid setups) using middleware for security decisions:

• Next.js < 12.3.5
• Next.js 13.0.0 – 13.5.8
• Next.js 14.0.0 – 14.2.24
• Next.js 15.0.0 – 15.2.2

Patched releases: 12.3.5, 13.5.9, 14.2.25, and 15.2.3.

A few scoping notes that matter for triage:

• Impact is highest for self-hosted deployments — behind a custom reverse proxy, in a Node.js server, in Docker/Kubernetes, or on non-Vercel edge platforms. Vercel's own edge network already stripped this header before it reached application code, which meaningfully limited real-world blast radius for apps hosted there.
• Apps that don't use middleware for authorization are not directly impacted by this specific header trick, but should still patch — middleware is used for enough adjacent security logic (CSRF checks, geofencing, WAF-style filtering) that skipping it is rarely benign.
• RSC and Server Actions are the amplifier, not the root cause. The header bypass is a Next.js routing bug; the RCE-class outcomes reported by researchers came from chaining it with separately weak authorization inside Server Actions or internal API routes that assumed middleware had already screened the caller.

Severity: CVSS, EPSS, and KEV context

The GitHub Security Advisory for CVE-2025-29927 was assigned a CVSS v3.1 base score of 9.1 (Critical) — network-exploitable, no privileges required, no user interaction, with high confidentiality and integrity impact reflecting the breadth of what middleware typically protects. That score generated some debate: Vercel's own advisory language argued real-world severity is deployment-dependent, since platforms that already strip the header (their own edge network, several CDNs and WAFs after patching their rules) are not exploitable via the public internet. Treat the 9.1 as the correct number for an unmitigated, self-hosted deployment, and adjust downward only after you've confirmed your specific edge/proxy configuration actually blocks the header.

EPSS scoring moved quickly in the days following disclosure, tracking the release of public proof-of-concept exploit code — a pattern consistent with the mass scanning activity multiple threat intelligence feeds reported within 48 hours of the advisory going public. As of this writing, CVE-2025-29927 has not been formally added to CISA's Known Exploited Vulnerabilities (KEV) catalog, but given the trivial exploitation path and observed internet-wide scanning, defenders should treat active-exploitation risk as high regardless of KEV status — KEV listing tends to lag real-world exploitation, not lead it.

Timeline

• Prior to disclosure: Independent security researchers Rachid Allam (zhero;inzo) and Yasser Allam identified the middleware bypass behavior and reported it to Vercel through a coordinated disclosure process.
• March 21, 2025: Vercel published patched releases (12.3.5, 13.5.9, 14.2.25, 15.2.3) alongside the GitHub Security Advisory for CVE-2025-29927.
• Within days: Public proof-of-concept exploit code appeared on GitHub, dramatically lowering the skill floor for exploitation.
• Following week: Threat intelligence vendors reported internet-wide scanning traffic probing for the vulnerable header behavior, consistent with opportunistic mass exploitation attempts rather than targeted attacks.
• Ongoing: Downstream advisories and blog posts from application security teams continued mapping real-world exploitation chains — from auth bypass into exposed Server Actions, internal admin panels, and in some documented cases, code execution on the underlying host.

Remediation steps

1. Upgrade immediately. Move to 12.3.5, 13.5.9, 14.2.25, or 15.2.3 (or later) across every service — not just customer-facing ones. Internal tools and admin dashboards built on Next.js are frequently the most under-patched and the most damaging to lose.
2. If you can't patch immediately, strip the header at the edge. Configure your reverse proxy, load balancer, or WAF to drop any inbound x-middleware-subrequest header before it reaches your Next.js origin. This is a mitigation, not a fix — patch as soon as you can.
3. Stop treating middleware as your only authorization layer. Re-enforce access control at the data layer, inside Server Actions, and in route handlers themselves. Middleware should be defense-in-depth, not the sole gate — this incident is a direct argument for not collapsing your entire authz model into one file.
4. Audit every Server Action and internal API route for what it assumes about the caller. Any endpoint that would be dangerous if reached anonymously needs its own explicit check, independent of routing-layer assumptions.
5. Review access logs for anomalous use of the header and for authenticated-looking activity that doesn't correlate with a real session — a common signature of successful bypass attempts.
6. Rotate session secrets and force re-authentication if log review suggests exploitation may have occurred, and extend the same review to any downstream systems reachable from the bypassed routes.

How Safeguard Helps

Patch advisories are only actionable once you know where you're exposed, and CVE-2025-29927's severity is genuinely deployment-dependent — which makes blanket CVSS scores a poor prioritization signal on their own. Safeguard's reachability analysis traces whether your specific middleware configuration actually enforces authorization on a code path an unauthenticated request could reach, so you're not triaging by version number alone. Griffin AI correlates that reachability signal with your real Server Action and route-handler logic to flag the specific chains — an exposed admin route, an under-guarded Server Action — that turn this bypass into an RCE-class incident, and ranks them ahead of instances where the header is already stripped upstream. SBOM generation and ingestion give you a fleet-wide inventory of every internal, admin, and customer-facing service still running an affected Next.js version, including ones your team forgot were RSC-based. And when it's time to act, Safeguard opens auto-fix pull requests that bump the framework to a patched release and pin a safe version range, so remediation ships at the speed the exploitation timeline demands rather than at the speed of a manual audit.