CVE-2026-88059

What it actually does

Angular's @angular/common HttpTransferCache can persist an authenticated HTTP response into TransferState during Server-Side Rendering when a hierarchical HttpClient is configured with withRequestsMadeViaParent. The child TransferCache keys and stores the response while the request is still anonymous; a parent interceptor later injects an Authorization header, cookie, or API token. The parent cache correctly skips the now-authenticated request, but the child has already stored the private payload, which is serialized as JSON into the ng-state script of the SSR HTML. Subsequent recipients of that HTML—typically via a CDN, reverse proxy, or application cache—receive another user's sensitive response data during hydration.

Why it matters to the business

Applications that SSR personalized pages and share HTML across users can leak one visitor's private API data (account details, tokens, PII, or other authenticated payloads) to unrelated visitors. That can drive privacy incidents, regulatory exposure, customer distrust, and forced cache flushes or emergency releases. Complexity is high and CVSS is 4.0, but a public exploit is available and the issue has been public for several weeks, so any Angular SSR estate using hierarchical HttpClient plus shared HTML caches should be treated as time-sensitive until patched or mitigated.

How an attack unfolds

An attacker does not need to authenticate or interact with a victim. They need an Angular app that uses provideClientHydration, a child provideHttpClient that delegates with withRequestsMadeViaParent, parent-level credential injection, and SSR HTML that is reused across users. When an authenticated user (or the attacker inducing such a request) hits a cacheable SSR route, the child TransferCache stores the private response before credentials are applied. That HTML, including the ng-state blob, is then stored by a CDN, reverse proxy, or app cache. Any later unauthenticated or unauthorized visitor who is served the same cached document can read the earlier user's sensitive response data from the embedded TransferState JSON. Public exploit material lowers the bar for reproducing this on misconfigured apps.

How to fix it

Upgrade @angular/common to 20.3.28, 21.2.20, or 22.1.1 (or later in the corresponding major line). Until upgrades land, attach credentials on the child HttpClient rather than only in a parent interceptor; exclude sensitive endpoints with withHttpTransferCacheOptions; disable transfer caching on authenticated or personalized routes; and mark personalized SSR HTML Cache-Control private or no-store so CDNs and reverse proxies cannot reuse it across users. Review hierarchical provideHttpClient / withRequestsMadeViaParent setups and any interceptors that add Authorization headers, cookies, or API tokens after the child cache decision.

How to confirm the fix worked

Confirm package versions of @angular/common are at least 20.3.28, 21.2.20, or 22.1.1. In a non-production replica of the SSR path, render an authenticated route that uses hierarchical HttpClient, then inspect the emitted HTML and verify TransferState/ng-state does not contain that user's authenticated response. Confirm CDN and origin Cache-Control for those routes is private or no-store. After deploy, sample hydration HTML for previously vulnerable routes and verify child TransferCache no longer stores responses that only become authenticated in a parent interceptor.

Typical attack path

1. Locate Angular SSR applications that enable client hydration, hierarchical HttpClient with withRequestsMadeViaParent, and parent-level credential injection
2. Confirm that SSR HTML for personalized or authenticated routes is stored and reused by a CDN, reverse proxy, or application cache
3. Wait for or induce an authenticated request that causes the child TransferCache to store a private API response in TransferState
4. Retrieve the cached SSR HTML as an unauthenticated or different user
5. Parse the ng-state script and extract the previously cached authenticated response body

How to detect it

This is a cache-borne disclosure, so look for evidence that SSR HTML containing another user's TransferState was served broadly—not for a malware implant. Review CDN, reverse-proxy, and origin cache logs for HIT/MISS on Angular SSR documents that should have been private, especially routes that call authenticated APIs. Compare ng-state JSON across responses delivered to different users or to anonymous sessions and flag TransferState entries whose URLs or bodies match authenticated endpoints (account, profile, session, payment, or similarly private APIs). Inspect archived or cached HTML for an ng-state script that embeds Authorization-gated response bodies. Application access logs showing an unauthenticated client receiving a document generated during an authenticated SSR render, plus WAF or CDN samples of those bodies, are the strongest historical artifacts. Named threat-actor attribution is not established for this CVE; treat opportunistic scraping of cached HTML as the realistic post-exploit pattern.

• <script id="ng-state" type="application/json">
• TransferState
• HttpTransferCache
• withRequestsMadeViaParent
• provideClientHydration
• Cache-Control: public
• x-cache: HIT
• "u":{"b":
• Authorization

What your security team should do

• Patch Angular to 20.3.28, 21.2.20, or 22.1.1 immediately on all SSR applications, prioritizing those behind shared HTML caches
• Inventory apps using provideClientHydration, withRequestsMadeViaParent, and parent interceptors that inject credentials
• Set Cache-Control private or no-store on personalized SSR HTML and purge CDN/reverse-proxy caches for those routes
• Exclude sensitive APIs from HttpTransferCache via withHttpTransferCacheOptions or disable transfer caching on authenticated routes
• Hunt cached HTML and ng-state blobs for cross-user authenticated payloads given that public exploit code exists
• Add regression tests so hierarchical HttpClient plus SSR cannot persist credentialed responses into TransferState