CVE-2026-111753

@angular/common: XSRF Token Leakage via URL Parsing Discrepancy in Angular HTTP Client (Incomplete fix for CVE-2025-66035)

An incomplete fix for GHSA-58c5-g7wp-6w37 (CVE-2025-66035) in @angular/common's HTTP Client (HttpClient) allows Cross-Site Request Forgery (XSRF) tokens to be leaked to attacker-controlled cross-origin domains when requests use URLs that exploit parsing discrepancies between regular expressions and the browser's WHATWG URL parser.

Technical Description

To address CVE-2025-66035, xsrfInterceptorFn introduced a regular expression (const ABSOLUTE_URL_REGEX = /^(?:https?:)?\/\//i) to detect and skip absolute and protocol-relative URLs before attaching the X-XSRF-TOKEN header.

However, browsers resolve request URLs passed to fetch() and XMLHttpRequest.open() using the WHATWG URL parser. For http: and https: schemes, the WHATWG URL standard performs several normalizations prior to resolving the authority/origin: * Backslashes (\) are treated as forward slashes (/) — e.g., /\evil.example/x, \\evil.example/x, \/evil.example/x, https:\\evil.example/x, https:/\evil.example/x. * Leading and trailing C0 control characters and spaces (<= 0x20) are stripped — e.g., ' //evil.example/x', '\0//evil.example/x', '\x1f//evil.example/x'. * ASCII tab (\t), newline (\n), and carriage return (\r) characters are removed anywhere in the input — e.g., '/\t/evil.example/x', '/\n/evil.example/x', 'htt\tps://evil.example/x'.

Because these URLs do not match /^(?:https?:)?\/\//i, xsrfInterceptorFn treats them as relative same-origin URLs and attaches the X-XSRF-TOKEN header, while the browser resolves and dispatches the request to the cross-origin host (evil.example).

Note: Angular 21.0.3+ and 22.x replaced the regular expression with a WHATWG new URL(req.url, locationOrigin) origin comparison in #65683 and were already unaffected. However, the 20.3.x LTS branch retained the regular expression until 20.3.34.

Impact

The token leakage bypasses Angular's built-in XSRF protection on affected versions, allowing an attacker to capture the user's valid X-XSRF-TOKEN header if their server permits the request and custom header via CORS. Once obtained, the attacker can perform Cross-Site Request Forgery (CSRF) attacks against the victim user's session.

Attack Preconditions

• The victim's Angular application must have XSRF protection enabled (enabled by default in HttpClient).
• The attacker must be able to make the application send a state-changing HTTP request (e.g., POST, PUT, DELETE, PATCH) to a URL they control (such as /\attacker.example/api or //attacker.example/api).

Patches

The issue is resolved by parsing and comparing the request URL's origin against the application's current origin using the standard URL constructor (new URL(req.url, locationOrigin)).

* 21.0.3 (and all 22.x releases) * 20.3.34

Workarounds

If you cannot immediately upgrade to a patched version: * Validate and normalize outgoing request URLs using new URL(url, window.location.origin) and verify that parsedUrl.origin === window.location.origin before passing dynamic URLs to mutating HttpClient requests. * Avoid passing untrusted or user-controlled URLs to HttpClient mutating methods.