Next-intl, a popular internationalization library for Next.js applications, ships with an open redirect vulnerability in versions before 4.9.1. Developers using its middleware with the localePrefix: 'as-needed' option face the highest risk. Attackers can craft seemingly legitimate URLs that redirect users to malicious sites, exploiting quirks in the WHATWG URL parser. Update to version 4.9.1 immediately if affected. This flaw enables phishing attacks by tricking users into leaving your domain without obvious signs.
The vulnerability stems from how next-intl’s middleware handles locale prefixes and redirects. With localePrefix: 'as-needed', the library adds locale paths only when multiple languages are in play, aiming for cleaner URLs. However, during redirect construction—say, for locale detection or navigation—the middleware builds URLs that the browser’s WHATWG URL parser resolves differently than expected. Relative targets like scheme-relative //evil.com or those with control characters (stripped by the parser) slip through, resolving to external hosts even if the initial URL appears trusted.
Technical Breakdown
Consider a Next.js app at https://example.com. An attacker sends a link like https://example.com/@%0a//evil.com. The %0a (line feed control character) gets stripped by the URL parser, leaving https://example.com/@//evil.com. Next-intl’s middleware, processing this for locale prefixing, treats the path oddly and issues a redirect. The browser parses //evil.com as https://evil.com, bouncing the user off-site.
This isn’t a novel trick—scheme-relative URLs have tricked redirect logic for years—but next-intl’s path handling amplified it. The WHATWG spec mandates percent-decoding before path splitting, and control characters vanish, creating a mismatch. Joni Liljeblad from Oura discovered this, reported it responsibly, and even proposed the patch. Props for that; quick disclosure keeps damage low.
Next-intl has over 5,000 GitHub stars and powers i18n in thousands of production Next.js apps. Next.js itself runs on 10%+ of the top million websites (per W3Techs), with e-commerce, SaaS, and finance sites leaning on libraries like this. A single phishable redirect in a login flow or payment page cascades: stolen sessions, credentials harvested, or malware dropped.
Why This Matters and What to Do
Open redirects rank high on OWASP lists for good reason—they’re stealthy entry points for broader attacks. In a post-cookie world with passkeys and biometrics, tricking users off-domain still nets OAuth tokens or induces fake login prompts. Skeptically, this isn’t catastrophic; it requires localePrefix: 'as-needed' (not the default ‘always’), user clicks, and middleware in play. But fairness demands action: unpatched apps stay exposed indefinitely.
Patch first: Run
npm install next-intl@4.9.1or
yarn add next-intl@4.9.1, then npm run build and deploy. Verify by testing crafted URLs—no external redirects. Beyond that, audit all redirects site-wide. Use a strict URL validator in middleware:
function isSameOrigin(urlString: string, baseOrigin: string): boolean {
try {
const url = new URL(urlString, baseOrigin);
return url.origin === new URL(baseOrigin).origin;
} catch {
return false;
}
}Disable localePrefix: 'as-needed' if possible—switch to ‘always’ for explicitness. Scan dependencies with npm audit or Snyk. In Next.js 14+, leverage built-in middleware URL validation. Watch for similar issues; URL parsing edge cases bite often (recall CVE-2023-28121 in Node.js URL parser).
Bottom line: This highlights library risks in the Next.js ecosystem. Maintainers fixed it fast—credit where due—but don’t sleep on updates. Your users’ trust hinges on boring security hygiene. Check your setup now.
