CVE-2026-27738: Angular SSR Open Redirect Vulnerability

CVE-2026-27738 Overview

An Open Redirect vulnerability has been identified in Angular SSR (Server-Side Rendering), a server-side rendering tool for Angular applications. The vulnerability exists in the internal URL processing logic that normalizes URL segments by stripping leading slashes. However, the implementation only removes a single leading slash, creating an exploitable condition when Angular SSR applications are deployed behind a proxy that passes the X-Forwarded-Prefix header.

When an attacker provides a value starting with three slashes in the X-Forwarded-Prefix header, the insufficient sanitization allows the redirect to be manipulated. This vulnerability can be leveraged for large-scale phishing campaigns and SEO hijacking attacks.

Critical Impact

Attackers can exploit this vulnerability to redirect users to malicious external domains, enabling phishing attacks and SEO poisoning when Angular SSR applications are deployed behind reverse proxies or CDNs that pass the X-Forwarded-Prefix header without proper sanitization.

Affected Products

• Angular SSR 19.x branch prior to version 19.2.21
• Angular SSR 20.x branch prior to version 20.3.17
• Angular SSR 21.x branch prior to versions 21.1.5 and 21.2.0-rc.1

Discovery Timeline

• 2026-02-25 - CVE CVE-2026-27738 published to NVD
• 2026-02-25 - Last updated in NVD database

Technical Details for CVE-2026-27738

Vulnerability Analysis

This Open Redirect vulnerability (CWE-601) stems from improper URL validation in Angular SSR's internal URL processing logic. The vulnerability specifically affects the joinUrlParts() function in packages/angular/ssr/src/utils/url.ts, which is responsible for normalizing and joining URL path segments.

The original implementation only stripped a single leading slash from URL parts, meaning that an input like ///evil.com would only become //evil.com after normalization. In HTTP/URL semantics, a path starting with // is interpreted as a protocol-relative URL, effectively redirecting users to an external domain.

For the vulnerability to be exploitable, the following conditions must be met:

• The application must use Angular SSR
• The application must have routes that perform internal redirects
• The infrastructure (Reverse Proxy/CDN) must pass the X-Forwarded-Prefix header to the SSR process without sanitization
• The cache must not vary on the X-Forwarded-Prefix header

Root Cause

The root cause lies in the insufficient input sanitization within the joinUrlParts() function. The original code used a simple conditional check if (part[0] === '/') followed by a single slice(1) operation to remove leading slashes. This approach fails to handle cases where multiple consecutive slashes are present at the beginning of the URL part.

The vulnerability is further compounded by the lack of validation in the X-Forwarded-Prefix header processing, which should reject prefix values that could result in protocol-relative URLs or path traversal sequences.

Attack Vector

