Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact Using carefully crafted input, an attacker may be able to sneak arbitrary HTML and CSS through Sanitize = 3.0.0, < 6.0.2 when Sanitize is configured to use the built-in "relaxed" config or when using a custom config that allows style elements and one or more CSS at-rules. This could result in XSS (cross-site scripting) or other undesired behavior when the malicious HTML and CSS are rendered in a browser. Patches Sanitize = 6.0.2 performs additional escaping of CSS in style element content, which fixes this issue. Workarounds Users who are unable to upgrade can prevent this issue by using a Sanitize config that doesn't allow style elements, using a Sanitize config that doesn't allow CSS at-rules, or by manually escaping the character sequence </ as <\/ in style element content. Credit This issue was found by @cure53 during an audit of a project that uses Sanitize and was reported by one of that project's maintainers. Thank you!
Recommended action: Upgrade to 6.0.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Using carefully crafted input, an attacker may be able to sneak arbitrary HTML through Sanitize = 5.0.0, < 6.0.1 when Sanitize is configured with a custom allowlist that allows noscript elements. This could result in XSS (cross-site scripting) or other undesired behavior when that HTML is rendered in a browser. Sanitize's default configs don't allow noscript elements and are not vulnerable. This issue only affects users who are using a custom config that adds noscript to the element allowlist. Patches Sanitize = 6.0.1 always removes noscript elements and their contents, even when noscript is in the allowlist. Workarounds Users who are unable to upgrade can prevent this issue by using one of Sanitize's default configs or by ensuring that their custom config does not include noscript in the element allowlist. Details The root cause of this issue is that HTML parsing rules treat the contents of a noscript element differently depending on whether scripting is enabled in the user…
Recommended action: Upgrade to 6.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When HTML is sanitized using Sanitize's "relaxed" config or a custom config that allows certain elements, some content in a <math or <svg element may not be sanitized correctly even if math and svg are not in the allowlist. You are likely to be vulnerable to this issue if you use Sanitize's relaxed config or a custom config that allows one or more of the following HTML elements: - iframe - math - noembed - noframes - noscript - plaintext - script - style - svg - xmp Impact Using carefully crafted input, an attacker may be able to sneak arbitrary HTML through Sanitize, potentially resulting in XSS (cross-site scripting) or other undesired behavior when that HTML is rendered in a browser. Releases This problem has been fixed in Sanitize 5.2.1. Workarounds If upgrading is not possible, a workaround is to override the default value of Sanitize's :removecontents config option with the following value, which ensures that the contents of math and svg elements (among others) are removed…
Recommended action: Upgrade to 5.2.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When Sanitize <= 4.6.2 is used in combination with libxml2 = 2.9.2, a specially crafted HTML fragment can cause libxml2 to generate improperly escaped output, allowing non-whitelisted attributes to be used on whitelisted elements. This can allow HTML and JavaScript injection, which could result in XSS if Sanitize's output is served to browsers.
Recommended action: Upgrade to 4.6.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.