Know every vulnerabilitybefore it knows you.
DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.
GHSA-2j22-pr5w-6gq8
No affected components available
Summary
Loofah::HTML5::Scrub.allowed_uri? 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 allowed_uri? 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 allowed_uri? string-level helper when passing HTML-encoded strings.
Impact
Applications that call Loofah::HTML5::Scrub.allowed_uri? 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 Loofah 2.25.0.
Mitigation
Upgrade to Loofah >= 2.25.1.
Credit
Responsibly reported by HackOne user @smlee.
The vulnerability can be exploited over the network without needing physical access. It is easy for an attacker to exploit this vulnerability. An attacker does not need any special privileges or access rights.
Limited exploitation activity has been observed. Close monitoring and planned remediation are recommended.
Probability that this vulnerability will be exploited in the wild within the next 30 days.
We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.
Browse More
Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.
Checkout DevGuard