CVE-2026-88059: Angular: Information Leak via `HttpTransferCache` Bypass When Using `withRequestsMadeViaParent`

Published Sep 10, 2026
·
Updated

A security bypass vulnerability was discovered in @angular/common when Server-Side Rendering (SSR) and hydration are enabled in applications using a hierarchical HttpClient configuration with withRequestsMadeViaParent().

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 (Authorization, Cookie, withCredentials, etc.).

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.

Impact

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

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

Attack Preconditions & Vulnerable Configurations

An application is affected only if all of the following conditions are met:

SSR and Hydration Enabled: The application uses Server-Side Rendering with hydration enabled (e.g., via provideClientHydration()). Hierarchical HttpClient with Delegation: The application configures a child HttpClient using withRequestsMadeViaParent(). Parent-Level Authentication Injection: Authentication credentials (such as Authorization headers, session cookies, or custom API tokens filtered via withHttpTransferCacheOptions) are attached by an interceptor in the parent injector chain rather than on the initial child request. Shared HTML Caching: The SSR HTML responses are cached by a shared caching layer (CDN, reverse proxy, or application-level HTML cache).

Vulnerable Code Pattern Example

ts // Parent Injector / Application Config export const appConfig: ApplicationConfig = { providers: [ provideHttpClient( // Parent interceptor attaches sensitive Authorization header withInterceptors([ (req, next) => next(req.clone({ setHeaders: { Authorization: Bearer ${getToken()} } })) ]) ), ], };

// Child Injector / Feature or Component Config const childClient = createEnvironmentInjector( [ // Child delegates to parent; TransferCache evaluates req BEFORE parent auth interceptor runs provideHttpClient(withRequestsMadeViaParent()), ], parentInjector ).get(HttpClient);

// Request originates without auth headers -> marked cacheable by child TransferCache childClient.get('/api/user/profile').subscribe();

Patches

The issue is resolved by updating @angular/common to run root interceptors in the terminal request chain so that delegated clients leave inherited root interceptors to the parent chain, preventing duplicate execution and ensuring HttpTransferCache evaluates cache eligibility after parent request interceptors run.

22.1.1 21.2.20 20.3.28

Workarounds & Mitigations

For applications that cannot immediately upgrade to a patched version, use one of the following mitigations:

1. Attach Credentials Before or Within the Child Client: Ensure authentication headers (e.g., Authorization) are attached directly when constructing the request or via an interceptor configured directly on the child HttpClient, rather than relying solely on parent interceptors. 2. Apply Explicit Cache Filters on the Child Client: Configure withHttpTransferCacheOptions with a filter on the child client that explicitly excludes endpoints returning user-specific or sensitive data: ts provideClientHydration( withHttpTransferCacheOptions({ filter: (req) => !req.url.includes('/api/private/'), }) ) 3. Disable HTTP Transfer Cache for Sensitive Routes: If specific SSR routes handle user-authenticated data, disable transfer caching for those requests or ensure the SSR response sets Cache-Control: no-store / private headers at your edge/CDN layer so personalized HTML is never shared.

Other sources

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.

MITRE

Affected Software

5 affected componentsFixes available
angular Angular<20.3.28, <21.2.20, <22.1.1
npm/@angular/common<=19.2.25
npm/@angular/common>=20.0.0<20.3.28
20.3.28
npm/@angular/common>=21.0.0<21.2.20
21.2.20
npm/@angular/common>=22.0.0<22.1.1
22.1.1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/@angular/common to a version that resolves this vulnerability.

    Fixed in 20.3.28
  2. Upgrade

    Upgrade npm/@angular/common to a version that resolves this vulnerability.

    Fixed in 21.2.20
  3. Upgrade

    Upgrade npm/@angular/common to a version that resolves this vulnerability.

    Fixed in 22.1.1
  4. Upgrade

    Upgrade @angular/common to a version that resolves this vulnerability.

    Fixed in 20.3.28
  5. Upgrade

    Upgrade @angular/common to a version that resolves this vulnerability.

    Fixed in 21.2.20
  6. Upgrade

    Upgrade @angular/common to a version that resolves this vulnerability.

    Fixed in 22.1.1
  7. Configuration

    On the child `HttpClient`, configure `withHttpTransferCacheOptions` with a filter that explicitly excludes endpoints returning user-specific or sensitive data so personalized/authenticated responses are not cached into `TransferState`.

    Angular HttpTransferCache (child HttpClient) withHttpTransferCacheOptions filter = exclude endpoints returning user-specific or sensitive data (e.g., filter that returns false for sensitive routes)
  8. Configuration

    Ensure authentication headers (such as `Authorization`) are attached directly when constructing the request or via an interceptor configured directly on the child `HttpClient`, rather than relying solely on parent interceptors when using `withRequestsMadeViaParent()`.

    Angular HttpClient (child vs parent interceptors) where credentials are attached = attach credentials directly on the child request/interceptor (e.g., `Authorization`)
  9. Configuration

    For SSR routes that return user-authenticated data, disable transfer caching for those requests or ensure the SSR response is marked with `Cache-Control: no-store` / `private` at the edge/CDN layer so personalized HTML is never shared across users.

    Edge/CDN / reverse proxy for SSR HTML caching Cache-Control for sensitive SSR routes = set `no-store` / `private` for SSR routes handling user-authenticated data

Event History

Sep 10, 2026
CVE Published
via MITRE·07:00 PM
Data Sourced
via MITRE·07:00 PM
DescriptionSeverityWeakness
Advisory Published
via GitHub·08:19 PM
Data Sourced
via GitHub·08:19 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Which application setups are exposed to this issue?

Exposure requires SSR with hydration enabled through provideClientHydration, a child HttpClient delegated through withRequestsMadeViaParent, and parent-level injection of an Authorization header, cookie, or API token. The SSR HTML must also be shared between users by a CDN, reverse proxy, or application cache.

2

What must an attacker do to obtain private data?

An attacker does not need credentials or user interaction, but must receive a shared SSR HTML response that was previously generated for an authenticated user. The private response data can be present in the serialized TransferState JSON in the ng-state script.

3

What can be done if upgrading is not immediately possible?

Attach credentials at the child HttpClient level rather than only through the parent interceptor chain, and filter sensitive endpoints from transfer caching. Prevent SSR HTML responses from being shared across users by CDN, proxy, or application caches.

4

Which Angular releases contain the fix?

The issue affects versions prior to 20.3.28, 21.2.20, and 22.1.1. Upgrade to the applicable fixed release or later.

5

How can teams assess whether data may already have been exposed?

Review whether authenticated SSR pages were stored or served by a shared CDN, reverse proxy, or application cache under the affected configuration. Cached HTML may contain authenticated API response data in the ng-state script's serialized TransferState JSON.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203