A Stored Cross-Site Scripting (XSS) vulnerability has been identified in the Angular Template Compiler. It occurs because the compiler's internal security schema is incomplete, allowing attackers to bypass Angular's built-in security sanitization. Specifically, the schema fails to classify certain URL-holding attributes (e.g., those that could contain javascript: URLs) as requiring strict URL security, enabling the injection of malicious scripts.
Additionally, a related vulnerability exists involving SVG animation elements (<animate>, <set>, <animateMotion>, <animateTransform>). The attributeName attribute on these elements was not properly validated, allowing attackers to dynamically target security-sensitive attributes like href or xlink:href on other elements. By binding attributeName to "href" and providing a javascript: URL in the values or to attribute, an attacker could bypass sanitization and execute arbitrary code.
Attributes confirmed to be vulnerable include: SVG-related attributes: (e.g., xlink:href), and various MathML attributes (e.g., math|href, annotation|href). SVG animation attributeName attribute when bound to "href" or "xlink:href".
When template binding is used to assign untrusted, user-controlled data to these attributes (e.g., [attr.xlink:href]="maliciousURL" or <animate [attributeName]="'href'" [values]="maliciousURL">), the compiler incorrectly falls back to a non-sanitizing context or fails to block the dangerous attribute assignment. This allows an attacker to inject a javascript:URL payload. Upon user interaction (like a click) on the element, or automatically in the case of animations, the malicious JavaScript executes in the context of the application's origin.
Impact
When exploited, this vulnerability allows an attacker to execute arbitrary code within the context of the vulnerable application's domain. This enables:
Session Hijacking: Stealing session cookies and authentication tokens. Data Exfiltration: Capturing and transmitting sensitive user data. Unauthorized Actions: Performing actions on behalf of the user.
Patches
- 19.2.17 - 20.3.15 - 21.0.2
Attack Preconditions
The victim's Angular application must render data derived from untrusted input (e.g., from a database or API) and bind it to one of the unsanitized URL attributes or the attributeName of an SVG animation element. The victim must perform a user interaction (e.g., clicking) on the compromised element for the stored script to execute, or the animation must trigger the execution.
Workarounds
If you cannot upgrade, you can workaround the issue by ensuring that any data bound to the vulnerable attributes is never sourced from untrusted user input (e.g., database, API response, URL parameters).
Avoid Affected Template Bindings: Specifically avoid using template bindings (e.g., [attr.xlink:href]="maliciousURL") to assign untrusted data to the vulnerable SVG/MathML attributes. Avoid Dynamic attributeName on SVG Animations: Do not bind untrusted data to the attributeName attribute of SVG animation elements (<animate>, <set>, etc.). Enable Content Security Policy (CSP): Configure a robust CSP header that disallows javascript: URLs.
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.