| Package | Affected versions | Patched versions |
|---|---|---|
| @angular/common | ≥ 20.0.0, < 20.3.34≥ 21.0.0, < 21.0.3≤ 19.2.25 | 20.3.3421.0.3 |
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.
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:
\) are treated as forward slashes (/) — e.g., /\evil.example/x, \\evil.example/x, \/evil.example/x, https:\\evil.example/x, https:/\evil.example/x.<= 0x20) are stripped — e.g., ' //evil.example/x', '\0//evil.example/x', '\x1f//evil.example/x'.\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 .
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site free20.3.34The 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.
HttpClient).POST, PUT, DELETE, PATCH) to a URL they control (such as /\attacker.example/api or //attacker.example/api).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.34If you cannot immediately upgrade to a patched version:
new URL(url, window.location.origin) and verify that parsedUrl.origin === window.location.origin before passing dynamic URLs to mutating HttpClient requests.HttpClient mutating methods.