CVE-2026-88057

What it actually does

Angular's compiler and runtime in @angular/core and @angular/compiler derived SecurityContext from the declaring directive or component selector instead of the concrete host element. As a result, URL-sensitive host bindings (href, src, action, xlink:href, data) could skip Angular's built-in sanitizer. The mismatch is reachable via hostDirectives composition, inherited HostBinding declarations, createComponent with a custom hostElement or dynamic directives, SVG/MathML namespaced elements, and tag-neutral selectors such as :not(...). Unsanitized attacker-controlled values can therefore be written to DOM attributes and execute script in the application's origin.

Why it matters to the business

Successful abuse yields cross-site scripting in the victim's browser under the application's origin, enabling session theft, account takeover, unauthorized actions as the user, and content injection. Impact is highest for internet-facing Angular apps that bind untrusted URLs into host attributes, especially those using hostDirectives, dynamic components, or SVG/MathML. CVSS 6.1 reflects network reach with required user interaction and no privileges. Public exploit material is already available and the issue has been public for about 27 days, so unpatched apps face elevated opportunistic scanning even though this CVE is not in CISA KEV and is not reported in ransomware campaigns.

How an attack unfolds

An attacker locates an Angular application on a vulnerable 20.x, 21.x, or 22.x release where a host binding for a URL-bearing attribute is composed, inherited, or applied to a host element whose namespace or tag does not match the declaring selector. They then supply a dangerous URL (for example a non-http(s) scheme) through any input that flows into that binding—query parameters, stored content, or API data. Because the wrong SecurityContext is chosen, Angular does not sanitize the value. When a user loads the affected view or activates the bound element, the browser treats the attribute as a navigable or loadable resource and runs attacker script in the application origin, with access to that origin's cookies, storage, and DOM.

How to fix it

Upgrade @angular/core and @angular/compiler to 20.3.28 (20.x), 21.2.20 (21.x), or 22.1.0 (22.x) or later. Rebuild and redeploy all frontend bundles so the patched compiler and runtime ship to clients. Applications that cannot upgrade immediately should pass untrusted URL values through DomSanitizer.sanitize with SecurityContext.URL before assignment, and/or allow only validated http and https schemes. Audit hostDirectives, inherited HostBinding usage, createComponent custom hosts, SVG/MathML templates, and tag-neutral selectors for bindings of href, src, action, xlink:href, and data. Lock dependency ranges in package manifests so older compiler/runtime packages cannot be reintroduced.

How to confirm the fix worked

Confirm installed @angular/core and @angular/compiler versions are at least 20.3.28, 21.2.20, or 22.1.0 in lockfiles and in shipped bundles. After upgrade, rebuild production artifacts and verify the running app's package versions (for example via ng version or lockfile inspection). Review templates and directive metadata for host bindings of URL attributes under composition, inheritance, dynamic hosts, and SVG/MathML. In a non-production check, ensure untrusted URL-like input is stripped or neutralized by Angular's sanitizer rather than written through to the DOM. Confirm workaround call sites use DomSanitizer.sanitize(SecurityContext.URL, ...) where upgrades are delayed.

Typical attack path

1. Identify an Angular app still on @angular/core or @angular/compiler before 20.3.28, 21.2.20, or 22.1.0.
2. Find a host binding, hostDirective, inherited HostBinding, dynamic createComponent host, or SVG/MathML element that assigns user-influenced data to href, src, action, xlink:href, or data.
3. Inject a non-http(s) URL scheme into that data path so it is stored or reflected into the binding.
4. Induce a victim to open the affected page or interact with the bound element (click, navigation, or resource load).
5. Execute script in the application's origin and steal session tokens, perform in-app actions, or persist further XSS.

How to detect it

This is client-side XSS, so server logs rarely show a unique exploit fingerprint. Review web access, WAF, and CDN logs for requests that store or reflect unusual URL schemes into pages that bind href, src, action, xlink:href, or data. On the client, inspect DOM snapshots, browser history, and CSP reports for javascript:, data:, vbscript:, or other non-http(s) schemes on those attributes, especially on SVG/MathML nodes or dynamically created hosts. Check CSP violation reports (script-src, object-src, navigate-to) around the publication window (from 2026-09-10 onward). Look for unexpected session use, new OAuth grants, or account changes following visits to Angular views that render user-controlled URLs. There are no named threat actors tied to this CVE; hunt for opportunistic XSS rather than a specific campaign. Source maps and deployed main.*.js bundles can confirm whether a pre-fix compiler was serving users at the time of a suspected incident.

• javascript:
• data:text/html
• data:application/javascript
• vbscript:
• xlink:href
• hostDirectives
• SecurityContext

What your security team should do

• Patch Angular 20.x to 20.3.28, 21.x to 21.2.20, and 22.x to 22.1.0 (or newer) and redeploy rebuilt bundles as the primary control.
• Inventory every Angular application for hostDirectives, inherited HostBindings, createComponent custom hosts, SVG/MathML, and tag-neutral selectors that bind href, src, action, xlink:href, or data.
• Until patched, sanitize untrusted URLs with DomSanitizer.sanitize(SecurityContext.URL) and restrict schemes to http/https.
• Prioritize internet-facing apps that render user- or partner-supplied links, images, or form actions; exploit material is already available.
• Hunt for historical XSS using the detection guidance below and rotate sessions if compromise is suspected.
• Pin Angular packages in CI so regressions to vulnerable compiler/runtime versions fail the build.
• Treat this as a medium-severity but actively exploitable client-side issue: user interaction is required, but no authentication is.