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.

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.

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.

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.

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.

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.

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