CVE-2026-27970: Cross-Site Scripting (XSS) in Angular i18n ICU Messages

Open source powers the modern software stack, but its security depends on a shared commitment to finding and fixing weaknesses before they become incidents.

At HeroDevs, that's our mission: secure open source. We do it in two ways:

1. Remediating known CVEs across critical ecosystems, and
2. Proactively researching vulnerabilities before attackers can exploit them.

A new high-severity vulnerability, CVE-2026-27970, has been disclosed in Angular's internationalization (i18n) pipeline. The vulnerability allows attackers to execute arbitrary JavaScript by injecting malicious content into translation files that Angular renders without proper sanitization.

For applications running Angular 18 or earlier, there is no upstream patch available. HeroDevs Never-Ending Support for Angular provides secure drop-in replacements for Angular v4 through v19, including patches for CVE-2026-27970 on versions the Angular team no longer maintains.

‍

What is CVE-2026-27970?

CVE-2026-27970 is a Cross-Site Scripting (XSS) vulnerability in Angular's i18n pipeline, specifically in how it processes ICU messages (International Components for Unicode). ICU messages handle complex translation patterns like pluralization, gender-specific phrasing, and conditional text selection.

The root cause: HTML embedded within translated content in ICU messages was not properly sanitized before being rendered into the DOM. If an attacker compromises the translation files used by an Angular application, they can inject JavaScript that executes in the context of the victim's browser session.

The Angular team published the advisory on February 26, 2026, with a CVSS v4 score of 7.6 (High).

‍

How Angular i18n Works (and Where It Breaks)

Angular's i18n workflow typically follows three steps:

1. Extract all translatable messages from the application source code.
2. Translate those messages, often by sending .xliff or .xtb files to a third-party translation vendor.
3. Merge the translated content back into the application at build time.

Translations are frequently handled by external contractors or localization platforms. The source messages are sent to a separate entity, and the final translations are received and compiled into the production build.

This workflow creates a supply chain trust boundary. The application implicitly trusts that the returned translation files contain safe content. CVE-2026-27970 exploits a gap in that trust: Angular was not adequately sanitizing HTML within ICU message expressions before rendering them.

‍

What are ICU messages?

ICU messages are the mechanism Angular uses for complex conditional text. They appear in templates like this:

<span i18n>{count, plural,

  =0 {No items}

  =1 {One item}

  other {{{count}} items}

}</span>

When Angular compiles the translated version of this message back into the application, it processes the ICU branches and renders the appropriate text. The vulnerability exists in how Angular handles HTML content within these branches after translation. If malicious HTML (such as a <script> tag or an event handler attribute) is embedded in the translated ICU message, Angular renders it without sanitization, allowing arbitrary JavaScript execution.

‍

Attack Preconditions

Unlike most XSS vulnerabilities, CVE-2026-27970 is not directly exploitable by arbitrary end users. An attacker must first compromise the application's translation pipeline. Successful exploitation requires all of the following conditions:

• The attacker must compromise the translation file (.xliff, .xtb, or equivalent). This could happen through a compromised translation vendor, a supply chain attack on the localization platform, or unauthorized access to the repository where translation files are stored.
• The victim application must use Angular i18n.
• The application must use one or more ICU messages in its templates.
• The application must render an ICU message that contains attacker-controlled translated content.
• The application must not defend against XSS via a restrictive Content Security Policy (CSP) or Trusted Types.

The requirement for translation file compromise raises the bar compared to a typical reflected XSS, but the impact when achieved is significant. Translation files are often treated as data rather than code, which means they may receive less scrutiny during code review and CI/CD validation than source files.

‍

Impact

When successfully exploited, CVE-2026-27970 allows an attacker to execute JavaScript in the application's origin. Depending on the nature of the application, this could lead to:

• Credential exfiltration: Stealing sensitive data stored in page memory, LocalStorage, IndexedDB, or cookies accessible to JavaScript, then transmitting it to an attacker-controlled server.
• Page vandalism: Modifying the application's appearance or behavior to mislead users, capture additional input, or redirect actions.
• Session hijacking: Using stolen tokens or cookies to impersonate authenticated users.

