GHSA-46FP-8F5P-PF2M

Vulnerability from github – Published: 2026-03-18 17:26 – Updated: 2026-03-18 17:26
VLAI
Summary
Improper detection of disallowed URIs by Loofah `allowed_uri?`
Details

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.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "loofah"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.25.0"
            },
            {
              "fixed": "2.25.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.25.0"
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-18T17:26:48Z",
    "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 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\u0027s 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`.",
  "id": "GHSA-46fp-8f5p-pf2m",
  "modified": "2026-03-18T17:26:48Z",
  "published": "2026-03-18T17:26:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/flavorjones/loofah/security/advisories/GHSA-46fp-8f5p-pf2m"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/flavorjones/loofah"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Improper detection of disallowed URIs by Loofah `allowed_uri?`"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…