Angular HttpClient CVE-2026-111753

Requires all of: (1) XSRF protection enabled in HttpClient (the default); (2) the application passing an attacker-controllable or untrusted URL into a mutating HttpClient method (POST/PUT/DELETE/PATCH) - if the app only ever uses static, developer-authored same-origin paths, the bypass has no injection point; (3) a crafted URL exploiting the regex/WHATWG parsing gap, e.g. leading backslashes (/\attacker.example/api), protocol-relative forms with leading spaces/C0 control bytes (' //attacker.example/api', '\x1f//attacker.example/x'), or embedded tab/newline/CR inside the scheme ('htt\tps://...'); and (4) the attacker's cross-origin server returning CORS headers that permit the request and the custom X-XSRF-TOKEN header, otherwise the browser blocks the token from being usable. Limiting factors: only versions 20.0.0-20.3.33, 21.0.0-21.0.2, and ≤19.2.25 are affected (21.0.3+ and all 22.x already use the WHATWG origin check); impact is confined to the single XSRF token rather than full session data; and exploitation hinges on the application design choice of feeding dynamic URLs to mutating requests.

No CVSS vector, EPSS, KEV, or POC signal is present in the input, so quantitative exploitation scoring is unavailable and must be inferred. This is an incomplete-fix regression (follows CVE-2025-66035) in @angular/common's HttpClient XSRF interceptor, where a regex (/^(?:https?:)?\/\//i) used to detect absolute URLs diverges from the browser's WHATWG URL parser, letting obfuscated URLs (backslashes, C0 control chars, embedded tab/newline/CR) be treated as same-origin and have the X-XSRF-TOKEN header attached while the browser actually dispatches cross-origin. The real-world risk is conditional rather than broadly wormable: exploitation requires the victim application to pass attacker-influenceable or untrusted URLs into mutating HttpClient requests, AND the attacker's server to permit the request plus the custom X-XSRF-TOKEN header via CORS. Because the X-XSRF-TOKEN is a security credential, the conceptual severity of a CSRF-protection bypass is real, but the daisy-chain of preconditions (dynamic/untrusted URL sink + permissive CORS on the attacker side) keeps this well below a default-config unauthenticated-RCE class issue. Net: a genuine but moderate-priority issue - patch promptly on affected LTS/current branches, but it is not a mass-exploitation 'drop everything' event absent evidence of active exploitation, which the input does not provide. Note the data gap: the official GHSA (GHSA-jfgx-762w-99vr) almost certainly carries a severity rating, but it was not supplied here - verify the vendor score.

A victim is logged into an Angular application (v20.0.0-20.3.33, v21.0.0-21.0.2, or any ≤19.2.25) that passes a dynamic or attacker-influenceable URL into a mutating HttpClient call. The attacker supplies a URL such as '/\attacker.example/api' or ' //attacker.example/api' that the interceptor's regex misreads as relative/same-origin, so the browser's WHATWG parser resolves it to attacker.example and sends the valid X-XSRF-TOKEN header cross-origin; the attacker's CORS-permissive endpoint captures the token and replays it to forge state-changing requests against the user's session. No public exploit identified at time of analysis, though the advisory documents concrete bypass payloads.