GHSA-5qhf-9phg-95m2

Suggest an improvement
Source
https://github.com/advisories/GHSA-5qhf-9phg-95m2
Import Source
https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/07/GHSA-5qhf-9phg-95m2/GHSA-5qhf-9phg-95m2.json
JSON Data
https://api.test.osv.dev/v1/vulns/GHSA-5qhf-9phg-95m2
Aliases
Downstream
Published
2026-07-21T22:03:11Z
Modified
2026-08-13T11:56:13.945739942Z
Severity
  • 2.3 (Low) CVSS_V4 - CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N CVSS Calculator
Summary
Loofah `allowed_uri?` does not detect `javascript:` URIs split by numeric character references without semicolons
Details

Summary

Loofah::HTML5::Scrub.allowed_uri? 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 allowed_uri? 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

allowed_uri? decodes HTML entities with CGI.unescapeHTML, which decodes numeric character references only when they carry a trailing ;. A reference without a semicolon such as &#58 (colon) or &#9 (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 &#58 becomes the : scheme separator, so javascript&#58alert(1) resolves to javascript:alert(1). Encoded whitespace such as &#9 (tab) is decoded and then stripped from the URL, rejoining the surrounding text, so java&#9script:alert(1) also resolves to javascript:alert(1). In both cases the URL executes while allowed_uri? approved it as safe.

Note that Loofah's default sanitize() path is not affected, because Nokogiri decodes or entity-escapes HTML entities during parsing before Loofah evaluates the URI protocol. This issue only affects callers of the public allowed_uri? string-level helper that pass it HTML-encoded strings.

Impact

Callers that validate a user-controlled URL with Loofah::HTML5::Scrub.allowed_uri? and then render the approved value into an href or other browser-interpreted URI attribute may be vulnerable to cross-site scripting (XSS). This includes applications that call allowed_uri? directly, as well as higher-level features built on top of it, such as Action Text 8.2's markdown link validation.

Mitigation

Upgrade to Loofah >= 2.25.2.

Credit

Responsibly reported by GitHub user @MoonFuji.

Database specific
{
    "cwe_ids": [
        "CWE-184",
        "CWE-79"
    ],
    "github_reviewed": true,
    "severity": "LOW",
    "github_reviewed_at": "2026-07-21T22:03:11Z",
    "nvd_published_at": null
}
References

Affected packages

RubyGems / loofah

Package

Name
loofah
Purl
pkg:gem/loofah

Affected ranges

Type
ECOSYSTEM
Events
Introduced
2.25.0
Fixed
2.25.2

Affected versions

2.*
2.25.0
2.25.1

Database specific

source
"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/07/GHSA-5qhf-9phg-95m2/GHSA-5qhf-9phg-95m2.json"