Angular's `HttpTransferCache` caches HTTP requests made during Server-Side Rendering (SSR) so that they can be reused during client-side hydration. This avoids repeating the same HTTP requests on the client. The cached responses are stored in `TransferState` using a cache key generated by hashing request properties (method, response type, mapped URL, serialized body, and sorted query parameters). The cache keys are generated using a weak 32-bit DJB2-like polynomial rolling hash. The 32-bit hash space is extremely small, allowing attackers to find hash collisions. An attacker can easily find a query parameter string (e.g., `q=aaCAZMMM` for a search request) that produces the exact same 32-bit hash as a sensitive endpoint (e.g., `/api/user/profile`). When a victim visits a crafted link containing the colliding parameter, the SSR process executes both the search request and the profile request. Due to the hash collision, the search response overwrites the profile response in the `TransferState` cache. ### Impact When the application attempts to retrieve the cached response for the sensitive endpoint (such as the user's profile), it receives the attacker-controlled response instead. This results in: * **State Poisoning**: The application runs with attacker-forged data, which can lead to bypassing client-side security controls or DOM-based Cross-Site Scripting (XSS) if the data is rendered unsafely. * **Information Leakage**: If the sensitive response is mistakenly associated with the attacker's search results and rendered on the page, the victim's sensitive data may be disclosed to the attacker. ### Patched Versions * 22.0.1 * 21.2.17 * 20.3.25 ### Framework-Level Fix The logic has been updated to use a cryptographically secure **SHA-256** hash algorithm for generating `TransferState` cache keys in `HttpTransferCache`. The cache keys are now 256-bit hexadecimal strings. ### Workarounds If you cannot upgrade immediately, configure your `HttpClient` requests to skip transfer caching for sensitive endpoints: ```ts this.http.get('/api/user/profile', { transferCache: false }); ``` Alternatively, disable the HTTP transfer cache globally in your application bootstrap config: ```ts import { provideClientHydration, withNoHttpTransferCache } from '@angular/platform-browser'; export const appConfig = { providers: [ provideClientHydration( withNoHttpTransferCache() ) ] }; ``` ### Credits This vulnerability was discovered and reported by [CodeMender from Google DeepMind](https://deepmind.google/blog/introducing-codemender-an-ai-agent-for-code-security/).
Angular's `HttpTransferCache` caches HTTP requests made during Server-Side Rendering (SSR) so that they can be reused during client-side hydration. This avoids repeating the same HTTP requests on the client. The cached responses are stored in `TransferState` using a cache key generated by hashing request properties (method, response type, mapped URL, serialized body, and sorted query parameters). The cache keys are generated using a weak 32-bit DJB2-like polynomial rolling hash. The 32-bit hash space is extremely small, allowing attackers to find hash collisions. An attacker can easily find a query parameter string (e.g., `q=aaCAZMMM` for a search request) that produces the exact same 32-bit hash as a sensitive endpoint (e.g., `/api/user/profile`). When a victim visits a crafted link containing the colliding parameter, the SSR process executes both the search request and the profile request. Due to the hash collision, the search response overwrites the profile response in the `TransferState` cache. ### Impact When the application attempts to retrieve the cached response for the sensitive endpoint (such as the user's profile), it receives the attacker-controlled response instead. This results in: * **State Poisoning**: The application runs with attacker-forged data, which can lead to bypassing client-side security controls or DOM-based Cross-Site Scripting (XSS) if the data is rendered unsafely. * **Information Leakage**: If the sensitive response is mistakenly associated with the attacker's search results and rendered on the page, the victim's sensitive data may be disclosed to the attacker. ### Patched Versions * 22.0.1 * 21.2.17 * 20.3.25 ### Framework-Level Fix The logic has been updated to use a cryptographically secure **SHA-256** hash algorithm for generating `TransferState` cache keys in `HttpTransferCache`. The cache keys are now 256-bit hexadecimal strings. ### Workarounds If you cannot upgrade immediately, configure your `HttpClient` requests to skip transfer caching for sensitive endpoints: ```ts this.http.get('/api/user/profile', { transferCache: false }); ``` Alternatively, disable the HTTP transfer cache globally in your application bootstrap config: ```ts import { provideClientHydration, withNoHttpTransferCache } from '@angular/platform-browser'; export const appConfig = { providers: [ provideClientHydration( withNoHttpTransferCache() ) ] }; ``` ### Credits This vulnerability was discovered and reported by [CodeMender from Google DeepMind](https://deepmind.google/blog/introducing-codemender-an-ai-agent-for-code-security/).
Update @angular/common to 22.0.1; @angular/common to 21.2.17; @angular/common to 20.3.25 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scan@angular/common: Weak 32-Bit Cache Key Hashing in `HttpTransferCache` Leading to Cross-Request Data Leakage and State Poisoning affects @angular/common (npm), @angular/common (npm), @angular/common (npm), @angular/common (npm). Severity is high. Angular's `HttpTransferCache` caches HTTP requests made during Server-Side Rendering (SSR) so that they can be reused during client-side hydration. This avoids repeating the same HTTP requests on the client. The cached responses are stored in `TransferState` using a cache key generated by hashing request properties (method, response type, mapped URL, serialized body, and sorted query parameters). The cache keys are generated using a weak 32-bit DJB2-like polynomial rolling hash. The 32-bit hash space is extremely small, allowing attackers to find hash collisions. An attacker can easily find a query parameter string (e.g., `q=aaCAZMMM` for a search request) that produces the exact same 32-bit hash as a sensitive endpoint (e.g., `/api/user/profile`). When a victim visits a crafted link containing the colliding parameter, the SSR process executes both the search request and the profile request. Due to the hash collision, the search response overwrites the profile response in the `TransferState` cache. ### Impact When the application attempts to retrieve the cached response for the sensitive endpoint (such as the user's profile), it receives the attacker-controlled response instead. This results in: * **State Poisoning**: The application runs with attacker-forged data, which can lead to bypassing client-side security controls or DOM-based Cross-Site Scripting (XSS) if the data is rendered unsafely. * **Information Leakage**: If the sensitive response is mistakenly associated with the attacker's search results and rendered on the page, the victim's sensitive data may be disclosed to the attacker. ### Patched Versions * 22.0.1 * 21.2.17 * 20.3.25 ### Framework-Level Fix The logic has been updated to use a cryptographically secure **SHA-256** hash algorithm for generating `TransferState` cache keys in `HttpTransferCache`. The cache keys are now 256-bit hexadecimal strings. ### Workarounds If you cannot upgrade immediately, configure your `HttpClient` requests to skip transfer caching for sensitive endpoints: ```ts this.http.get('/api/user/profile', { transferCache: false }); ``` Alternatively, disable the HTTP transfer cache globally in your application bootstrap config: ```ts import { provideClientHydration, withNoHttpTransferCache } from '@angular/platform-browser'; export const appConfig = { providers: [ provideClientHydration( withNoHttpTransferCache() ) ] }; ``` ### Credits This vulnerability was discovered and reported by [CodeMender from Google DeepMind](https://deepmind.google/blog/introducing-codemender-an-ai-agent-for-code-security/).
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 | >=22.0.0-next.0,<22.0.1 | 22.0.1 |
| @angular/commonnpm | >=21.0.0-next.0,<21.2.17 | 21.2.17 |
| @angular/commonnpm | >=20.0.0-next.0,<20.3.25 | 20.3.25 |
| @angular/commonnpm | <=19.2.25 | Not reported |
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 22.0.1; @angular/common to 21.2.17; @angular/common to 20.3.25 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scan@angular/common: Weak 32-Bit Cache Key Hashing in `HttpTransferCache` Leading to Cross-Request Data Leakage and State Poisoning affects @angular/common (npm), @angular/common (npm), @angular/common (npm), @angular/common (npm). Severity is high. Angular's `HttpTransferCache` caches HTTP requests made during Server-Side Rendering (SSR) so that they can be reused during client-side hydration. This avoids repeating the same HTTP requests on the client. The cached responses are stored in `TransferState` using a cache key generated by hashing request properties (method, response type, mapped URL, serialized body, and sorted query parameters). The cache keys are generated using a weak 32-bit DJB2-like polynomial rolling hash. The 32-bit hash space is extremely small, allowing attackers to find hash collisions. An attacker can easily find a query parameter string (e.g., `q=aaCAZMMM` for a search request) that produces the exact same 32-bit hash as a sensitive endpoint (e.g., `/api/user/profile`). When a victim visits a crafted link containing the colliding parameter, the SSR process executes both the search request and the profile request. Due to the hash collision, the search response overwrites the profile response in the `TransferState` cache. ### Impact When the application attempts to retrieve the cached response for the sensitive endpoint (such as the user's profile), it receives the attacker-controlled response instead. This results in: * **State Poisoning**: The application runs with attacker-forged data, which can lead to bypassing client-side security controls or DOM-based Cross-Site Scripting (XSS) if the data is rendered unsafely. * **Information Leakage**: If the sensitive response is mistakenly associated with the attacker's search results and rendered on the page, the victim's sensitive data may be disclosed to the attacker. ### Patched Versions * 22.0.1 * 21.2.17 * 20.3.25 ### Framework-Level Fix The logic has been updated to use a cryptographically secure **SHA-256** hash algorithm for generating `TransferState` cache keys in `HttpTransferCache`. The cache keys are now 256-bit hexadecimal strings. ### Workarounds If you cannot upgrade immediately, configure your `HttpClient` requests to skip transfer caching for sensitive endpoints: ```ts this.http.get('/api/user/profile', { transferCache: false }); ``` Alternatively, disable the HTTP transfer cache globally in your application bootstrap config: ```ts import { provideClientHydration, withNoHttpTransferCache } from '@angular/platform-browser'; export const appConfig = { providers: [ provideClientHydration( withNoHttpTransferCache() ) ] }; ``` ### Credits This vulnerability was discovered and reported by [CodeMender from Google DeepMind](https://deepmind.google/blog/introducing-codemender-an-ai-agent-for-code-security/).
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 | >=22.0.0-next.0,<22.0.1 | 22.0.1 |
| @angular/commonnpm | >=21.0.0-next.0,<21.2.17 | 21.2.17 |
| @angular/commonnpm | >=20.0.0-next.0,<20.3.25 | 20.3.25 |
| @angular/commonnpm | <=19.2.25 | Not reported |
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