CVE-2026-88059

Overview

Angular is a TypeScript-based web development platform for building scalable single-page and server-side rendered applications. It provides a modular architecture, powerful dependency injection, and built-in tools for building modern, performant, and maintainable applications across web, mobile, and desktop environments.

An Information Exposure vulnerability (CVE-2026-88059) has been identified in Angular's Common HTTP Client, which allows authenticated responses to be stored in the server-side rendering transfer cache when a child client delegates requests through withRequestsMadeViaParent and can lead to private data being disclosed to unauthorized users.

Per MITRE CWE-524: A Use of Cache Containing Sensitive Information vulnerability means that the code uses a cache that contains sensitive information, but the cache can be read by an actor outside of the intended control sphere.

This issue affects multiple versions of Angular.

‍

Details

Module Info

• Product: Angular
• Affected packages: @angular/common
• Affected versions:
  • >=16.0.0-next.7 <=19.2.25
  • >=20.0.0 <20.3.28
  • >=21.0.0 <21.2.20
  • >=22.0.0 <22.1.1
• GitHub repository: https://github.com/angular/angular
• Published packages: https://www.npmjs.com/package/@angular/common
• Package manager: npm
• Fixed in:
  • OSS Angular v20.3.28, v21.2.20 and v22.1.1
  • Angular NES v19.2.30, v18.2.26, v17.3.26, v16.2.26

Vulnerability Info

This Medium-severity vulnerability is found in the @angular/common package in multiple published versions of Angular.

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, serialized as JSON in <script id="ng-state">. Following the remediation of CVE-2026-50170, HttpTransferCache automatically skips caching requests that contain authentication headers or credentials such as Authorization, Cookie, and withCredentials.

However, when a child HttpClient delegates to a parent client via withRequestsMadeViaParent(), the child's TransferCache interceptor evaluates whether the request is eligible for caching before delegating to the parent client's interceptor chain. If an outgoing request originates as anonymous from the child client, the child TransferCache marks the request as cacheable. When the request reaches a parent interceptor that injects sensitive authentication credentials, such as an Authorization header or API token, the parent TransferCache correctly skips caching the authenticated request. However, when the backend returns the private, authenticated response, the child TransferCache still stores the response in TransferState based on its initial pre-delegation evaluation.

Successful exploitation allows sensitive, user-specific information belonging to an authenticated user to be leaked to unauthenticated or unauthorized users. This occurs when:

• During SSR, a child HttpClient initiates an unauthenticated request that is subsequently authenticated by a parent interceptor.
• The authenticated response body is cached into the SSR-rendered HTML page (TransferState).
• The rendered HTML page is stored by a shared caching layer such as a CDN, edge cache, or reverse proxy, or is served across user sessions.
• Subsequent visitors requesting the same page receive the cached HTML containing the previous user's private data.

Applications are exposed where Server-Side Rendering is used with hydration enabled, for example via provideClientHydration(), where a child HttpClient is configured using withRequestsMadeViaParent(), and where authentication credentials such as Authorization headers, session cookies, or custom API tokens are attached by an interceptor in the parent injector chain rather than on the initial child request. The leaked state reaches other users wherever the resulting SSR HTML is shared, including through a CDN, reverse proxy, or application-level HTML cache.

‍

Mitigation

Angular versions prior to 20 were already End-of-Life when this CVE was published and will not receive any updates to address this issue. For more information see here.

Users of the affected components should apply one of the following mitigations:

• Migrate affected applications to a patched version of Angular.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.