CVE-2026-88059: 
JavaScript vulnerability analysis and mitigation

CVE-2026-88059 is an information disclosure vulnerability in Angular's @angular/common package, specifically in the HttpTransferCache component used during Server-Side Rendering (SSR) with hydration. When an application uses a hierarchical HttpClient configured with withRequestsMadeViaParent(), the child TransferCache interceptor incorrectly caches authenticated responses — even when the parent interceptor chain adds authentication credentials — serializing private response data as JSON in the ng-state script tag of the SSR HTML. This cached HTML can then be served to subsequent unauthenticated or unauthorized users via a CDN, reverse proxy, or application cache. Affected versions include @angular/common ≤ 19.2.25, 20.0.0–20.3.27, 21.0.0–21.2.19, and 22.0.0–22.1.0. The vulnerability has a CVSS v3.1 base score of 4.0 (Medium) (GitHub Advisory, Red Hat CVE).

The root cause is a race condition in interceptor evaluation order (CWE-524: Use of Cache Containing Sensitive Information; CWE-200: Exposure of Sensitive Information to an Unauthorized Actor). When a child HttpClient uses withRequestsMadeViaParent(), the child's TransferCache interceptor evaluates cache eligibility on the outgoing request before it is delegated to the parent's interceptor chain. If the parent interceptor subsequently injects authentication credentials (e.g., Authorization header, session cookie, or API token), the parent's TransferCache correctly skips caching the now-authenticated request — but the child's TransferCache has already marked the request as cacheable and stores the private authenticated response in TransferState. This TransferState is serialized as JSON inside the <script id="ng-state"> tag in the SSR-rendered HTML page. The fix (PR #69778) introduces an internal HttpParentBackend class so the interceptor handler can distinguish delegated clients from independent child configurations, ensuring HttpTransferCache evaluates cache eligibility only after all parent interceptors have run (GitHub Advisory, Fix PR, Fix Commit).

Successful exploitation allows sensitive, user-specific data from an authenticated user's session to be leaked to unauthenticated or unauthorized visitors. The leaked data may include authentication tokens, session cookies, API credentials, and other private application data embedded in the cached SSR HTML page. The impact is limited to confidentiality (no integrity or availability impact), and exploitation requires a shared caching layer (CDN, reverse proxy, or application cache) to serve the poisoned HTML to subsequent users. The scope is changed because the vulnerability in the Angular framework component affects data belonging to users of the application (GitHub Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of disclosure. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires a specific combination of conditions: SSR with hydration enabled (provideClientHydration()), a hierarchical HttpClient using withRequestsMadeViaParent(), parent-level credential injection via interceptors, and a shared HTML caching layer — making opportunistic exploitation unlikely without targeted knowledge of the application's architecture (GitHub Advisory, Feedly).

1. Identify a vulnerable target: Find an Angular SSR application that uses provideClientHydration(), a child HttpClient configured with withRequestsMadeViaParent(), and parent-level authentication interceptors (e.g., injecting Authorization headers or cookies). Confirm the application's SSR HTML responses are cached by a shared layer (CDN, reverse proxy, or application cache).
2. Trigger an authenticated SSR render: As an authenticated user (or by observing normal application traffic), cause the application to perform an SSR render of a page that issues HTTP requests through the vulnerable child HttpClient. The parent interceptor will add credentials, and the child TransferCache will incorrectly store the authenticated response in TransferState.
3. Ensure the poisoned HTML is cached: Confirm that the CDN, reverse proxy, or application cache stores the SSR-rendered HTML page containing the <script id="ng-state"> tag with the serialized private response data.
4. Access the cached page as an unauthenticated user: Request the same URL as an unauthenticated or unauthorized user. If the shared cache serves the previously cached HTML, the ng-state script tag will contain the prior authenticated user's sensitive response data (e.g., API tokens, profile data, session information).
5. Extract sensitive data: Parse the ng-state JSON payload from the HTML source to retrieve the leaked authenticated response data (GitHub Advisory, Angular Issue).

• Network: Requests from unauthenticated users receiving SSR HTML responses with a populated <script id="ng-state"> tag containing user-specific or sensitive API response data; CDN or proxy cache hits on pages that should be personalized or private.
• File System / Application State: SSR-rendered HTML files or cached responses on disk/CDN containing ng-state JSON blobs with authentication tokens, user profile data, or API credentials.
• Logs: Application or CDN access logs showing unauthenticated requests (no Authorization or session cookie headers) receiving cached responses for authenticated endpoints; cache HIT responses for URLs that serve user-specific data.
• Application Behavior: Client-side Angular application hydrating with data belonging to a different user (e.g., displaying another user's profile or account information on initial page load) (GitHub Advisory, Angular Issue).

Upgrade @angular/common to the patched versions: 20.3.28, 21.2.20, or 22.1.1. Angular versions ≤ 19.2.25 are end-of-life and will not receive a patch. For applications that cannot immediately upgrade, the following workarounds are available: (1) attach authentication credentials directly on the child HttpClient request or via a child-level interceptor rather than relying on parent interceptors; (2) use withHttpTransferCacheOptions({ filter: (req) => !req.url.includes('/api/private/') }) on the child client to explicitly exclude sensitive endpoints from caching; (3) disable HTTP transfer caching for sensitive SSR routes entirely; or (4) configure CDN/reverse proxy cache headers (Cache-Control: private or no-store) on personalized HTML responses to prevent shared caching (GitHub Advisory, Red Hat CVE).

The vulnerability was originally reported by community contributor SkyZeroZx via GitHub issue #69777 on July 15, 2026, and the fix was developed and merged through a collaborative review process involving Angular team members JeanMeche and alan-agius4. The advisory notes a relationship to a prior similar vulnerability (GHSA-q6f4-qqrg-jv6x / CVE-2026-50170), indicating this is a recurring pattern in Angular's SSR transfer cache logic. No significant broader media coverage or social media reactions have been identified beyond the GitHub advisory and standard vulnerability database entries (GitHub Advisory, Fix PR).