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(); });

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

An issue in the @angular/compiler and @angular/core packages allows bypassing element and attribute sanitization/validation through specific namespace workarounds.

Specifically, namespaced script elements (e.g., <svg:script> or <:svg:script>) were not properly identified as script elements by the Angular template preparser, allowing them to pass through template compilation without being stripped.

Furthermore, security context schema mappings for element attributes did not consistently handle attributes within namespaced elements (like SVG and MathML), opening up gaps where malicious namespaced attributes could bypass runtime and compile-time sanitizers.

Combined, these flaws enable an attacker who can inject or supply a template/tag structure with custom namespaces to bypass Angular's script-stripping logic and attribute sanitizers, leading to client-side Cross-Site Scripting (XSS).

Impact Any Angular application that compiles user-controlled templates at runtime, or relies on sanitization of namespaced elements/attributes, is vulnerable to this security bypass.

Once exploited, this allows a malicious actor to inject a namespaced script element or dynamic attribute bindings, bypassing core sanitization constraints 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 Template Input: The application must accept user-controlled inputs that are directly processed by the Angular template compiler at runtime. 2. Namespace Parsing Support: The input structure must employ custom namespace prefixes (such as <svg:script>) to evade standard tag-name blocklists/checks. 3. Absence of Additional Context Sanitization: The application does not perform separate input sanitization before feeding values to the Angular compiler.

Patches 22.0.0-rc.2 21.2.15 20.3.22 19.2.23

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

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 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

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