CVE-2026-27738: 
JavaScript vulnerability analysis and mitigation

CVE-2026-27738 is an Open Redirect vulnerability (CWE-601) in Angular SSR (Server-Side Rendering), the @angular/ssr npm package. The flaw exists in the internal URL normalization logic (joinUrlParts() in packages/angular/ssr/src/utils/url.ts), which only strips a single leading slash from URL segments, allowing attackers to craft a X-Forwarded-Prefix header value starting with three slashes (e.g., ///evil.com) to produce a protocol-relative redirect (//evil.com) in the HTTP Location header. Affected versions include the 19.x branch prior to 19.2.21, the 20.x branch prior to 20.3.17, and the 21.x branch prior to 21.1.5 and 21.2.0-rc.1. The vulnerability was reported by VenkatKwest, disclosed via GitHub Advisory on February 23, 2026, and published to NVD on February 25, 2026. It carries a CVSS v4.0 base score of 6.9 (Medium) (GitHub Advisory, Angular CLI Advisory).

The root cause is insufficient input sanitization in the joinUrlParts() function (packages/angular/ssr/src/utils/url.ts, line 106), classified as CWE-601 (URL Redirection to Untrusted Site). The function used a single if check to strip only one leading slash from each URL segment; when the X-Forwarded-Prefix header contains ///evil.com, stripping one slash leaves //evil.com, which browsers interpret as a protocol-relative URL and follow as an external redirect to https://evil.com. The attack is network-based, requires no authentication or user interaction, and is exploitable against any Angular SSR application that: (1) uses routes with internal redirects (e.g., redirectTo or i18n locale switches), (2) is deployed behind a reverse proxy or CDN that forwards the X-Forwarded-Prefix header without sanitization, and (3) has a cache that does not vary on the X-Forwarded-Prefix header. The fix updates joinUrlParts to strip all leading and trailing slashes using pointer-based iteration, and adds strict validation in validation.ts to reject headers starting with // or \ or containing path traversal segments (Angular CLI Issue, Fix Commit).

Successful exploitation enables large-scale phishing attacks and SEO hijacking. Because the initial request originates from a trusted domain, users and security tools are less likely to flag the redirect as malicious, increasing the effectiveness of credential theft and malware distribution campaigns. If the poisoned redirect response lacks Cache-Control headers, CDNs may cache and serve the malicious redirect to all subsequent users of the affected route until the cache expires — meaning a single attacker request can impact a high volume of users. Search engine crawlers following these redirects may index the malicious destination, causing the legitimate site to be delisted or associated with harmful domains (GitHub Advisory, Angular CLI Advisory).

No public proof-of-concept exploit code has been identified, and there is no evidence of in-the-wild exploitation at this time (GitHub Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.061% (19th percentile), indicating a low near-term exploitation probability. However, the attack requires no privileges or user interaction and is remotely exploitable with low complexity, making it straightforward to attempt against vulnerable deployments once the preconditions are met.

1. Reconnaissance: Identify Angular SSR applications deployed behind a reverse proxy (e.g., Nginx, HAProxy, AWS ALB, Kubernetes Ingress) that forwards the X-Forwarded-Prefix header. Check for routes that perform internal redirects (e.g., redirectTo in routing config or i18n locale switches).
2. Verify header passthrough: Confirm that the proxy passes X-Forwarded-Prefix to the SSR process without sanitization by sending a benign test request with a custom header value and observing the Location response header.
3. Craft malicious request: Send an HTTP request to a redirect route on the target application with a crafted header: X-Forwarded-Prefix: ///evil.com. For example:

   curl -v -H "X-Forwarded-Prefix: ///evil.com" https://target-app.com/redirect

4. Observe redirect: The Angular SSR joinUrlParts() function strips one slash, producing //evil.com. The server responds with HTTP 302 Found and Location: //evil.com/home, which browsers interpret as a protocol-relative URL and follow to https://evil.com/home.
5. Cache poisoning (optional): If the CDN or reverse proxy caches the redirect response without varying on X-Forwarded-Prefix, the poisoned redirect is served to all subsequent users accessing the same route until the cache expires, amplifying the attack's reach.
6. Phishing/SEO abuse: Direct victims to the attacker-controlled site via phishing links using the trusted domain's URL, or allow search engine crawlers to index the malicious redirect for SEO poisoning (Angular CLI Issue, Angular CLI Advisory).

• Network: HTTP requests to Angular SSR redirect routes containing the X-Forwarded-Prefix header with values starting with two or more slashes (e.g., ///evil.com, //attacker.com); HTTP 302 responses with Location headers containing protocol-relative URLs (e.g., //external-domain.com/...).
• Logs: Web server or proxy access logs showing requests to redirect routes with unusual X-Forwarded-Prefix header values; SSR application logs showing redirect responses to external domains not in the expected allow-list.
• Cache: CDN or proxy cache entries for redirect routes serving Location headers pointing to external domains; cache hit responses with Location: //... values indicating a poisoned cache entry.

Upgrade @angular/ssr to one of the patched versions: 19.2.21, 20.3.17, 21.1.5, or 21.2.0-rc.1 (or later), depending on your current branch. As an interim workaround before patching, sanitize the X-Forwarded-Prefix header in server.ts before the Angular engine processes the request:

app.use((req, res, next) => {
  const prefix = req.headers['x-forwarded-prefix']?.trim();
  if (prefix) {
    req.headers['x-forwarded-prefix'] = prefix.replace(/^[/\\]+/, '/');
  }
  next();
});

Additionally, configure reverse proxies and CDNs to sanitize or strip the X-Forwarded-Prefix header before forwarding to the SSR process, and configure caching to vary on this header to prevent cache poisoning. Implementing a strict Content Security Policy (CSP) limiting redirect destinations to trusted domains provides additional defense-in-depth (GitHub Advisory, Angular CLI Advisory).

The vulnerability was originally reported to Google Bug Hunters by VenkatKwest, who confirmed the issue and suggested public disclosure via the Angular CLI GitHub issue tracker (Angular CLI Issue). The Angular team (alan-agius4) responded promptly, merging a fix within days of the report and publishing a formal security advisory on February 23, 2026. Community discussion noted the chainability of the open redirect with web cache poisoning as a particularly impactful attack scenario, given that CDNs may cache poisoned redirects and serve them to all users.