Impact

A Server-Side Request Forgery (SSRF) vulnerability exists in @angular/platform-server. The issue stems from how the server-side rendering (SSR) engine processes the request URL provided to the rendering entry points.

When an absolute-form URL (e.g., http://evil.com) is passed to the rendering engine, the internal ServerPlatformLocation can be manipulated into adopting the attacker-controlled domain as the "current" hostname.

Consequently, any relative HttpClient requests or PlatformLocation.hostname references are redirected to the attacker controlled server, potentially exposing internal APIs or metadata services.

Fix Information The vulnerability is mitigated by introducing an Allowlist Mechanism directly into the core rendering APIs. The renderModule and renderApplication functions now include an allowedHosts configuration option. The rendering engine validates the hostname extracted from the request URL against this list before proceeding. If the hostname does not match an allowed entry, the engine prevents the hostname hijacking, ensuring that HttpClient requests remain restricted to trusted domains.

Patches - 22.0.0-next.12 - 21.2.13 - 20.3.21 - 19.2.22

Workarounds Developers unable to update immediately should implement strict URL validation in their server entry point (e.g., server.ts). Ensure that req.url is validated against a known list of trusted hostnames or normalized to a relative path before being passed torenderApplication or renderModule.

TypeScript // Example manual normalization in Express app.get('', (req, res, next) => { const trustedHost = 'localhost:4000'; // Ensure the request target matches expectations if (req.headers.host !== trustedHost) { return res.status(403).send('Forbidden'); } next(); });

An issue in the @angular/platform-server package allows remote attackers to bypass host allowlist constraints and direct server-side outgoing requests to arbitrary external endpoints. This occurs due to a parser differential between the strict WHATWG URL parser used for allowlist validation and the lenient Domino URL parser used to initialize the server emulated DOM.

When a server-side request contains a malformed URL with a double port structure (e.g., http://evil.com:80:80/path), Node's strict URL.canParse(url) logic returns false and skips host check validation entirely. However, the same malformed URL is later accepted and parsed leniently by Domino's internal parser, which resolves the origin to http://evil.com:80. The Angular SSR HTTP request interceptor (relativeUrlsTransformerInterceptorFn) then resolves all relative backend HTTP requests against this adopted origin, executing the SSRF attack.

Impact

Any Angular application utilizing server-side rendering (@angular/platform-server) that configures host routing allowlists (allowedHosts) is vulnerable to this allowlist bypass.

By sending an HTTP request with a malformed Host header (e.g. Host: evil.com:80:80) or an absolute-form request URI, an attacker can bypass the allowlist logic completely (even when configured with a strict default deny setup). The SSR application will then route all relative HttpClient outgoing API queries—which commonly carry sensitive credentials, session cookies, and internal authorization tokens—to the attacker-controlled server instead of the intended backend services. Additionally, the attacker can supply custom payloads back to the emulated DOM, leading to response injection and content poisoning within the rendered HTML served to users.

Attack Preconditions

To successfully exploit this vulnerability, the following environment parameters and application states must all concurrently exist:

1. Active Server-Side Rendering (SSR): The application must be configured to run with Angular Server-Side Rendering (@angular/platform-server). 2. Host Header/URI Propagation: The SSR handler must reconstruct the request URL using raw client inputs (such as request Host headers or absolute-form URIs) and pass it as config.url to the rendering API (renderApplication or renderModule). 3. Outbound Relative HTTP Requests: The server application must perform outbound backend API requests using relative paths (e.g., this.http.get('/api/data')) that undergo base-URL interceptor rewriting. 4. Enabled Allowed Hosts Check: The server must use the framework-provided allowedHosts options to limit valid server locations.

Patches

22.0.0-rc.2 21.2.15 20.3.22 19.2.23

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.

Impact The vulnerability is a Server-Side Request Forgery (SSRF) flaw within the URL resolution mechanism of Angular's Server-Side Rendering package (@angular/ssr).

The function createRequestUrl uses the native URL constructor. When an incoming request path (e.g., originalUrl or url) begins with a double forward slash (//) or backslash (\\), the URL constructor treats it as a schema-relative URL. This behavior overrides the security-intended base URL (protocol, host, and port) supplied as the second argument, instead resolving the URL against the scheme of the base URL but adopting the attacker-controlled hostname.

This allows an attacker to specify an external domain in the URL path, tricking the Angular SSR environment into setting the page's virtual location (accessible via DOCUMENT or PlatformLocation tokens) to this attacker-controlled domain. Any subsequent relative HTTP requests made during the SSR process (e.g., using HttpClient.get('assets/data.json')) will be incorrectly resolved against the attacker's domain, forcing the server to communicate with an arbitrary external endpoint.

Exploit Scenario A request to http://localhost:4200//attacker-domain.com/some-page causes Angular to believe the host is attacker-domain.com. A relative request to api/data then becomes a server-side request to http://attacker-domain.com/api/data.

Patches

- @angular/ssr 19.2.18 - @angular/ssr 20.3.6 - @angular/ssr 21.0.0-next.8

Mitigation

The application's internal location must be robustly determined from the incoming request. The fix requires sanitizing or validating the request path to prevent it from being interpreted as a schema-relative URL (i.e., ensuring it does not start with //).

Server-Side Middleware If you can't upgrade to a patched version, implement a middleware on the Node.js/Express server that hosts the Angular SSR application to explicitly reject or sanitize requests where the path begins with a double slash (//).

Example (Express/Node.js):

ts // Place this middleware before the Angular SSR handler app.use((req, res, next) => { if (req.originalUrl?.startsWith('//')) { // Sanitize by forcing a single slash req.originalUrl = req.originalUrl.replace(/^\/\/+/, '/'); req.url = req.url.replace(/^\/\/+/, '/'); } next(); });

References

- Report: https://github.com/angular/angular-cli/issues/31464 - Fix: https://github.com/angular/angular-cli/pull/31474

Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Prior to versions 19.2.21, 20.3.19, 21.2.9, and 22.0.0-next.8, a Server-Side Request Forgery (SSRF) vulnerability exists in @angular/platform-server due to improper handling of URLs during Server-Side Rendering (SSR). When an attacker sends a request such as GET /\evil.com/ HTTP/1.1 the server engine (Express, etc.) passes the URL string to Angular’s rendering functions. Because the URL parser normalizes the backslash to a forward slash for HTTP/HTTPS schemes, the internal state of the application is hijacked to believe the current origin is evil.com. This misinterpretation tricks the application into treating the attacker’s domain as the local origin. Consequently, any relative HttpClient requests or PlatformLocation.hostname references are redirected to the attacker controlled server, potentially exposing internal APIs or metadata services. This issue has been patched in versions 19.2.21, 20.3.19, 21.2.9, and 22.0.0-next.8.

The Angular Language Service VS Code Extension provides a rich editing experience for Angular templates. Prior to 21.2.4, the client-side Angular Language Service VS Code extension reads the custom TypeScript SDK paths typescript.tsdk and js/ts.tsdk.path directly from workspace configurations (.vscode/settings.json) without verifying VS Code Workspace Trust state or asking for user consent (located in client/src/client.ts). The client-side extension then passes the parsed settings path as a command-line argument (--tsdk) to the background Node.js language server process. During server initialization, the background language server resolves and dynamically imports (via standard Node.js require()) the module library tsserverlibrary.js relative to the workspace-specified custom directory path. An attacker can exploit this behavior by committing a repository containing a local malicious tsserverlibrary.js script inside a custom folder, and a crafted .vscode/settings.json file pointing to that folder. When a developer opens the repository folder in VS Code, the extension automatically attempts to initialize and load the server, which dynamically resolves, loads, and executes the malicious script silently in the background. This vulnerability is fixed in 21.2.4.

The Angular Language Service VS Code Extension provides a rich editing experience for Angular templates. the client-side Angular Language Service VS Code extension configures the tooltip Markdown renderer with the isTrusted: true option (located in client/src/client.ts). This setting instructs VS Code to trust all rendered content it receives, which enables active elements such as command: URIs. However, the background Angular Language Server process fails to escape or sanitize brackets, raw links, and control characters from JSDoc strings before forwarding the hover Markdown content (located in server/src/handlers/hover.ts and server/src/textrender.ts). An attacker can leverage this behavior by crafting a project TypeScript or JavaScript file (or a third-party npm package dependency) containing a malicious JSDoc tooltip with an embedded active command link. When a developer hovers over the target symbol to render the tooltip and clicks the malicious link, the IDE executes the command sequence directly on the developer's host machine. Prior to 21.2.4, This vulnerability is fixed in 21.2.4.

A Cross-Site Scripting (XSS) vulnerability has been identified in the Angular runtime and compiler. It occurs when the application uses a security-sensitive attribute (for example href on an anchor tag) together with Angular's ability to internationalize attributes. Enabling internationalization for the sensitive attribute by adding i18n-<attribute> name bypasses Angular's built-in sanitization mechanism, which when combined with a data binding to untrusted user-generated data can allow an attacker to inject a malicious script.

The following example illustrates the issue: html <a href="{{maliciousUrl}}" i18n-href>Click me</a>

The following attributes have been confirmed to be vulnerable: - action - background - cite - codebase - data - formaction - href - itemtype - longdesc - poster - src - xlink:href

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.

Attack Preconditions 1. The application must use a vulnerable version of Angular. 2. The application must bind unsanitized user input to one of the attributes mentioned above. 3. The bound value must be marked for internationalization via the presence of a i18n-<name> attribute on the same element.

Patches - 22.0.0-next.3 - 21.2.4 - 20.3.18 - 19.2.20

Workarounds The primary workaround is to ensure that any data bound to the vulnerable attributes is never sourced from untrusted user input (e.g., database, API response, URL parameters) until the patch is applied, or when it is, it shouldn't be marked for internationalization.

Alternatively, users can explicitly sanitize their attributes by passing them through Angular's DomSanitizer: ts import {Component, inject, SecurityContext} from '@angular/core'; import {DomSanitizer} from '@angular/platform-browser';

@Component({ template: <form action="{{url}}" i18n-action> <button>Submit</button> </form> , }) export class App { url: string;

constructor() { const dangerousUrl = 'javascript:alert(1)'; const sanitizer = inject(DomSanitizer); this.url = sanitizer.sanitize(SecurityContext.URL, dangerousUrl) || ''; } }

References - Fix 1 - Fix 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 raw-text elements (such as <script>, <style>, and <iframe>).

domino supports escaping raw-text elements during serialization to prevent closing-tag breakout. However, a Unicode index alignment bug existed in this escaping logic.

In JavaScript, string lengths and character indices are calculated based on UTF-16 code units (where astral characters—such as emojis—occupy 2 code units / 4 bytes). If the bound dynamic text contained astral Unicode characters before the closing tag (e.g. </script>, </style>, or </iframe>), the index offset calculation in domino's replacement logic shifted.

This misalignment caused domino to fail to replace or escape the closing tag, leaving it raw and unescaped in the output HTML.

An attacker who controls the dynamic text can supply a payload containing both an astral Unicode character and a closing tag (e.g., 😀</iframe><script>alert(1)</script>). When serialized on the server during SSR, the browser parses the unescaped closing tag, exits the raw-text context early, and executes the subsequent <script> block, leading to 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 raw-text elements. This can lead to session hijacking, credentials theft, unauthorized actions on behalf of users, and defacement.

Patched Versions

- 22.0.0-rc.2 - 21.2.16 - 20.3.24 - 19.2.25

Workarounds

If you cannot immediately update your dependencies, you can:

- Avoid binding user-controlled values inside <iframe> or other raw-text elements. - Sanitize any user input placed inside raw-text elements to explicitly strip closing tags before passing it to the template.

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

When rendering dynamic text content inside a <noscript> element via template bindings (such as {{ value }} or [textContent]), the template engine expects the browser to render the content safely. Under Server-Side Rendering (SSR), domino is configured with scripting enabled, meaning <noscript> is treated as a raw-text element.

However, domino's serializer completely omitted <noscript> from the list of raw-text elements requiring closing-tag escaping during DOM serialization. As a result, any occurrence of </noscript> in the bound dynamic text was never escaped under any circumstances.

The unescaped closing tag was serialized directly into the output HTML (e.g. <noscript></noscript><script>alert(1)</script></noscript>). When parsed by a browser, it closes the <noscript> block early, allowing the 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 a <noscript> element. This can lead to session hijacking, credentials theft, unauthorized actions on behalf of users, and defacement.

Patched Versions

- 22.0.0-rc.2 - 21.2.16 - 20.3.24 - 19.2.25

Workarounds

If you cannot immediately update your dependencies, you can:

- Avoid binding user-controlled values inside <noscript> elements. - Sanitize any user input placed inside <noscript> to explicitly strip closing </noscript> tags before passing it to the template.

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.

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 Cross-Site Scripting (XSS) vulnerability has been identified in the Angular Template Compiler. The vulnerability exists because Angular’s internal sanitization schema fails to recognize the href and xlink:href attributes of SVG <script> elements as a Resource URL context.

In a standard security model, attributes that can load and execute code (like a script's source) should be strictly validated. However, because the compiler does not classify these specific SVG attributes correctly, it allows attackers to bypass Angular's built-in security protections.

When template binding is used to assign user-controlled data to these attributes for example, <script [attr.href]="userInput"> the compiler treats the value as a standard string or a non-sensitive URL rather than a resource link. This enables an attacker to provide a malicious payload, such as a data:text/javascript URI or a link to an external malicious script.

Impact When successfully exploited, this vulnerability allows for arbitrary JavaScript execution within the context of the victim's browser session. This can lead to: - Session Hijacking: Stealing session cookies, localStorage data, or authentication tokens. - Data Exfiltration: Accessing and transmitting sensitive information displayed within the application. - Unauthorized Actions: Performing state-changing actions (like clicking buttons or submitting forms) on behalf of the authenticated user.

Attack Preconditions

1. The victim application must explicitly use SVG <script> elements within its templates. 2. The application must use property or attribute binding (interpolation) for the href or xlink:href attributes of those SVG scripts. 3. The data bound to these attributes must be derived from an untrusted source (e.g., URL parameters, user-submitted database entries, or unsanitized API responses).

Patches - 19.2.18 - 20.3.16 - 21.0.7 - 21.1.0-rc.0

Workarounds Until the patch is applied, developers should:

- Avoid Dynamic Bindings: Do not use Angular template binding (e.g., [attr.href]) for SVG <script> elements. - Input Validation: If dynamic values must be used, strictly validate the input against a strict allowlist of trusted URLs on the server side or before it reaches the template.

Resources

- https://github.com/angular/angular/pull/66318

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 Angular. The formatNumber function, which is also utilized by DecimalPipe, PercentPipe, and CurrencyPipe, does not properly validate the upper bounds of the digitsInfo parameter. Specifically, the minimum and maximum fraction digits parsed from the digitsInfo string (e.g., 1.2-4) are converted to integers and used without limits.

When parsing a maliciously crafted digitsInfo string with excessively large fraction digit values (e.g., 1.200000000-200000000), the internal roundNumber function attempts to pad the digits array to match the requested fraction size. This results in an unbounded loop that repeatedly pushes elements into an array.

Impact

Successful exploitation of this vulnerability allows an attacker to trigger resource exhaustion, leading to a Denial of Service (DoS):

Server-Side Rendering (SSR): In applications using SSR (e.g., @angular/ssr), an attacker can crash the Node.js server process due to a JavaScript heap out of memory error. This affects the availability of the application for all users. Client-Side Rendering (CSR): In standard client-side applications, the unbounded loop will block the main thread, freezing the user's browser tab and making it unresponsive.

Attack Preconditions

For this vulnerability to be exploitable, the following conditions must be met:

1. Vulnerable Component Usage: The application must use Angular's number formatting utilities, such as the formatNumber function directly, or via template pipes (DecimalPipe, PercentPipe, CurrencyPipe). 2. Attacker-Controlled Parameter: The digitsInfo parameter passed to these utilities must be customizable or directly controlled by untrusted user input (e.g., parsed from query parameters, user preference settings, or API responses that accept user-defined formatting options). If digitsInfo is trusted or limited to a known, defined range for its value, the vulnerability is not exploitable by external attackers.

Patches - 22.0.0-rc.2 - 21.2.15 - 20.3.22 - 19.2.23

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

A vulnerability was discovered in @angular/common when Server-Side Rendering (SSR) and hydration are enabled. 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.

However, the caching mechanism fails to inspect the withCredentials flag or the Cookie header of outgoing requests. As a result, credentialed, user-specific responses may be cached by default in the shared TransferState payload. When these responses are serialized into the HTML, any caching layer (such as a CDN, reverse proxy, or shared server cache) that caches the SSR-rendered HTML page could inadvertently cache and leak one user's private data to other users, leading to a high-severity information disclosure vulnerability.

Impact

Successful exploitation allows an unauthenticated attacker to obtain sensitive, user-specific information of other authenticated users. This occurs when:

The SSR-rendered HTML containing the cached private data is stored in a shared cache (e.g., CDN, reverse proxy). Subsequent requests for the same page receive the cached HTML containing the first user's private data.

Attack Preconditions

SSR and Hydration Enabled: The Angular application must be configured to use Server-Side Rendering and hydration (e.g., using provideClientHydration()). Credentialed Requests during SSR: The application must perform HTTP requests that require user-specific authentication (using cookies or withCredentials: true) during the initial server-side render. Shared Caching: The application's HTML responses must be cached by a shared caching layer (CDN, reverse proxy, or server-side cache) without proper cache-control headers to distinguish authenticated users.

Patches - 22.0.0-rc.2 - 21.2.15 - 20.3.22 - 19.2.23

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 versions 19.2.16, 20.3.14, and 21.0.1, there is a XSRF token leakage via protocol-relative URLs in angular HTTP clients. The vulnerability is a Credential Leak by App Logic that leads to the unauthorized disclosure of the Cross-Site Request Forgery (XSRF) token to an attacker-controlled domain. Angular's HttpClient has a built-in XSRF protection mechanism that works by checking if a request URL starts with a protocol (http:// or https://) to determine if it is cross-origin. If the URL starts with protocol-relative URL (//), it is incorrectly treated as a same-origin request, and the XSRF token is automatically added to the X-XSRF-TOKEN header. This issue has been patched in versions 19.2.16, 20.3.14, and 21.0.1. A workaround for this issue involves avoiding using protocol-relative URLs (URLs starting with //) in HttpClient requests. All backend communication URLs should be hardcoded as relative paths (starting with a single /) or fully qualified, trusted absolute URLs.

A Cross-site Scripting (XSS) vulnerability has been identified in the Angular internationalization (i18n) pipeline. In ICU messages (International Components for Unicode), HTML from translated content was not properly sanitized and could execute arbitrary JavaScript.

Angular i18n typically involves three steps, extracting all messages from an application in the source language, sending the messages to be translated, and then merging their translations back into the final source code. Translations are frequently handled by contracts with specific partner companies, and involve sending the source messages to a separate contractor before receiving final translations for display to the end user.

If the returned translations have malicious content, it could be rendered into the application and execute arbitrary JavaScript.

Impact When successfully exploited, this vulnerability allows for execution of attacker controlled JavaScript in the application origin. Depending on the nature of the application being exploited this could lead to:

- Credential Exfiltration: Stealing sensitive user data stored in page memory, LocalStorage, IndexedDB, or cookies available to JS and sending them to an attacker controlled server. - Page Vandalism: Mutating the page to read or act differently than intended by the developer.

Attach Preconditions

- The attacker must compromise the translation file (xliff, xtb, etc.). - Unlike most XSS vulnerabilities, this one is not exploitable by arbitrary users. An attacker must first compromise an application's translation file before they can escalate privileges into the Angular application client. - The victim application must use Angular i18n. - The victim application must use one or more ICU messages. - The victim application must render an ICU message. - The victim application must not defend against XSS via a safe Content-Security Policy (CSP) or Trusted Types.

Patches - 21.2.0 - 21.1.6 - 20.3.17 - 19.2.19

Workarounds Until the patch is applied, developers should consider:

- Reviewing and verifying translated content received from untrusted third parties before incorporating it in an Angular application. - Enabling strict CSP controls to block unauthorized JavaScript from executing on the page. - Enabling Trusted Types to enforce proper HTML sanitization.

References

- Fix

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.

This affects versions of the package angular from 1.3.0; versions of the package angularjs from 1.3.0. A regular expression used to split the value of the ng-srcset directive is vulnerable to super-linear runtime due to backtracking. With large carefully-crafted input, this can result in catastrophic backtracking and cause a denial of service. Note: This package is EOL and will not receive any updates to address this issue. Users should migrate to @angular/core.

An Open Redirect vulnerability exists in @angular/ssr due to an incomplete fix for CVE-2026-27738. While the original fix successfully blocked multiple leading slashes (e.g., ///), the internal validation logic fails to account for a single backslash (\) bypass.

When an Angular SSR application is deployed behind a proxy that passes the X-Forwarded-Prefix header:

- An attacker provides a value starting with a single backslash (e.g., \evil.com). - The internal validation failed to flag the single backslash as invalid. - The application prepends a leading forward slash, resulting in a Location header containing /\evil.com. - Modern browsers interpret the /\ sequence as //, treating it as a protocol-relative URL and redirecting the user to the attacker-controlled domain.

Furthermore, the response lacks the Vary: X-Forwarded-Prefix header, allowing the malicious redirect to be stored in intermediate caches (Web Cache Poisoning).

Impact This vulnerability allows attackers to conduct large-scale phishing and SEO hijacking:

- Scale: A single request can poison a high-traffic route, impacting all users until the cache expires. - SEO Poisoning: Search engine crawlers may follow and index these malicious redirects, causing the legitimate site to be delisted or associated with malicious domains. - Trust: Because the initial URL belongs to the trusted domain, users and security tools are less likely to flag the redirect as malicious.

Patches

- 22.0.0-next.2 - 21.2.3 - 20.3.21

Workarounds Until the patch is applied, developers should sanitize the X-Forwarded-Prefix header in their server.ts before the Angular engine processes the request:

ts app.use((req, res, next) => { const prefix = req.headers['x-forwarded-prefix']; if (typeof prefix === 'string') { // Sanitize by removing all leading forward and backward slashes req.headers['x-forwarded-prefix'] = prefix.trim().replace(/^[/\\]+/, '/'); } next(); });

References

- Fix: https://github.com/angular/angular-cli/pull/32771 - Original CVE: CVE-2026-27738

Description A vulnerability exists in the X-Forwarded-Prefix header processing logic within Angular SSR. The internal validation mechanism fails to properly account for URL-encoded characters, specifically dots (%2e%2e). This allows an attacker to bypass security filters by injecting encoded path traversal sequences that are later decoded and utilized by the application logic. When an Angular SSR application is configured to trust proxy headers and is deployed behind a proxy that forwards the X-Forwarded-Prefix header without prior sanitization, an attacker can provide a payload such as /%2e%2e/evil.

The vulnerability manifests in two ways: - Open Redirect: The application processes a redirect (e.g., router redirectTo). The decoded traversal payload manipulates the Location header, forcing the browser to an unintended path or external domain. - Server-Side Request Steering: The manipulated prefix is used as the base path for server-side HttpClient requests. This causes the server to make requests to unintended internal paths or external endpoints.

Attack Preconditions - The application must use Angular SSR. - The application must perform internal redirects or use relative URLs in server-side HttpClient requests. - The upstream infrastructure (Reverse Proxy/CDN) must pass the X-Forwarded-Prefix header to the SSR process without stripping or sanitizing it.

Workarounds Until the patch is applied, developers should manually sanitize the X-Forwarded-Prefix header in their server.ts. The workaround involves decoding the component to catch encoded traversal attempts before normalization:

ts app.use((req, res, next) => { let prefix = req.headers['x-forwarded-prefix']; if (Array.isArray(prefix)) prefix = prefix[0];

if (prefix) { try { // Decode the prefix to catch encoded characters like %2e (dots) const decodedPrefix = decodeURIComponent(prefix); // Sanitize: remove traversal attempts and ensure a safe leading slash req.headers['x-forwarded-prefix'] = decodedPrefix .replace(/\.\./g, '') // Remove any dot-dot sequences .replace(/^[/\\]+/, '/'); // Ensure it starts with exactly one slash } catch (e) { // If decoding fails, remove the potentially malicious header entirely delete req.headers['x-forwarded-prefix']; } } next(); }); Configuring Trusted Proxy Headers By default, Angular ignores all X-Forwarded- headers. If your application is behind a trusted reverse proxy (like a load balancer) that sets these headers, you can configure Angular to trust them. You can configure trustProxyHeaders when initializing the application engine:

ts const appEngine = new AngularAppEngine({ // Trust specific headers trustProxyHeaders: ['x-forwarded-host', 'x-forwarded-proto', 'x-forwarded-prefix'], });

const nodeAppEngine = new AngularNodeAppEngine({ // Trust all X-Forwarded- headers trustProxyHeaders: true, });

Patches - 22.0.0-next.7 - 21.2.9 - 20.3.25 - 19.2.25

Resources

- https://github.com/angular/angular-cli/pull/33031 - https://angular.dev/best-practices/security#configuring-trusted-proxy-headers

An issue in the @angular/service-worker package compromises the integrity of request-policy enforcement during request reconstruction. When the Angular Service Worker intercepts network requests for matched assets, it reconstructs a new Request object using an internal helper function.

During this reconstruction process, the helper function strips the strict, client-defined request redirect policy configuration (such as redirect: 'error'), falling back to the browser's default 'follow' strategy.

If the target web application makes client-side requests with a strict policy (e.g., expecting a network error instead of automatically following redirects), the service worker will bypass this instruction and automatically follow HTTP 3xx redirects to other destinations. This acts as an unintended proxy/intermediary ("Confused Deputy") and can result in cookie/credential exposure or same-origin session-restricted data leakage if public dynamic routes redirect to sensitive routes.

Impact Web applications registering the @angular/service-worker package are vulnerable to this redirect-policy bypass if they make safe client-side fetch calls (such as { redirect: 'error' }) to paths matched by a service worker asset group (such as lazy-loaded JavaScript bundles or dynamic public assets) that can return HTTP redirects to authenticated same-origin secure endpoints.

By stripping developer-defined safety boundaries, the service worker allows the browser to transparently query and return data from credentials-guarded resources that should have been blocked at the network barrier.

Attack Preconditions To successfully exploit this vulnerability, all of the following application states and parameters must concurrently exist: 1. Active Angular Service Worker: The target application uses @angular/service-worker and has an active registration of ngsw-worker.js inside the client's browser context. 2. Asset Group Matching: An assetGroups pattern in ngsw-config.json encompasses the target dynamic routing endpoint. 3. Same-Origin Dynamic Redirection: The server routes a public matched asset route to a service that returns an HTTP 3xx redirect pointing to a sensitive, session-restricted same-origin private route (e.g., /private/account-summary.json). 4. Established User Session: The victim user currently has an active authentication state, such as valid same-origin session cookies or auth headers stored by the browser. 5. Client-Side Safe Fetch Call: The application initiates an explicit fetch request to the route with safety parameters: { redirect: 'error' }.

Mitigations & Workarounds If upgrading the @angular/service-worker package is not immediately feasible, developers should implement the following defensive measures: Avoid Public-to-Private Dynamic Redirection: Refactor the server architecture so that public paths matched by service worker asset groups never issue HTTP 3xx redirects to authenticated same-origin secure endpoints. Strict Cookie Configuration: Apply strict flags to session cookies (SameSite=Strict; Secure; HttpOnly) and consider explicit route isolations (such as subdomains) for credential-guarded private resources. Exclude Secure Endpoints from SW Config: Verify your ngsw-config.json settings and ensure that patterns targeting dynamic, secure endpoints are explicitly excluded from automatic asset groups or caching scopes.

Patches - 22.0.0-rc.2 - 21.2.15 - 20.3.22 - 19.2.23

An issue in the @angular/service-worker package compromises the integrity of request-policy enforcement during request reconstruction. When the Angular Service Worker intercepts network requests for matched assets, it reconstructs a new Request object using an internal helper function.

During this reconstruction process, the helper function strips explicit client-defined safety parameters: the credentials configuration (such as credentials: 'omit') and the HTTP cache mode configuration (such as cache: 'no-store'). These are reverted back to standard browser-default parameters (credentials: 'same-origin' and default HTTP cache properties).

This causes the browser to include active credentials (such as cookies or Authorization headers) on outbound requests where the client-side developer explicitly instructed they should be omitted, leading to potential session leaks. Additionally, it causes private or non-cacheable resources to be cached by the service worker's engine, making private page states accessible or persistent inside the client's local cache post-logout.

Impact Web applications registering the @angular/service-worker package are vulnerable to credential exposure or post-logout cache persistence if client-side code relies on fetch calls with explicit safety attributes (such as { credentials: 'omit' } or { cache: 'no-store' }) targeting paths matched by service worker asset groups.

By stripping these safety boundaries, the service worker exposes same-origin cookies and dynamic sensitive data to endpoints that should not receive them, or retains dynamic user sessions in cache storage where logout operations fail to fully evict user records.

Attack Preconditions To successfully exploit this vulnerability, all of the following application states and parameters must concurrently exist: 1. Active Angular Service Worker: The target application uses @angular/service-worker and has an active registration of ngsw-worker.js inside the client's browser context. 2. Asset Group Matching: An assetGroups pattern in ngsw-config.json encompasses the target dynamic routing endpoint. 3. Established User Session: The victim user currently has an active authentication state, such as valid same-origin session cookies or auth headers stored by the browser. 4. Client-Side Safe Fetch Call: The application initiates an explicit fetch request to the route with safety parameters: { credentials: 'omit' } or specific cache control parameters (e.g. { cache: 'no-store' }).

Mitigations & Workarounds If upgrading the @angular/service-worker package is not immediately feasible, developers should implement the following defensive measures: Strict Cookie Configuration: Apply strict flags to session cookies (SameSite=Strict; Secure; HttpOnly) and ensure complete route isolation for credential-guarded secure resources. Exclude Secure Endpoints from SW Config: Ensure that patterns targeting dynamic, secure endpoints are explicitly excluded from automatic asset groups or caching scopes in your ngsw-config.json. Post-Logout Cache Invalidation: Programmatically purge the browser's Cache Storage API entries registered by the Angular Service Worker upon user logout: javascript if ('caches' in window) { caches.keys().then(names => { for (let name of names) { if (name.startsWith('ngsw:')) { caches.delete(name); } } }); } Patches - 22.0.0-rc.2 - 21.2.15 - 20.3.22 - 19.2.23

A reflected cross-site scripting (XSS) vulnerability in CKeditor v46.1.0 & Angular v18.0.0 allows attackers to execute arbitrary code in the context of a user's browser via injecting a crafted payload.

A vulnerability was found in Angular up to 11.0.4/11.1.0-next.2. It has been classified as problematic. Affected is the handling of comments. The manipulation leads to cross site scripting. It is possible to launch the attack remotely but it might require an authentication first. Upgrading to version 10.2.5, 11.0.5 or 11.1.0-next.3 is advised to to address this issue.

An issue in the @angular/core package allows bypassing script-execution restrictions during dynamic component creation.

Specifically, the dynamic component instantiation mechanism (createComponent) failed to reject mounting components directly onto a <script> or namespaced script element (such as <svg:script>). This enabled the initialization of custom components on a tag that executes scripts, allowing attackers to hijack or inject script-executing hosts.

This flaw enables an attacker who can control the host element or selector parameter passed to createComponent to initialize or mount an Angular component directly onto a <script> tag, leading to execution of untrusted code or client-side Cross-Site Scripting (XSS).

Impact Any Angular application that registers dynamic components based on user-supplied parameters (like selectors or host elements) is vulnerable to this security bypass.

Once exploited, this allows a malicious actor to mount a dynamic component on a script tag, bypassing core dynamic component creation safeguards to execute arbitrary JavaScript within the target user's browser context. This could lead to session hijacking, sensitive data exposure, or unauthorized actions on behalf of the user.

Attack Preconditions To successfully exploit these vulnerabilities, the following environment parameters and application states must all concurrently exist: 1. User-Controlled Host Selection: The application must accept user-controlled inputs that are passed as a selector/host element to createComponent. 2. Absence of Additional Context Sanitization: The application does not perform separate input sanitization before feeding values to the dynamic creation APIs.

Patches 22.0.0-rc.2 21.2.15 20.3.22 19.2.23