GHSA-8WHX-365G-H9VV
Vulnerability from github – Published: 2026-07-21 15:04 – Updated: 2026-08-12 20:59Summary
Loofah::HTML5::Scrub.allowed_uri? 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
allowed_uri? 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 (U+0009 and U+000A; there is no named reference for U+000D). /   decode to U+00A0, which browsers do not strip, so they aren't usable for this bypass.
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 @connorshea.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "loofah"
},
"ranges": [
{
"events": [
{
"introduced": "2.25.0"
},
{
"fixed": "2.25.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-73491"
],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T15:04:14Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "## Summary\n\n`Loofah::HTML5::Scrub.allowed_uri?` does not correctly reject `javascript:` URIs when the scheme is split or prefixed by the HTML5 named character references `\u0026Tab;` (tab) or `\u0026NewLine;` (line feed).\n\nThis is a bypass of the fix for [GHSA-46fp-8f5p-pf2m](https://github.com/flavorjones/loofah/security/advisories/GHSA-46fp-8f5p-pf2m), which handled the equivalent numeric character references (`\u0026#9;`, `\u0026#10;`, `\u0026#13;`) but did not cover the named forms.\n\n## Details\n\n`allowed_uri?` decodes HTML entities with `CGI.unescapeHTML`, which handles numeric character references but not HTML5 named character references. Payloads like `java\u0026Tab;script:alert(1)` are therefore left intact, so the method does not recognize the `javascript:` scheme and returns `true`. A browser, however, decodes `\u0026Tab;` and `\u0026NewLine;` to tab and line feed and strips them from the URL during parsing, producing `javascript:alert(1)`.\n\n`\u0026Tab;` and `\u0026NewLine;` 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 (U+0009 and U+000A; there is no named reference for U+000D). `\u0026nbsp;` / `\u0026NonBreakingSpace;` decode to U+00A0, which browsers do not strip, so they aren\u0027t usable for this bypass.\n\nNote that Loofah\u0027s 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.\n\n## Impact\n\nCallers 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\u0027s markdown link validation.\n\n## Mitigation\n\nUpgrade to Loofah \u003e= 2.25.2.\n\n## Credit\n\nResponsibly reported by GitHub user @connorshea.",
"id": "GHSA-8whx-365g-h9vv",
"modified": "2026-08-12T20:59:24Z",
"published": "2026-07-21T15:04:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/flavorjones/loofah/security/advisories/GHSA-8whx-365g-h9vv"
},
{
"type": "WEB",
"url": "https://github.com/flavorjones/loofah/commit/5e91af861e3cdab47b91dd0b81f3afdfd13a5e19"
},
{
"type": "PACKAGE",
"url": "https://github.com/flavorjones/loofah"
},
{
"type": "WEB",
"url": "https://github.com/flavorjones/loofah/releases/tag/v2.25.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "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",
"type": "CVSS_V4"
}
],
"summary": "Loofah `allowed_uri?` does not detect `javascript:` URIs split by named whitespace character references"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.