NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
💎 RubyGems
Not in CISA KEV

Loofah has improper detection of disallowed URIs via `allowed_uri?`GHSA-2j22-pr5w-6gq8

Fix: flavorjones/loofah@f4ebc9c

GHSA-2j22-pr5w-6gq8 is a security vulnerability in loofah. A fix is available for loofah — see the affected versions and patch details below.

Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Sep 10, 2026 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected
💎loofah

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects RubyGems packages — download data is not available via public APIs for these ecosystems.

Description

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.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
💎RubyGemsloofah≥ 2.25.0&&< 2.25.12.25.1bundle update loofah --conservative

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for loofah, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update loofah to 2.25.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-2j22-pr5w-6gq8 is resolved across your whole dependency graph.

  3. Workarounds

    Escape or sanitise the affected output on the server side rather than relying on client-side filtering, and add a Content-Security-Policy that blocks inline script execution so injected markup cannot run even if it reaches the page.

Frequently Asked Questions

## 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 `&#13;` (carriage return), `&#10;` (line feed), or `&#9;` (tab). ## Details The `allowed_uri?` method strips literal control characters before decoding HTML entities. Payloads like `java&#13;script:alert(1)` survive the control character strip, then `&#13;` 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
O3 Security · Impact-Aware SCA

Is GHSA-2j22-pr5w-6gq8 in your dependencies?

Find it across RubyGems, including transitive dependencies.

Scan my dependencies How O3 SCA works
Loofah has improper detection of disallowed URIs via…