Angular i18n flaw could let compromised translation files inject malicious JavaScript

A newly disclosed Angular vulnerability could let attackers run malicious JavaScript inside affected web apps, but only under specific conditions. The issue, tracked as CVE-2026-27970, affects Angular’s i18n pipeline and centers on ICU messages where translated HTML was not properly sanitized before rendering.

The most important detail is this: the flaw does not work like a typical XSS bug that any random visitor can trigger. An attacker must first compromise the application’s translation file, such as an XLIFF or XTB file, and the target app must use Angular i18n, render at least one ICU message, and lack strong protections such as a safe Content Security Policy or Trusted Types.

That makes the issue narrower than many alarmist headlines suggest, but still serious for teams that rely on external translation workflows. Angular’s own advisory says the problem can lead to attacker-controlled JavaScript running in the application origin, which can expose user data or alter page behavior.

What happened

GitHub’s official security advisory for Angular says a cross-site scripting vulnerability exists in the framework’s internationalization pipeline. In affected cases, HTML embedded in translated ICU content may execute JavaScript because Angular did not sanitize that content correctly. The advisory was published on February 25, 2026 and updated on February 27, 2026.

Angular’s i18n workflow usually involves extracting source messages, sending them out for translation, and then merging them back into the application. That normal process becomes risky if a translation file gets tampered with before it returns to the developer or deployment pipeline. According to the advisory, malicious content in those returned translations could be rendered into the final application.

Severity and why the scoring matters

The sample article calls this a critical flaw, but the official records do not support that wording. GitHub marks the issue High, while the NVD page shows a CVSS v4.0 score of 7.6 High from the CNA and an NVD CVSS v3.1 score of 6.1 Medium. That means the flaw is real and important, but “critical” overstates the current public scoring.

This scoring split also explains why summaries online may look inconsistent. If you want the safest interpretation, call it a high-severity Angular i18n XSS flaw with important exploitation preconditions. That description matches the official advisory and the public vulnerability records more closely than “critical remote XSS.”

Vulnerability details

Item	Details
CVE	CVE-2026-27970
Package	@angular/core
Issue type	Cross-site scripting in Angular i18n
Weakness	CWE-79
Main trigger	Malicious content in compromised translation files
Risky area	ICU messages in translated content
Main impact	JavaScript execution in the application origin

Affected and patched versions

Affected range	Fixed version
>= 21.2.0-next.0, <= 21.2.0-rc.0	21.2.0
>= 21.0.0-next.0, <= 21.1.5	21.1.6
>= 20.0.0-next.0, <= 20.3.16	20.3.17
>= 19.0.0-next.0, <= 19.2.18	19.2.19
<= 18.2.14	No 18.x patch listed in the GitHub advisory

One detail needs extra care: some summaries say all affected versions have direct patch releases, but the official GitHub advisory lists patched versions only for 21.2.0, 21.1.6, 20.3.17, and 19.2.19. It does not list a patched 18.x release in the advisory text shown publicly.

What attackers could do

If the exploit works, Angular says the attacker may run JavaScript in the application’s origin. That can lead to:

• theft of data available to JavaScript, including page memory, LocalStorage, IndexedDB, or accessible cookies
• page tampering or misleading content changes
• abuse of the victim’s active session inside the affected app

These impacts depend on what the application stores client-side and what defenses already exist in the browser and app architecture. Still, for business apps, dashboards, and admin tools, even a constrained XSS issue can create a meaningful risk.

Why this is different from normal XSS

This flaw is unusual because the attacker must first get control of the translation content supply chain. GitHub’s advisory says the attacker must compromise a translation file, and the app must use Angular i18n plus one or more ICU messages that actually render in the browser. On top of that, strong CSP or Trusted Types can block or reduce exploitability.

So the danger is not “every Angular site is instantly exploitable.” The real risk sits with teams that:

• send translations to third parties
• automatically ingest translated content
• use ICU-based localized messages
• lack modern browser-side XSS defenses

That narrower threat model still matters a lot for enterprise apps with global localization pipelines.

What developers should do now

• Upgrade Angular immediately to a fixed version in a supported branch. The official patched releases are 21.2.0, 21.1.6, 20.3.17, and 19.2.19.
• Review translation files from outside vendors or contractors before merging them into builds. Angular’s advisory explicitly recommends verifying translated content received from untrusted third parties.
• Enable a strict Content Security Policy to reduce the chances of unauthorized script execution.
• Enable Trusted Types in Angular where possible. Angular’s advisory points developers to official Trusted Types guidance.
• Audit ICU-heavy localized templates and look closely at any workflow that imports HTML-like content from translation tools or external providers. This is a grounded recommendation based on the vulnerability’s behavior in ICU messages.

FAQ