--- id: "CVE-2026-111753" kind: "vulnerability" aliases: ["CVE-2026-111753", "GHSA-jfgx-762w-99vr"] title: "@angular/common: XSRF Token Leakage via URL Parsing Discrepancy in Angular HTTP Client (Incomplete fix for CVE-2025-66035)" severity: "medium" cvss: null epss: null exploited: false status: "open" category: "package" products: [{"name": "@angular/common", "fixed": ["21.0.3"], "affected": ">= 21.0.0, < 21.0.3", "ecosystem": "npm"}, {"name": "@angular/common", "fixed": ["20.3.34"], "affected": ">= 20.0.0, < 20.3.34", "ecosystem": "npm"}, {"name": "@angular/common", "fixed": [], "affected": "<= 19.2.25", "ecosystem": "npm"}] ecosystems: ["npm"] tags: ["angular", "browser-apps", "cwe-201", "cwe-359", "npm", "package", "spa"] not_affected_if: ["default-config-no-xsrf-needed", "not-on-affected-versions", "server-side-only", "static-export"] published_at: "2026-10-20T20:37:57+00:00" first_seen_at: "2026-10-23T19:11:32+00:00" updated_at: "2026-10-23T20:13:26+00:00" sources: [{"source": "ghsa", "url": "https://github.com/advisories/GHSA-jfgx-762w-99vr", "first_seen_at": "2026-10-23T19:11:32+00:00"}] --- # @angular/common: XSRF Token Leakage via URL Parsing Discrepancy in Angular HTTP Client (Incomplete fix for CVE-2025-66035) Angular'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, check and fix written by a model from the sources; labelled as such._ ## Affected - npm:@angular/common affected >= 21.0.0, < 21.0.3 fixed 21.0.3 - npm:@angular/common affected >= 20.0.0, < 20.3.34 fixed 20.3.34 - npm:@angular/common affected <= 19.2.25 fixed ? ## How to check 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. ## Fix Upgrade @angular/common to 21.0.3 or later (21.x line, or 22.x), or 20.3.34 on the 20.x LTS line. Until upgraded, validate dynamic URLs with new URL(url, window.location.origin) and require parsedUrl.origin to equal window.location.origin before mutating requests. ## Timeline - 2026-10-23T19:11:32+00:00 ghsa https://github.com/advisories/GHSA-jfgx-762w-99vr ## From the sources 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. --- _Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_