PT-2026-118577 · Npm · @Angular/Platform-Server
CVE-2026-111754
·
تاريخ النشر
2026-10-20
·
تاريخ التحديث
2026-10-20
CVSS v4.0
5.1
متوسطة
| المتجه | AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N |
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.Impact
Successful exploitation allows an unauthenticated remote attacker to craft URLs that trick Angular SSR into redirecting users to an arbitrary external domain.
- Bypasses Application-Level Guards: Common application-level validation routines (such as checking
!returnUrl.startsWith('//')before invokingrouter.navigateByUrl) accept/.//evil.testor/.;/(//evil.test)as a safe relative path, allowing attackers to bypass redirect allowlists. - Client-side SPAs Unaffected: Pure client-side Angular applications (Single Page Applications without SSR) are not vulnerable, as
ServerPlatformLocationis only utilized in server-side execution environments.
Attack Preconditions & Vulnerable Configurations
An application is affected if the following conditions are met:
- SSR Enabled: The application runs in a Server-Side Rendering environment using
@angular/platform-serverand@angular/ssr. - Parameter Route Shapes: The router contains parameter routes with wildcard or child segments (e.g.
/:tenantmatching.and serializing secondary outlet groups(//evil.test)to/.//evil.test), or passes user-provided navigation targets (e.g.returnUrl). - Reverse Proxy Passthrough: Upstream reverse proxies (Nginx, Cloudflare, ALB) pass semicolons (
;) or dot-segments without stripping or normalizing them.
Exploit Payload Example
An attacker sends a request targeting a route with parameters and child segments:
http
GET /.;/(//evil.test) HTTP/1.1
Host: example.comResponse:
http
HTTP/1.1 302 Found
Location: //evil.testThe client browser resolves
//evil.test protocol-relatively and redirects the user away from example.com to evil.test.Patches
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.33
Workarounds & Mitigations
If you cannot immediately upgrade to a patched version, apply one of the following mitigations at your edge reverse proxy or WAF:
- Reject Paths with Dot-Segments Followed by Slashes:
Configure your reverse proxy (e.g., Nginx, Cloudflare, AWS WAF) to block requests containing
/.//,/..//, or/.;/:
nginx
# Nginx example: reject suspicious path normalization sequences
if ($request uri ~* "(
/./|/.;)") {
return 400;
}- Sanitize Redirect Headers:
Ensure edge proxies or API gateways rewrite or disallow protocol-relative (
//)Locationresponse headers originating from the SSR upstream.
إصلاح
Open Redirect
وجدت خطأً في الوصف؟ لديك ما تضيفه؟ لا تتردد في مراسلتنا 👾
تصنيف نقاط الضعف
المعرّفات ذات الصلة
المنتجات المتأثرة
@Angular/Platform-Server