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 1. The victim's Angular application must have **XSRF protection enabled**. 2. 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 1. The victim's Angular application must have **XSRF protection enabled**. 2. 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.
Update @angular/common to 21.0.1; @angular/common to 20.3.14; @angular/common to 19.2.16 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanAngular is Vulnerable to XSRF Token Leakage via Protocol-Relative URLs in Angular HTTP Client affects @angular/common (npm), @angular/common (npm), @angular/common (npm). Severity is high. 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 1. The victim's Angular application must have **XSRF protection enabled**. 2. 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.
AI coding agents often install or upgrade packages automatically in npm. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| @angular/commonnpm | >=21.0.0-next.0,<21.0.1 | 21.0.1 |
| @angular/commonnpm | >=20.0.0-next.0,<20.3.14 | 20.3.14 |
| @angular/commonnpm | <19.2.16 | 19.2.16 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate @angular/common to 21.0.1; @angular/common to 20.3.14; @angular/common to 19.2.16 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanAngular is Vulnerable to XSRF Token Leakage via Protocol-Relative URLs in Angular HTTP Client affects @angular/common (npm), @angular/common (npm), @angular/common (npm). Severity is high. 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 1. The victim's Angular application must have **XSRF protection enabled**. 2. 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.
AI coding agents often install or upgrade packages automatically in npm. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| @angular/commonnpm | >=21.0.0-next.0,<21.0.1 | 21.0.1 |
| @angular/commonnpm | >=20.0.0-next.0,<20.3.14 | 20.3.14 |
| @angular/commonnpm | <19.2.16 | 19.2.16 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard