CVE-2026-50555: Angular Server-Side Rendering XSS via Unicode Index Misalignment in Domino

Technical summary

The vulnerability resides in the domino DOM emulation library used by @angular/platform-server during server-side rendering. Domino implements escaping logic to prevent closing-tag breakout attacks in raw-text elements by replacing unsafe content. However, a Unicode index alignment bug exists in this escaping mechanism. JavaScript calculates string indices using UTF-16 code units, where astral characters (U+10000 and above, including emojis) occupy 2 code units instead of 1. When dynamic content contains astral characters before a closing tag (e.g., emoji followed by </iframe>), the index offset calculation in domino's replacement logic miscalculates the position of the closing tag. This causes the escaping logic to skip the closing tag entirely, leaving it unescaped in the serialized HTML. When a browser parses the server-rendered output, the unescaped closing tag prematurely terminates the raw-text context, allowing subsequent inline scripts to execute with same-origin context.

Business impact

Organizations deploying Angular applications with server-side rendering are at risk of XSS attacks targeting their users. An attacker can craft malicious input containing emoji or other astral Unicode characters combined with JavaScript payloads. If this input flows through SSR and reaches a victim's browser, the victim's session can be compromised, credentials stolen, or malware injected—all within the application's origin. The attack surface includes any user-controlled data that reaches a raw-text element during SSR: form submissions, URL parameters, API responses, or database content. The impact depends on what an attacker can accomplish with same-origin access, potentially including account takeover, data exfiltration, or lateral movement.

Affected systems

The vulnerability affects Angular applications using @angular/platform-server for server-side rendering across versions prior to 22.0.0-rc.2, 21.2.16, 20.3.24, and 19.2.25. Any Angular SSR deployment on these older versions is potentially vulnerable if it processes untrusted dynamic content that could include Unicode characters. This includes web frameworks and hosted platforms that rely on Angular SSR for performance or SEO purposes.

Exploitability

The vulnerability requires user interaction (UI:R) and is reachable over the network without authentication (AV:N, PR:N). However, exploitation is not trivial: an attacker must control dynamic text that flows into a raw-text element during SSR and must know or guess that astral Unicode characters will bypass the escaping. The attack succeeds only when user-controlled input reaches the server-side renderer and when the victim's browser subsequently parses the output. No public exploit code or active exploitation has been reported in the KEV catalog, but the mechanics are straightforward once understood. Organizations with strict content security policies (CSP) may reduce impact, though same-origin XSS can often circumvent weak CSP rules.

Remediation

Upgrade Angular to patched versions: 22.0.0-rc.2 or later, 21.2.16 or later, 20.3.24 or later, or 19.2.25 or later. Verify the exact version in your package.json and run npm update @angular/platform-server to pull the fix. The patches correct the index alignment bug in domino's escaping logic. Organizations unable to patch immediately should sanitize user input before passing it to SSR contexts, validate that raw-text elements do not contain untrusted content, and implement strict CSP headers to limit inline script execution. However, patching is the definitive remediation.

Patch guidance

Verify your current Angular version using npm list @angular/platform-server or by checking package.json. If your version is older than 22.0.0-rc.2, 21.2.16, 20.3.24, or 19.2.25 (depending on which major version line you are on), upgrade immediately. Run npm install @angular/platform-server@latest or specify the exact patched version. Test your SSR application thoroughly after upgrading, particularly with dynamic content containing Unicode characters, to confirm that rendering and escaping behavior is correct. Consider automated testing of SSR outputs with emoji and other astral characters to prevent regression.

Detection guidance

Review your server-rendered HTML output for unescaped closing tags in raw-text elements. Look for patterns like 😀</iframe> or similar emoji-before-closing-tag sequences in the rendered DOM. Monitor for XSS attempts in user input logs, especially those containing emoji or high-Unicode characters followed by script tags. Implement Content Security Policy headers with script-src restrictions to limit the impact of any unescaped closing tags. Analyze SSR template variables and component bindings that output user-controlled data into raw-text elements; these are high-risk areas. Web application firewalls can be configured to detect payloads combining emoji with closing tags, though false positives should be managed.

Why prioritize this

This vulnerability merits prompt patching due to its MEDIUM CVSS score (6.1), ease of delivery over the network, and potential for same-origin XSS leading to account compromise or data theft. Although user interaction is required, the bar for exploitation is low once an attacker understands the Unicode alignment bug. SSR is a common optimization technique, especially in isomorphic JavaScript frameworks, making the attack surface broad in many organizations. The lack of KEV listing does not diminish urgency; patching is straightforward and risk reduction is immediate.

Risk score, explained

The CVSS 3.1 score of 6.1 (MEDIUM) reflects a network-reachable vulnerability with low attack complexity and no privilege requirement, but with user interaction needed and limited impact scope (confidentiality and integrity, not availability). While the score appears moderate, the practical risk is elevated for SSR deployments because XSS in the same origin can lead to session hijacking, credential theft, and further attack chain development. Organizations should weight their exposure (how many SSR instances serve untrusted user data) and user trust model when assessing risk.

Frequently asked questions