Live › vulnerability › CVE-2026-111753
Go to dashboardAngular's HttpClient XSRF interceptor uses a regex to skip absolute URLs, but browsers parse URLs with backslashes, tabs, newlines or leading control characters differently, so the X-XSRF-TOKEN header is sent to attacker-chosen cross-origin hosts. An attacker who can make the app send a POST, PUT, DELETE or PATCH to a crafted URL can capture the user's XSRF token and use it for CSRF against their session.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 19:11 UTC. All times on this page are UTC.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| @angular/common | npm | >= 21.0.0, < 21.0.3 | 21.0.3 |
| @angular/common | npm | >= 20.0.0, < 20.3.34 | 20.3.34 |
| @angular/common | npm | <= 19.2.25 | – |
Run npm ls @angular/common and check whether the resolved version is in the affected ranges: 21.0.0 to before 21.0.3, 20.0.0 to before 20.3.34, or 19.2.25 and below.
Search app code for HttpClient mutating calls whose URL comes from user input or config.
21.0.3 or later (21.x line, or 22.x), or 20.3.34 on the 20.x LTS lineEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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 20.3.34.
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.
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.This page as .md · .json · in your agent: get_signal("CVE-2026-111753")
GitHub Advisory Database, CC-BY 4.0. Posts quoted belong to their authors.