Angular XSS flaw puts apps at risk when i18n is used on sensitive attributes

A high-severity Angular vulnerability could expose web applications to cross-site scripting attacks, but the risk is narrower than the headline suggests. The flaw, tracked as CVE-2026-32635, affects Angular only when an app binds untrusted input to a security-sensitive HTML attribute and also marks that same attribute for internationalization with i18n-<attribute>.

Angular’s advisory says the bug affects both @angular/core and @angular/compiler. In that scenario, Angular’s usual sanitization can be bypassed, which may let an attacker inject malicious script into the page context. The example given by Angular uses a malicious value bound to href together with i18n-href.

This does not mean every Angular site is suddenly exposed. An attacker still needs the target app to meet three conditions: it must run a vulnerable Angular version, bind untrusted user-controlled data to one of the affected attributes, and use the matching i18n-<name> marker on the same element. Without that exact pattern, the issue does not trigger.

The impact can still be serious in applications that match those conditions. Angular says successful exploitation can lead to arbitrary code execution in the context of the vulnerable site, which may allow session hijacking, data exfiltration, and unauthorized actions performed on behalf of the user. GitHub rates the issue High severity with a CVSS score of 8.6.

What makes the Angular bug dangerous

The vulnerable pattern involves internationalized sensitive attributes, not general Angular templating. Angular has confirmed the following attributes as vulnerable in this case: action, background, cite, codebase, data, formaction, href, itemtype, longdesc, poster, src, and xlink:href.

That matters because developers may assume Angular’s default sanitization still protects them everywhere. In this specific i18n binding path, the framework’s built-in protections can be bypassed, which turns otherwise familiar attribute bindings into a possible XSS path if the value comes from untrusted input.

Affected and fixed Angular versions

One important detail stands out in the advisory. Angular lists no patched version for the affected 17.x and 18.x lines, so teams still on those branches may need to rely on code changes and input handling workarounds instead of a direct upgrade within the same major line.

What developers should do now

• Upgrade to a patched version as soon as possible if you are on Angular 19, 20, 21, or 22 prerelease branches covered by the advisory.
• Audit templates for sensitive attributes that use both data binding and i18n-<attribute> on the same element.
• Remove internationalization markers from sensitive attributes if the value comes from untrusted data. Angular specifically recommends avoiding untrusted user input in those bindings until patched.
• Use DomSanitizer explicitly where needed. Angular’s advisory provides a workaround example that sanitizes the dangerous URL through SecurityContext.URL before binding it.

Why this matters for enterprise apps

Angular powers many internal dashboards, portals, and customer-facing applications, so even a narrowly scoped framework flaw deserves attention. This one is especially relevant for teams that localize user-facing interfaces heavily and may have added i18n-* attributes across templates without reviewing how those bindings interact with untrusted data sources. That combination can turn a translation feature into a security exposure.

FAQ