🚨 [security] Update rails-html-sanitizer 1.7.0 → 1.7.1 (patch)

[depfu]

---

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!

---

Here is everything you need to know about this update. Please take a good look at what changed and the test results before merging this pull request.

What changed?

↗️ rails-html-sanitizer (indirect, 1.7.0 → 1.7.1) · Repo · Changelog

Security Advisories 🚨

🚨 Rails HTML Sanitizers: Possible XSS vulnerability with certain configurations

Summary

There is a possible cross-site scripting vulnerability in rails-html-sanitizer when the sanitizer is configured to allow an SVG reference element such as <use>. See related GHSA-9wjq-cp2p-hrgf in Loofah, whose SVG local-reference logic rails-html-sanitizer mirrors.

• Versions affected: >= 1.0.3, < 1.7.1
• Not affected: < 1.0.3
• Fixed versions: 1.7.1

Impact

Rails::HTML::PermitScrubber restricts SVG reference elements in the SVG_ALLOW_LOCAL_HREF collection to local, same-document references, but that restriction covered only the xlink:href attribute. Browsers also accept a plain href attribute per the SVG 2 spec, and it was not restricted, so those elements could reference arbitrary external documents. SVG <use> can load and render external SVG content by reference, and if the referenced document is same-origin and contains scripts, it could execute in the context of the sanitized document. <feImage> can load external images, which can be used for tracking.

Applications are impacted only when the allowed tags are overridden to include one of these SVG reference elements, for example <use> or <feImage>. The default allowed tags do not include these SVG elements, so applications using the default configuration are not affected.

Workarounds

Remove the SVG reference elements (such as use and feImage) from the overridden allowed tags. Applications using the default allowed tags are not affected.

References

• GHSA-9wjq-cp2p-hrgf: SVG href attribute bypasses local-reference restriction in Loofah
• CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Credit

Found by maintainer Mike Dalessio during a security audit.

Release Notes

1.7.1

v1.7.1 / 2026-07-15

• SVG reference elements now restrict both href and xlink:href to local references.

  Previously PermitScrubber restricted only xlink:href on elements in SVG_ALLOW_LOCAL_HREF,
  so a plain href attribute on those elements could reference an external document. Applications
  are only affected if the allowed tags are overridden to include an SVG reference element such as
  use; the default configuration is not affected.

  This change addresses GHSA-cj75-f6xr-r4g7 (CVE requested). The minimum Loofah dependency is now
  ~> 2.25, >= 2.25.2.

  Mike Dalessio @flavorjones

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 10 commits:

