CVE-2026-111753

Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Prior to 20.3.34 and 21.0.3, the @angular/common HttpClient function xsrfInterceptorFn uses a regular expression that does not normalize request URLs in the same way as the browser's WHATWG URL parser. With XSRF protection enabled, a mutating HTTP request to an attacker-controlled URL containing backslashes, stripped control characters or spaces, or removable ASCII whitespace can be misclassified as relative and same-origin, causing the interceptor to attach the X-XSRF-TOKEN header before the browser dispatches the request to a cross-origin host. With permissive CORS handling for the custom header, the attacker can obtain the victim's XSRF token and use it to perform cross-site request forgery against the victim session. This issue is fixed in versions 20.3.34 and 21.0.3.

Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Prior to 20.3.34 and 21.0.3, the @angular/common HttpClient function xsrfInterceptorFn uses a regular expression that does not normalize request URLs in the same way as the browser's WHATWG URL parser. With XSRF protection enabled, a mutating HTTP request to an attacker-controlled URL containing backslashes, stripped control characters or spaces, or removable ASCII whitespace can be misclassified as relative and same-origin, causing the interceptor to attach the X-XSRF-TOKEN header before the browser dispatches the request to a cross-origin host. With permissive CORS handling for the custom header, the attacker can obtain the victim's XSRF token and use it to perform cross-site request forgery against the victim session. This issue is fixed in versions 20.3.34 and 21.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.

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 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.

Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Prior to 20.3.34 and 21.0.3, the @angular/common HttpClient function xsrfInterceptorFn uses a regular expression that does not normalize request URLs in the same way as the browser's WHATWG URL parser. With XSRF protection enabled, a mutating HTTP request to an attacker-controlled URL containing backslashes, stripped control characters or spaces, or removable ASCII whitespace can be misclassified as relative and same-origin, causing the interceptor to attach the X-XSRF-TOKEN header before the browser dispatches the request to a cross-origin host. With permissive CORS handling for the custom header, the attacker can obtain the victim's XSRF token and use it to perform cross-site request forgery against the victim session. This issue is fixed in versions 20.3.34 and 21.0.3.

Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Prior to 20.3.34 and 21.0.3, the @angular/common HttpClient function xsrfInterceptorFn uses a regular expression that does not normalize request URLs in the same way as the browser's WHATWG URL parser. With XSRF protection enabled, a mutating HTTP request to an attacker-controlled URL containing backslashes, stripped control characters or spaces, or removable ASCII whitespace can be misclassified as relative and same-origin, causing the interceptor to attach the X-XSRF-TOKEN header before the browser dispatches the request to a cross-origin host. With permissive CORS handling for the custom header, the attacker can obtain the victim's XSRF token and use it to perform cross-site request forgery against the victim session. This issue is fixed in versions 20.3.34 and 21.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.

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 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.