CVE-2026-88058: Angular: SSR XSS via Unescaped Processing Instruction (<?...?>) Nodes in Fallback Raw-Content Elements
Summary An XSS vulnerability exists in @angular/platform-server during server-side rendering (SSR) HTML serialization of ProcessingInstruction DOM nodes (<?target data?>, nodeType === 7) when nested inside fallback raw-content elements (<noscript>, <iframe>, <noembed>, <noframes>). While processing instruction data escaped > to >, it did not check for or escape matching closing tags of ancestor fallback elements (e.g., </noscript>). When rendered in a browser with scripting enabled, an unescaped closing tag sequence in a processing instruction prematurely closes the fallback raw-content tag and causes subsequent sibling elements to execute as live HTML.
Technical Description In HTML5 parsing, fallback raw-content elements (<noscript>, <iframe>, <noembed>, <noframes>) place the browser's HTML tokenizer into RAWTEXT mode. In RAWTEXT mode, processing instruction tokens (<?...?>) are treated as literal raw text rather than bogus comments, and the parser ignores > or ?>. The only token sequence that terminates the container is an end tag matching the container tag name (</noscript, </iframe, etc.).
During server-side HTML serialization, processing instruction nodes previously only replaced > with > (preventing bogus comment breakouts in normal HTML data states) but left < untouched. Crucially, processing instruction serialization never inspected ancestor fallback raw-content tags. As a result, if a ProcessingInstruction node inside <noscript> contained </noscript in its data payload, it was emitted unescaped as <?x </noscript ?>.
Impact & Reachability Reachability: Processing instruction nodes cannot be authored directly through standard Angular template syntax (which parses <?...> into comment nodes in DOM position). Reaching this vulnerability requires application or library code calling inject(DOCUMENT).createProcessingInstruction(target, data) or Renderer2 DOM insertion methods with untrusted user input passed to data inside a fallback raw-content container. Impact: In applications that programmatically construct processing instruction nodes inside fallback elements during server-side rendering, an attacker controlling the processing instruction data can break out of the container and execute arbitrary JavaScript in victims' browsers.
Proof of Concept (Minimal Reproduction) ts import { Component, ElementRef, Renderer2, inject, DOCUMENT, AfterViewInit } from '@angular/core';
@Component({ selector: 'app-root', standalone: true, template: <noscript id="host"></noscript> }) export class AppComponent implements AfterViewInit { private r = inject(Renderer2); private el = inject(ElementRef); private doc = inject(DOCUMENT);
ngAfterViewInit() { const host = this.el.nativeElement.querySelector('#host'); // Attacker-controlled input passed as Processing Instruction data const pi = this.doc.createProcessingInstruction('x', '</noscript '); this.r.appendChild(host, pi); // Sibling markup that should remain inert inside <noscript> const img = this.r.createElement('img'); this.r.setAttribute(img, 'src', 'x'); this.r.setAttribute(img, 'onerror', 'alert("SSRPIXSS")'); this.r.appendChild(host, img); } } Vulnerable SSR Output: html <noscript><?x </noscript ?><img src="x" onerror="alert('SSRPIXSS')"></noscript>
Workarounds Avoid passing untrusted user input into document.createProcessingInstruction(target, data) when the node is inserted into <noscript>, <iframe>, <noembed>, or <noframes> during server-side rendering. Manually sanitize or replace < with < in any untrusted data passed to processing instruction nodes on the server.
Other sources
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 ProcessingInstruction DOM nodes inside fallback raw-content elements without escaping matching ancestor closing tags. ProcessingInstruction data escaped greater-than characters but left less-than characters untouched and did not inspect fallback ancestors, so data such as a matching closing tag prematurely terminates noscript, iframe, noembed, or noframes containers. The vulnerable nodes cannot be authored through standard Angular templates; reachability requires application or library code using inject(DOCUMENT).createProcessingInstruction with attacker-controlled data or Renderer2 DOM insertion inside a fallback container. In HTML5 RAWTEXT parsing, the premature close causes subsequent sibling elements to be interpreted as live HTML and enables arbitrary JavaScript execution in a victim's browser. This issue is fixed in versions 20.3.30, 21.2.22, and 22.1.4.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/@angular/platform-serverto a version that resolves this vulnerability.Fixed in 20.3.30 - Upgrade
Upgrade
npm/@angular/platform-serverto a version that resolves this vulnerability.Fixed in 21.2.22 - Upgrade
Upgrade
npm/@angular/platform-serverto a version that resolves this vulnerability.Fixed in 22.1.4 - Compensating control
Do not pass untrusted user input to document.createProcessingInstruction(target, data) or Renderer2 DOM insertion when the processing instruction is inserted into <noscript>, <iframe>, <noembed>, or <noframes> during server-side rendering; otherwise manually sanitize the data by replacing < with <.
Event History
Frequently Asked Questions
Which applications are realistically exposed to this issue?
Only Angular applications using server-side rendering through @angular/platform-server are exposed, and only if application or library code creates ProcessingInstruction nodes with attacker-controlled data inside noscript, iframe, noembed, or noframes fallback containers. Standard Angular templates cannot author the vulnerable nodes.
What does an attacker need to control to exploit it?
The attacker needs control over data supplied to a ProcessingInstruction created through inject(DOCUMENT).createProcessingInstruction or inserted through Renderer2 within a fallback raw-content container. The controlled data must include a closing tag matching an ancestor fallback element, allowing later sibling content to be parsed as live HTML.
Are default Angular SSR applications affected?
The issue is not reachable through standard Angular templates alone. Exposure depends on custom application or library DOM-manipulation code that creates or inserts the affected node type in the specified fallback containers.
How can I determine whether my application is affected?
Review SSR-capable application and library code for inject(DOCUMENT).createProcessingInstruction and Renderer2 DOM insertion. Investigate cases where attacker-controlled values can reach ProcessingInstruction data inside noscript, iframe, noembed, or noframes elements.
What versions contain the fix?
Upgrade Angular to 20.3.30, 21.2.22, or 22.1.4, as applicable.