Angular SSR XSS from unescaped template content in @angular/platform-server

Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Prior to 20.3.30, 21.2.22, and 22.1.4, Angular server-side rendering (SSR) in @angular/platform-server serializes untrusted input inside template content nested in fallback raw-content elements such as noscript, iframe, noembed, and noframes. The Domino serializer's fallbackRawContentTags traversal stopped at the DocumentFragment used by template.content, so matching closing tags in xmp, style, script, comments, or text nodes were not escaped. Standard interpolation with comments or text nodes is reachable without relaxed schemas; literal xmp or style requires CUSTOM_ELEMENTS_SCHEMA or NO_ERRORS_SCHEMA, while Renderer2 imperative DOM construction is unconditionally affected. When HTML5 RAWTEXT browser parsing encounters the unescaped closing tag, it exits the fallback container and interprets trailing markup as active DOM elements, enabling arbitrary JavaScript execution. This issue is fixed in versions 20.3.30, 21.2.22, and 22.1.4.

• @angular/platform-server in Angular <= 19.2.25 is affected. The advisory states that this branch is end of support or LTS expired and will not be patched.
• Angular >= 20.0.0, < 20.3.30 is affected; the confirmed patched release is 20.3.30.
• Angular >= 21.0.0, < 21.2.22 is affected; the confirmed patched release is 21.2.22.
• Angular >= 22.0.0, < 22.1.4 is affected; the confirmed patched release is 22.1.4.
• The record does not establish the status of other branches, so a parallel or later release branch should not be assumed unaffected from the listed fixes alone.

During SSR, @angular/platform-server uses the Domino serializer to convert the DOM tree into HTML. Fallback raw-content elements such as noscript, iframe, noembed, and noframes put the HTML5 tokenizer into RAWTEXT mode, where content is treated as text until a matching closing tag is encountered. The serializer previously inspected only element ancestors when determining which tags to escape and stopped at the separate DocumentFragment used by template.content, so it failed to see fallback elements outside the template. As a result, matching closing sequences such as </noscript> in xmp, style, script, comments, or text nodes could be emitted without escaping; the browser could then leave the fallback container and interpret trailing markup as active DOM elements, enabling arbitrary JavaScript execution. Standard interpolation involving comments or text nodes can reach this path without relaxed schemas; literal xmp or style requires CUSTOM_ELEMENTS_SCHEMA or NO_ERRORS_SCHEMA, while imperative DOM construction through Renderer2 bypasses those checks and is unconditionally affected. The record does not identify which individual applications actually place untrusted data in these structures, so each deployment's data flow and rendering pattern must be verified.

The flaw is reachable over the network during Angular SSR HTML generation. The supplied assessment describes no required privileges, low attack complexity, and passive user interaction, meaning that a victim browser or another user-triggered process must process the affected SSR HTML. The practical precondition is that untrusted input reaches the vulnerable serialization path inside a template placed within a fallback raw-content element. The record marks public exploit material as available, and the Angular advisory includes a minimal reproduction, but the available evidence does not establish active exploitation, a named campaign, a victim, or a breach.

A successful exploit can cause the HTML returned by SSR to contain markup that escapes the fallback container and leads to arbitrary JavaScript execution. Possible consequences include reading data exposed to the page, changing displayed content, or performing actions in the user's context; the actual scope depends on the page's privileges and the data available in that session. The supplied assessment indicates high confidentiality and integrity impact to the vulnerable system, while it does not identify an availability impact. The flaw does not by itself show that every Angular application is exploitable, because untrusted data must reach the specific SSR structure and serialization path.

• Successful JavaScript execution could read data available to the victim's page and alter displayed content or page behavior.
• Depending on the user's session and the data exposed to the page, the script could perform actions on the user's behalf; this is a possible consequence, not evidence of a specific compromise.
• The primary consequences concern confidentiality and integrity of rendered web content. The supplied assessment does not identify an availability impact.
• Applications using SSR, accepting untrusted input, and implementing the affected template or DOM-construction patterns should receive priority for review.

1. Upgrade @angular/platform-server and the related Angular dependencies to 20.3.30 for the 20.x branch, 21.2.22 for the 21.x branch, or 22.1.4 for the 22.x branch.
2. For Angular <= 19.2.25, do not wait for a 19.x patch because the advisory states that the branch is end of support or LTS expired and will not be patched. Plan migration to a supported branch after compatibility review.
3. Until the upgrade is complete, avoid rendering untrusted input inside template elements nested in noscript, iframe, noembed, or noframes. Also avoid programmatic DOM assembly of template elements inside those fallback containers when the data may be attacker controlled.
4. After upgrading, verify the lockfile, runtime dependency resolution, and actual SSR HTML so the application uses the patched release, then test interpolation, comments, text nodes, and relevant Renderer2 paths.

1. Inventory dependencies and lockfiles to identify applications using @angular/platform-server, then compare each Angular branch with the affected and fixed boundaries.
2. Review SSR templates for template elements nested in noscript, iframe, noembed, or noframes, especially where interpolation, comments, or text nodes receive untrusted data.
3. Check templates using xmp or style with CUSTOM_ELEMENTS_SCHEMA or NO_ERRORS_SCHEMA, along with directives or components that use Renderer2 to construct template elements inside fallback containers.
4. In a test environment, inspect serialized SSR HTML to verify that closing tags matching the fallback container are escaped when they occur inside template content.
5. Browser-side XSS monitoring can be added as a precaution, but no specific IOC or log event is established; absence of log evidence does not prove that a deployment is safe.