• version bump to v1.7.1
• Merge pull request #223 from rails/svg-href-local-ref
• Properly restrict SVG href attributes
• Adjust data: URI mediatype tests for loofah 2.25.2 (#222)
• Harden GitHub Actions workflows (#220)
• dep(dev): update nokogiri (#219)
• build(deps-dev): bump concurrent-ruby from 1.3.6 to 1.3.7 (#218)
• dep(dev): update development dependencies (#217)
• Merge pull request #215 from yuri-zubov/reduce-gem-size
• Reduce gem size by excluding test files

↗️ crass (indirect, 1.0.6 → 1.0.7) · Repo · Changelog

Release Notes

1.0.7

Security

• High: Fixed a denial of service vulnerability in which a large numeric exponent could consume disproportionate CPU and memory before the value was clamped. Exponents are now bounded before 10**exponent is computed. (GHSA-6wmf-3r64-vcwv)

• Moderate: Fixed a scenario in which deeply nested simple blocks or functions could exhaust the Ruby stack and raise SystemStackError, or could result in excessive memory usage. Parser nesting is now limited to a configurable maximum depth via a new option (:maximum_depth, with a conservative default of 25). Constructs nested more deeply are discarded as an :error node with the value "maximum-depth-exceeded". (GHSA-6jxj-px6v-747w)

• Moderate: Fixed a scenario in which a long run of adjacent comments could exhaust the Ruby stack and raise SystemStackError. Discarded comments are now skipped iteratively rather than recursively. (GHSA-wwpr-jff3-395c)

• Moderate: Fixed a denial of service vulnerability in which inputs containing many non-ASCII characters could cause excessive CPU usage due to inefficient handling of multi-byte characters during tokenization. (GHSA-8vfg-2r28-hvhj)

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 26 commits:

• Release 1.0.7
• Fix inefficient handling of non-ASCII characters during tokenization
• Prevent a long run of adjacent comments from exhausting the stack
• Limit recursion depth to prevent stack overflow and memory exhaustion
• Prevent resource exhaustion denial of service via excessively large exponents
• Bump version to 1.0.7
• Update CI workflow dependencies
• Update CI test matrix
• Upgrade minitest and rake
• Merge pull request #18 from stoivo/main
• Update links to point to the targeted version
• name Test name look a bit nicer
• Upgrade minitest to 5.21.1
• Use actions/checkout@v4
• Add Ruby 3.2.x to the test matrix
• Merge pull request #13 from voxik/minitest519
• Fix compatibility with Minitest 5.19+
• Remove redundant Ruby 3.2 from the CI matrix
• Add Ruby 3.1 and 3.2 to the CI matrix.
• Remove 1.9.3 and truffleruby from the test matrix
• Replace Travis with GitHub Actions
• Reformat readme and history
• Remove copyright year
• Require mfa
• Upgrade dev dependencies
• 🎨

↗️ loofah (indirect, 2.25.1 → 2.25.2) · Repo · Changelog

Security Advisories 🚨

🚨 Loofah `allowed_uri?` does not detect `javascript:` URIs split by named whitespace character references

Summary

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.

🚨 Loofah: SVG `href` attribute bypasses local-reference restriction

Summary

Loofah's HTML5 sanitizer restricted only the xlink:href attribute on certain SVG elements to local, same-document references. Browsers also accept a plain href attribute as an alternative to the deprecated xlink:href per the SVG 2 spec, but Loofah did not apply the same restriction to it, allowing those elements to reference arbitrary external documents.

Impact

SVG <use> can load and render external SVG content by reference. If the referenced external SVG is same-origin and contains scripts or other dangerous content, it could execute in the context of the sanitized document. <feImage> can load external images, which can be used for tracking. Modern browsers restrict cross-origin <use> fetches, which limits but does not eliminate the risk.

Applications that sanitize user-supplied SVG (directly, or as part of HTML) with Loofah's default allowlist are affected.

Mitigation

Upgrade to Loofah >= 2.25.2.

Credit

Found by the maintainer, Mike Dalessio, during a security audit.

🚨 Loofah `allowed_uri?` does not detect `javascript:` URIs split by numeric character references without semicolons

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.

Release Notes

2.25.2

2.25.2 / 2026-07-15

Security

• Ensure Loofah::HTML5::Scrub.allowed_uri? recognizes numeric character references without semicolons (e.g. javascript&#58alert(1)), which browsers decode and execute, and rejects schemes split by them. See GHSA-5qhf-9phg-95m2. @flavorjones
• Ensure Loofah::HTML5::Scrub.allowed_uri? recognizes the named character references 	 and 
, which CGI.unescapeHTML does not decode and browsers strip from URIs, and rejects schemes split by them (e.g. java	script:alert(1)). See GHSA-8whx-365g-h9vv. @flavorjones
• Ensure that both href and xlink:href attributes on SVG elements like use are restricted to local (same-document) references. Previously only xlink:href was restricted, allowing the SVG 2 href attribute to reference external documents. See GHSA-9wjq-cp2p-hrgf. @flavorjones

Improved

• Harden data: URI mediatype parsing in Loofah::HTML5::Scrub.allowed_uri?. The mediatype is now parsed following the WHATWG data: URL spec and RFC 2397 instead of simply being split on a colon. A data: URI with an omitted or malformed mediatype is now treated as text/plain and allowed, and one without the required comma is now rejected. #305 @flavorjones
• Remove feed from the default set of allowed protocols. The feed URI scheme was never accepted as a standard protocol, and no major browser supports it. Removing it reduces the attack surface particularly for non-browser contexts. #304 @flavorjones
• Remove a vestigial &#x70 alternative from Loofah::HTML5::SafeList::PROTOCOL_SEPARATOR. This appears to be an ancient typo dating back to pre-extraction Rails circa 2007. #305 @flavorjones

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 14 commits:

• version bump to v2.25.2
• Merge pull request #308 from flavorjones/security-2252
• Update `allowed_uri?` to decode semicolon-less numeric character references
• Update `allowed_uri?` to handle named whitespace character references
• Properly restrict SVG href attributes
• test: opt into JSON comment parsing for sanitizer testdata (#307)
• test: do not run in verbose mode
• doc: update CHANGELOG
• Merge pull request #305 from flavorjones/drop-protocol-typo
• version bump to 2.25.2.beta1
• Harden `data:` URI mediatype parsing
• Remove `&#x70` from PROTOCOL_SEPARATOR
• Merge pull request #304 from flavorjones/drop-feed-protocol
• Remove `feed` from the default allowed protocols

---

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands

@​depfu rebase

Rebases against your default branch and redoes this update

@​depfu recreate

Recreates this PR, overwriting any edits that you've made to it

@​depfu merge

Merges this PR once your tests are passing and conflicts are resolved

@​depfu cancel merge

Cancels automatic merging of this PR

@​depfu close

Closes this PR and deletes the branch

@​depfu reopen

Restores the branch and reopens this PR (if it's closed)

@​depfu pause

Ignores all future updates for this dependency and closes this PR

@​depfu pause [minor|major]

Ignores all future minor/major updates for this dependency and closes this PR

@​depfu resume

Future versions of this dependency will create PRs again (leaves this PR as is)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.93%. Comparing base (4ca6480) to head (d9f05c7).

Additional details and impacted files

@@           Coverage Diff            @@
##           develop     #932   +/-   ##
========================================
  Coverage    96.93%   96.93%           
========================================
  Files           81       81           
  Lines         1861     1861           
========================================
  Hits          1804     1804           
  Misses          57       57           

Flag	Coverage Δ
pull_request	96.93% <ø> (ø)
push	96.93% <ø> (ø)
ruby	96.93% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[depfu]

Sorry, but the merge failed with:

At least 1 approving review is required by reviewers with write access.

[depfu]

Sorry, but the merge failed with:

At least 1 approving review is required by reviewers with write access.