GHSA-39pv-4j6c-2g6v is a medium-severity (CVSS 6.1) CWE-328 vulnerability in @angular/common. O3 Security confirms whether GHSA-39pv-4j6c-2g6v is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
@angular/common: Weak 32-Bit Cache Key Hashing in `HttpTransferCache` Leading to Cross-Request Data Leakage 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-39pv-4j6c-2g6v.
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.
How urgent is this, really
GHSA-39pv-4j6c-2g6v plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 0 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
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. 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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @angular/common | ≥ 22.0.0-next.0&&< 22.0.1 | 22.0.1 |
| 📦npm | @angular/common | ≥ 21.0.0-next.0&&< 21.2.17 | 21.2.17 |
| 📦npm | @angular/common | ≥ 20.0.0-next.0&&< 20.3.25 | 20.3.25 |
| 📦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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @angular/common to 22.0.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-39pv-4j6c-2g6v 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 pinpoints whether GHSA-39pv-4j6c-2g6v is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-39pv-4j6c-2g6v. 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-39pv-4j6c-2g6v in your dependencies?
O3 detects GHSA-39pv-4j6c-2g6v across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.