The attack surface is especially concerning in enterprise environments where Angular applications handle sensitive workflows (financial transactions, healthcare records, government systems) and where translation files move through multi-vendor supply chains.

‍

Affected Versions and Patches

The Angular team released patches for currently supported major versions. Angular 18 and all prior versions have no upstream fix.

This is a critical gap. Angular 18 reached end-of-life (EOL), and Angular versions 4 through 17 have been EOL for even longer. Yet many enterprise applications still run these versions in production. If your application uses Angular i18n with ICU messages on any of these unsupported versions, you are exposed to CVE-2026-27970 with no upgrade path from the Angular open source project.

‍

What If You're Running Angular 18 or Earlier?

For teams on supported Angular versions (19+), the path is clear: upgrade to the patched version.

For teams running Angular 18 or earlier, community support has ended. The Angular team does not backport security patches to EOL versions. This leaves organizations in a difficult position: either undertake a potentially large-scale migration to Angular 19+ or accept the risk.

HeroDevs Never-Ending Support (NES) for Angular provides a third option. NES for Angular delivers secure drop-in replacements for Angular v4 through v19, including backported security patches like the fix for CVE-2026-27970. Switching requires no code changes: update your package.json to point to the NES registry, rebuild, and deploy.

NES for Angular includes:

• CVE remediation with SLA-backed response times
• Compliance support for SOC 2, PCI DSS, HIPAA, FedRAMP, and EU CRA
• Browser compatibility updates for Chrome, Safari, Edge, and Firefox
• SBOM and VEX generation in CycloneDX and SPDX formats
• Expert support from engineers who have worked on Angular's core team

‍

Mitigation Guidance

Whether or not you can immediately upgrade, take these steps to reduce your exposure:

1. Upgrade or patch

If you are on Angular 19, 20, or 21, update to the patched versions: 19.2.19, 20.3.17, 21.1.6, or 21.2.0.

If you are on Angular 18 or earlier, evaluate HeroDevs NES for Angular for a secure drop-in replacement that includes the fix.

2. Treat translation files as untrusted input

Translation files should be treated as a supply chain input, with the same rigor applied to third-party code. Review and verify all translated content received from external vendors before incorporating it into your build pipeline. Consider adding automated validation in CI/CD to detect suspicious HTML or script content in .xliff and .xtb files.

3. Enable strict Content Security Policy (CSP)

A restrictive CSP can prevent inline script execution even if malicious content reaches the DOM. At minimum, avoid unsafe-inline in your script-src directive.

4. Enable Trusted Types

Angular supports Trusted Types, which enforce proper HTML sanitization at the browser level. Enabling Trusted Types provides a defense-in-depth layer that blocks unsanitized HTML from being injected into the DOM.

5. Audit your i18n usage

Identify whether your application uses ICU messages and whether any rendered translations come from external sources. Applications that only use static, internally-maintained translations have a significantly reduced attack surface.

‍

Why This Matters for the Angular Ecosystem

CVE-2026-27970 highlights a pattern that security teams should watch closely: supply chain attacks through content pipelines.

Translation files occupy an unusual position in the trust hierarchy. They are not "code" in the traditional sense, so they often bypass the security controls applied to source files, dependencies, and container images. Yet they flow directly into the rendered output of the application. When the framework does not enforce sanitization at the boundary where translated content enters the DOM, attackers gain a viable injection point.

This is also a reminder that XSS vulnerabilities are not always about user input fields and URL parameters. Any content pipeline where external data becomes part of the rendered page is a potential vector, and frameworks must sanitize aggressively at every trust boundary.

‍

Taking Action

CVE-2026-27970 is a real-world example of why EOL software creates compounding risk. The vulnerability affects every Angular version ever released, but only versions 19 through 21 received upstream patches. Organizations running Angular 18 or earlier are left without a fix from the open source project.

If your organization depends on Angular at scale, especially on EOL versions, this is exactly the kind of risk HeroDevs exists to address: reduce exposure in the open source supply chain before it becomes an incident.

‍