Which versions of Next.js are affected by EUVD-2026-49571?

Vercel Next.js framework versions 14.1.1-15.5.20 and 16.0.0-16.2.10 contain a server-side request routing vulnerability that allows attackers to redirect internal application traffic to external…. A patch is available.

How to fix or mitigate EUVD-2026-49571?

Within 24 hours, inventory all Next.js deployments and document their versions across production and non-production environments. Within 7 days, apply the vendor patch to development and staging systems to validate functionality; if immediate patching poses operational risk, implement host header pinning at your reverse proxy or load balancer as an interim control. Within 30 days, complete production rollout of the vendor patch to all affected Next.js instances, document patch versions applied to each system, and confirm host-header validation remains active post-patch.

Next.js EUVD-2026-49571

Q: What is the CVSS score of EUVD-2026-49571?

EUVD-2026-49571 has a CVSS 4.0 base score of 8.3 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.6%.

| CVE-2026-64649 HIGH

Server-Side Request Forgery (SSRF) (CWE-918)

2026-07-22 https://github.com/vercel/next.js

GHSA-89xv-2m56-2m9x

SSRF Red Hat

8.3

CVSS 4.0 · Vendor: https://github.com/vercel/next.js

Severity by source

Vendor (https://github.com/vercel/next.js) PRIMARY

8.3 HIGH

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

6.5 MEDIUM

Unauthenticated network attack (PR:N), but AC:H reflects the required non-default configuration where the Host header is not pinned; high confidentiality from internal-value disclosure, low integrity, no availability impact.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N

4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N

Red Hat

8.2 HIGH

qualitative

Primary rating from Vendor (https://github.com/vercel/next.js).

CVSS VectorVendor: https://github.com/vercel/next.js

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Analysis Updated

Jul 27, 2026 - 20:28 vuln.today

v2 (cvss_changed)

Re-analysis Queued

Jul 27, 2026 - 20:22 vuln.today

cvss_changed

CVSS changed

Jul 27, 2026 - 20:22 NVD

8.3 (HIGH)

Source Code Evidence Fetched

Jul 22, 2026 - 23:32 vuln.today

Analysis Generated

Jul 22, 2026 - 23:32 vuln.today

CVE Published

Jul 22, 2026 - 23:09 cve.org

HIGH

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

15,765 npm packages depend on next (1,508 direct, 14,296 indirect)

Ecosystem-wide dependent count for version 14.1.1.

DescriptionCVE.org

Impact

When a Server Action forwards or redirects a request, an attacker can cause the server to send that outbound request to a malicious host (Server-Side Request Forgery). This requires the attacker's request to control Host-associated headers. In some configurations, it's also possible to obtain internal values that weaken middleware/proxy authorization.

Applications that use Server Actions are affected when the incoming host header is not fixed to a trusted value. This typically occurs on custom servers, or on deployments not behind a proxy that pins the host. Managed hosting pins the host upstream and is not affected; next start and standalone output do the same from version 14.2 onward.

Workarounds

If you cannot upgrade, ensure clients do not control the host header your application receives. Pin or validate Host and X-Forwarded-Host at your edge or proxy. On version 14.2.0 and later, you can additionally set the __NEXT_PRIVATE_ORIGIN environment variable to your deployment's real origin:

bash

__NEXT_PRIVATE_ORIGIN=https://www.example.com node server.js

AnalysisAI

Server-Side Request Forgery in the Vercel Next.js framework (versions 14.1.1 through 15.5.20 and 16.0.0 through 16.2.10) lets a remote attacker who controls Host-associated headers coerce a Server Action's forwarded or redirected request to an attacker-chosen host, and in some setups leak internal values that weaken middleware/proxy authorization. Exploitation is limited to deployments where the incoming Host header is not pinned to a trusted value - typically custom servers or setups not fronted by a host-pinning proxy. There is no public exploit identified at time of analysis, EPSS is low (0.62%, 46th percentile), and CISA SSVC rates exploitation as 'none' with partial technical impact.

Technical ContextAI

Next.js is a widely used React-based full-stack web framework (npm package 'next', CPE pkg:npm/next). The flaw is CWE-918 (Server-Side Request Forgery) in the App Router Server Actions handler (packages/next/src/server/app-render/action-handler.ts). When a Server Action forwards a response (createForwardedActionResponse) or issues a redirect (createRedirectRenderResult), the server derived the outbound request origin from the client-supplied Host header (${proto}://${host.value}) unless the __NEXT_PRIVATE_ORIGIN environment variable was set. Because the origin was reconstructed from attacker-influenceable Host/X-Forwarded-Host headers, an attacker could redirect the server's internal outbound request. The patch removes reliance on the request-derived host and instead resolves the origin from the framework's trusted initURL request metadata, throwing an InvariantError ('Missing initURL') or an origin-determination error rather than trusting client headers.

RemediationAI

Vendor-released patch: upgrade to Next.js 15.5.21 (for the 14.1.1-15.5.x line, https://github.com/vercel/next.js/releases/tag/v15.5.21) or 16.2.11 (for the 16.x line, https://github.com/vercel/next.js/releases/tag/v16.2.11); fixes are in commits b51206321854193208c0805ba42acc49287f942b and e3e5666ccead3a15162793d697af5e48b7cc0498. If you cannot upgrade immediately, ensure clients cannot control the Host header your application receives by pinning or validating both Host and X-Forwarded-Host at your edge or reverse proxy (trade-off: requires correct proxy configuration and can break multi-tenant/virtual-host setups if over-restrictive). On version 14.2.0 and later you can additionally set the __NEXT_PRIVATE_ORIGIN environment variable to your deployment's real origin (e.g. __NEXT_PRIVATE_ORIGIN=https://www.example.com node server.js), which forces a trusted origin but is a private/undocumented variable slated for removal, so treat it as a stopgap and still plan the upgrade. See the advisory at https://github.com/vercel/next.js/security/advisories/GHSA-89xv-2m56-2m9x.