Packages / @angular/common / Security
@angular/common: Weak 32-Bit Cache Key Hashing in `HttpTransferCache` Leading to Cross-Request Data Leakage and State Poisoning
Affected releases · @angular/common
- 22.x22.0.0Fixed in 22.0.1
- 21.x21.0.0 – 21.2.16Fixed in 21.2.17
- 20.x20.0.0 – 20.3.24Fixed in 20.3.25
- 19.x19.0.0 – 19.2.25No fix on this line yet
- 18.x and older2.0.0 – 18.2.14No fix, no longer updated
On 22.x, the newest line:
npm install @angular/common@22.0.1Affected
22.0.0
1 release
Fixed
22.0.1 – 22.2.3
21 releases, latest
Affected
21.0.0 – 21.2.16
34 releases
Fixed
21.2.17 – 21.2.25
9 releases
Affected
20.0.0 – 20.3.24
46 releases
Fixed
20.3.25 – 20.3.34
10 releases
Affected
19.0.0 – 19.2.25
43 releases
Affected
18.0.0 – 18.2.14
29 releases
Affected
17.0.0 – 17.3.12
32 releases
Affected
16.0.0 – 16.2.12
30 releases
Affected
15.0.0 – 15.2.10
22 releases
Affected
14.0.0 – 14.3.0
26 releases
Affected
13.0.0 – 13.4.0
30 releases
Affected
12.0.0 – 12.2.17
30 releases
Affected
11.0.0 – 11.2.14
28 releases
Affected
10.0.0 – 10.2.5
28 releases
Affected
9.0.0 – 9.1.13
22 releases
Affected
8.0.0 – 8.2.14
23 releases
Affected
7.0.0 – 7.2.16
27 releases
Affected
6.0.0 – 6.1.10
20 releases
Affected
5.0.0 – 5.2.11
22 releases
Affected
4.0.0 – 4.4.7
30 releases
Affected
2.0.0 – 2.4.10
24 releases
Is your project affected?
Paste your package.json, or type the range you declare for @angular/common. It is read in your browser and sent nowhere.
What happens
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:
this.http.get('/api/user/profile', {
transferCache: false
});Alternatively, disable the HTTP transfer cache globally in your application bootstrap config:
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.