CVE-2026-22610: Angular SVG Script Attribute Sanitization Bypass Leading to XSS

CVE-2026-22610 is a high-severity Cross-Site Scripting (XSS) vulnerability in Angular’s template compiler that allows an attacker to execute arbitrary JavaScript in a victim’s browser when untrusted data is bound to the href or xlink:href attributes of SVG <script> elements. The issue exists because Angular’s internal sanitization schema did not classify those SVG script attributes as a Resource URL context, so they were not checked/blocked like other resource-loading attributes. Patched Angular releases were published the week of Jan 8–11, 2026.

Affected components & patched versions

Vulnerable package(s): @angular/compiler (and affected uses in @angular/core template processing).
Patched releases (examples advertised by vendors): 19.2.18, 20.3.16, 21.0.7, and 21.1.0-rc.0 (upgrade to at least these versions or later).

Vulnerability root cause — technical breakdown

SVG `<script>` and resource contexts

SVG allows <script> elements where the script source can be referenced through attributes such as href or the older xlink:href. Loading script bytes from a URL is a resource load operation that, in many frameworks, should be treated as a Resource URL context (similar to <script src="..."> or <iframe src="...">). Resource URL contexts are risky because they cause the browser to fetch and execute remote content.

What Angular did wrong

Angular’s template compiler maintains a schema that classifies attributes by the context in which they are used (e.g., URL, Resource URL, style, HTML, etc.). For certain contexts Angular applies stricter sanitization or blocks untrusted input. In CVE-2026-22610 the compiler’s internal schema did not treat href and xlink:href on SVG <script> elements as a Resource URL context—so expressions or bindings that set those attributes could inject attacker-controlled URLs without being sanitized or rejected. That omission allowed an attacker who can control bound data to get browsers to load attacker-controlled scripts and execute them in the victim’s origin.

Impact / exploitability

Impact: arbitrary JavaScript execution in the context of the vulnerable web application. This enables session theft, data exfiltration, performing actions as the victim user, or persistent XSS if stored input is used.
CVSS / Severity: reported as High; vendors and repositories list CVSS scores in the 7.x–8.x range depending on the assessor (e.g., some sources cite CVSS 4.0/7.3; others provide higher weighted scores). Treat this as high-priority for web applications that bind untrusted data into SVG attributes.
Exploitation prerequisites: the attacker must be able to supply or influence data that gets bound into href / xlink:href attributes in a template compiled by a vulnerable Angular version, and the victim must visit the page (or the page must render malicious content for the victim). Not all apps are exploitable; only those that bind untrusted input into those specific SVG attributes (or otherwise render attacker-supplied markup that results in such attributes) are at risk.

Detection & scouting in your codebase

Search for templates or runtime bindings that set href/xlink:href inside SVG <script> elements. Useful grep / ripgrep patterns (safe, non-exploitative) you can run in your repository:

Find likely template occurrences:

# search Angular templates / components for 'xlink:href' or 'href' inside svg/script contexts
rg "<script[^>]* (href|xlink:href)=\"|<script[^>]* \[(href|xlink:href)\]="

Search for binding expressions that might be runtime-supplied:

rg "\[(href|xlink:href)\]\s*=\s*\"|{{\s*.*(href|xlink:href).*}}"

Also audit any places where user input is injected into raw SVG markup (e.g., innerHtml/[innerHTML] or server-generated SVGs containing placeholders). If you see bindings in or around <svg>/<script> tags, treat them as high priority for review. (These commands are defensive scanning—do not use them to craft payloads.)

Responsible disclosure / credits

The GitHub Advisory and Angular team entries list contributors who reported and triaged the issue (credit appears on the advisory). The advisory and commits detail the fix and the versions that include it. See the official GitHub security advisory for the canonical disclosure and links to the fix/PR.

Mitigations & recommended fixes (practical guidance)

Upgrade Angular immediately
Upgrade @angular/compiler (and your Angular toolchain) to the patched versions listed by Angular: >= 19.2.18, >= 20.3.16, >= 21.0.7 or 21.1.0-rc.0 / later as appropriate for your major version. Upgrading addresses the sanitization schema omission at compiler time. Test after upgrading.
Audit template bindings
Do a focused audit for any bindings to href or xlink:href inside <svg> and especially <svg><script> contexts. Replace runtime bindings of untrusted data in these attributes with safer patterns (e.g., don’t bind user data to resource-loading attributes).
Avoid binding untrusted data to resource URLs
If you must load resources dynamically, validate and canonicalize the URL server-side (whitelist domains), or use safer programmatic approaches that explicitly control allowed URLs. Avoid using DomSanitizer.bypassSecurityTrustResourceUrl() except for trusted, developer-controlled strings—bypassing sanitization defeats framework protections.
Harden with Content Security Policy (CSP)
Use a strict CSP that limits script sources (e.g., script-src 'self' https://trusted.cdn.example) and disallows inline scripts ('unsafe-inline') where possible. CSP reduces the impact of XSS by preventing browser fetch/execution of attacker-hosted scripts even if a binding is exploitable. (CSP is defense-in-depth, not a substitute for fixing the bug.)
Sanitize or escape user-supplied SVG content
If your application stores or renders user-provided SVGs, sanitize those server-side with a vetted SVG sanitizer (for example, libraries that remove script elements and dangerous attributes) before storing or rendering. Never trust client-side sanitization alone.
Monitoring and detection
- Watch for anomalous external script loads (unexpected domains) in application telemetry or web server logs.
- Add alerts for new occurrences of xlink:href / href being set to third-party hosts from templates that historically do not do so.
- Update vulnerability scanners and SCA (software composition analysis) tools to flag projects with vulnerable Angular versions. Several vendors have already added checks (Snyk, Tenable, etc.).

Why this matters (developer/ops perspective)

Framework sanitizers are the last line of defense between developer templates and client-side injection. An omission in the compiler’s attribute schema means seemingly innocuous template bindings can become critical attack vectors. Even if your app doesn’t directly bind user input into those specific SVG attributes today, third-party libraries or future code changes may introduce such bindings; upgrading and auditing proactively is the safest path.

What to communicate to stakeholders (plain language)

Product owners / managers: This is a high-priority security fix. It allows attackers to run code in users’ browsers. Patch Angular toolchain (build/CI) and deploy fixes; prioritize audit of pages that render SVGs.
Developers: Don’t bind untrusted data to resource-loading attributes inside SVGs; upgrade Angular and check for href/xlink:href bindings in templates.
Ops / Sec teams: Monitor for exploit attempts, update scanning rules, and deploy CSPs and runtime detection to reduce blast radius until all apps are patched.