Angular: Cache-Key Ambiguity in HttpTransferCache Leading to Cross-Request Response Reuse and State Poisoning
Published 3 Aug 2026 · Updated 3 Aug 2026
Affected packages
- Affected
- >=22.0.0-next.0 <22.0.2
- Fixed in
- 22.0.2
npm install @angular/common@22.0.2- Affected
- >=21.0.0-next.0 <21.2.19
- Fixed in
- 21.2.19
npm install @angular/common@21.2.19- Affected
- >=20.0.0-next.0 <20.3.27
- Fixed in
- 20.3.27
npm install @angular/common@20.3.27- Affected
- <=19.2.25
- Fixed in
- No fix released
Details
Angular's HttpTransferCache caches HTTP requests made during Server-Side Rendering (SSR) so that they can be reused during client-side hydration.
During SSR, HttpTransferCache previously generated identical key material for distinct request parameters when repeated values were present because repeated values were joined with commas:
new HttpParams().set('role', 'user,admin')
new HttpParams().append('role', 'user').append('role', 'admin')Both requests previously serialized as role=user,admin, allowing distinct HttpClient requests to produce the same transfer-cache key material.
Impact
In an SSR application, this cache-key ambiguity can make a later security-sensitive HttpClient request receive the response from an earlier semantically different request in the same render. For example, an attacker-influenced scalar-comma request can be cached and then replayed as the response for a trusted repeated-param authorization or data request to the same URL. As a result, Angular's server-rendered output can be based on the wrong backend response because the trusted request is not dispatched. This can lead to:
- State Poisoning: Using incorrect or attacker-influenced cached responses for subsequent application logic.
- Cross-Request Response Reuse: Reusing cached responses across requests with semantically different parameters.
Patched Versions
- 22.0.2
- 21.2.19
- 20.3.27
Workarounds
If you cannot upgrade immediately, configure your HttpClient requests to skip transfer caching for sensitive endpoints where repeated parameter keys are used:
this.http.get('/api/resource', {
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()
)
]
};Is GHSA-jhpw-976m-542j in any of your client repos?
Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected @angular/common, and gives you the command that fixes it.
References
- Linkgithub.com/angular/angular/security/advisories/GHSA-jhpw-976m-542j
- Linkgithub.com/angular/angular/pull/68571
- Linkgithub.com/angular/angular/commit/6867f77ec779a0a24f6339ad6c775f444202103c
- Linkgithub.com/angular/angular/commit/948a8d6831e8920b54663ec79421da95210e0e35
- Linkgithub.com/angular/angular/commit/a64e2883e9dc4abdac70209129be303de79e5b2b
- Linkgithub.com/angular/angular/commit/a6c7fc5c13e6e494a4c9bd8e773b8d4b2a99b20c
- Packagegithub.com/angular/angular
Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.