{"id":"CVE-2026-111753","aliases":["GHSA-jfgx-762w-99vr"],"title":"@angular/common: XSRF Token Leakage via URL Parsing Discrepancy in Angular HTTP Client (Incomplete fix for CVE-2025-66035)","summary":"@angular/common: XSRF Token Leakage via URL Parsing Discrepancy in Angular HTTP Client (Incomplete fix for CVE-2025-66035)","severity":"medium","cwe":["CWE-201","CWE-359"],"vendor":"angular","product":"@angular/common","ecosystem":"npm","affected":["@angular/common >= 21.0.0, < 21.0.3","@angular/common >= 20.0.0, < 20.3.34","@angular/common <= 19.2.25"],"patched":["@angular/common 21.0.3","@angular/common 20.3.34"],"published":"2026-10-20","updated":"2026-10-20","sourceUpdated":"2026-10-20T20:37:58Z","source":"GHSA","sourceUrl":"https://github.com/advisories/GHSA-jfgx-762w-99vr","references":[{"url":"https://github.com/angular/angular/security/advisories/GHSA-jfgx-762w-99vr"},{"url":"https://github.com/angular/angular/pull/65683"},{"url":"https://github.com/angular/angular/pull/71295"},{"url":"https://github.com/angular/angular/commit/0659d11c854c9c6b886a2e925afef98d70bb005f"},{"url":"https://github.com/angular/angular/commit/20474d3f0fd7c64071add6e84acf720627e5c19b"},{"url":"https://github.com/angular/angular/commit/933ce817d53e25926844fa56af8230816763d08e"},{"url":"https://github.com/advisories/GHSA-jfgx-762w-99vr"}],"tags":["ghsa","npm"],"ingestedAt":"2026-10-20T21:19:21.138Z","slug":"CVE-2026-111753","body":"## Overview\n\nAn 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.\n\n### Technical Description\n\nTo 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.\n\nHowever, 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:\n* 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`.\n* Leading and trailing C0 control characters and spaces (`<= 0x20`) are stripped — e.g., `' //evil.example/x'`, `'\\0//evil.example/x'`, `'\\x1f//evil.example/x'`.\n* 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'`.\n\nBecause 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`).\n\nNote: 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`.\n\n### Impact\n\nThe 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.\n\n### Attack Preconditions\n\n1. The victim's Angular application must have **XSRF protection enabled** (enabled by default in `HttpClient`).\n2. 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`).\n\n### Patches\n\nThe 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)`).\n\n* `21.0.3` (and all `22.x` releases)\n* `20.3.34`\n\n### Workarounds\n\nIf you cannot immediately upgrade to a patched version:\n* 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.\n* Avoid passing untrusted or user-controlled URLs to `HttpClient` mutating methods.\n\n## Affected packages\n\n- `@angular/common >= 21.0.0, < 21.0.3`\n- `@angular/common >= 20.0.0, < 20.3.34`\n- `@angular/common <= 19.2.25`\n\n## Remediation\n\nUpgrade to a patched release:\n\n- `@angular/common 21.0.3`\n- `@angular/common 20.3.34`","depth":"sunlit","depthScore":28,"depthScoreParts":{"impact":27.5,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[]}