The attack is network-based and requires no authentication or user interaction beyond visiting a crafted URL. An attacker can manipulate the X-Forwarded-Prefix header with a value containing triple slashes (e.g., ///attacker.com). When Angular SSR processes a redirect, the insufficient normalization results in a URL like //attacker.com/path, which browsers interpret as a protocol-relative URL pointing to the attacker's domain.

This enables:

• Phishing attacks: Users can be redirected to malicious sites that mimic legitimate login pages
• SEO hijacking: Search engines may index malicious redirects, damaging the application's search ranking
• Cache poisoning: If responses are cached, all users accessing the cached resource may be redirected

The following patch demonstrates how the Angular team fixed the vulnerability by implementing proper multi-slash stripping:

  * ```
  */
 export function joinUrlParts(...parts: string[]): string {
-  const normalizeParts: string[] = [];
+  const normalizedParts: string[] = [];
+
   for (const part of parts) {
     if (part === '') {
       // Skip any empty parts
       continue;
     }
 
-    let normalizedPart = part;
-    if (part[0] === '/') {
-      normalizedPart = normalizedPart.slice(1);
+    let start = 0;
+    let end = part.length;
+
+    // Use "Pointers" to avoid intermediate slices
+    while (start < end && part[start] === '/') {
+      start++;
     }
-    if (part.at(-1) === '/') {
-      normalizedPart = normalizedPart.slice(0, -1);
+
+    while (end > start && part[end - 1] === '/') {
+      end--;
     }
-    if (normalizedPart !== '') {
-      normalizeParts.push(normalizedPart);

Source: GitHub Commit Update

Additionally, a new validation regex was introduced to detect invalid prefix patterns:

  */
 const VALID_HOST_REGEX = /^[a-z0-9.:-]+$/i;
 
+/**
+ * Regular expression to validate that the prefix is valid.
+ */
+const INVALID_PREFIX_REGEX = /^[/\\]{2}|(?:^|[/\\])\.\.?(?:[/\\]|$)/;
+
 /**
  * Extracts the first value from a multi-value header string.
  *

Source: GitHub Commit Update

Detection Methods for CVE-2026-27738

Indicators of Compromise

• Unusual X-Forwarded-Prefix header values containing multiple consecutive slashes (e.g., ///, ////)
• HTTP 3xx redirect responses pointing to external domains not associated with the application
• Access logs showing requests with malformed prefix headers followed by redirect responses
• Unexpected outbound connections from user browsers to unknown external domains

Detection Strategies

• Implement Web Application Firewall (WAF) rules to detect and block X-Forwarded-Prefix headers containing double or triple leading slashes
• Configure reverse proxy or CDN logging to capture and alert on anomalous header values
• Monitor application redirect responses for destinations outside of expected domain whitelist
• Review Angular SSR application logs for URL normalization errors or warnings

Monitoring Recommendations

• Set up alerts for HTTP redirect responses (301, 302, 307, 308) containing protocol-relative URLs in the Location header
• Monitor cache hit rates and investigate unexpected variations that could indicate cache poisoning attempts
• Implement real-time log analysis to detect patterns of X-Forwarded-Prefix header manipulation
• Track user-reported phishing incidents that may indicate exploitation of this vulnerability

How to Mitigate CVE-2026-27738

Immediate Actions Required

• Upgrade Angular SSR to patched versions: 19.2.21, 20.3.17, 21.1.5, or 21.2.0-rc.1 depending on your branch
• Review and sanitize X-Forwarded-Prefix header handling in your reverse proxy or CDN configuration
• Configure cache to vary on the X-Forwarded-Prefix header to prevent cache poisoning
• Audit application routes that perform internal redirects for potential exposure

Patch Information

Angular has released security patches across all affected version branches. The fix implements a loop-based approach to strip all leading and trailing slashes from URL parts, along with a new validation regex (INVALID_PREFIX_REGEX) that detects invalid prefix patterns including protocol-relative URLs and path traversal sequences.

Patched versions:

• Version 19.2.21 for the 19.x branch
• Version 20.3.17 for the 20.x branch
• Version 21.1.5 for the 21.x branch
• Version 21.2.0-rc.1 for the 21.2.x release candidate branch

For additional technical details, refer to the GitHub Security Advisory, the GitHub Pull Request, and the GitHub Issue Discussion.

Workarounds

• Sanitize the X-Forwarded-Prefix header in your server.ts file before the Angular engine processes the request
• Configure your reverse proxy to strip or validate the X-Forwarded-Prefix header before forwarding to the Angular SSR application
• Implement an allowlist of valid prefix values at the proxy level
• Disable forwarding of X-Forwarded-Prefix header if not required for your application's functionality

// server.ts - Sanitize X-Forwarded-Prefix header before Angular processing
app.use((req, res, next) => {
  const prefix = req.headers['x-forwarded-prefix'];
  if (prefix) {
    // Remove all leading slashes and validate
    const sanitized = String(prefix).replace(/^\/+/, '/');
    if (sanitized.startsWith('//') || sanitized.includes('..')) {
      delete req.headers['x-forwarded-prefix'];
    } else {
      req.headers['x-forwarded-prefix'] = sanitized;
    }
  }
  next();
});