GHSA-JHPW-976M-542J
Vulnerability from github – Published: 2026-08-03 15:59 – Updated: 2026-08-03 15:59Angular'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": [
{
"package": {
"ecosystem": "npm",
"name": "@angular/common"
},
"ranges": [
{
"events": [
{
"introduced": "22.0.0-next.0"
},
{
"fixed": "22.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@angular/common"
},
"ranges": [
{
"events": [
{
"introduced": "21.0.0-next.0"
},
{
"fixed": "21.2.19"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@angular/common"
},
"ranges": [
{
"events": [
{
"introduced": "20.0.0-next.0"
},
{
"fixed": "20.3.27"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@angular/common"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "19.2.25"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-68945"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-03T15:59:13Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Angular\u0027s `HttpTransferCache` caches HTTP requests made during Server-Side Rendering (SSR) so that they can be reused during client-side hydration.\n\nDuring SSR, `HttpTransferCache` previously generated identical key material for distinct request parameters when repeated values were present because repeated values were joined with commas:\n\n```ts\nnew HttpParams().set(\u0027role\u0027, \u0027user,admin\u0027)\nnew HttpParams().append(\u0027role\u0027, \u0027user\u0027).append(\u0027role\u0027, \u0027admin\u0027)\n```\n\nBoth requests previously serialized as `role=user,admin`, allowing distinct `HttpClient` requests to produce the same transfer-cache key material.\n\n### Impact\n\nIn 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\u0027s server-rendered output can be based on the wrong backend response because the trusted request is not dispatched. This can lead to:\n\n- **State Poisoning**: Using incorrect or attacker-influenced cached responses for subsequent application logic.\n- **Cross-Request Response Reuse**: Reusing cached responses across requests with semantically different parameters.\n\n### Patched Versions\n\n- 22.0.2\n- 21.2.19\n- 20.3.27\n\n### Workarounds\n\nIf you cannot upgrade immediately, configure your `HttpClient` requests to skip transfer caching for sensitive endpoints where repeated parameter keys are used:\n\n```ts\nthis.http.get(\u0027/api/resource\u0027, {\n transferCache: false\n});\n```\n\nAlternatively, disable the HTTP transfer cache globally in your application bootstrap config:\n\n```ts\nimport { provideClientHydration, withNoHttpTransferCache } from \u0027@angular/platform-browser\u0027;\n\nexport const appConfig = {\n providers: [\n provideClientHydration(\n withNoHttpTransferCache()\n )\n ]\n};\n```",
"id": "GHSA-jhpw-976m-542j",
"modified": "2026-08-03T15:59:13Z",
"published": "2026-08-03T15:59:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/angular/angular/security/advisories/GHSA-jhpw-976m-542j"
},
{
"type": "WEB",
"url": "https://github.com/angular/angular/pull/68571"
},
{
"type": "WEB",
"url": "https://github.com/angular/angular/commit/6867f77ec779a0a24f6339ad6c775f444202103c"
},
{
"type": "WEB",
"url": "https://github.com/angular/angular/commit/948a8d6831e8920b54663ec79421da95210e0e35"
},
{
"type": "WEB",
"url": "https://github.com/angular/angular/commit/a64e2883e9dc4abdac70209129be303de79e5b2b"
},
{
"type": "WEB",
"url": "https://github.com/angular/angular/commit/a6c7fc5c13e6e494a4c9bd8e773b8d4b2a99b20c"
},
{
"type": "PACKAGE",
"url": "https://github.com/angular/angular"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Angular: Cache-Key Ambiguity in HttpTransferCache Leading to Cross-Request Response Reuse and State Poisoning"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.