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
11 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Loofah::HTML5::Scrub.alloweduri? does not correctly reject javascript: or vbscript: URIs when the scheme is split by a numeric character reference that has no trailing semicolon. A browser decodes such references and resolves the URL to an executable javascript: scheme, while alloweduri? reports it safe. This is a bypass of the fix for GHSA-46fp-8f5p-pf2m, which handled numeric character references with a trailing ; (	, , ) but did not cover the forms without semicolons. Details alloweduri? decodes HTML entities with CGI.unescapeHTML, which decodes numeric character references only when they carry a trailing ;. A reference without a semicolon such as : (colon) or 	 (tab) is left literal, so the scheme-detection check finds no scheme, and the method falls through to its scheme-less path and returns true. A browser, however, decodes numeric character references even without a trailing semicolon. An encoded colon such as : becomes the : scheme separator, so…
Recommended action: Upgrade to 2.25.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Loofah's HTML5 sanitizer restricted only the xlink:href attribute on certain SVG elements to local, same-document references. Browsers also accept a plain href attribute as an alternative to the deprecated xlink:href per the SVG 2 spec, but Loofah did not apply the same restriction to it, allowing those elements to reference arbitrary external documents. Impact SVG <use can load and render external SVG content by reference. If the referenced external SVG is same-origin and contains scripts or other dangerous content, it could execute in the context of the sanitized document. <feImage can load external images, which can be used for tracking. Modern browsers restrict cross-origin <use fetches, which limits but does not eliminate the risk. Applications that sanitize user-supplied SVG (directly, or as part of HTML) with Loofah's default allowlist are affected. Mitigation Upgrade to Loofah = 2.25.2. Credit Found by the maintainer, Mike Dalessio, during a security audit.
Recommended action: Upgrade to 2.25.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Loofah::HTML5::Scrub.alloweduri? does not correctly reject javascript: URIs when the scheme is split or prefixed by the HTML5 named character references 	 (tab) or 
 (line feed). This is a bypass of the fix for GHSA-46fp-8f5p-pf2m, which handled the equivalent numeric character references (	, , ) but did not cover the named forms. Details alloweduri? decodes HTML entities with CGI.unescapeHTML, which handles numeric character references but not HTML5 named character references. Payloads like java	script:alert(1) are therefore left intact, so the method does not recognize the javascript: scheme and returns true. A browser, however, decodes 	 and 
 to tab and line feed and strips them from the URL during parsing, producing javascript:alert(1). 	 and 
 are the only relevant named character references: across the HTML5 named-character table, they are the only two that decode to characters the WHATWG URL parser strips from a URL…
Recommended action: Upgrade to 2.25.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Loofah::HTML5::Scrub.alloweduri? does not correctly reject javascript: URIs when the scheme is split by HTML entity-encoded control characters such as (carriage return), (line feed), or 	 (tab). Details The alloweduri? method strips literal control characters before decoding HTML entities. Payloads like java script:alert(1) survive the control character strip, then is decoded to a carriage return, producing java\rscript:alert(1). Note that the Loofah sanitizer's default sanitize() path is not affected because Nokogiri decodes HTML entities during parsing before Loofah evaluates the URI protocol. This issue only affects direct callers of the alloweduri? string-level helper when passing HTML-encoded strings. Impact Applications that call Loofah::HTML5::Scrub.alloweduri? to validate user-controlled URLs and then render approved URLs into href or other browser-interpreted URI attributes may be vulnerable to cross-site scripting (XSS). This only affects…
Recommended action: Upgrade to 2.25.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Loofah::HTML5::Scrub.alloweduri? does not correctly reject javascript: URIs when the scheme is split by HTML entity-encoded control characters such as (carriage return), (line feed), or 	 (tab). Details The alloweduri? method strips literal control characters before decoding HTML entities. Payloads like java script:alert(1) survive the control character strip, then is decoded to a carriage return, producing java\rscript:alert(1). Note that the Loofah sanitizer's default sanitize() path is not affected because Nokogiri decodes HTML entities during parsing before Loofah evaluates the URI protocol. This issue only affects direct callers of the alloweduri? string-level helper when passing HTML-encoded strings. Impact Applications that call Loofah::HTML5::Scrub.alloweduri? to validate user-controlled URLs and then render approved URLs into href or other browser-interpreted URI attributes may be vulnerable to cross-site scripting (XSS). This only affects…
Recommended action: Upgrade to 2.25.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Loofah = 2.2.0, < 2.19.1 uses recursion for sanitizing CDATA sections, making it susceptible to stack exhaustion and raising a SystemStackError exception. This may lead to a denial of service through CPU resource consumption. Mitigation Upgrade to Loofah = 2.19.1. Users who are unable to upgrade may be able to mitigate this vulnerability by limiting the length of the strings that are sanitized. Severity The Loofah maintainers have evaluated this as High Severity 7.5 (CVSS3.1). References - CWE - CWE-674: Uncontrolled Recursion (4.9)
Recommended action: Upgrade to 2.19.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Loofah = 2.1.0, < 2.19.1 is vulnerable to cross-site scripting via the image/svg+xml media type in data URIs. Mitigation Upgrade to Loofah = 2.19.1. Severity The Loofah maintainers have evaluated this as Medium Severity 6.1. References - CWE - CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (4.9) - SVG MIME Type (image/svg+xml) is misleading to developers · Issue #266 · w3c/svgwg - https://hackerone.com/reports/1694173 - https://github.com/flavorjones/loofah/issues/101 Credit This vulnerability was responsibly reported by Maciej Piechota (@haqpl).
Recommended action: Upgrade to 2.19.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Loofah < 2.19.1 contains an inefficient regular expression that is susceptible to excessive backtracking when attempting to sanitize certain SVG attributes. This may lead to a denial of service through CPU resource consumption. Mitigation Upgrade to Loofah = 2.19.1. Severity The Loofah maintainers have evaluated this as High Severity 7.5 (CVSS3.1). References - CWE - CWE-1333: Inefficient Regular Expression Complexity (4.9) - https://hackerone.com/reports/1684163 Credit This vulnerability was responsibly reported by @ooooooo-q (https://github.com/ooooooo-q).
Recommended action: Upgrade to 2.19.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In the Loofah gem for Ruby through v2.3.0, unsanitized JavaScript may occur in sanitized output when a crafted SVG element is republished.
Recommended action: Upgrade to 2.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In the Loofah gem for Ruby, through version 2.2.2, unsanitized JavaScript may occur in sanitized output when a crafted SVG element is republished. Users are advised to upgrade to version 2.2.3. See https://github.com/flavorjones/loofah/issues/154 for more details.
Recommended action: Upgrade to 2.2.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Loofah allows non-whitelisted attributes to be present in sanitized output when input with specially-crafted HTML fragments. Users are affected if running Loofah < 2.2.1, but only: when running on MRI or RBX, in combination with libxml2 = 2.9.2. JRuby users are not affected.
Recommended action: Upgrade to 2.2.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.