CVE-2026-32635 is a critical cross site scripting flaw in Angular, scored CVSS 9.0 by NVD. Adding an i18n attribute to a sensitive binding such as href skips Angular's sanitization. Upgrade to 22.0.0-next.3, 21.2.4, 20.3.18 or 19.2.20, and audit templates that bind user data to those attributes.
What's affected
The GitHub advisory covers two npm packages, @angular/core and @angular/compiler. Affected and patched versions are:
- 22.0.0-next.0 up to before 22.0.0-next.3. Fixed in 22.0.0-next.3.
- 21.0.0-next.0 up to before 21.2.4. Fixed in 21.2.4.
- 20.0.0-next.0 up to before 20.3.18. Fixed in 20.3.18.
- 19.0.0-next.0 up to before 19.2.20. Fixed in 19.2.20.
- 17.0.0-next.0 up to and including 18.2.14. The advisory lists no patched version for this range.
If you are on version 17 or 18, plan a move to a patched line. The advisory also lists the attributes confirmed as vulnerable: action, background, cite, codebase, data, formaction, href, itemtype, longdesc, poster, src and xlink:href.
The advisory gives its own severity as High. The NVD score is 9.0.
How to check if you're exposed
List the installed Angular packages:
npm ls @angular/core @angular/compiler
Then search your templates for i18n markers on the sensitive attributes:
grep -rnE 'i18n-(action|background|cite|codebase|data|formaction|href|itemtype|longdesc|poster|src|xlink:href)' src/
Each hit is a place where the sanitizer may be skipped. A hit is only dangerous when the bound value can come from untrusted data such as a database field, an API response or a URL parameter. The advisory lists three preconditions: a vulnerable version, unsanitized user input bound to one of those attributes, and an i18n marker on the same element.
What to do now
- Upgrade @angular/core and @angular/compiler to a patched version on your line: 22.0.0-next.3, 21.2.4, 20.3.18 or 19.2.20 or later.
- If you are on 17 or 18, schedule an upgrade to a supported patched line, because the advisory lists no fix for them.
- Until you patch, remove the i18n marker from any sensitive attribute that carries untrusted data.
- Or sanitize the value yourself with the DomSanitizer service before binding, as the advisory describes.
- Rebuild and redeploy the application. A compiled bundle keeps the old behavior until you do.
- Add a lint or code search rule that flags i18n markers on the attributes above.
A few practical notes for planning the fix.
First, find every Angular application you own, including internal tools that nobody has touched for a while. The vulnerable code is compiled into the client bundle, so each application needs its own rebuild and redeploy. A scan of your repositories for package manifests is the fastest way to build that list.
Second, the version 17 and 18 range has no patched release in the advisory. If you are there, the upgrade is a larger project, so use the template search above and the DomSanitizer workaround to reduce exposure while you plan it.
Third, add a check to your pull request process. A search for i18n markers on the listed attributes is cheap, and it catches new uses as developers add them. Pair it with a rule that user controlled values must not reach those attributes unsanitized.
Why it matters
The class is CWE-79, cross site scripting. Angular normally treats values bound to risky attributes as untrusted and strips dangerous content. The advisory says that turning on internationalization for such an attribute bypassed that built in sanitization. A bound value holding a script URL could then run in the application's own origin.
The impact the advisory lists is the usual set for XSS: stolen session tokens, data sent to an attacker, and actions taken as the user. Because the code runs inside your domain, the browser trusts it.
The fix lives in your build, not in a server. That makes the dependency inventory important. You need to know which applications ship which Angular version, including old internal tools. The record's KEV flag is false.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is every Angular application affected?
No. The advisory requires a vulnerable version, untrusted input bound to one of the listed attributes, and an i18n marker on that same element.
Can I work around it without upgrading?
Yes, per the advisory. Keep untrusted data out of those bindings when they are marked for i18n, or pass the value through the DomSanitizer first. Upgrading is still the cleaner fix.
Does a server side change help?
Not by itself. The behavior is in the compiled client code, so you need to rebuild with a patched version.
Sources
Last reviewed: 19 October 2026.
