GHSA-hh8m-fm6v-7cvg: XSS
Angular automatically sanitizes untrusted values bound to security-sensitive DOM sinks (such as href, src, action, xlink:href, and data) to protect against Cross-Site Scripting (XSS).
Prior to the fix, the Angular compiler determined the SecurityContext for directive host bindings (host: {'[attr.href]': 'value'} or @HostBinding('attr.href')) based solely on the declaring directive or component selector at compile time, rather than the concrete host element that the directive was applied to.
When a directive with a security-sensitive host binding was applied to a different concrete host element—such as through: - hostDirectives composition, - Class inheritance of host bindings, - Dynamic component instantiation (createComponent with custom hostElement or dynamic directives), - Elements with SVG/MathML namespaces (e.g. <svg:a>, <math>), or - Elements using tag-neutral selectors (e.g. :not(...)),
the compiler either failed to associate a sanitizer with the host binding or attached an incorrect security context. As a result, untrusted inputs (e.g. javascript:... URLs) bound via the host binding would be written to the DOM attribute without passing through Angular's built-in sanitizer.
Impact An attacker capable of controlling the value bound to an affected directive host binding could execute arbitrary JavaScript in the user's browser context (Cross-Site Scripting).
Patches This issue has been resolved in versions: - 22.1.0 - 21.2.20 - 20.3.28
Workarounds Ensure that any user-controlled values assigned to properties bound via directive host bindings are explicitly sanitized using DomSanitizer.sanitize(SecurityContext.URL, ...) before assignment, or restrict the input to validated safe URL schemes (e.g. http://, https://).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/@angular/compilerto a version that resolves this vulnerability.Fixed in 20.3.28 - Upgrade
Upgrade
npm/@angular/coreto a version that resolves this vulnerability.Fixed in 20.3.28 - Upgrade
Upgrade
npm/@angular/compilerto a version that resolves this vulnerability.Fixed in 21.2.20 - Upgrade
Upgrade
npm/@angular/coreto a version that resolves this vulnerability.Fixed in 21.2.20 - Upgrade
Upgrade
npm/@angular/compilerto a version that resolves this vulnerability.Fixed in 22.1.0 - Upgrade
Upgrade
npm/@angular/coreto a version that resolves this vulnerability.Fixed in 22.1.0
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications are exposed when a directive or component uses a security-sensitive host binding and is applied to a concrete host element different from the one implied by its selector. Relevant cases include hostDirectives composition, inherited host bindings, dynamic component creation with a custom host element or dynamic directives, SVG or MathML elements, and tag-neutral selectors.
What does an attacker need to exploit it?
An attacker needs influence over an untrusted value that is bound through an affected host binding to a security-sensitive attribute such as href, src, action, xlink:href, or data. A value such as a javascript: URL may then be written to the DOM without sanitization.
Are ordinary host bindings necessarily affected?
No. The issue occurs when the compiler determines the binding security context from the declaring directive or component selector rather than the concrete host element where the directive is used. Host bindings that remain on the expected concrete host element are not identified by the provided data as affected.
How can I identify potentially affected code?
Review directives and components with host bindings such as [attr.href] or @HostBinding('attr.href'), and trace where they are applied. Prioritize bindings involving untrusted input and usages through composition, inheritance, dynamic host elements or directives, SVG/MathML namespaces, and tag-neutral selectors.