Skip to content

Angular: Information Leak via `HttpTransferCache` Bypass When Using `withRequestsMadeViaParent`

Moderate severity GitHub Reviewed Published Aug 20, 2026 in angular/angular • Updated Sep 10, 2026

Package

npm @angular/common (npm)

Affected versions

>= 22.0.0, < 22.1.1
>= 21.0.0, < 21.2.20
>= 20.0.0, < 20.3.28
<= 19.2.25

Patched versions

22.1.1
21.2.20
20.3.28

Description

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

// 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:
    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.

References

@alan-agius4 alan-agius4 published to angular/angular Aug 20, 2026
Published to the GitHub Advisory Database Sep 10, 2026
Reviewed Sep 10, 2026
Last updated Sep 10, 2026

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
High
Privileges required
None
User interaction
None
Scope
Changed
Confidentiality
Low
Integrity
None
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(22nd percentile)

Weaknesses

Exposure of Sensitive Information to an Unauthorized Actor

The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information. Learn more on MITRE.

Use of Cache Containing Sensitive Information

The code uses a cache that contains sensitive information, but the cache can be read by an actor outside of the intended control sphere. Learn more on MITRE.

CVE ID

CVE-2026-88059

GHSA ID

GHSA-p297-fm68-3q8c

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.