CVE-2025-57822

What it actually does

This is a server-side request forgery risk in self-hosted Next.js applications using affected Next.js Middleware versions. If custom middleware calls next() without explicitly passing the request object, and the application or surrounding proxy stack incorrectly forwards user-controlled headers, attacker-supplied routing or forwarding headers may influence server-side request handling. The practical impact depends on the application’s middleware, proxy, and outbound network access, but may include causing the application server to make requests to unintended internal services, cloud metadata endpoints, loopback interfaces, or trusted backend systems.

Why it matters to the business

Successful exploitation can let an external attacker use a public web application as a bridge into internal network resources that are not directly exposed to the internet. This may lead to disclosure of internal service responses, credential or metadata exposure, bypass of network trust boundaries, or reconnaissance of private infrastructure. The issue is not currently listed in CISA KEV and has a relatively low EPSS score, but exploit maturity is reported as weaponized, so self-hosted Next.js deployments with custom middleware and permissive header forwarding should treat remediation as time-sensitive.

How an attack unfolds

An attacker first identifies a self-hosted Next.js application running an affected version and using custom Middleware. They then send requests containing crafted forwarding-related headers such as Host, Forwarded, X-Forwarded-Host, X-Forwarded-Proto, or similar headers that may be trusted by middleware, application code, or upstream proxies. In vulnerable configurations where next() is called without explicitly preserving the intended request object, these attacker-controlled values can influence server-side request construction or routing. The application server may then initiate requests to attacker-selected destinations, including internal addresses or metadata services reachable only from the server. The attacker observes returned content, timing, status codes, or error behavior to confirm reachability and may iterate to enumerate internal services or extract sensitive responses where the application reflects or processes them.

How to fix it

Upgrade Next.js to a fixed release: v14.2.32 or later for the 14.x line, or v15.4.7 or later for the 15.x line. For source-based tracking, ensure the fix containing commit f30d815859e932e09222e93bb6e8a376b918d874 is present. Audit all custom Middleware that uses next() and update it to explicitly pass the intended request object according to the fixed Next.js guidance. Review reverse proxy, CDN, ingress, and load balancer configurations so that user-supplied forwarding headers are stripped or overwritten at the trust boundary rather than blindly forwarded. Restrict application egress so web servers cannot reach cloud metadata endpoints, loopback-only admin services, or unnecessary private network ranges. Where immediate upgrade is not possible, prioritize compensating controls: sanitize Host, Forwarded, X-Forwarded-Host, X-Forwarded-Proto, X-Forwarded-For, X-Real-IP, and similar headers; enforce an allowlist of expected hostnames; and block outbound requests to internal and link-local addresses from the application runtime.

How to confirm the fix worked

Confirm package versions using package manager output and lockfiles, such as npm ls next, yarn why next, pnpm why next, package-lock.json, yarn.lock, or pnpm-lock.yaml. Verify deployed containers or build artifacts use Next.js v14.2.32 or later, v15.4.7 or later, or include commit f30d815859e932e09222e93bb6e8a376b918d874. Inspect middleware source for next() usage and confirm the request object is explicitly preserved where required. Validate ingress behavior by sending benign test requests with unexpected Host, Forwarded, and X-Forwarded-* values and confirming the application ignores or normalizes them. Review egress controls by confirming the application cannot reach link-local metadata services, loopback-only administrative ports, or unauthorized private network destinations. Add regression tests for middleware routes to ensure crafted forwarding headers do not alter server-side request targets, redirects, rewrites, or backend fetch destinations.

Typical attack path

1. Identify a public self-hosted Next.js application and fingerprint the Next.js version or behavior.
2. Determine whether custom Middleware is present by observing redirects, rewrites, authentication gates, localization routing, or header-dependent behavior.
3. Send requests with crafted forwarding and host-related headers intended to alter the server-side request context.
4. Trigger middleware code paths that call next() without explicitly passing the request object.
5. Cause the server to make or route requests toward unintended internal, loopback, cloud metadata, or attacker-controlled endpoints.
6. Use response content, errors, redirects, DNS callbacks, or timing differences to confirm SSRF behavior.
7. Iterate against internal address ranges or known metadata/service endpoints to collect information or sensitive data where reachable.

How to detect it

To determine whether exploitation already occurred, review edge proxy, CDN, load balancer, web server, and application logs for requests containing unusual Host, Forwarded, X-Forwarded-Host, X-Forwarded-Proto, X-Forwarded-For, X-Real-IP, or similar headers. Look for values referencing loopback addresses, link-local metadata services, RFC1918 private IP ranges, unusual schemes, unexpected ports, or domains not associated with the application. Correlate inbound suspicious requests with outbound application egress logs, DNS resolver logs, VPC flow logs, firewall logs, service mesh telemetry, and cloud metadata service access logs. Key indicators include attempted access to 169.254.169.254, metadata.google.internal, localhost, 127.0.0.1, ::1, internal hostnames, or unexpected private IPs shortly after external requests with crafted forwarding headers. Also inspect application error logs for failed URL parsing, connection refused errors, timeout messages, redirects to internal addresses, or backend fetch failures caused by attacker-controlled host values. If SSRF to cloud metadata endpoints is suspected, review cloud audit logs for use of instance role credentials, unusual token retrieval, or anomalous API calls from the affected workload identity after the suspicious web requests.

• 169.254.169.254
• http://169.254.169.254
• /latest/meta-data/
• /latest/api/token
• metadata.google.internal
• computeMetadata/v1
• Metadata-Flavor: Google
• 169.254.169.254/metadata/instance
• Metadata: true
• 100.100.100.200
• 127.0.0.1
• http://127.0.0.1
• localhost
• http://localhost
• [::1]
• 0.0.0.0
• X-Forwarded-Host: 127.0.0.1
• X-Forwarded-Host: localhost
• X-Forwarded-Host: 169.254.169.254
• X-Forwarded-Proto: http
• Forwarded: host=127.0.0.1
• Forwarded: host=localhost
• Forwarded: host=169.254.169.254
• Host: 169.254.169.254
• Host: localhost
• Connection refused
• ECONNREFUSED 127.0.0.1
• ECONNREFUSED ::1
• ETIMEDOUT 169.254.169.254
• ENOTFOUND metadata.google.internal

What your security team should do

• Inventory all self-hosted Next.js applications, prioritizing internet-facing deployments and applications with custom Middleware.
• Upgrade affected applications to Next.js v14.2.32 or later, v15.4.7 or later, or a build containing commit f30d815859e932e09222e93bb6e8a376b918d874.
• Search code for middleware calls to next() and verify the request object is explicitly passed or handled according to current Next.js guidance.
• Harden reverse proxies, CDNs, and ingress controllers to overwrite or drop untrusted forwarding headers at the edge.
• Implement outbound network restrictions for application runtimes, especially blocking access to 169.254.169.254, loopback, RFC1918 ranges not explicitly required, and internal administrative services.
• Review recent access, application, proxy, DNS, and egress logs for SSRF probing patterns involving metadata endpoints, localhost, private IP ranges, or unusual Host/X-Forwarded-* values.
• Create SIEM detections for suspicious forwarding headers and application egress to link-local or internal-only destinations.
• If suspicious activity is found, rotate potentially exposed cloud instance credentials, service tokens, and secrets accessible from the affected runtime.