An incomplete fix for "GHSA-58c5-g7wp-6w37" (https://github.com/angular/angular/security/advisories/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" (https://github.com/angular/angular/pull/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 1. The victim's Angular application must have XSRF protection enabled (enabled by default in "HttpClient"). 2. 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. ### References * Original Advisory: https://github.com/angular/angular/security/advisories/GHSA-58c5-g7wp-6w37 ("CVE-2025-66035") * Issue: https://github.com/angular/angular/issues/71294 * Fix PR (21.x / 22.x): https://github.com/angular/angular/pull/65683 * Backport PR (20.3.x): https://github.com/angular/angular/pull/71295