Angular @angular/common HttpTransferCache exposes authenticated SSR data through shared HTML caches

Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Prior to 20.3.28, 21.2.20, and 22.1.1, Angular's @angular/common HttpTransferCache can cache an authenticated response when Server-Side Rendering (SSR) and hydration use a hierarchical HttpClient configured with withRequestsMadeViaParent. The child TransferCache evaluates an initially anonymous request before delegation, then a parent withInterceptors chain adds an Authorization header, cookie, or API token; although the parent cache skips the authenticated request, the child still stores the private response in TransferState serialized as JSON in the ng-state script. Exploitation requires provideClientHydration, child provideHttpClient delegation through withRequestsMadeViaParent, parent-level credential injection, and an SSR HTML response shared across users by a CDN, reverse proxy, or application cache. A later unauthenticated or unauthorized visitor can receive the cached HTML containing the earlier authenticated user's sensitive response data. Applications can mitigate by attaching credentials at the child, filtering sensitive endpoints with withHttpTransferCacheOptions, disabling transfer caching for sensitive routes, or marking personalized HTML private or no-store. This issue is fixed in versions 20.3.28, 21.2.20, and 22.1.1.

The advisory identifies these Angular @angular/common branches as affected:

• <= 19.2.25: affected; the advisory states that this branch is out of support or LTS and will not be patched.
• >= 20.0.0, < 20.3.28: affected; the identified fixed release is 20.3.28.
• >= 21.0.0, < 21.2.20: affected; the identified fixed release is 21.2.20.
• >= 22.0.0, < 22.1.1: affected; the identified fixed release is 22.1.1.

The status of other branches or releases should not be inferred beyond these documented boundaries.

Within @angular/common, HttpTransferCache evaluates cache eligibility in the child before delegation occurs. With withRequestsMadeViaParent(), the request then passes through the parent interceptor chain, which can add an Authorization header, cookie, or API token. The parent cache recognizes the authenticated request and skips caching, but the child retains its initial anonymous, cacheable decision and stores the private response in TransferState, which is serialized as JSON in the ng-state script in the SSR HTML. An application is exposed only when SSR and hydration are enabled, provideClientHydration is used, a child provideHttpClient delegates through withRequestsMadeViaParent, credentials are injected at the parent level, and SSR HTML is shared across users by a CDN, reverse proxy, or application cache. The requester-controlled action established by the evidence is requesting the same SSR page; no special payload is established. The exact endpoint and sensitive data returned depend on the application and are not specified by the sources.

• The issue is reachable over the network through an application's SSR page when the vulnerable configuration and a shared HTML cache are present.
• The normalized record indicates that attacker privileges and end-user interaction are not required. Exploitation is nevertheless configuration-dependent because SSR, hydration, hierarchical HttpClient delegation, parent-level credential injection, and cross-user HTML sharing must all be present.
• A later unauthenticated or unauthorized visitor can request the same page and receive cached HTML containing private response data from an earlier authenticated user.
• The record marks public exploit availability, but it does not provide a named exploit, payload, exploit sequence, or campaign. Confirmed exploitation in the wild is not established.

The technical outcome is that a private response from a request authenticated by a parent interceptor can appear in TransferState and in cached SSR HTML. An unauthenticated or unauthorized visitor may read that data when receiving the same cached HTML; the available evidence does not indicate response modification or loss of availability. The attacker does not need an account for the described access path, but the application must meet all of the configuration and caching conditions documented by the advisory. The amount and sensitivity of exposed data depend on the endpoint invoked during SSR and the scope of the shared HTML cache. The evidence does not establish that every Angular application or every SSR response is affected.

An authenticated user's response can be serialized into SSR HTML and then reused across sessions by a CDN, reverse proxy, or application cache. This can disclose private or user-specific data to visitors who are not authorized to access it, turning a shared page-cache entry into a cross-user confidentiality incident. The available evidence supports information disclosure, but does not establish data modification, service disruption, or a particular breach.

1. Upgrade @angular/common to the fixed release for the deployed branch: 20.3.28, 21.2.20, or 22.1.1. For 19.2.25 and earlier, the advisory states that the branch is out of support and will not be patched, so migrate to a supported branch with a documented fix.
2. If an upgrade cannot be completed immediately, attach credentials directly to the child request or through an interceptor configured on the child HttpClient, rather than relying only on parent interceptors.
3. Use withHttpTransferCacheOptions to explicitly exclude endpoints that return user-specific or sensitive data from the HTTP transfer cache.
4. Disable transfer caching for SSR routes that handle authenticated data.
5. Ensure personalized HTML is sent with Cache-Control: private or no-store so that CDNs, reverse proxies, and application caches do not share the response across users.

1. Inventory the @angular/common package in applications that use SSR, and identify which applications enable hydration.
2. Review application configuration for provideClientHydration(), child provideHttpClient(withRequestsMadeViaParent()), and parent interceptors that add Authorization, cookies, or API tokens.
3. Inspect CDN, reverse proxy, and application cache policy to determine whether SSR HTML is shared across users. Confirm that personalized pages are marked private or no-store where required.
4. In a controlled test environment, inspect SSR HTML and the JSON data in ng-state for responses from user-specific endpoints or other sensitive data.
5. Compare cache behavior for the same page using controlled authenticated and unauthenticated test identities, checking whether the earlier user's response appears in the later HTML.
6. Monitor cache hits on personalized SSR pages as a precaution. This is general monitoring guidance, not a source-confirmed indicator of compromise.