CVE-2026-40299: next-intl SSRF Vulnerability

CVE-2026-40299 Overview

CVE-2026-40299 is an Open Redirect vulnerability affecting the next-intl internationalization library for Next.js applications. Applications using the next-intl middleware prior to version 4.9.1 with localePrefix: 'as-needed' configuration could construct URLs where path handling and the WHATWG URL parser resolved a relative redirect target to another host. This allows attackers to craft malicious URLs using scheme-relative paths (e.g., //) or control characters that are silently stripped by the URL parser, enabling the middleware to redirect users to external malicious sites while the initial URL appears to originate from a trusted application domain.

Critical Impact

Attackers can leverage this vulnerability to redirect users from trusted application URLs to malicious external sites, potentially enabling phishing attacks, credential theft, or malware distribution by exploiting user trust in the legitimate application domain.

Affected Products

• next-intl versions prior to 4.9.1
• Next.js applications using next-intl middleware with localePrefix: 'as-needed' configuration
• Applications utilizing locale-based URL routing with the vulnerable middleware

Discovery Timeline

• 2026-04-17 - CVE-2026-40299 published to NVD
• 2026-04-20 - Last updated in NVD database

Technical Details for CVE-2026-40299

Vulnerability Analysis

This vulnerability (CWE-601: URL Redirection to Untrusted Site) exists in the next-intl middleware's pathname sanitization logic. The vulnerability stems from how the middleware handles URL path parsing in conjunction with the WHATWG URL parser's behavior. When processing locale-prefixed URLs, the middleware failed to account for control characters (specifically U+0009 TAB, U+000A LF, and U+000D CR) that the WHATWG URL parser silently strips during URL normalization.

An attacker could exploit this by inserting these control characters into URL paths. When the middleware processes a path like /en/\t/malicious.com, the tab character creates a visual segment separator, but when passed to the URL parser, the tab is stripped, collapsing the path to //malicious.com. This scheme-relative URL is then interpreted as a protocol-relative redirect to malicious.com, effectively bypassing the application's URL validation.

Root Cause

The root cause lies in the sanitizePathname() function within packages/next-intl/src/middleware/utils.tsx. The original implementation only sanitized backslashes and consecutive forward slashes, but failed to account for WHATWG-stripped control characters (TAB, LF, CR) that could be exploited to construct open redirect payloads. The WHATWG URL specification silently strips these characters during parsing, creating a discrepancy between what the middleware validates and what the browser interprets.

Attack Vector

The attack is network-based and requires no authentication or user interaction beyond clicking a malicious link. An attacker crafts a URL targeting the vulnerable application with embedded control characters (TAB, LF, or CR) positioned to create scheme-relative redirects after WHATWG parsing. Since the link appears to originate from the trusted domain, users are more likely to click it, making this particularly effective for phishing campaigns.

// Vulnerable sanitizePathname function (before patch)
// Source: https://github.com/amannn/next-intl/commit/1c80b668aa6d853f470319eec10a3f61e78a70e6

export function sanitizePathname(pathname: string) {
  // Sanitize malicious URIs, e.g.:
  // '/en/\\example.org → /en/%5C%5Cexample.org'
  // '/en////example.org → /en/example.org'
  return pathname.replace(/\\/g, '%5C').replace(/\/+/g, '/');
}

// Patched sanitizePathname function (version 4.9.1)
// Source: https://github.com/amannn/next-intl/commit/1c80b668aa6d853f470319eec10a3f61e78a70e6

export function sanitizePathname(pathname: string) {
  // Sanitize malicious URIs, e.g.:
  // '/en/\\example.org'  → '/en/%5Cexample.org'     (backslash → %5C)
  // '/en/\t/example.org' → '/en/example.org'        (WHATWG-stripped TAB)
  // '/en/\n/example.org' → '/en/example.org'        (WHATWG-stripped LF)
  // '/en/\r/example.org' → '/en/example.org'        (WHATWG-stripped CR)
  // '/en////example.org' → '/en/example.org'        (consecutive slashes)
  //
  // U+0009/000A/000D are silently stripped by the WHATWG URL parser
  // (https://url.spec.whatwg.org/#concept-url-parser). Without removing
  // them here, a decoded TAB in a segment separator position causes
  // new URL("/\t/host", base) to collapse to "//host" → open redirect.
  return pathname
    .replace(/\\/g, '%5C')
    .replace(/[\t\n\r]/g, '')
    .replace(/\/+/g, '/');
}

Detection Methods for CVE-2026-40299

Indicators of Compromise

• HTTP requests containing URL-encoded control characters in path segments (e.g., %09, %0A, %0D)
• Redirect responses pointing to external domains from locale-switching endpoints
• Unusual patterns in application logs showing decoded TAB, LF, or CR characters in URL paths
• User reports of unexpected redirects from trusted application links

Detection Strategies

• Monitor web application firewall (WAF) logs for requests containing control characters in URL paths
• Implement detection rules for URL patterns matching /%09/, /%0A/, /%0D/ or their decoded equivalents
• Review HTTP response headers for Location headers pointing to unexpected external domains
• Audit Next.js application logs for middleware redirect events to non-application domains

Monitoring Recommendations

• Configure SIEM alerts for HTTP 3xx responses redirecting to external hosts from locale endpoints
• Implement URL normalization logging to detect discrepancies between raw and parsed URLs
• Monitor for anomalous traffic patterns suggesting open redirect exploitation attempts
• Set up browser-side monitoring for navigation events to unexpected domains

How to Mitigate CVE-2026-40299

Immediate Actions Required

• Upgrade next-intl to version 4.9.1 or later immediately
• Audit application logs for evidence of exploitation attempts
• Review any custom URL handling or redirect logic for similar WHATWG parsing issues
• Implement WAF rules to block requests containing control characters in URL paths as a defense-in-depth measure

Patch Information

The vulnerability has been patched in next-intl@4.9.1. The fix enhances the sanitizePathname() function to strip WHATWG-stripped control characters (TAB, LF, CR) before URL processing, preventing the open redirect condition. For detailed patch information, see the GitHub Security Advisory GHSA-8f24-v5vv-gm5j and the GitHub Release v4.9.1.

Workarounds

• If immediate upgrade is not possible, implement middleware to strip control characters from incoming request URLs before they reach next-intl
• Configure reverse proxy or WAF rules to reject requests containing %09, %0A, or %0D in URL paths
• Consider temporarily disabling localePrefix: 'as-needed' configuration if the feature is not critical
• Implement Content Security Policy headers to limit redirect destinations

# Upgrade next-intl to patched version
npm update next-intl@4.9.1

# Or using yarn
yarn upgrade next-intl@4.9.1

# Verify installed version
npm list next-intl