npm · @angular/platform-server
@angular/platform-server: Open Redirect via Protocol-Relative URLs in Server-Side Rendering (SSR)
An open redirect vulnerability was identified in @angular/platform-server when Server-Side Rendering (SSR) is enabled.
When Angular SSR renders an incoming request, URL resolution and platform navigation are managed by ServerPlatformLocation using resolveUrl (or parseUrl in v20). While resolveUrl rejected protocol-relative URLs whose raw string directly started with //, this check ran prior to WHATWG URL normalization.
When a request URL includes a popping dot-segment followed by multiple slashes (such as /.//evil.test or serialized from router route shapes like /.;/(//evil.test)), the input bypassed the initial urlStr.startsWith('//') check. Subsequent WHATWG URL parsing resolved the dot-segments and resulted in a pathname starting with // (//evil.test).
Consequently, ServerPlatformLocation stored pathname = '//evil.test'. When @angular/ssr detected a mismatch between the rendered URL and the router's final location state, it emitted the unnormalized pathname into the HTTP Location response header, producing an HTTP 302 redirect with Location: //evil.test, which browsers resolve as a protocol-relative navigation off-origin.
Successful exploitation allows an unauthenticated remote attacker to craft URLs that trick Angular SSR into redirecting users to an arbitrary external domain.
!returnUrl.startsWith('//') before invoking router.navigateByUrl) accept /.//evil.test or /.;/(//evil.test) as a safe relative path, allowing attackers to bypass redirect allowlists.ServerPlatformLocation is only utilized in server-side execution environments.An application is affected if the following conditions are met:
@angular/platform-server and @angular/ssr./:tenant matching . and serializing secondary outlet groups (//evil.test) to /.//evil.test), or passes user-provided navigation targets (e.g. returnUrl).;) or dot-segments without stripping or normalizing them.An attacker sends a request targeting a route with parameters and child segments:
GET /.;/(//evil.test) HTTP/1.1
Host: example.com
Response:
HTTP/1.1 302 Found
Location: //evil.test
The client browser resolves //evil.test protocol-relatively and redirects the user away from example.com to evil.test.
The issue is resolved by updating resolveUrl (and parseUrl in v20) in @angular/platform-server to verify that the normalized URL pathname does not start with // when allowProtocolRelative is false.
22.2.121.2.2520.3.33If you cannot immediately upgrade to a patched version, apply one of the following mitigations at your edge reverse proxy or WAF:
/.//, /..//, or /.;/:# Nginx example: reject suspicious path normalization sequences
if ($request_uri ~* "(\n/\.\/|\/\.\;)") {
return 400;
}
//) Location response headers originating from the SSR upstream.Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.