An Open Redirect vulnerability exists in the internal URL processing logic in Angular SSR. The logic normalizes URL segments by stripping leading slashes; however, it only removes a single leading slash.
When an Angular SSR application is deployed behind a proxy that passes the X-Forwarded-Prefix header, an attacker can provide a value starting with three slashes (e.g., ///evil.com).
1. The application processes a redirect (e.g., from a router redirectTo or i18n locale switch). 2. Angular receives ///evil.com as the prefix. 3. It strips one slash, leaving //evil.com. 4. The resulting string is used in the Location header. 5. Modern browsers interpret // as a protocol-relative URL, redirecting the user from https://your-app.com to https://evil.com.
Impact This vulnerability allows attackers to conduct large-scale phishing and SEO hijacking: - Scale: A single request can poison a high-traffic route, impacting all users until the cache expires. - SEO Poisoning: Search engine crawlers may follow and index these malicious redirects, causing the legitimate site to be delisted or associated with malicious domains. - Trust: Because the initial URL belongs to the trusted domain, users and security tools are less likely to flag the redirect as malicious.
Attack Preconditions
- 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.
Patches - 21.2.0-rc.1 - 21.1.5 - 20.3.17 - 19.2.21
Workarounds Until the patch is applied, developers should sanitize the X-Forwarded-Prefix header in theirserver.ts before the Angular engine processes the request:
ts app.use((req, res, next) => { const prefix = req.headers['x-forwarded-prefix']?.trim(); if (prefix) { // Sanitize by removing all leading slashes req.headers['x-forwarded-prefix'] = prefix.replace(/^[/\\]+/, '/'); } next(); });
Resources - Report - Fix
The Angular SSR is a server-rise rendering tool for Angular applications. Prior to versions 20.3.36, 21.2.23, and 22.1.7, the CommonEngine retrieveSSGPage prerendered-page retrieval logic in @angular/ssr/node, and in @angular/ssr for versions 17 through 18, accepts a relative request URL containing a backslash parent-traversal segment on Windows. The non-special resolve:// URL base preserves the backslash, path.join interprets it as a Windows separator, and the pagePath.startsWith(normalize(publicPath)) check incorrectly accepts a sibling output directory whose name shares the configured public-directory prefix. An unauthenticated requester can therefore retrieve a sibling prerendered HTML page when that page contains the Angular SSG marker. The issue is limited to Windows deployments that pass relative request URLs to CommonEngine.render, have a prefix-sharing sibling output directory, and contain qualifying prerendered Angular HTML; it does not provide arbitrary file read. This issue is fixed in versions 20.3.36, 21.2.23, and 22.1.7.