EUVD-2026-38292
GHSA-q6f4-qqrg-jv6x
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
ReconIdentify SSR Angular app behind shared cache
-
DeliveryVictim authenticates and loads page
-
ExploitSSR caches credentialed response in TransferState
-
InstallCDN stores rendered HTML by URL
-
C2Attacker requests same URL unauthenticated
-
ExecuteReceive cached HTML with victim data
-
ImpactParse TransferState to extract private information
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V3 - Web Frontend Security Cache-Control for sensitive pages
|
| Exploitation Conditions | Three concrete conditions must all hold: (1) the Angular application enables SSR with hydration via provideClientHydration() and uses @angular/common in a vulnerable version; (2) the SSR pass issues HttpClient requests that authenticate via a Cookie header or withCredentials: true (Authorization-header auth is already excluded and not vulnerable); (3) a shared caching layer in front of the app (CDN, reverse proxy, or server-side full-page cache) stores the rendered HTML without varying on session identity or marking it private. Limiting factors: applications using only token/Authorization-header auth, applications without SSR/hydration, and deployments where authenticated HTML is already marked Cache-Control: private/no-store are not exposed; exploitation is opportunistic and depends on cache key collisions rather than attacker-controlled inputs. |
| Impact | No NVD CVSS vector was supplied, but the vulnerability chain is realistic and high-impact for affected deployments: an unauthenticated attacker simply browses a cached page and receives another user's private data, requiring no interaction with the victim. The triggering conditions, however, materially limit population at risk - the app must use Angular SSR with hydration, must perform credentialed HTTP calls during the server render, and must sit behind a shared cache that does not vary on user identity. There is no KEV listing and no public POC referenced, so this is best treated as a serious latent data-exposure bug in a popular framework rather than an active mass-exploitation event; EPSS data was not provided. The most important caveat: exploitation is largely opportunistic (cache races/collisions) rather than directed, so impact depends heavily on the downstream caching layer's configuration, which is outside Angular's control. |
| Exploit ScenarioDerived | An authenticated user (Alice) loads an SSR page that fetches /api/profile during server-side render with her session cookie; HttpTransferCache embeds her profile JSON into the page's TransferState block, and the upstream CDN caches the resulting HTML keyed only by URL. Moments later, an unauthenticated attacker requests the same URL, receives Alice's cached HTML, and parses the TransferState block to extract her private profile data. No public exploit identified at time of analysis, but the attack is essentially passive cache-poisoning-by-observation and requires no special tooling. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jun 15, 2026
Information disclosure in @angular/common HttpTransferCache allows unauthenticated attackers to obtain other users' private data when Server-Side Rendering and hydration are enabled. The flaw stems from the cache failing to inspect the withCredentials flag or Cookie header, allowing credentialed responses to be serialized into SSR HTML and inadvertently shared via downstream CDN/reverse-proxy caches. No public exploit identified at time of analysis, but a vendor patch and detailed advisory describing the conditions are available.
RemediationAI
Vendor-released patches are available: upgrade @angular/common to 22.0.0-rc.2, 21.2.15, 20.3.22, or 19.2.23 depending on your major version, per advisory GHSA-q6f4-qqrg-jv6x and PR https://github.com/angular/angular/pull/67964. After patching, requests carrying a Cookie header or sent with withCredentials: true are excluded from HttpTransferCache by default, matching the existing exclusion for Authorization headers. If immediate upgrade is not possible, configure withHttpTransferCacheOptions to disable caching for sensitive endpoints, set includeRequestsWithAuthHeaders to false, or avoid issuing credentialed HTTP calls during SSR by deferring them to the client (trade-off: hydration benefits and time-to-content for authenticated views are reduced). Additionally, harden the downstream cache layer by adding Cache-Control: private, no-store for authenticated HTML responses or by varying cache keys on session cookies (trade-off: lower CDN hit rate for logged-in users). Vendor advisory: https://github.com/angular/angular/security/advisories/GHSA-q6f4-qqrg-jv6x; patch reference: https://github.com/angular/angular/pull/67964; additional context: https://www.herodevs.com/vulnerability-directory/cve-2026-50170.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 6 packages in npm, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Angular's @angular/common npm package provides the HttpTransferCache utility, which optimizes hydration by caching outgoing HEAD/GET HttpClient requests made during SSR and replaying them on the client via TransferState. Prior to the fix, shouldCacheRequest only excluded requests carrying Authorization or Proxy-Authorization headers; it did not check for the Cookie header or the withCredentials flag, both of which are the canonical mechanisms used to associate an HTTP request with a specific authenticated user. This is a CWE-524 (Use of Cache Containing Sensitive Information) flaw: user-specific HTTP responses end up embedded into the rendered HTML payload (TransferState block), and when an upstream shared cache (CDN, reverse proxy, or server-side cache) stores that HTML keyed only by URL, requests from different users can collide on the same cached page.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Network-reachable and unauthenticated, but high complexity because it requires a vulnerable SSR+hydration deployment behind a misconfigured shared cache; high confidentiality impact crossing user-trust boundary (scope change), no integrity or availability impact.
Primary rating from Vendor (https://github.com/angular/angular).
CVSS VectorVendor: https://github.com/angular/angular
Lifecycle Timeline
1DescriptionCVE.org
A vulnerability was discovered in @angular/common when Server-Side Rendering (SSR) and hydration are enabled. The HttpTransferCache utility optimizes hydration by caching outgoing HTTP requests performed during SSR and transferring the cached state to the client-side application via TransferState.
However, the caching mechanism fails to inspect the withCredentials flag or the Cookie header of outgoing requests. As a result, credentialed, user-specific responses may be cached by default in the shared TransferState payload. When these responses are serialized into the HTML, any caching layer (such as a CDN, reverse proxy, or shared server cache) that caches the SSR-rendered HTML page could inadvertently cache and leak one user's private data to other users, leading to a high-severity information disclosure vulnerability.
Impact
Successful exploitation allows an unauthenticated attacker to obtain sensitive, user-specific information of other authenticated users. This occurs when:
- The SSR-rendered HTML containing the cached private data is stored in a shared cache (e.g., CDN, reverse proxy).
- Subsequent requests for the same page receive the cached HTML containing the first user's private data.
Attack Preconditions
- SSR and Hydration Enabled: The Angular application must be configured to use Server-Side Rendering and hydration (e.g., using
provideClientHydration()). - Credentialed Requests during SSR: The application must perform HTTP requests that require user-specific authentication (using cookies or
withCredentials: true) during the initial server-side render. - Shared Caching: The application's HTML responses must be cached by a shared caching layer (CDN, reverse proxy, or server-side cache) without proper cache-control headers to distinguish authenticated users.
Patches
- 22.0.0-rc.2
- 21.2.15
- 20.3.22
- 19.2.23
Executive ViewAI
The @angular/common HttpTransferCache vulnerability creates a data privacy exposure where authenticated user sessions can leak sensitive information through server caches when Server-Side Rendering is active. This affects organizations using Angular SSR architecture and could result in customer data being accessible to unauthorized parties through CDN or reverse proxy caches. A vendor patch is available and remediation should be prioritized.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Exploit-DB