Headline
GHSA-58c5-g7wp-6w37: Angular is Vulnerable to XSRF Token Leakage via Protocol-Relative URLs in Angular HTTP Client
The vulnerability is a Credential Leak by App Logic that leads to the unauthorized disclosure of the Cross-Site Request Forgery (XSRF) token to an attacker-controlled domain.
Angular’s HttpClient has a built-in XSRF protection mechanism that works by checking if a request URL starts with a protocol (http:// or https://) to determine if it is cross-origin. If the URL starts with protocol-relative URL (//), it is incorrectly treated as a same-origin request, and the XSRF token is automatically added to the X-XSRF-TOKEN header.
Impact
The token leakage completely bypasses Angular’s built-in CSRF protection, allowing an attacker to capture the user’s valid XSRF token. Once the token is obtained, the attacker can perform arbitrary Cross-Site Request Forgery (CSRF) attacks against the victim user’s session.
Attack Preconditions
- The victim’s Angular application must have XSRF protection enabled.
- The attacker must be able to make the application send a state-changing HTTP request (e.g.,
POST) to a protocol-relative URL (e.g.,//attacker.com) that they control.
Patches
- 19.2.16
- 20.3.14
- 21.0.1
Workarounds
Developers should avoid using protocol-relative URLs (URLs starting with //) in HttpClient requests. All backend communication URLs should be hardcoded as relative paths (starting with a single /) or fully qualified, trusted absolute URLs.
The vulnerability is a Credential Leak by App Logic that leads to the unauthorized disclosure of the Cross-Site Request Forgery (XSRF) token to an attacker-controlled domain.
Angular’s HttpClient has a built-in XSRF protection mechanism that works by checking if a request URL starts with a protocol (http:// or https://) to determine if it is cross-origin. If the URL starts with protocol-relative URL (//), it is incorrectly treated as a same-origin request, and the XSRF token is automatically added to the X-XSRF-TOKEN header.
Impact
The token leakage completely bypasses Angular’s built-in CSRF protection, allowing an attacker to capture the user’s valid XSRF token. Once the token is obtained, the attacker can perform arbitrary Cross-Site Request Forgery (CSRF) attacks against the victim user’s session.
Attack Preconditions
- The victim’s Angular application must have XSRF protection enabled.
- The attacker must be able to make the application send a state-changing HTTP request (e.g., POST) to a protocol-relative URL (e.g., //attacker.com) that they control.
Patches
- 19.2.16
- 20.3.14
- 21.0.1
Workarounds
Developers should avoid using protocol-relative URLs (URLs starting with //) in HttpClient requests. All backend communication URLs should be hardcoded as relative paths (starting with a single /) or fully qualified, trusted absolute URLs.
References
- GHSA-58c5-g7wp-6w37
- angular/angular@0276479
- angular/angular@05fe668
- angular/angular@3240d85
- https://github.com/angular/angular/releases/tag/19.2.16
- https://github.com/angular/angular/releases/tag/20.3.14
- https://github.com/angular/angular/releases/tag/21.0.1
Related news
Hackers aren’t kicking down the door anymore. They just use the same tools we use every day — code packages, cloud accounts, email, chat, phones, and “trusted” partners — and turn them against us. One bad download can leak your keys. One weak vendor can expose many customers at once. One guest invite, one link on a phone, one bug in a common tool, and suddenly your mail, chats, repos, and