Bump loofah from 2.25.1 to 2.25.2 in /rails

[dependabot]

Bumps loofah from 2.25.1 to 2.25.2.

Release notes

Sourced from loofah's releases.

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

Changelog

Sourced from loofah's changelog.

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

Commits

• 2706d7e version bump to v2.25.2
• 1afde0c Merge pull request #308 from flavorjones/security-2252
• f1be9d8 Update allowed_uri? to decode semicolon-less numeric character references
• 5e91af8 Update allowed_uri? to handle named whitespace character references
• 20867b9 Properly restrict SVG href attributes
• 5f3bff4 test: opt into JSON comment parsing for sanitizer testdata (#307)
• b07713d test: do not run in verbose mode
• babe7a8 doc: update CHANGELOG
• a8d8d96 Merge pull request #305 from flavorjones/drop-protocol-typo
• b52f4b0 version bump to 2.25.2.beta1
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

[ems-pr-review]

It looks like you are reviewing a Dependabot upgrade PR! 🛠️
That’s great! Keeping our packages up to date to fix security issues in our stack is super important. Team Application Security wants to help make this process as easy and low friction as possible while still moving at pace.

We aim to merge Dependabot PRs within the below timeframes. The objectives are based on the severity of the security vulnerability we are mitigating with the upgrade:

Severity	Target Merge (days)
CRITICAL	7 days
HIGH	14 days
MEDIUM	30 days
LOW	90 days

🎯 Target merge date for this PR: 21/10/2026 🎯

FAQ

What if we aren’t vulnerable to this particular CVE? Do we still have to upgrade the package?

It’s still a good idea to upgrade the package if we can. With new code patterns and paths being introduced every day, we have no guarantee that we won’t later make ourselves vulnerable. Keeping packages up to date as a matter of due course is also good hygiene.

What if we’re not vulnerable and upgrading is going to be a lot of work?

In these cases it’s a good idea to list out the steps you took to confirm we are not vulnerable in this PR. The PR can then be closed and the corresponding Dependabot Alert should be dismissed with the triage steps included as a comment. Please get in touch with Team Application Security via #ask-security before dismissing any CRITICAL alerts.

This is a major version upgrade that requires substantial code refactoring. What should I do?

If the upgrade requires substantial refactoring then it is possible that we will miss the objectives we have outlined above. In these cases, you should add the dependabot-refactor-required label to this PR and ping #ask-security for further advice.