{"id":"GHSA-2j22-pr5w-6gq8","aliases":[],"status":"published","title":"Loofah has improper detection of disallowed URIs via `allowed_uri?`","description":"## Summary\n\n`Loofah::HTML5::Scrub.allowed_uri?` does not correctly reject `javascript:` URIs when the scheme is split by HTML entity-encoded control characters such as `\u0026#13;` (carriage return), `\u0026#10;` (line feed), or `\u0026#9;` (tab).\n\n## Details\n\nThe `allowed_uri?` method strips literal control characters before decoding HTML entities. Payloads like `java\u0026#13;script:alert(1)` survive the control character strip, then `\u0026#13;` is decoded to a carriage return, producing `java\\rscript:alert(1)`.\n\nNote 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.\n\n## Impact\n\nApplications 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).\n\nThis only affects Loofah `2.25.0`.\n\n## Mitigation\n\nUpgrade to Loofah \u003e= `2.25.1`.\n\n## Credit\n\nResponsibly reported by HackOne user @smlee.","severity":{"version":"4.0","score":2.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N","level":"low","from":"ghsa"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-116","CWE-79"],"published":"2026-03-26T22:19:02Z","modified":"2026-09-10T03:50:36Z","fixes":[{"ecosystem":"RubyGems","package":"loofah","fixed_in":["2.25.1"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"RubyGems","package":"loofah","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.25.0"},{"last_affected":"2.25.0"},{"fixed":"2.25.1"}]}],"versions":["2.25.0"]},{"source":"osv","ecosystem":"RubyGems","package":"loofah","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.25.0"},{"fixed":"2.25.1"}]}],"versions":["2.25.0"]}],"references":[{"url":"https://github.com/flavorjones/loofah/security/advisories/GHSA-46fp-8f5p-pf2m","tags":["web"]},{"url":"https://github.com/flavorjones/loofah/commit/f4ebc9c5193dde759a57541062e490e86fc7c068","tags":["web"]},{"url":"https://github.com/flavorjones/loofah/releases/tag/v2.25.1","tags":["web"]},{"url":"https://github.com/rubysec/ruby-advisory-db/blob/master/gems/loofah/GHSA-46fp-8f5p-pf2m.yml","tags":["web"]},{"url":"https://github.com/advisories/GHSA-2j22-pr5w-6gq8"},{"url":"https://github.com/flavorjones/loofah","tags":["package"]}],"sources":{"ghsa":[{"id":"GHSA-2j22-pr5w-6gq8","title":"Loofah has improper detection of disallowed URIs via `allowed_uri?`","description":"## Summary\n\n`Loofah::HTML5::Scrub.allowed_uri?` does not correctly reject `javascript:` URIs when the scheme is split by HTML entity-encoded control characters such as `\u0026#13;` (carriage return), `\u0026#10;` (line feed), or `\u0026#9;` (tab).\n\n## Details\n\nThe `allowed_uri?` method strips literal control characters before decoding HTML entities. Payloads like `java\u0026#13;script:alert(1)` survive the control character strip, then `\u0026#13;` is decoded to a carriage return, producing `java\\rscript:alert(1)`.\n\nNote 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.\n\n## Impact\n\nApplications 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).\n\nThis only affects Loofah `2.25.0`.\n\n## Mitigation\n\nUpgrade to Loofah \u003e= `2.25.1`.\n\n## Credit\n\nResponsibly reported by HackOne user @smlee.","status":"published","published":"2026-03-26T22:19:02Z","modified":"2026-03-26T22:19:04Z","cvss":[{"version":"4.0","score":2.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N","level":"low"}],"cwes":["CWE-79","CWE-116"],"updated_at":"2026-11-02T14:39:43.747579Z"}],"osv":[{"id":"GHSA-2j22-pr5w-6gq8","title":"Loofah has improper detection of disallowed URIs via `allowed_uri?`","description":"## Summary\n\n`Loofah::HTML5::Scrub.allowed_uri?` does not correctly reject `javascript:` URIs when the scheme is split by HTML entity-encoded control characters such as `\u0026#13;` (carriage return), `\u0026#10;` (line feed), or `\u0026#9;` (tab).\n\n## Details\n\nThe `allowed_uri?` method strips literal control characters before decoding HTML entities. Payloads like `java\u0026#13;script:alert(1)` survive the control character strip, then `\u0026#13;` is decoded to a carriage return, producing `java\\rscript:alert(1)`.\n\nNote 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.\n\n## Impact\n\nApplications 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).\n\nThis only affects Loofah `2.25.0`.\n\n## Mitigation\n\nUpgrade to Loofah \u003e= `2.25.1`.\n\n## Credit\n\nResponsibly reported by HackOne user @smlee.","status":"published","published":"2026-03-26T22:19:02Z","modified":"2026-09-10T03:50:36.423427224Z","cvss":[{"version":"4.0","score":2.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N","level":"low"}],"cwes":["CWE-116","CWE-79"],"updated_at":"2026-11-02T15:46:34.338541Z"}]}}