CVE-2026-40299

What it actually does

This is an open redirect flaw in next-intl middleware for Next.js applications configured with localePrefix: 'as-needed' before next-intl 4.9.1. Under certain URL constructions, path normalization and WHATWG URL parsing can cause a redirect target that appears relative to be resolved as an external host, including cases involving scheme-relative URLs such as //example.com or control characters that are stripped during parsing. The vulnerable middleware may therefore emit a redirect response that sends the browser from a trusted application URL to an attacker-controlled site. The flaw does not directly provide code execution, data access, or server compromise, but it can undermine trust boundaries around login, account workflows, and user-facing links.

Why it matters to the business

Attackers can abuse trusted application links to send users to malicious sites, increasing the risk of phishing, credential theft, session hijacking attempts, malware delivery, or fraud. The operational risk is highest for public-facing applications where links are shared in email, messaging, support workflows, password reset flows, or authentication redirects. EPSS is currently low and the issue is not in CISA KEV, but the bug has been public for more than 100 days, so affected internet-facing applications should still be upgraded during normal security patch cycles, with higher priority for applications involved in identity, payments, or customer communications.

How an attack unfolds

An attacker identifies a Next.js application using vulnerable next-intl middleware with localePrefix: 'as-needed'. They craft a URL on the legitimate application domain that causes the middleware to perform locale-related redirect handling. By using a redirect target that the application treats like a relative path but the browser or URL parser resolves as an external destination, the attacker causes the application to return a redirect to an attacker-controlled host. The attacker then distributes the legitimate-looking URL through phishing emails, ads, chat messages, social media, or embedded links. A user opens the trusted URL and is automatically redirected off-site, where the attacker can present a fake login page, collect credentials, prompt for MFA codes, distribute malware, or continue a social-engineering flow. Successful exploitation generally leaves evidence in web access logs as unusual redirect-generating requests followed by external Location headers or suspicious paths containing double slashes or encoded control characters.

How to fix it

Upgrade next-intl to version 4.9.1 or later. Rebuild and redeploy affected Next.js applications after updating dependencies, and ensure lockfiles and container images are refreshed so the vulnerable package is not still present in production artifacts. Review middleware configuration for localePrefix: 'as-needed' and avoid redirect logic that accepts or constructs untrusted destinations without strict validation. As a defense-in-depth measure, validate redirect targets by allowing only same-origin relative paths, reject scheme-relative URLs beginning with //, reject encoded or raw control characters in path inputs, and avoid passing untrusted strings directly into URL constructors for redirect decisions. Where feasible, add centralized redirect safety checks and tests covering malformed paths, encoded characters, and external-host resolution.

How to confirm the fix worked

Confirm package manifests and lockfiles resolve next-intl to 4.9.1 or later, including package-lock.json, yarn.lock, pnpm-lock.yaml, container layers, and software composition analysis results. Verify deployed artifacts, not just source repositories, by checking production build metadata or dependency inventories. Test affected routes that use next-intl middleware with localePrefix: 'as-needed' and confirm they do not issue redirects to external hosts when given scheme-relative paths, encoded slashes, backslashes, or encoded control characters. Inspect HTTP responses and ensure Location headers remain same-origin or are rejected with a safe error response. Add regression tests for redirect handling to prevent reintroduction in future middleware or routing changes.

Typical attack path

1. Identify a public Next.js application using next-intl middleware before version 4.9.1 with localePrefix: 'as-needed'.
2. Probe locale-handling routes for redirect behavior and URL parser edge cases.
3. Craft a trusted-domain URL that causes the middleware to resolve the redirect destination to an attacker-controlled external host.
4. Send the crafted URL to users through phishing, advertising, social media, support impersonation, or other social-engineering channels.
5. User opens the trusted-looking URL and receives an HTTP redirect from the legitimate application.
6. Browser navigates to the attacker-controlled site, where the attacker attempts credential theft, MFA interception, malware delivery, or fraud.

How to detect it

To determine whether this was already exploited, review HTTP access logs, application middleware logs, CDN/WAF logs, reverse proxy logs, and redirect telemetry for requests to locale-handled routes that resulted in 3xx responses to external domains. Focus on requests containing scheme-relative path patterns, encoded slashes, backslashes, URL-encoded control characters, or suspicious values that normalize differently after parsing. Correlate suspicious requests with response Location headers, referrers, user agents, source IPs, and subsequent reports of phishing or credential theft. If the application logs only requests and not response headers, use CDN, load balancer, reverse proxy, or APM traces that capture outbound redirect destinations. Investigate spikes in 301, 302, 307, or 308 responses from middleware-managed routes, especially where the requested URL includes double slashes after the host, percent-encoded characters, or destinations resembling external domains. There are no known public threat actors, ransomware campaigns, or KEV exploitation associated with this vulnerability based on the provided data, so detection should be behavior-based rather than signature-only.

• next-intl@4.9.0
• next-intl@4.8.
• next-intl@4.7.
• next-intl@4.6.
• next-intl@4.5.
• localePrefix: 'as-needed'
• localePrefix:"as-needed"
• Location: //
• HTTP/1.1 302
• HTTP/1.1 301
• HTTP/1.1 307
• HTTP/1.1 308
• %0d
• %0a
• %09
• %00
• %2f%2f
• %5c
• //http
• //https

What your security team should do

• Inventory internet-facing Next.js applications using next-intl and identify any running versions earlier than 4.9.1.
• Prioritize patching applications that handle authentication, password reset, payment, customer support, or externally shared links.
• Upgrade next-intl to 4.9.1 or later, rebuild artifacts, redeploy, and verify dependency versions in runtime images or deployed packages.
• Search recent web access logs for suspicious locale-routing requests containing scheme-relative URLs, encoded control characters, or unusual redirect destinations.
• Review application and edge-proxy redirect logging to identify any Location headers pointing to unapproved external domains.
• Add or enforce safe redirect validation that permits only same-origin relative paths unless an explicit allowlist is required.
• Educate phishing-response teams that trusted-domain links may have been used as redirectors even if the final malicious site is external.