GHSA-jhpw-976m-542j — @angular/common
Fix: angular/angular#68571GHSA-jhpw-976m-542j is a CWE-345 vulnerability in @angular/common. A fix is available for @angular/common — see the affected versions and patch details below.
Angular: Cache-Key Ambiguity in HttpTransferCache Leading to Cross-Request Response Reuse and State Poisoning
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-jhpw-976m-542j.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
@angular/commonnpmDescription
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()
)
]
};
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @angular/common | ≥ 22.0.0-next.0&&< 22.0.2 | 22.0.2npm install @angular/common@22.0.2 |
| 📦npm | @angular/common | ≥ 21.0.0-next.0&&< 21.2.19 | 21.2.19npm install @angular/common@21.2.19 |
| 📦npm | @angular/common | ≥ 20.0.0-next.0&&< 20.3.27 | 20.3.27npm install @angular/common@20.3.27 |
| 📦npm | @angular/common | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @angular/common, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update @angular/common to 22.0.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-jhpw-976m-542j is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-jhpw-976m-542j can be triaged on real exposure rather than presence alone.
Tailored to GHSA-jhpw-976m-542j. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-jhpw-976m-542j in your dependencies?
O3 Security finds GHSA-jhpw-976m-542j across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.