GHSA-8f24-v5vv-gm5j: Open Redirect in next-intl Middleware via URL Parsing Discrepancy

The next-intl library provides internationalization capabilities for Next.js applications. It utilizes middleware to manage locale-based routing, handling user navigation across different language variants. This middleware normalizes URLs, manages redirects, and ensures requests are correctly prefixed with the appropriate locale.

Versions of next-intl prior to 4.9.1 contain an open redirect vulnerability (CWE-601) within the middleware routing logic. The flaw allows an unauthenticated remote attacker to craft specific URIs that redirect users to arbitrary external domains. The vulnerability stems from incomplete sanitization of URL paths containing specific ASCII control characters.

The vulnerability is currently tracked under the GitHub Security Advisory GHSA-8f24-v5vv-gm5j. While open redirects are generally classified as moderate severity, they serve as a critical enabler for targeted phishing campaigns and OAuth token leakage. Security teams should prioritize patching applications utilizing the vulnerable middleware component.

The vulnerability exists within the sanitizePathname function located in packages/next-intl/src/middleware/utils.tsx. This function normalizes incoming request paths to prevent malicious redirects, specifically attempting to neutralize protocol-relative URLs that begin with double slashes (//).

Prior to the patch, the sanitization logic performed only two operations: encoding backslashes (\) as %5C and collapsing multiple consecutive slashes (//+) into a single slash (/). This implementation failed to account for the WHATWG URL Specification, which governs how modern browsers parse and construct URLs.

The WHATWG specification mandates that certain ASCII control characters—specifically TAB (U+0009), LF (U+000A), and CR (U+000D)—are silently stripped during URL parsing. When a user requests a path containing these characters, the middleware preserves them, but the client-side browser subsequently removes them when resolving the redirect target. This discrepancy between server-side sanitization and client-side parsing creates the conditions for the open redirect.

The patch introduces a critical string replacement operation within the sanitizePathname function. The original implementation missed the removal of ASCII control characters, allowing them to pass through the middleware's normalization process intact.

// Vulnerable Implementation
export function sanitizePathname(pathname: string) {
  return pathname
    .replace(/\\/g, '%5C')
    .replace(/\/+/g, '/');
}

The updated code, introduced in commit 1c80b668aa6d853f470319eec10a3f61e78a70e6, implements an explicit removal of TAB, LF, and CR characters. This replacement occurs immediately after backslash encoding and before slash collapsing.

// Patched Implementation
export function sanitizePathname(pathname: string) {
  return pathname
    .replace(/\\/g, '%5C')
    .replace(/[\t\n\r]/g, '') // Strips TAB, LF, CR
    .replace(/\/+/g, '/');
}

By stripping these characters on the server side, the middleware effectively aligns its normalization logic with the WHATWG specification. If an attacker attempts to inject a TAB character between slashes, the server now strips the TAB and subsequently collapses the resulting double slash into a single slash, neutralizing the protocol-relative URL attack vector.

Exploitation requires the attacker to construct a URL targeting a Next.js application running a vulnerable version of next-intl. The attacker embeds an encoded control character, such as %09 (TAB), strategically within the URL path. A typical payload follows the structure http://<victim-domain>/<locale>/%09/attacker.com.

When the victim clicks the crafted link, the next-intl middleware processes the request. It decodes the URL-encoded characters, resulting in a path structured as /en/[TAB]/attacker.com. The middleware then attempts to normalize this path by removing the locale prefix and issues an HTTP redirect instruction to the client.

Upon receiving the redirect response, the victim's browser processes the target URL /[TAB]/attacker.com. Following the WHATWG specification, the browser silently drops the TAB character. The resulting string //attacker.com is interpreted as a protocol-relative URL, instructing the browser to initiate a request to the external domain attacker.com.

The primary impact of this vulnerability is the facilitation of sophisticated phishing campaigns. Attackers leverage the reputation and trust of the vulnerable domain to construct convincing links. When victims click these links, they are transparently redirected to an attacker-controlled site designed to harvest credentials or distribute malware.

Beyond basic phishing, open redirects often serve as a critical stepping stone in complex attack chains. If the vulnerable application implements OAuth or similar authentication flows, attackers can utilize the open redirect to exfiltrate authorization codes or access tokens by manipulating callback URIs.

The vulnerability is classified as moderate severity, reflecting the requirement for user interaction. The execution relies exclusively on social engineering to prompt a victim to initiate the malicious request. However, the lack of authentication requirements and the high success rate of domain-trusted phishing links warrant immediate remediation.

The primary remediation strategy requires upgrading the next-intl package to version 4.9.1 or later. This update contains the necessary logic to strip ASCII control characters during path sanitization. Development teams should execute npm install next-intl@latest to apply the fix.

Organizations unable to deploy the patch immediately can mitigate the vulnerability using Web Application Firewall (WAF) rules. Administrators should configure the WAF to intercept and drop HTTP requests containing encoded control characters (%09, %0A, %0D) within the request path.

Security engineers should also review existing application routing logic for similar URL parsing discrepancies. The misalignment between server-side path normalization and client-side URL parsing is a common source of bypasses in routing middleware. Relying exclusively on regex-based string replacements often leaves edge cases exposed to manipulation.