🚨 [security] Update rails 6.1.5 → 8.0.2.1 (major)

🚨 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 upgrade. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ rails (6.1.5 → 8.0.2.1) · Repo

Security Advisories 🚨

🚨 Rails has possible XSS Vulnerability in Action Controller

Possible XSS Vulnerability in Action Controller

There is a possible XSS vulnerability when using the translation helpers
(translate, t, etc) in Action Controller. This vulnerability has been
assigned the CVE identifier CVE-2024-26143.

Versions Affected: >= 7.0.0.
Not affected: < 7.0.0
Fixed Versions: 7.1.3.1, 7.0.8.1

Impact

Applications using translation methods like translate, or t on a
controller, with a key ending in "_html", a :default key which contains
untrusted user input, and the resulting string is used in a view, may be
susceptible to an XSS vulnerability.

For example, impacted code will look something like this:

class ArticlesController < ApplicationController
  def show  
    @message = t("message_html", default: untrusted_input)
    # The `show` template displays the contents of `@message`
  end
end

To reiterate the pre-conditions, applications must:

  • Use a translation function from a controller (i.e. not I18n.t, or t from
    a view)
  • Use a key that ends in _html
  • Use a default value where the default value is untrusted and unescaped input
  • Send the text to the victim (whether that's part of a template, or a
    render call)

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The fixed releases are available at the normal locations.

Workarounds

There are no feasible workarounds for this issue.

Patches

To aid users who aren't able to upgrade immediately we have provided patches for
the two supported release series. They are in git-am format and consist of a
single changeset.

  • 7-0-translate-xss.patch - Patch for 7.0 series
  • 7-1-translate-xss.patch - Patch for 7.1 series

Credits

Thanks to ooooooo_q for the patch and fix!

🚨 Rails has possible XSS Vulnerability in Action Controller

Possible XSS Vulnerability in Action Controller

There is a possible XSS vulnerability when using the translation helpers
(translate, t, etc) in Action Controller. This vulnerability has been
assigned the CVE identifier CVE-2024-26143.

Versions Affected: >= 7.0.0.
Not affected: < 7.0.0
Fixed Versions: 7.1.3.1, 7.0.8.1

Impact

Applications using translation methods like translate, or t on a
controller, with a key ending in "_html", a :default key which contains
untrusted user input, and the resulting string is used in a view, may be
susceptible to an XSS vulnerability.

For example, impacted code will look something like this:

class ArticlesController < ApplicationController
  def show  
    @message = t("message_html", default: untrusted_input)
    # The `show` template displays the contents of `@message`
  end
end

To reiterate the pre-conditions, applications must:

  • Use a translation function from a controller (i.e. not I18n.t, or t from
    a view)
  • Use a key that ends in _html
  • Use a default value where the default value is untrusted and unescaped input
  • Send the text to the victim (whether that's part of a template, or a
    render call)

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The fixed releases are available at the normal locations.

Workarounds

There are no feasible workarounds for this issue.

Patches

To aid users who aren't able to upgrade immediately we have provided patches for
the two supported release series. They are in git-am format and consist of a
single changeset.

  • 7-0-translate-xss.patch - Patch for 7.0 series
  • 7-1-translate-xss.patch - Patch for 7.1 series

Credits

Thanks to ooooooo_q for the patch and fix!

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

✳️ minitest (5.18.0 → 5.25.5) · Repo · Changelog

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

✳️ rake (13.0.6 → 13.3.0) · Repo · Changelog

Release Notes

13.3.0

What's Changed

  • Add missing changelog by @VitaliySerov in #555
  • Exclude 2.3-2.5 on macos-14 iamge by @hsbt in #563
  • Use require_relative in the Rake codebase by @koic in #566
  • Provide a 'Changelog' link on rubygems.org/gems/rake by @mark-young-atg in #572
  • Remove dependency on win32ole by @Earlopain in #573
  • Switch changelog_uri to releases tab by @fynsta in #577
  • chore: refactor/reformat the heredocs (in tests) ... by @pvdb in #589
  • chore: remove $trace global variable / option by @pvdb in #592
  • Link to Jim's last rake commit (not the git tree with that SHA) by @pvdb in #593
  • chore: refactor how temporary files are created (in tests) by @pvdb in #590
  • refactor: use $LOADED_FEATURES built-in instead of $" by @pvdb in #605
  • refactor: remove "exposed" @system_dir instance variable (in helper method) by @pvdb in #604
  • refactor: simplify Rake::Application#system_dir method by @pvdb in #591
  • Remove unused argument by @takmar in #623
  • Use latest RDoc release instead of Ruby 3.2's default version by @st0012 in #630
  • Enabled trusted publisher for rubygems.org by @hsbt in #634
  • refactor: use Dir.home to find rake's standard system dir by @pvdb in #608
  • Fix RDoc links in Rake Information section by @komagata in #627
  • refactor: move dependency requires to ruby_runner.rb file by @pvdb in #609
  • Pattern matching support for arguments by @rgarner in #515

New Contributors

Full Changelog: v13.2.1...v13.3.0

13.2.1

What's Changed

  • Suppressed "internal:array:52:in 'Array#each'" from backtrace by @hsbt in #554
  • Bump actions/configure-pages from 4 to 5 by @dependabot in #553

Full Changelog: v13.2.0...v13.2.1

13.2.0

What's Changed

New Contributors

Full Changelog: v13.1.0...v13.2.0

13.1.0

What's Changed

New Contributors

Full Changelog: v13.0.6...v13.1.0

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

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ actioncable (indirect, 6.1.5 → 8.0.2.1) · Repo · Changelog

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ actionmailbox (indirect, 6.1.5 → 8.0.2.1) · Repo · Changelog

↗️ actionmailer (indirect, 6.1.5 → 8.0.2.1) · Repo · Changelog

Security Advisories 🚨

🚨 Possible ReDoS vulnerability in block_format in Action Mailer

There is a possible ReDoS vulnerability in the block_format helper in Action Mailer. This vulnerability has been assigned the CVE identifier CVE-2024-47889.

Impact

Carefully crafted text can cause the block_format helper to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade or apply the relevant patch immediately.

Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 requires Ruby 3.2 or greater so is unaffected.

Releases

The fixed releases are available at the normal locations.

Workarounds

Users can avoid calling the block_format helper or upgrade to Ruby 3.2

Credits

Thanks to yuki_osaki for the report!

🚨 Possible ReDoS vulnerability in block_format in Action Mailer

There is a possible ReDoS vulnerability in the block_format helper in Action Mailer. This vulnerability has been assigned the CVE identifier CVE-2024-47889.

Impact

Carefully crafted text can cause the block_format helper to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade or apply the relevant patch immediately.

Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 requires Ruby 3.2 or greater so is unaffected.

Releases

The fixed releases are available at the normal locations.

Workarounds

Users can avoid calling the block_format helper or upgrade to Ruby 3.2

Credits

Thanks to yuki_osaki for the report!

🚨 Possible ReDoS vulnerability in block_format in Action Mailer

There is a possible ReDoS vulnerability in the block_format helper in Action Mailer. This vulnerability has been assigned the CVE identifier CVE-2024-47889.

Impact

Carefully crafted text can cause the block_format helper to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade or apply the relevant patch immediately.

Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 requires Ruby 3.2 or greater so is unaffected.

Releases

The fixed releases are available at the normal locations.

Workarounds

Users can avoid calling the block_format helper or upgrade to Ruby 3.2

Credits

Thanks to yuki_osaki for the report!

🚨 Possible ReDoS vulnerability in block_format in Action Mailer

There is a possible ReDoS vulnerability in the block_format helper in Action Mailer. This vulnerability has been assigned the CVE identifier CVE-2024-47889.

Impact

Carefully crafted text can cause the block_format helper to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade or apply the relevant patch immediately.

Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 requires Ruby 3.2 or greater so is unaffected.

Releases

The fixed releases are available at the normal locations.

Workarounds

Users can avoid calling the block_format helper or upgrade to Ruby 3.2

Credits

Thanks to yuki_osaki for the report!

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ actionpack (indirect, 6.1.5 → 8.0.2.1) · Repo · Changelog

Security Advisories 🚨

🚨 Possible Content Security Policy bypass in Action Dispatch

There is a possible Cross Site Scripting (XSS) vulnerability in the content_security_policy helper in Action Pack.

Impact

Applications which set Content-Security-Policy (CSP) headers dynamically from untrusted user input may be vulnerable to carefully crafted inputs being able to inject new directives into the CSP. This could lead to a bypass of the CSP and its protection against XSS and other attacks.

Releases

The fixed releases are available at the normal locations.

Workarounds

Applications can avoid setting CSP headers dynamically from untrusted input, or can validate/sanitize that input.

Credits

Thanks to ryotak for the report!

🚨 Possible Content Security Policy bypass in Action Dispatch

There is a possible Cross Site Scripting (XSS) vulnerability in the content_security_policy helper in Action Pack.

Impact

Applications which set Content-Security-Policy (CSP) headers dynamically from untrusted user input may be vulnerable to carefully crafted inputs being able to inject new directives into the CSP. This could lead to a bypass of the CSP and its protection against XSS and other attacks.

Releases

The fixed releases are available at the normal locations.

Workarounds

Applications can avoid setting CSP headers dynamically from untrusted input, or can validate/sanitize that input.

Credits

Thanks to ryotak for the report!

🚨 Possible Content Security Policy bypass in Action Dispatch

There is a possible Cross Site Scripting (XSS) vulnerability in the content_security_policy helper in Action Pack.

Impact

Applications which set Content-Security-Policy (CSP) headers dynamically from untrusted user input may be vulnerable to carefully crafted inputs being able to inject new directives into the CSP. This could lead to a bypass of the CSP and its protection against XSS and other attacks.

Releases

The fixed releases are available at the normal locations.

Workarounds

Applications can avoid setting CSP headers dynamically from untrusted input, or can validate/sanitize that input.

Credits

Thanks to ryotak for the report!

🚨 Possible Content Security Policy bypass in Action Dispatch

There is a possible Cross Site Scripting (XSS) vulnerability in the content_security_policy helper in Action Pack.

Impact

Applications which set Content-Security-Policy (CSP) headers dynamically from untrusted user input may be vulnerable to carefully crafted inputs being able to inject new directives into the CSP. This could lead to a bypass of the CSP and its protection against XSS and other attacks.

Releases

The fixed releases are available at the normal locations.

Workarounds

Applications can avoid setting CSP headers dynamically from untrusted input, or can validate/sanitize that input.

Credits

Thanks to ryotak for the report!

🚨 Possible ReDoS vulnerability in HTTP Token authentication in Action Controller

There is a possible ReDoS vulnerability in Action Controller's HTTP Token authentication. This vulnerability has been assigned the CVE identifier CVE-2024-47887.

Impact

For applications using HTTP Token authentication via authenticate_or_request_with_http_token or similar, a carefully crafted header may cause header parsing to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade or apply the relevant patch immediately.

Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 depends on Ruby 3.2 or greater so is unaffected.

Releases

The fixed releases are available at the normal locations.

Workarounds

Users on Ruby 3.2 are unaffected by this issue.

Credits

Thanks to scyoon for reporting

🚨 Possible ReDoS vulnerability in query parameter filtering in Action Dispatch

There is a possible ReDoS vulnerability in the query parameter filtering routines of Action Dispatch. This vulnerability has been assigned the CVE identifier CVE-2024-41128.

Impact

Carefully crafted query parameters can cause query parameter filtering to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade or apply the relevant patch immediately.

Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 depends on Ruby 3.2 or greater so is unaffected.

Releases

The fixed releases are available at the normal locations.

Workarounds

Users on Ruby 3.2 are unaffected by this issue.

Credits

Thanks to scyoon for the report and patches!

🚨 Possible ReDoS vulnerability in HTTP Token authentication in Action Controller

There is a possible ReDoS vulnerability in Action Controller's HTTP Token authentication. This vulnerability has been assigned the CVE identifier CVE-2024-47887.

Impact

For applications using HTTP Token authentication via authenticate_or_request_with_http_token or similar, a carefully crafted header may cause header parsing to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade or apply the relevant patch immediately.

Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 depends on Ruby 3.2 or greater so is unaffected.

Releases

The fixed releases are available at the normal locations.

Workarounds

Users on Ruby 3.2 are unaffected by this issue.

Credits

Thanks to scyoon for reporting

🚨 Possible ReDoS vulnerability in HTTP Token authentication in Action Controller

There is a possible ReDoS vulnerability in Action Controller's HTTP Token authentication. This vulnerability has been assigned the CVE identifier CVE-2024-47887.

Impact

For applications using HTTP Token authentication via authenticate_or_request_with_http_token or similar, a carefully crafted header may cause header parsing to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade or apply the relevant patch immediately.

Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 depends on Ruby 3.2 or greater so is unaffected.

Releases

The fixed releases are available at the normal locations.

Workarounds

Users on Ruby 3.2 are unaffected by this issue.

Credits

Thanks to scyoon for reporting

🚨 Possible ReDoS vulnerability in query parameter filtering in Action Dispatch

There is a possible ReDoS vulnerability in the query parameter filtering routines of Action Dispatch. This vulnerability has been assigned the CVE identifier CVE-2024-41128.

Impact

Carefully crafted query parameters can cause query parameter filtering to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade or apply the relevant patch immediately.

Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 depends on Ruby 3.2 or greater so is unaffected.

Releases

The fixed releases are available at the normal locations.

Workarounds

Users on Ruby 3.2 are unaffected by this issue.

Credits

Thanks to scyoon for the report and patches!

🚨 Possible ReDoS vulnerability in query parameter filtering in Action Dispatch

There is a possible ReDoS vulnerability in the query parameter filtering routines of Action Dispatch. This vulnerability has been assigned the CVE identifier CVE-2024-41128.

Impact

Carefully crafted query parameters can cause query parameter filtering to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade or apply the relevant patch immediately.

Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 depends on Ruby 3.2 or greater so is unaffected.

Releases

The fixed releases are available at the normal locations.

Workarounds

Users on Ruby 3.2 are unaffected by this issue.

Credits

Thanks to scyoon for the report and patches!

🚨 Possible ReDoS vulnerability in HTTP Token authentication in Action Controller

There is a possible ReDoS vulnerability in Action Controller's HTTP Token authentication. This vulnerability has been assigned the CVE identifier CVE-2024-47887.

Impact

For applications using HTTP Token authentication via authenticate_or_request_with_http_token or similar, a carefully crafted header may cause header parsing to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade or apply the relevant patch immediately.

Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 depends on Ruby 3.2 or greater so is unaffected.

Releases

The fixed releases are available at the normal locations.

Workarounds

Users on Ruby 3.2 are unaffected by this issue.

Credits

Thanks to scyoon for reporting

🚨 Possible ReDoS vulnerability in query parameter filtering in Action Dispatch

There is a possible ReDoS vulnerability in the query parameter filtering routines of Action Dispatch. This vulnerability has been assigned the CVE identifier CVE-2024-41128.

Impact

Carefully crafted query parameters can cause query parameter filtering to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade or apply the relevant patch immediately.

Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 depends on Ruby 3.2 or greater so is unaffected.

Releases

The fixed releases are available at the normal locations.

Workarounds

Users on Ruby 3.2 are unaffected by this issue.

Credits

Thanks to scyoon for the report and patches!

🚨 Missing security headers in Action Pack on non-HTML responses

Permissions-Policy is Only Served on HTML Content-Type

The application configurable Permissions-Policy is only served on responses
with an HTML related Content-Type.

This has been assigned the CVE identifier CVE-2024-28103.

Versions Affected: >= 6.1.0
Not affected: < 6.1.0
Fixed Versions: 6.1.7.8, 7.0.8.4, and 7.1.3.4

Impact

Responses with a non-HTML Content-Type are not serving the configured Permissions-Policy. There are certain non-HTML Content-Types that would benefit from having the Permissions-Policy enforced.

Releases

The fixed releases are available at the normal locations.

Workarounds

N/A

Patches

To aid users who aren't able to upgrade immediately we have provided patches for
the supported release series in accordance with our
maintenance policy
regarding security issues. They are in git-am format and consist of a
single changeset.

  • 6-1-include-permissions-policy-header-on-non-html.patch - Patch for 6.1 series
  • 7-0-include-permissions-policy-header-on-non-html.patch - Patch for 7.0 series
  • 7-1-include-permissions-policy-header-on-non-html.patch - Patch for 7.1 series

Credits

Thank you shinkbr for reporting this!

🚨 Missing security headers in Action Pack on non-HTML responses

Permissions-Policy is Only Served on HTML Content-Type

The application configurable Permissions-Policy is only served on responses
with an HTML related Content-Type.

This has been assigned the CVE identifier CVE-2024-28103.

Versions Affected: >= 6.1.0
Not affected: < 6.1.0
Fixed Versions: 6.1.7.8, 7.0.8.4, and 7.1.3.4

Impact

Responses with a non-HTML Content-Type are not serving the configured Permissions-Policy. There are certain non-HTML Content-Types that would benefit from having the Permissions-Policy enforced.

Releases

The fixed releases are available at the normal locations.

Workarounds

N/A

Patches

To aid users who aren't able to upgrade immediately we have provided patches for
the supported release series in accordance with our
maintenance policy
regarding security issues. They are in git-am format and consist of a
single changeset.

  • 6-1-include-permissions-policy-header-on-non-html.patch - Patch for 6.1 series
  • 7-0-include-permissions-policy-header-on-non-html.patch - Patch for 7.0 series
  • 7-1-include-permissions-policy-header-on-non-html.patch - Patch for 7.1 series

Credits

Thank you shinkbr for reporting this!

🚨 Missing security headers in Action Pack on non-HTML responses

Permissions-Policy is Only Served on HTML Content-Type

The application configurable Permissions-Policy is only served on responses
with an HTML related Content-Type.

This has been assigned the CVE identifier CVE-2024-28103.

Versions Affected: >= 6.1.0
Not affected: < 6.1.0
Fixed Versions: 6.1.7.8, 7.0.8.4, and 7.1.3.4

Impact

Responses with a non-HTML Content-Type are not serving the configured Permissions-Policy. There are certain non-HTML Content-Types that would benefit from having the Permissions-Policy enforced.

Releases

The fixed releases are available at the normal locations.

Workarounds

N/A

Patches

To aid users who aren't able to upgrade immediately we have provided patches for
the supported release series in accordance with our
maintenance policy
regarding security issues. They are in git-am format and consist of a
single changeset.

  • 6-1-include-permissions-policy-header-on-non-html.patch - Patch for 6.1 series
  • 7-0-include-permissions-policy-header-on-non-html.patch - Patch for 7.0 series
  • 7-1-include-permissions-policy-header-on-non-html.patch - Patch for 7.1 series

Credits

Thank you shinkbr for reporting this!

🚨 Rails has possible XSS Vulnerability in Action Controller

Possible XSS Vulnerability in Action Controller

There is a possible XSS vulnerability when using the translation helpers
(translate, t, etc) in Action Controller. This vulnerability has been
assigned the CVE identifier CVE-2024-26143.

Versions Affected: >= 7.0.0.
Not affected: < 7.0.0
Fixed Versions: 7.1.3.1, 7.0.8.1

Impact

Applications using translation methods like translate, or t on a
controller, with a key ending in "_html", a :default key which contains
untrusted user input, and the resulting string is used in a view, may be
susceptible to an XSS vulnerability.

For example, impacted code will look something like this:

class ArticlesController < ApplicationController
  def show  
    @message = t("message_html", default: untrusted_input)
    # The `show` template displays the contents of `@message`
  end
end

To reiterate the pre-conditions, applications must:

  • Use a translation function from a controller (i.e. not I18n.t, or t from
    a view)
  • Use a key that ends in _html
  • Use a default value where the default value is untrusted and unescaped input
  • Send the text to the victim (whether that's part of a template, or a
    render call)

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The fixed releases are available at the normal locations.

Workarounds

There are no feasible workarounds for this issue.

Patches

To aid users who aren't able to upgrade immediately we have provided patches for
the two supported release series. They are in git-am format and consist of a
single changeset.

  • 7-0-translate-xss.patch - Patch for 7.0 series
  • 7-1-translate-xss.patch - Patch for 7.1 series

Credits

Thanks to ooooooo_q for the patch and fix!

🚨 Rails has possible ReDoS vulnerability in Accept header parsing in Action Dispatch

Possible ReDoS vulnerability in Accept header parsing in Action Dispatch

There is a possible ReDoS vulnerability in the Accept header parsing routines
of Action Dispatch. This vulnerability has been assigned the CVE identifier
CVE-2024-26142.

Versions Affected: >= 7.1.0, < 7.1.3.1
Not affected: < 7.1.0
Fixed Versions: 7.1.3.1

Impact

Carefully crafted Accept headers can cause Accept header parsing in Action
Dispatch to take an unexpected amount of time, possibly resulting in a DoS
vulnerability. All users running an affected release should either upgrade or
use one of the workarounds immediately.

Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby
3.2 or newer are unaffected.

Releases

The fixed releases are available at the normal locations.

Workarounds

There are no feasible workarounds for this issue.

Patches

To aid users who aren't able to upgrade immediately we have provided patches for
the two supported release series. They are in git-am format and consist of a
single changeset.

  • 7-1-accept-redox.patch - Patch for 7.1 series

Credits

Thanks svalkanov for the report and patch!

🚨 Rails has possible XSS Vulnerability in Action Controller

Possible XSS Vulnerability in Action Controller

There is a possible XSS vulnerability when using the translation helpers
(translate, t, etc) in Action Controller. This vulnerability has been
assigned the CVE identifier CVE-2024-26143.

Versions Affected: >= 7.0.0.
Not affected: < 7.0.0
Fixed Versions: 7.1.3.1, 7.0.8.1

Impact

Applications using translation methods like translate, or t on a
controller, with a key ending in "_html", a :default key which contains
untrusted user input, and the resulting string is used in a view, may be
susceptible to an XSS vulnerability.

For example, impacted code will look something like this:

class ArticlesController < ApplicationController
  def show  
    @message = t("message_html", default: untrusted_input)
    # The `show` template displays the contents of `@message`
  end
end

To reiterate the pre-conditions, applications must:

  • Use a translation function from a controller (i.e. not I18n.t, or t from
    a view)
  • Use a key that ends in _html
  • Use a default value where the default value is untrusted and unescaped input
  • Send the text to the victim (whether that's part of a template, or a
    render call)

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The fixed releases are available at the normal locations.

Workarounds

There are no feasible workarounds for this issue.

Patches

To aid users who aren't able to upgrade immediately we have provided patches for
the two supported release series. They are in git-am format and consist of a
single changeset.

  • 7-0-translate-xss.patch - Patch for 7.0 series
  • 7-1-translate-xss.patch - Patch for 7.1 series

Credits

Thanks to ooooooo_q for the patch and fix!

🚨 Actionpack has possible cross-site scripting vulnerability via User Supplied Values to redirect_to

The redirect_to method in Rails allows provided values to contain characters which are not legal in an HTTP header value. This results in the potential for downstream services which enforce RFC compliance on HTTP response headers to remove the assigned Location header. This vulnerability has been assigned the CVE identifier CVE-2023-28362.

Versions Affected: All. Not affected: None Fixed Versions: 7.0.5.1, 6.1.7.4

Impact

This introduces the potential for a Cross-site-scripting (XSS) payload to be delivered on the now static redirection page. Note that this both requires user interaction and for a Rails app to be configured to allow redirects to external hosts (defaults to false in Rails >= 7.0.x).

Releases

The FIXED releases are available at the normal locations.

Workarounds

Avoid providing user supplied URLs with arbitrary schemes to the redirect_to method.

🚨 Actionpack has possible cross-site scripting vulnerability via User Supplied Values to redirect_to

The redirect_to method in Rails allows provided values to contain characters which are not legal in an HTTP header value. This results in the potential for downstream services which enforce RFC compliance on HTTP response headers to remove the assigned Location header. This vulnerability has been assigned the CVE identifier CVE-2023-28362.

Versions Affected: All. Not affected: None Fixed Versions: 7.0.5.1, 6.1.7.4

Impact

This introduces the potential for a Cross-site-scripting (XSS) payload to be delivered on the now static redirection page. Note that this both requires user interaction and for a Rails app to be configured to allow redirects to external hosts (defaults to false in Rails >= 7.0.x).

Releases

The FIXED releases are available at the normal locations.

Workarounds

Avoid providing user supplied URLs with arbitrary schemes to the redirect_to method.

🚨 ReDoS based DoS vulnerability in Action Dispatch

There is a possible regular expression based DoS vulnerability in Action Dispatch. This vulnerability has been assigned the CVE identifier CVE-2023-22792.

Versions Affected: >= 3.0.0 Not affected: < 3.0.0 Fixed Versions: 5.2.8.15 (Rails LTS), 6.1.7.1, 7.0.4.1
Impact

Specially crafted cookies, in combination with a specially crafted X_FORWARDED_HOST header can cause the regular expression engine to enter a state of catastrophic backtracking. This can cause the process to use large amounts of CPU and memory, leading to a possible DoS vulnerability All users running an affected release should either upgrade or use one of the workarounds immediately.
Releases

The FIXED releases are available at the normal locations.
Workarounds

We recommend that all users upgrade to one of the FIXED versions. In the meantime, users can mitigate this vulnerability by using a load balancer or other device to filter out malicious X_FORWARDED_HOST headers before they reach the application.
Patches

To aid users who aren’t able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.

6-1-Use-string-split-instead-of-regex-for-domain-parts.patch - Patch for 6.1 series
7-0-Use-string-split-instead-of-regex-for-domain-parts.patch - Patch for 7.0 series

Please note that only the 7.0.Z and 6.1.Z series are supported at present, and 6.0.Z for severe vulnerabilities. Users of earlier unsupported releases are advised to upgrade as soon as possible as we cannot guarantee the continued availability of security fixes for unsupported releases.

https://rubyonrails.org/2023/1/17/Rails-Versions-6-0-6-1-6-1-7-1-7-0-4-1-have-been-released

🚨 ReDoS based DoS vulnerability in Action Dispatch

There is a possible regular expression based DoS vulnerability in Action Dispatch. This vulnerability has been assigned the CVE identifier CVE-2023-22792.

Versions Affected: >= 3.0.0 Not affected: < 3.0.0 Fixed Versions: 5.2.8.15 (Rails LTS), 6.1.7.1, 7.0.4.1
Impact

Specially crafted cookies, in combination with a specially crafted X_FORWARDED_HOST header can cause the regular expression engine to enter a state of catastrophic backtracking. This can cause the process to use large amounts of CPU and memory, leading to a possible DoS vulnerability All users running an affected release should either upgrade or use one of the workarounds immediately.
Releases

The FIXED releases are available at the normal locations.
Workarounds

We recommend that all users upgrade to one of the FIXED versions. In the meantime, users can mitigate this vulnerability by using a load balancer or other device to filter out malicious X_FORWARDED_HOST headers before they reach the application.
Patches

To aid users who aren’t able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.

6-1-Use-string-split-instead-of-regex-for-domain-parts.patch - Patch for 6.1 series
7-0-Use-string-split-instead-of-regex-for-domain-parts.patch - Patch for 7.0 series

Please note that only the 7.0.Z and 6.1.Z series are supported at present, and 6.0.Z for severe vulnerabilities. Users of earlier unsupported releases are advised to upgrade as soon as possible as we cannot guarantee the continued availability of security fixes for unsupported releases.

https://rubyonrails.org/2023/1/17/Rails-Versions-6-0-6-1-6-1-7-1-7-0-4-1-have-been-released

🚨 Open Redirect Vulnerability in Action Pack

There is a vulnerability in Action Controller’s redirect_to. This vulnerability has been assigned the CVE identifier CVE-2023-22797.

Versions Affected: >= 7.0.0 Not affected: < 7.0.0 Fixed Versions: 7.0.4.1
Impact

There is a possible open redirect when using the redirect_to helper with untrusted user input.

Vulnerable code will look like this:

redirect_to(params[:some_param])

Rails 7.0 introduced protection against open redirects from calling redirect_to with untrusted user input. In prior versions the developer was fully responsible for only providing trusted input. However the check introduced could be bypassed by a carefully crafted URL.

All users running an affected release should either upgrade or use one of the workarounds immediately.
Releases

The FIXED releases are available at the normal locations.
Workarounds

There are no feasible workarounds for this issue.
Patches

To aid users who aren’t able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.

7-0-Fix-sec-issue-with-_url_host_allowed.patch - Patch for 7.0 series

Please note that only the 7.0.Z and 6.1.Z series are supported at present, and 6.0.Z for severe vulnerabilities. Users of earlier unsupported releases are advised to upgrade as soon as possible as we cannot guarantee the continued availability of security fixes for unsupported releases.

🚨 ReDoS based DoS vulnerability in Action Dispatch

There is a possible regular expression based DoS vulnerability in Action Dispatch related to the If-None-Match header. This vulnerability has been assigned the CVE identifier CVE-2023-22795.

Versions Affected: All Not affected: None Fixed Versions: 5.2.8.15 (Rails LTS), 6.1.7.1, 7.0.4.1

Impact

A specially crafted HTTP If-None-Match header can cause the regular expression engine to enter a state of catastrophic backtracking, when on a version of Ruby below 3.2.0. This can cause the process to use large amounts of CPU and memory, leading to a possible DoS vulnerability All users running an affected release should either upgrade or use one of the workarounds immediately.
Releases

The FIXED releases are available at the normal locations.
Workarounds

We recommend that all users upgrade to one of the FIXED versions. In the meantime, users can mitigate this vulnerability by using a load balancer or other device to filter out malicious If-None-Match headers before they reach the application.

Users on Ruby 3.2.0 or greater are not affected by this vulnerability.
Patches

To aid users who aren’t able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.

6-1-Avoid-regex-backtracking-on-If-None-Match-header.patch - Patch for 6.1 series
7-0-Avoid-regex-backtracking-on-If-None-Match-header.patch - Patch for 7.0 series

Please note that only the 7.0.Z and 6.1.Z series are supported at present, and 6.0.Z for severe vulnerabilities. Users of earlier unsupported releases are advised to upgrade as soon as possible as we cannot guarantee the continued availability of security fixes for unsupported releases.

🚨 ReDoS based DoS vulnerability in Action Dispatch

There is a possible regular expression based DoS vulnerability in Action Dispatch related to the If-None-Match header. This vulnerability has been assigned the CVE identifier CVE-2023-22795.

Versions Affected: All Not affected: None Fixed Versions: 5.2.8.15 (Rails LTS), 6.1.7.1, 7.0.4.1

Impact

A specially crafted HTTP If-None-Match header can cause the regular expression engine to enter a state of catastrophic backtracking, when on a version of Ruby below 3.2.0. This can cause the process to use large amounts of CPU and memory, leading to a possible DoS vulnerability All users running an affected release should either upgrade or use one of the workarounds immediately.
Releases

The FIXED releases are available at the normal locations.
Workarounds

We recommend that all users upgrade to one of the FIXED versions. In the meantime, users can mitigate this vulnerability by using a load balancer or other device to filter out malicious If-None-Match headers before they reach the application.

Users on Ruby 3.2.0 or greater are not affected by this vulnerability.
Patches

To aid users who aren’t able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.

6-1-Avoid-regex-backtracking-on-If-None-Match-header.patch - Patch for 6.1 series
7-0-Avoid-regex-backtracking-on-If-None-Match-header.patch - Patch for 7.0 series

Please note that only the 7.0.Z and 6.1.Z series are supported at present, and 6.0.Z for severe vulnerabilities. Users of earlier unsupported releases are advised to upgrade as soon as possible as we cannot guarantee the continued availability of security fixes for unsupported releases.

🚨 Cross-site Scripting Vulnerability in Action Pack

There is a possible XSS vulnerability in Rails / Action Pack. This vulnerability has been
assigned the CVE identifier CVE-2022-22577.

Versions Affected: >= 5.2.0
Not affected: < 5.2.0
Fixed Versions: 7.0.2.4, 6.1.5.1, 6.0.4.8, 5.2.7.1

Impact

CSP headers were only sent along with responses that Rails considered as
"HTML" responses. This left API requests without CSP headers, which could
possibly expose users to XSS attacks.

Releases

The FIXED releases are available at the normal locations.

Workarounds

Set a CSP for your API responses manually.

🚨 Cross-site Scripting Vulnerability in Action Pack

There is a possible XSS vulnerability in Rails / Action Pack. This vulnerability has been
assigned the CVE identifier CVE-2022-22577.

Versions Affected: >= 5.2.0
Not affected: < 5.2.0
Fixed Versions: 7.0.2.4, 6.1.5.1, 6.0.4.8, 5.2.7.1

Impact

CSP headers were only sent along with responses that Rails considered as
"HTML" responses. This left API requests without CSP headers, which could
possibly expose users to XSS attacks.

Releases

The FIXED releases are available at the normal locations.

Workarounds

Set a CSP for your API responses manually.

🚨 Exposure of information in Action Pack

Impact

Under certain circumstances response bodies will not be closed, for example a bug in a webserver or a bug in a Rack middleware. In the event a response is not notified of a close, ActionDispatch::Executor will not know to reset thread local state for the next request. This can lead to data being leaked to subsequent requests, especially when interacting with ActiveSupport::CurrentAttributes.

Upgrading to the FIXED versions of Rails will ensure mitigation of this issue even in the context of a buggy webserver or middleware implementation.

Patches

This has been fixed in Rails 7.0.2.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2.

Workarounds

Upgrading is highly recommended, but to work around this problem the following middleware can be used:

class GuardedExecutor < ActionDispatch::Executor
  def call(env)
    ensure_completed!
    super
  end

  private

    def ensure_completed!
      @executor.new.complete! if @executor.active?
    end
end

# Ensure the guard is inserted before ActionDispatch::Executor
Rails.application.configure do
  config.middleware.swap ActionDispatch::Executor, GuardedExecutor, executor
end
Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ actiontext (indirect, 6.1.5 → 8.0.2.1) · Repo · Changelog

Security Advisories 🚨

🚨 Possible ReDoS vulnerability in plain_text_for_blockquote_node in Action Text

There is a possible ReDoS vulnerability in the plain_text_for_blockquote_node helper in Action Text. This vulnerability has been assigned the CVE identifier CVE-2024-47888.

Impact

Carefully crafted text can cause the plain_text_for_blockquote_node helper to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade or apply the relevant patch immediately.

Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 depends on Ruby 3.2 or greater so is unaffected.

Releases

The fixed releases are available at the normal locations.

Workarounds

Users can avoid calling plain_text_for_blockquote_node or upgrade to Ruby 3.2

Credits

Thanks to ooooooo_q for the report!

🚨 Possible ReDoS vulnerability in plain_text_for_blockquote_node in Action Text

There is a possible ReDoS vulnerability in the plain_text_for_blockquote_node helper in Action Text. This vulnerability has been assigned the CVE identifier CVE-2024-47888.

Impact

Carefully crafted text can cause the plain_text_for_blockquote_node helper to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade or apply the relevant patch immediately.

Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 depends on Ruby 3.2 or greater so is unaffected.

Releases

The fixed releases are available at the normal locations.

Workarounds

Users can avoid calling plain_text_for_blockquote_node or upgrade to Ruby 3.2

Credits

Thanks to ooooooo_q for the report!

🚨 Possible ReDoS vulnerability in plain_text_for_blockquote_node in Action Text

There is a possible ReDoS vulnerability in the plain_text_for_blockquote_node helper in Action Text. This vulnerability has been assigned the CVE identifier CVE-2024-47888.

Impact

Carefully crafted text can cause the plain_text_for_blockquote_node helper to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade or apply the relevant patch immediately.

Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 depends on Ruby 3.2 or greater so is unaffected.

Releases

The fixed releases are available at the normal locations.

Workarounds

Users can avoid calling plain_text_for_blockquote_node or upgrade to Ruby 3.2

Credits

Thanks to ooooooo_q for the report!

🚨 Possible ReDoS vulnerability in plain_text_for_blockquote_node in Action Text

There is a possible ReDoS vulnerability in the plain_text_for_blockquote_node helper in Action Text. This vulnerability has been assigned the CVE identifier CVE-2024-47888.

Impact

Carefully crafted text can cause the plain_text_for_blockquote_node helper to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade or apply the relevant patch immediately.

Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 depends on Ruby 3.2 or greater so is unaffected.

Releases

The fixed releases are available at the normal locations.

Workarounds

Users can avoid calling plain_text_for_blockquote_node or upgrade to Ruby 3.2

Credits

Thanks to ooooooo_q for the report!

🚨 ActionText ContentAttachment can Contain Unsanitized HTML

Instances of ActionText::Attachable::ContentAttachment included within a rich_text_area tag could potentially contain unsanitized HTML.

This has been assigned the CVE identifier CVE-2024-32464.

Versions Affected: >= 7.1.0
Not affected: < 7.1.0
Fixed Versions: 7.1.3.4

Impact

This could lead to a potential cross site scripting issue within the Trix editor.

Releases

The fixed releases are available at the normal locations.

Workarounds

N/A

Patches

To aid users who aren't able to upgrade immediately we have provided patches for the supported release series in accordance with our maintenance policy regarding security issues. They are in git-am format and consist of a single changeset.

  • action_text_content_attachment_xss_7_1_stable.patch - Patch for 7.1 series

Credits

Thank you ooooooo_q for reporting this!

🚨 Trix Editor Arbitrary Code Execution Vulnerability

The Trix editor, versions prior to 2.1.1, is vulnerable to arbitrary code execution when copying and pasting content from the web or other documents with markup into the editor. The vulnerability stems from improper sanitization of pasted content, allowing an attacker to embed malicious scripts which are executed within the context of the application.

Vulnerable Versions:

  • 1.x series up to and including 1.3.1
  • 2.x series up to and including 2.1.0

Fixed Versions:

  • v1.3.2
  • v2.1.1

Vector:

  • Bug 1: When copying content manipulated by a script, such as:
document.addEventListener('copy', function(e){
  e.clipboardData.setData('text/html', '<div><noscript><div class="123</noscript>456<img src=1 onerror=alert(1)//"></div></noscript></div>');
  e.preventDefault();
});

and pasting into the Trix editor, the script within the content is executed.

  • Bug 2: Similar execution occurs with content structured as:
document.write(`copy<div data-trix-attachment="{&quot;contentType&quot;:&quot;text/html&quot;,&quot;content&quot;:&quot;&lt;img src=1 onerror=alert(101)&gt;HELLO123&quot;}"></div>me`);

Impact:

An attacker could exploit these vulnerabilities to execute arbitrary JavaScript code within the context of the user's session, potentially leading to unauthorized actions being performed or sensitive information being disclosed.

Remediation:

Update Recommendation: Users should upgrade to Trix editor version 2.1.1 or later, which incorporates proper sanitization of input from copied content.

CSP Enhancement: Additionally, enhancing the Content Security Policy (CSP) to disallow inline scripts can significantly mitigate the risk of such vulnerabilities. Set CSP policies such as script-src 'self' to ensure that only scripts hosted on the same origin are executed, and explicitly prohibit inline scripts using script-src-elem.

References:

Credit: These issues were reported by security researchers loknop and pinpie.

🚨 Trix Editor Arbitrary Code Execution Vulnerability

The Trix editor, versions prior to 2.1.1, is vulnerable to arbitrary code execution when copying and pasting content from the web or other documents with markup into the editor. The vulnerability stems from improper sanitization of pasted content, allowing an attacker to embed malicious scripts which are executed within the context of the application.

Vulnerable Versions:

  • 1.x series up to and including 1.3.1
  • 2.x series up to and including 2.1.0

Fixed Versions:

  • v1.3.2
  • v2.1.1

Vector:

  • Bug 1: When copying content manipulated by a script, such as:
document.addEventListener('copy', function(e){
  e.clipboardData.setData('text/html', '<div><noscript><div class="123</noscript>456<img src=1 onerror=alert(1)//"></div></noscript></div>');
  e.preventDefault();
});

and pasting into the Trix editor, the script within the content is executed.

  • Bug 2: Similar execution occurs with content structured as:
document.write(`copy<div data-trix-attachment="{&quot;contentType&quot;:&quot;text/html&quot;,&quot;content&quot;:&quot;&lt;img src=1 onerror=alert(101)&gt;HELLO123&quot;}"></div>me`);

Impact:

An attacker could exploit these vulnerabilities to execute arbitrary JavaScript code within the context of the user's session, potentially leading to unauthorized actions being performed or sensitive information being disclosed.

Remediation:

Update Recommendation: Users should upgrade to Trix editor version 2.1.1 or later, which incorporates proper sanitization of input from copied content.

CSP Enhancement: Additionally, enhancing the Content Security Policy (CSP) to disallow inline scripts can significantly mitigate the risk of such vulnerabilities. Set CSP policies such as script-src 'self' to ensure that only scripts hosted on the same origin are executed, and explicitly prohibit inline scripts using script-src-elem.

References:

Credit: These issues were reported by security researchers loknop and pinpie.

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ actionview (indirect, 6.1.5 → 8.0.2.1) · Repo · Changelog

Security Advisories 🚨

🚨 rails-ujs vulnerable to DOM Based Cross-site Scripting contenteditable HTML Elements

NOTE: rails-ujs is part of Rails/actionview since 5.1.0.

There is a potential DOM based cross-site scripting issue in rails-ujs
which leverages the Clipboard API to target HTML elements that are
assigned the contenteditable attribute. This has the potential to
occur when pasting malicious HTML content from the clipboard that
includes a data-method, data-remote or data-disable-with attribute.

This vulnerability has been assigned the CVE identifier CVE-2023-23913.

Not affected: < 5.1.0
Versions Affected: >= 5.1.0
Fixed Versions: 6.1.7.3, 7.0.4.3

Impact
If the specified malicious HTML clipboard content is provided to a
contenteditable element, this could result in the arbitrary execution
of javascript on the origin in question.

Releases
The FIXED releases are available at the normal locations.

Workarounds
We recommend that all users upgrade to one of the FIXED versions.
In the meantime, users can attempt to mitigate this vulnerability
by removing the contenteditable attribute from elements in pages
that rails-ujs will interact with.

Patches
To aid users who aren’t able to upgrade immediately we have provided
patches for the two supported release series. They are in git-am
format and consist of a single changeset.

  • rails-ujs-data-method-contenteditable-6-1.patch - Patch for 6.1 series
  • rails-ujs-data-method-contenteditable-7-0.patch - Patch for 7.0 series

Please note that only the 7.0.Z and 6.1.Z series are
supported at present, and 6.0.Z for severe vulnerabilities.

Users of earlier unsupported releases are advised to upgrade as
soon as possible as we cannot guarantee the continued availability
of security fixes for unsupported releases.

Credits
We would like to thank ryotak 15 for reporting this!

  • rails-ujs-data-method-contenteditable-6-1.patch (8.5 KB)
  • rails-ujs-data-method-contenteditable-7-0.patch (8.5 KB)
  • rails-ujs-data-method-contenteditable-main.patch (8.9 KB)

🚨 rails-ujs vulnerable to DOM Based Cross-site Scripting contenteditable HTML Elements

NOTE: rails-ujs is part of Rails/actionview since 5.1.0.

There is a potential DOM based cross-site scripting issue in rails-ujs
which leverages the Clipboard API to target HTML elements that are
assigned the contenteditable attribute. This has the potential to
occur when pasting malicious HTML content from the clipboard that
includes a data-method, data-remote or data-disable-with attribute.

This vulnerability has been assigned the CVE identifier CVE-2023-23913.

Not affected: < 5.1.0
Versions Affected: >= 5.1.0
Fixed Versions: 6.1.7.3, 7.0.4.3

Impact
If the specified malicious HTML clipboard content is provided to a
contenteditable element, this could result in the arbitrary execution
of javascript on the origin in question.

Releases
The FIXED releases are available at the normal locations.

Workarounds
We recommend that all users upgrade to one of the FIXED versions.
In the meantime, users can attempt to mitigate this vulnerability
by removing the contenteditable attribute from elements in pages
that rails-ujs will interact with.

Patches
To aid users who aren’t able to upgrade immediately we have provided
patches for the two supported release series. They are in git-am
format and consist of a single changeset.

  • rails-ujs-data-method-contenteditable-6-1.patch - Patch for 6.1 series
  • rails-ujs-data-method-contenteditable-7-0.patch - Patch for 7.0 series

Please note that only the 7.0.Z and 6.1.Z series are
supported at present, and 6.0.Z for severe vulnerabilities.

Users of earlier unsupported releases are advised to upgrade as
soon as possible as we cannot guarantee the continued availability
of security fixes for unsupported releases.

Credits
We would like to thank ryotak 15 for reporting this!

  • rails-ujs-data-method-contenteditable-6-1.patch (8.5 KB)
  • rails-ujs-data-method-contenteditable-7-0.patch (8.5 KB)
  • rails-ujs-data-method-contenteditable-main.patch (8.9 KB)

🚨 XSS Vulnerability in Action View tag helpers

There is a possible XSS vulnerability in Action View tag helpers. Passing untrusted input as hash keys can lead to a possible XSS vulnerability. This vulnerability has been assigned the CVE identifier CVE-2022-27777.

Versions Affected: ALL
Not affected: NONE
Fixed Versions: 7.0.2.4, 6.1.5.1, 6.0.4.8, 5.2.7.1

Impact

If untrusted data is passed as the hash key for tag attributes, there is a possibility that the untrusted data may not be properly escaped which can lead to an XSS vulnerability.

Impacted code will look something like this:

check_box_tag('thename', 'thevalue', false, aria: { malicious_input => 'thevalueofaria' })

Where the "malicious_input" variable contains untrusted data.

All users running an affected release should either upgrade or use one of the workarounds immediately.

Releases

The FIXED releases are available at the normal locations.

Workarounds

Escape the untrusted data before using it as a key for tag helper methods.

🚨 XSS Vulnerability in Action View tag helpers

There is a possible XSS vulnerability in Action View tag helpers. Passing untrusted input as hash keys can lead to a possible XSS vulnerability. This vulnerability has been assigned the CVE identifier CVE-2022-27777.

Versions Affected: ALL
Not affected: NONE
Fixed Versions: 7.0.2.4, 6.1.5.1, 6.0.4.8, 5.2.7.1

Impact

If untrusted data is passed as the hash key for tag attributes, there is a possibility that the untrusted data may not be properly escaped which can lead to an XSS vulnerability.

Impacted code will look something like this:

check_box_tag('thename', 'thevalue', false, aria: { malicious_input => 'thevalueofaria' })

Where the "malicious_input" variable contains untrusted data.

All users running an affected release should either upgrade or use one of the workarounds immediately.

Releases

The FIXED releases are available at the normal locations.

Workarounds

Escape the untrusted data before using it as a key for tag helper methods.

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ activejob (indirect, 6.1.5 → 8.0.2.1) · Repo · Changelog

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ activemodel (indirect, 6.1.5 → 8.0.2.1) · Repo · Changelog

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ activerecord (indirect, 6.1.5 → 8.0.2.1) · Repo · Changelog

Security Advisories 🚨

🚨 Active Record logging vulnerable to ANSI escape injection

This vulnerability has been assigned the CVE identifier CVE-2025-55193

Impact

The ID passed to find or similar methods may be logged without escaping. If this is directly to the terminal it may include unescaped ANSI sequences.

Releases

The fixed releases are available at the normal locations.

Credits

Thanks to lio346 for reporting this vulnerability

🚨 Active Record logging vulnerable to ANSI escape injection

This vulnerability has been assigned the CVE identifier CVE-2025-55193

Impact

The ID passed to find or similar methods may be logged without escaping. If this is directly to the terminal it may include unescaped ANSI sequences.

Releases

The fixed releases are available at the normal locations.

Credits

Thanks to lio346 for reporting this vulnerability

🚨 Active Record logging vulnerable to ANSI escape injection

This vulnerability has been assigned the CVE identifier CVE-2025-55193

Impact

The ID passed to find or similar methods may be logged without escaping. If this is directly to the terminal it may include unescaped ANSI sequences.

Releases

The fixed releases are available at the normal locations.

Credits

Thanks to lio346 for reporting this vulnerability

🚨 SQL Injection Vulnerability via ActiveRecord comments

There is a possible vulnerability in ActiveRecord related to the sanitization of comments. This vulnerability has been assigned the CVE identifier CVE-2023-22794.

Versions Affected: >= 6.0.0 Not affected: < 6.0.0 Fixed Versions: 6.0.6.1, 6.1.7.1, 7.0.4.1
Impact

Previously the implementation of escaping for comments was insufficient for

If malicious user input is passed to either the annotate query method, the optimizer_hints query method, or through the QueryLogs interface which automatically adds annotations, it may be sent to the database with insufficient sanitization and be able to inject SQL outside of the comment.

In most cases these interfaces won’t be used with user input and users should avoid doing so.

Example vulnerable code:

Post.where(id: 1).annotate("#{params[:user_input]}")

Post.where(id: 1).optimizer_hints("#{params[:user_input]}")

Example vulnerable QueryLogs configuration (the default configuration is not vulnerable):

config.active_record.query_log_tags = [
  {
    something: -> { <some value including user input> }
  }
]

All users running an affected release should either upgrade or use one of the workarounds immediately.
Releases

The FIXED releases are available at the normal locations.
Workarounds

Avoid passing user input to annotate and avoid using QueryLogs configuration which can include user input.
Patches

To aid users who aren’t able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.

6-0-Make-sanitize_as_sql_comment-more-strict.patch - Patch for 6.0 series
6-1-Make-sanitize_as_sql_comment-more-strict.patch - Patch for 6.1 series
7-0-Make-sanitize_as_sql_comment-more-strict.patch - Patch for 7.0 series

Please note that only the 7.0.Z and 6.1.Z series are supported at present, and 6.0.Z for severe vulnerabilities. Users of earlier unsupported releases are advised to upgrade as soon as possible as we cannot guarantee the continued availability of security fixes for unsupported releases.

🚨 Denial of Service Vulnerability in ActiveRecord's PostgreSQL adapter

There is a potential denial of service vulnerability present in ActiveRecord’s PostgreSQL adapter.

This has been assigned the CVE identifier CVE-2022-44566.

Versions Affected: All. Not affected: None. Fixed Versions: 5.2.8.15 (Rails LTS, which is a paid service and not part of the rubygem), 6.1.7.1, 7.0.4.1

Impact:
In ActiveRecord <7.0.4.1 and <6.1.7.1, when a value outside the range for a 64bit signed integer is provided to the PostgreSQL connection adapter, it will treat the target column type as numeric. Comparing integer values against numeric values can result in a slow sequential scan resulting in potential Denial of Service.
Releases

The fixed releases are available at the normal locations.
Workarounds

Ensure that user supplied input which is provided to ActiveRecord clauses do not contain integers wider than a signed 64bit representation or floats.
Patches

To aid users who aren’t able to upgrade immediately we have provided patches for the supported release series in accordance with our maintenance policy 1 regarding security issues. They are in git-am format and consist of a single changeset.

6-1-Added-integer-width-check-to-PostgreSQL-Quoting.patch - Patch for 6.1 series
7-0-Added-integer-width-check-to-PostgreSQL-Quoting.patch - Patch for 7.0 series

🚨 Denial of Service Vulnerability in ActiveRecord's PostgreSQL adapter

There is a potential denial of service vulnerability present in ActiveRecord’s PostgreSQL adapter.

This has been assigned the CVE identifier CVE-2022-44566.

Versions Affected: All. Not affected: None. Fixed Versions: 5.2.8.15 (Rails LTS, which is a paid service and not part of the rubygem), 6.1.7.1, 7.0.4.1

Impact:
In ActiveRecord <7.0.4.1 and <6.1.7.1, when a value outside the range for a 64bit signed integer is provided to the PostgreSQL connection adapter, it will treat the target column type as numeric. Comparing integer values against numeric values can result in a slow sequential scan resulting in potential Denial of Service.
Releases

The fixed releases are available at the normal locations.
Workarounds

Ensure that user supplied input which is provided to ActiveRecord clauses do not contain integers wider than a signed 64bit representation or floats.
Patches

To aid users who aren’t able to upgrade immediately we have provided patches for the supported release series in accordance with our maintenance policy 1 regarding security issues. They are in git-am format and consist of a single changeset.

6-1-Added-integer-width-check-to-PostgreSQL-Quoting.patch - Patch for 6.1 series
7-0-Added-integer-width-check-to-PostgreSQL-Quoting.patch - Patch for 7.0 series

🚨 SQL Injection Vulnerability via ActiveRecord comments

There is a possible vulnerability in ActiveRecord related to the sanitization of comments. This vulnerability has been assigned the CVE identifier CVE-2023-22794.

Versions Affected: >= 6.0.0 Not affected: < 6.0.0 Fixed Versions: 6.0.6.1, 6.1.7.1, 7.0.4.1
Impact

Previously the implementation of escaping for comments was insufficient for

If malicious user input is passed to either the annotate query method, the optimizer_hints query method, or through the QueryLogs interface which automatically adds annotations, it may be sent to the database with insufficient sanitization and be able to inject SQL outside of the comment.

In most cases these interfaces won’t be used with user input and users should avoid doing so.

Example vulnerable code:

Post.where(id: 1).annotate("#{params[:user_input]}")

Post.where(id: 1).optimizer_hints("#{params[:user_input]}")

Example vulnerable QueryLogs configuration (the default configuration is not vulnerable):

config.active_record.query_log_tags = [
  {
    something: -> { <some value including user input> }
  }
]

All users running an affected release should either upgrade or use one of the workarounds immediately.
Releases

The FIXED releases are available at the normal locations.
Workarounds

Avoid passing user input to annotate and avoid using QueryLogs configuration which can include user input.
Patches

To aid users who aren’t able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.

6-0-Make-sanitize_as_sql_comment-more-strict.patch - Patch for 6.0 series
6-1-Make-sanitize_as_sql_comment-more-strict.patch - Patch for 6.1 series
7-0-Make-sanitize_as_sql_comment-more-strict.patch - Patch for 7.0 series

Please note that only the 7.0.Z and 6.1.Z series are supported at present, and 6.0.Z for severe vulnerabilities. Users of earlier unsupported releases are advised to upgrade as soon as possible as we cannot guarantee the continued availability of security fixes for unsupported releases.

🚨 Active Record RCE bug with Serialized Columns

When serialized columns that use YAML (the default) are deserialized, Rails uses YAML.unsafe_load to convert the YAML data in to Ruby objects. If an attacker can manipulate data in the database (via means like SQL injection), then it may be possible for the attacker to escalate to an RCE.

There are no feasible workarounds for this issue, but other coders (such as JSON) are not impacted.

🚨 Active Record RCE bug with Serialized Columns

When serialized columns that use YAML (the default) are deserialized, Rails uses YAML.unsafe_load to convert the YAML data in to Ruby objects. If an attacker can manipulate data in the database (via means like SQL injection), then it may be possible for the attacker to escalate to an RCE.

There are no feasible workarounds for this issue, but other coders (such as JSON) are not impacted.

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ activestorage (indirect, 6.1.5 → 8.0.2.1) · Repo · Changelog

Security Advisories 🚨

🚨 Active Storage allowed transformation methods that were potentially unsafe

Active Storage attempts to prevent the use of potentially unsafe image transformation methods and parameters by default.

The default allowed list contains three methods allowing for the circumvention of the safe defaults which enables potential command injection vulnerabilities in cases where arbitrary user supplied input is accepted as valid transformation methods or parameters.

This has been assigned the CVE identifier CVE-2025-24293.

Versions Affected: >= 5.2.0
Not affected: < 5.2.0
Fixed Versions: 7.1.5.2, 7.2.2.2, 8.0.2.1

Impact

This vulnerability impacts applications that use Active Storage with the image_processing processing gem in addition to mini_magick as the image processor.

Vulnerable code will look something similar to this:

<%= image_tag blob.variant(params[:t] => params[:v]) %>

Where the transformation method or its arguments are untrusted arbitrary input.

All users running an affected release should either upgrade or use one of the workarounds immediately.

Releases

The fixed releases are available at the normal locations.

Workarounds

Consuming user supplied input for image transformation methods or their parameters is unsupported behavior and should be considered dangerous.

Strict validation of user supplied methods and parameters should be performed as well as having a strong ImageMagick security policy deployed.

Credits

Thank you lio346 for reporting this!

🚨 Active Storage allowed transformation methods that were potentially unsafe

Active Storage attempts to prevent the use of potentially unsafe image transformation methods and parameters by default.

The default allowed list contains three methods allowing for the circumvention of the safe defaults which enables potential command injection vulnerabilities in cases where arbitrary user supplied input is accepted as valid transformation methods or parameters.

This has been assigned the CVE identifier CVE-2025-24293.

Versions Affected: >= 5.2.0
Not affected: < 5.2.0
Fixed Versions: 7.1.5.2, 7.2.2.2, 8.0.2.1

Impact

This vulnerability impacts applications that use Active Storage with the image_processing processing gem in addition to mini_magick as the image processor.

Vulnerable code will look something similar to this:

<%= image_tag blob.variant(params[:t] => params[:v]) %>

Where the transformation method or its arguments are untrusted arbitrary input.

All users running an affected release should either upgrade or use one of the workarounds immediately.

Releases

The fixed releases are available at the normal locations.

Workarounds

Consuming user supplied input for image transformation methods or their parameters is unsupported behavior and should be considered dangerous.

Strict validation of user supplied methods and parameters should be performed as well as having a strong ImageMagick security policy deployed.

Credits

Thank you lio346 for reporting this!

🚨 Active Storage allowed transformation methods that were potentially unsafe

Active Storage attempts to prevent the use of potentially unsafe image transformation methods and parameters by default.

The default allowed list contains three methods allowing for the circumvention of the safe defaults which enables potential command injection vulnerabilities in cases where arbitrary user supplied input is accepted as valid transformation methods or parameters.

This has been assigned the CVE identifier CVE-2025-24293.

Versions Affected: >= 5.2.0
Not affected: < 5.2.0
Fixed Versions: 7.1.5.2, 7.2.2.2, 8.0.2.1

Impact

This vulnerability impacts applications that use Active Storage with the image_processing processing gem in addition to mini_magick as the image processor.

Vulnerable code will look something similar to this:

<%= image_tag blob.variant(params[:t] => params[:v]) %>

Where the transformation method or its arguments are untrusted arbitrary input.

All users running an affected release should either upgrade or use one of the workarounds immediately.

Releases

The fixed releases are available at the normal locations.

Workarounds

Consuming user supplied input for image transformation methods or their parameters is unsupported behavior and should be considered dangerous.

Strict validation of user supplied methods and parameters should be performed as well as having a strong ImageMagick security policy deployed.

Credits

Thank you lio346 for reporting this!

🚨 Rails has possible Sensitive Session Information Leak in Active Storage

Possible Sensitive Session Information Leak in Active Storage

There is a possible sensitive session information leak in Active Storage. By
default, Active Storage sends a Set-Cookie header along with the user's
session cookie when serving blobs. It also sets Cache-Control to public.
Certain proxies may cache the Set-Cookie, leading to an information leak.

This vulnerability has been assigned the CVE identifier CVE-2024-26144.

Versions Affected: >= 5.2.0, < 7.1.0
Not affected: < 5.2.0, > 7.1.0
Fixed Versions: 7.0.8.1, 6.1.7.7

Impact

A proxy which chooses to caches this request can cause users to share
sessions. This may include a user receiving an attacker's session or vice
versa.

This was patched in 7.1.0 but not previously identified as a security
vulnerability.

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The fixed releases are available at the normal locations.

Workarounds

Upgrade to Rails 7.1.X, or configure caching proxies not to cache the
Set-Cookie headers.

Credits

Thanks to tyage for reporting this!

🚨 Rails has possible Sensitive Session Information Leak in Active Storage

Possible Sensitive Session Information Leak in Active Storage

There is a possible sensitive session information leak in Active Storage. By
default, Active Storage sends a Set-Cookie header along with the user's
session cookie when serving blobs. It also sets Cache-Control to public.
Certain proxies may cache the Set-Cookie, leading to an information leak.

This vulnerability has been assigned the CVE identifier CVE-2024-26144.

Versions Affected: >= 5.2.0, < 7.1.0
Not affected: < 5.2.0, > 7.1.0
Fixed Versions: 7.0.8.1, 6.1.7.7

Impact

A proxy which chooses to caches this request can cause users to share
sessions. This may include a user receiving an attacker's session or vice
versa.

This was patched in 7.1.0 but not previously identified as a security
vulnerability.

All users running an affected release should either upgrade or use one of the
workarounds immediately.

Releases

The fixed releases are available at the normal locations.

Workarounds

Upgrade to Rails 7.1.X, or configure caching proxies not to cache the
Set-Cookie headers.

Credits

Thanks to tyage for reporting this!

🚨 Possible code injection vulnerability in Rails / Active Storage

The Active Storage module of Rails starting with version 5.2.0 is possibly vulnerable to code injection. This issue was patched in versions 5.2.6.3, 6.0.4.7, 6.1.4.7, and 7.0.2.3. To work around this issue, applications should implement a strict allow-list on accepted transformation methods or arguments. Additionally, a strict ImageMagick security policy will help mitigate this issue.

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ activesupport (indirect, 6.1.5 → 8.0.2.1) · Repo · Changelog

Security Advisories 🚨

🚨 Active Support Possibly Discloses Locally Encrypted Files

There is a possible file disclosure of locally encrypted files in Active Support. This vulnerability has been assigned the CVE identifier CVE-2023-38037.

Versions Affected: >= 5.2.0 Not affected: < 5.2.0 Fixed Versions: 7.0.7.1, 6.1.7.5

Impact

ActiveSupport::EncryptedFile writes contents that will be encrypted to a temporary file. The temporary file’s permissions are defaulted to the user’s current umask settings, meaning that it’s possible for other users on the same system to read the contents of the temporary file.

Attackers that have access to the file system could possibly read the contents of this temporary file while a user is editing it.

All users running an affected release should either upgrade or use one of the workarounds immediately.

Releases

The fixed releases are available at the normal locations.

Workarounds

To work around this issue, you can set your umask to be more restrictive like this:

$ umask 0077

🚨 Active Support Possibly Discloses Locally Encrypted Files

There is a possible file disclosure of locally encrypted files in Active Support. This vulnerability has been assigned the CVE identifier CVE-2023-38037.

Versions Affected: >= 5.2.0 Not affected: < 5.2.0 Fixed Versions: 7.0.7.1, 6.1.7.5

Impact

ActiveSupport::EncryptedFile writes contents that will be encrypted to a temporary file. The temporary file’s permissions are defaulted to the user’s current umask settings, meaning that it’s possible for other users on the same system to read the contents of the temporary file.

Attackers that have access to the file system could possibly read the contents of this temporary file while a user is editing it.

All users running an affected release should either upgrade or use one of the workarounds immediately.

Releases

The fixed releases are available at the normal locations.

Workarounds

To work around this issue, you can set your umask to be more restrictive like this:

$ umask 0077

🚨 Possible XSS Security Vulnerability in SafeBuffer#bytesplice

There is a vulnerability in ActiveSupport if the new bytesplice method is called on a SafeBuffer with untrusted user input.
This vulnerability has been assigned the CVE identifier CVE-2023-28120.

Versions Affected: All. Not affected: None Fixed Versions: 7.0.4.3, 6.1.7.3

Impact

ActiveSupport uses the SafeBuffer string subclass to tag strings as html_safe after they have been sanitized.
When these strings are mutated, the tag is should be removed to mark them as no longer being html_safe.

Ruby 3.2 introduced a new bytesplice method which ActiveSupport did not yet understand to be a mutation.
Users on older versions of Ruby are likely unaffected.

All users running an affected release and using bytesplice should either upgrade or use one of the workarounds immediately.

Workarounds

Avoid calling bytesplice on a SafeBuffer (html_safe) string with untrusted user input.

🚨 Possible XSS Security Vulnerability in SafeBuffer#bytesplice

There is a vulnerability in ActiveSupport if the new bytesplice method is called on a SafeBuffer with untrusted user input.
This vulnerability has been assigned the CVE identifier CVE-2023-28120.

Versions Affected: All. Not affected: None Fixed Versions: 7.0.4.3, 6.1.7.3

Impact

ActiveSupport uses the SafeBuffer string subclass to tag strings as html_safe after they have been sanitized.
When these strings are mutated, the tag is should be removed to mark them as no longer being html_safe.

Ruby 3.2 introduced a new bytesplice method which ActiveSupport did not yet understand to be a mutation.
Users on older versions of Ruby are likely unaffected.

All users running an affected release and using bytesplice should either upgrade or use one of the workarounds immediately.

Workarounds

Avoid calling bytesplice on a SafeBuffer (html_safe) string with untrusted user input.

🚨 ReDoS based DoS vulnerability in Active Support's underscore

There is a possible regular expression based DoS vulnerability in Active Support. This vulnerability has been assigned the CVE identifier CVE-2023-22796.

Versions Affected: All Not affected: None Fixed Versions: 5.2.8.15 (Rails LTS, which is a paid service and not part of the rubygem), 6.1.7.1, 7.0.4.1
Impact

A specially crafted string passed to the underscore method can cause the regular expression engine to enter a state of catastrophic backtracking. This can cause the process to use large amounts of CPU and memory, leading to a possible DoS vulnerability.

This affects String#underscore, ActiveSupport::Inflector.underscore, String#titleize, and any other methods using these.

All users running an affected release should either upgrade or use one of the workarounds immediately.
Releases

The FIXED releases are available at the normal locations.
Workarounds

There are no feasible workarounds for this issue.

Users on Ruby 3.2.0 or greater may be able to reduce the impact by configuring Regexp.timeout.
Patches

To aid users who aren’t able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.

6-1-Avoid-regex-backtracking-in-Inflector.underscore.patch - Patch for 6.1 series
7-0-Avoid-regex-backtracking-in-Inflector.underscore.patch - Patch for 7.0 series

Please note that only the 7.0.Z and 6.1.Z series are supported at present, and 6.0.Z for severe vulnerabilities. Users of earlier unsupported releases are advised to upgrade as soon as possible as we cannot guarantee the continued availability of security fixes for unsupported releases.

🚨 ReDoS based DoS vulnerability in Active Support's underscore

There is a possible regular expression based DoS vulnerability in Active Support. This vulnerability has been assigned the CVE identifier CVE-2023-22796.

Versions Affected: All Not affected: None Fixed Versions: 5.2.8.15 (Rails LTS, which is a paid service and not part of the rubygem), 6.1.7.1, 7.0.4.1
Impact

A specially crafted string passed to the underscore method can cause the regular expression engine to enter a state of catastrophic backtracking. This can cause the process to use large amounts of CPU and memory, leading to a possible DoS vulnerability.

This affects String#underscore, ActiveSupport::Inflector.underscore, String#titleize, and any other methods using these.

All users running an affected release should either upgrade or use one of the workarounds immediately.
Releases

The FIXED releases are available at the normal locations.
Workarounds

There are no feasible workarounds for this issue.

Users on Ruby 3.2.0 or greater may be able to reduce the impact by configuring Regexp.timeout.
Patches

To aid users who aren’t able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.

6-1-Avoid-regex-backtracking-in-Inflector.underscore.patch - Patch for 6.1 series
7-0-Avoid-regex-backtracking-in-Inflector.underscore.patch - Patch for 7.0 series

Please note that only the 7.0.Z and 6.1.Z series are supported at present, and 6.0.Z for severe vulnerabilities. Users of earlier unsupported releases are advised to upgrade as soon as possible as we cannot guarantee the continued availability of security fixes for unsupported releases.

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ builder (indirect, 3.2.4 → 3.3.0) · Repo · Changelog

Commits

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

↗️ concurrent-ruby (indirect, 1.1.9 → 1.3.5) · Repo · Changelog

Release Notes

1.3.5

What's Changed

New Contributors

Full Changelog: v1.3.4...v1.3.5

1.3.4

What's Changed

  • Update comment for JRuby variant of processor_count to reality by @meineerde in #1054
  • Add Concurrent.cpu_requests that is cgroups aware. by @heka1024 in #1058
  • Fix the doc of Concurrent.available_processor_count by @y-yagi in #1059
  • Fix the return value of Concurrent.available_processor_count when cpu.cfs_quota_us is -1 by @y-yagi in #1060

New Contributors

Full Changelog: v1.3.3...v1.3.4

1.3.3

What's Changed

Full Changelog: v1.3.2...v1.3.3

1.3.2

What's Changed

New Contributors

Full Changelog: v1.3.1...v1.3.2

1.3.1

This release is essentially v1.3.0, but with a properly packaged gem. There was an issue publishing v1.3.0 and that gem needed to be yanked to avoid breaking downstream projects. The v1.3.0 changelog is reproduced below.

What's Changed

  • Add Concurrent.usable_processor_count that is cgroups aware by @casperisfine in #1038
  • Align Java Executor Service behavior for shuttingdown?, shutdown? by @bensheldon in #1042

New Contributors

Full Changelog: v1.2.3...v1.3.1

1.2.3

What's Changed

New Contributors

Full Changelog: v1.2.2...v1.2.3

1.2.2

concurrent-ruby 1.2.2:

  • (#993) Fix arguments passed to Concurrent::Map's default_proc.

1.2.1

concurrent-ruby 1.2.1:

  • (#990) Add missing require 'fiber' for FiberLocalVar.
  • (#989) Optimize Concurrent::Map#[] on CRuby by letting the backing Hash handle the default_proc.

1.2.0

concurrent-ruby 1.2.0:

  • (#975) Set the Ruby compatibility version at 2.3
  • (#962) Fix ReentrantReadWriteLock to use the same granularity for locals as for Mutex it uses.
  • (#983) Add FiberLocalVar
  • (#934) concurrent-ruby now supports requiring individual classes (public classes listed in the docs), e.g., require 'concurrent/map'
  • (#976) Let Promises.any_fulfilled_future take an Event
  • Improve documentation of various classes
  • (#972) Remove Rubinius-related code

concurrent-ruby-edge 0.7.0:

  • (#975) Set the Ruby compatibility version at 2.3
  • (#934) concurrent-ruby now supports requiring individual classes (public classes listed in the docs), e.g., require 'concurrent/map'
  • (#972) Remove Rubinius-related code

1.1.10

concurrent-ruby:

  • (#951) Set the Ruby compatibility version at 2.2
  • (#939, #933) The caller_runs fallback policy no longer blocks reads from the job queue by worker threads
  • (#938, #761, #652) You can now explicitly prune_pool a thread pool (Sylvain Joyeux)
  • (#937, #757, #670) We switched the Yahoo stock API for demos to Alpha Vantage (Gustavo Caso)
  • (#932, #931) We changed how SafeTaskExecutor handles local jump errors (Aaron Jensen)
  • (#927) You can use keyword arguments in your initialize when using Async (Matt Larraz)
  • (#926, #639) We removed timeout from TimerTask because it wasn't sound, and now it's a no-op with a warning (Jacob Atzen)
  • (#919) If you double-lock a re-entrant read-write lock, we promote to locked for writing (zp yuan)
  • (#915) monotonic_time now accepts an optional unit parameter, as Ruby's clock_gettime (Jean Boussier)

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

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ erubi (indirect, 1.10.0 → 1.13.1) · Repo · Changelog

Release Notes

1.13.1 (from changelog)

* Avoid spurious frozen string literal warnings for chilled strings when using Ruby 3.4 (jeremyevans)

1.13.0 (from changelog)

* Define Erubi.h as a module function (jeremyevans)

* Add erubi/capture_block, supporting capturing block output via standard <%= and <%== tags (jeremyevans)

1.12.0 (from changelog)

* Use erb/escape for faster html escaping if available (jeremyevans)

* Default :freeze_template_literals option to false if running with --enable-frozen-string-literal (casperisfine) (#35)

1.11.0 (from changelog)

* Support :freeze_template_literals option for configuring whether to add .freeze to template literal strings (casperisfine) (#33)

* Support :chain_appends option for chaining appends to the buffer variable (casperisfine, jeremyevans) (#32)

* Avoid unnecessary defined? usage on Ruby 3+ when using the :ensure option (jeremyevans)

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

Commits

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

↗️ globalid (indirect, 1.0.0 → 1.2.1) · Repo · Changelog

Security Advisories 🚨

🚨 ReDoS based DoS vulnerability in GlobalID

There is a ReDoS based DoS vulnerability in the GlobalID gem. This vulnerability has been assigned the CVE identifier CVE-2023-22799.

Versions Affected: >= 0.2.1 Not affected: NOTAFFECTED Fixed Versions: 1.0.1
Impact

There is a possible DoS vulnerability in the model name parsing section of the GlobalID gem. Carefully crafted input can cause the regular expression engine to take an unexpected amount of time. All users running an affected release should either upgrade or use one of the workarounds immediately.
Releases

The FIXED releases are available at the normal locations.
Workarounds

There are no feasible workarounds for this issue.
Patches

To aid users who aren’t able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.

1-0-model-name-redos.patch - Patch for 1.0 series
Release Notes

1.2.0

What's Changed

New Contributors

Full Changelog: v1.1.0...v1.2.0

1.1.0

What's Changed

New Contributors

Full Changelog: v1.0.1...v1.1.0

1.0.1

Possible ReDoS based DoS vulnerability in GlobalID

There is a ReDoS based DoS vulnerability in the GlobalID gem. This
vulnerability has been assigned the CVE identifier CVE-2023-22799.

Versions Affected: >= 0.2.1
Not affected: NOTAFFECTED
Fixed Versions: 1.0.1

Impact

There is a possible DoS vulnerability in the model name parsing section of the
GlobalID gem. Carefully crafted input can cause the regular expression engine
to take an unexpected amount of time. All users running an affected release
should either upgrade or use one of the workarounds immediately.

Releases

The FIXED releases are available at the normal locations.

Workarounds

There are no feasible workarounds for this issue.

Credits

Thank you ooooooo_k for reporting this!

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

Commits

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

↗️ i18n (indirect, 1.10.0 → 1.14.7) · Repo · Changelog

Release Notes

1.14.7

What's Changed

  • Ruby 3.4 Hash#inspect compatibility. by @voxik in #709
  • Removed (annoying) post-install message that was triggering on all Rubies, rather than the specified versions.

Full Changelog: v1.14.6...v1.14.7

1.14.6

What's Changed

Ruby < 3.2 support will be dropped April 2025. Upgrade now to continue using i18n after that date.

New Contributors

Full Changelog: v1.14.5...v1.14.6

1.14.5

What's Changed

  • Explicitly bundle racc gem for Ruby 3.3+ by @amatsuda in #690
  • Optimize I18n::Locale::Fallbacks#[] for recursive locale mappings by @uiur in #692
  • Add I18n.interpolation_keys by @tom-lord in #682
  • Fix syntax in documentation for I18n::Backend::Base.interpolate by @tom-lord in #691
  • Fix that escaped interpolations with reserved keywords raised ReservedInterpolationKey by @Bilka2 in #688

New Contributors

Full Changelog: v1.14.4...v1.14.5

1.14.4

What's Changed

Note: the racc dependency will be coming back in Version 2.

  • undo strict racc dependency on this branch by @radar in #687

Full Changelog: v1.14.3...v1.14.4

1.14.3

What's Changed

  • Pass options to along to exists? super calls by @radar in #671
  • Improve TOKENIZER by 23% by @kbrock in #668
  • Regex part deux - INTERPOLATION_SYNTAX by @kbrock in #669
  • Raise when translated entry contains interpolations for reserved keywords and no substitutions provided by @fatkodima in #678
  • Implement Fallbacks#inspect and Fallbacks#empty? by @fatkodima in #683

Upkeep

New Contributors

Full Changelog: v1.14.1...v1.14.3

1.14.1

Included in this release

  • Simplify the "Translation missing" message when default is an empty Array by @amatsuda in #662

Maintenance stuff

Thanks to @amatsuda for these PRs!

New Contributors

Full Changelog: v1.14.0...v1.14.1

1.14.0

What's Changed

  • fix LazyLoadable#available_locales duplicating locales by @ccutrer in #655
  • Add more helpful translation error when :default option is provided. by @Nerian in #654
  • Fix I18n::Locale::Fallbacks not initializing itself on Ruby 3 by @yheuhtozr in #653
  • Fix I18n.t when locale contains separator by @tubaxenor in #656
    • This reverts a change from #651, that was released in v1.13.0

New Contributors

Full Changelog: v1.13.0...v1.14.0

1.13.0

What's Changed

New Contributors

Full Changelog: v1.12.0...v1.13.0

1.12.0

What's Changed

  • Revert "Add support for CLDR data in I18n::Backend::Pluralization" by @radar in #633 -- this was causing breaking changes unintentionally.

Full Changelog: v1.11.0...v1.12.0

1.11.0

What's Changed

New Contributors

Full Changelog: v1.10.0...v1.11.0

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

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ loofah (indirect, 2.19.1 → 2.24.1) · Repo · Changelog

Release Notes

2.24.1

2.24.1 / 2025-05-12

Ruby support

  • Import only what's needed from cgi for support for Ruby 3.5 #296 @Earlopain

2.24.0

2.24.0 / 2024-12-24

Added

Improved

  • Built-in scrubber :targetblank now skips a tags whose href attribute is an anchor link. Previously, all a tags were modified to have target='_blank'. #291 @fnando

New Contributors

Full Changelog: v2.23.1...v2.24.0

2.23.1

2.23.1 / 2024-10-25

Added

  • Allow CSS properties min-height and max-height. [#288] @lazyatom

Full Changelog: v2.23.0...v2.23.1

2.23.0

2.23.0 / 2024-10-24

Added

New Contributors

Full Changelog: v2.22.0...v2.23.0

2.22.0

2.22.0 / 2023-11-13

Added

  • A :targetblank HTML scrubber which ensures all hyperlinks have target="_blank". [#275] @stefannibrasil and @thdaraujo
  • A :noreferrer HTML scrubber which ensures all hyperlinks have rel=noreferrer, similar to the :nofollow and :noopener scrubbers. [#277] @wynksaiddestroy

2.21.4

2.21.4 / 2023-10-10

Fixed

  • Loofah::HTML5::Scrub.scrub_css is more consistent in preserving whitespace (and lack of whitespace) in CSS property values. In particular, .scrub_css no longer inserts whitespace between tokens that did not already have whitespace between them. [#273, fixes #271]

2.21.3

2.21.3 / 2023-05-15

  • Quash "instance variable not initialized" warning in Ruby < 3.0. [#268] (Thanks, @dharamgollapudi!)

2.21.2

2.21.2 / 2023-05-11

Dependencies

  • Update the dependency on Nokogiri to be >= 1.12.0. The dependency in 2.21.0 and 2.21.1 was left at >= 1.5.9 but versions before 1.12 would result in a NameError exception. [#266]

2.21.1

2.21.1 / 2023-05-10

Fixed

  • Don't define HTML5::Document and HTML5::DocumentFragment when Nokogiri is < 1.14. In 2.21.0 these classes were defined whenever Nokogiri::HTML5 was defined, but Nokogiri v1.12 and v1.13 do not support Loofah subclassing properly.

2.21.0

2.21.0 / 2023-05-10

HTML5 Support

Classes Loofah::HTML5::Document and Loofah::HTML5::DocumentFragment are introduced, along with helper methods:

  • Loofah.html5_document
  • Loofah.html5_fragment
  • Loofah.scrub_html5_document
  • Loofah.scrub_html5_fragment

These classes and methods use Nokogiri's HTML5 parser to ensure modern web standards are used.

⚠ HTML5 functionality is only available with Nokogiri v1.14.0 and higher.

⚠ HTML5 functionality is not available for JRuby. Please see this upstream Nokogiri issue if you're interested in helping implement and support HTML5 support.

Loofah::HTML4 module and namespace

Loofah::HTML has been renamed to Loofah::HTML4, and Loofah::HTML is aliased to preserve backwards-compatibility. Nokogiri::HTML and Nokogiri::HTML4 parse methods still use libxml2's (or NekoHTML's) HTML4 parser.

Take special note that if you rely on the class name of an object in your code, objects will now report a class of Loofah::HTML4::Foo where they previously reported Loofah::HTML::Foo. Instead of relying on the string returned by Object#class, prefer Class#=== or Object#is_a? or Object#instance_of?.

Future releases of Nokogiri may deprecate HTML classes and methods or otherwise change this behavior, so please start using HTML4 in place of HTML.

Official support for JRuby

This version introduces official support for JRuby. Previously, the test suite had never been green due to differences in behavior in the underlying HTML parser used by Nokogiri. We've updated the test suite to accommodate those differences, and have added JRuby to the CI suite.

2.20.0

2.20.0 / 2023-04-01

Features

  • Allow SVG attributes color-profile, cursor, filter, marker, and mask. [#246]
  • Allow SVG elements altGlyph, cursor, feImage, pattern, and tref. [#246]
  • Allow protocols fax and modem. [#255] (Thanks, @cjba7!)

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

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ mail (indirect, 2.7.1 → 2.8.1) · Repo · Changelog

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ marcel (indirect, 1.0.2 → 1.0.4) · Repo

Release Notes

1.0.4

What's Changed

  • Regression fix: binary declared type should fall back to filename extension type by @jeremy in #99

Full Changelog: v1.0.3...v1.0.4

1.0.3

What's Changed

New Contributors

Full Changelog: v1.0.2...v1.0.3

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

Commits

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

↗️ mini_mime (indirect, 1.1.2 → 1.1.5) · Repo · Changelog

Commits

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

↗️ mini_portile2 (indirect, 2.8.0 → 2.8.9) · Repo · Changelog

Release Notes

2.8.9

2.8.9 / 2025-05-12

Ruby support

  • Import only what's needed from cgi, for supporting Ruby 3.5. #160 @Earlopain

New Contributors

Full Changelog: v2.8.8...v2.8.9

2.8.8

2.8.8 / 2024-11-14

Improved

  • Raise an exception with a clear error message when xzcat is needed but is not installed. (#152) @flavorjones

2.8.7

2.8.7 / 2024-05-31

Added

  • When setting the C compiler through the MiniPortile constructor, the preferred keyword argument is now :cc_command. The original :gcc_command is still supported. (#144 by @flavorjones)
  • Add support for extracting xz-compressed tarballs on OpenBSD. (#141 by @postmodern)
  • Add OpenBSD support to the experimental method MakeMakefile#mkmf_config. (#141 by @flavorjones)

Changed

  • MiniPortileCMake now detects the C and C++ compiler the same way MiniPortile does: by examining environment variables, then using kwargs, then looking in RbConfig (in that order). (#144 by @flavorjones)
  • GPG file verification error messages are captured in the raised exception. Previously these errors went to stderr. (#145 by @flavorjones)

2.8.6

2.8.6 / 2024-04-14

Added

  • When using CMake on FreeBSD, default to clang's "cc" and "c++" compilers. (#139 by @mudge)

2.8.5

2.8.5 / 2023-10-22

Added

  • New methods #lib_path and #include_path which point at the installed directories under ports. (by @flavorjones)
  • Add config param for CMAKE_BUILD_TYPE, which now defaults to Release. (#136 by @Watson1978)

Experimental

Introduce experimental support for MiniPortile#mkmf_config which sets up MakeMakefile variables to properly link against the recipe. This should make it easier for C extensions to package third-party libraries. (by @flavorjones)

  • With no arguments, will set up just $INCFLAGS, $libs, and $LIBPATH.
  • Optionally, if provided a pkg-config file, will use that config to more precisely set $INCFLAGS, $libs, $LIBPATH, and $CFLAGS/$CXXFLAGS.
  • Optionally, if provided the name of a static archive, will rewrite linker flags to ensure correct linkage.

Note that the behavior may change slightly before official support is announced. Please comment on #118 if you have feedback.

2.8.4

2.8.4 / 2023-07-18

  • cmake: set CMAKE compile flags to configure cross-compilation similarly to autotools --host flag: SYSTEM_NAME, SYSTEM_PROCESSOR, C_COMPILER, and CXX_COMPILER. [#130] (Thanks, @stanhu!)

2.8.3

2.8.3 / 2023-07-18

Fixed

  • cmake: only use MSYS/NMake generators when available. [#129] (Thanks, @stanhu!)

2.8.2

2.8.2 / 2023-04-30

Fixed

  • Ensure that the source_directory option will work when given a Windows path to an autoconf directory. [#126]

2.8.1

2.8.1 / 2022-12-24

Fixed

  • Support applying patches via git apply even when the working directory resembles a git directory. [#119] (Thanks, @h0tw1r3!)

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

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ nio4r (indirect, 2.5.8 → 2.7.4) · Repo · Changelog

Release Notes

2.7.2 (from changelog)

  • Modernize gem (list all authors, etc).
  • Drop official support for Ruby 2.4.
  • Fix JRuby release version.

2.7.1

What's Changed

Full Changelog: v2.7.0...v2.7.1

2.7.0

What's Changed

New Contributors

Full Changelog: v2.6.1...v2.7.0

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

Commits

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

↗️ nokogiri (indirect, 1.13.10 → 1.18.9) · Repo · Changelog

Security Advisories 🚨

🚨 Nokogiri patches vendored libxml2 to resolve multiple CVEs

Summary

Nokogiri v1.18.9 patches the vendored libxml2 to address CVE-2025-6021, CVE-2025-6170, CVE-2025-49794, CVE-2025-49795, and CVE-2025-49796.

Impact and severity

CVE-2025-6021

A flaw was found in libxml2's xmlBuildQName function, where integer overflows in buffer size calculations can lead to a stack-based buffer overflow. This issue can result in memory corruption or a denial of service when processing crafted input.

NVD claims a severity of 7.5 High (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

Fixed by applying https://gitlab.gnome.org/GNOME/libxml2/-/commit/17d950ae

CVE-2025-6170

A flaw was found in the interactive shell of the xmllint command-line tool, used for parsing XML files. When a user inputs an overly long command, the program does not check the input size properly, which can cause it to crash. This issue might allow attackers to run harmful code in rare configurations without modern protections.

NVD claims a severity of 2.5 Low (CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L)

Fixed by applying https://gitlab.gnome.org/GNOME/libxml2/-/commit/5e9ec5c1

CVE-2025-49794

A use-after-free vulnerability was found in libxml2. This issue occurs when parsing XPath elements under certain circumstances when the XML schematron has the <sch:name path="..."/> schema elements. This flaw allows a malicious actor to craft a malicious XML document used as input for libxml, resulting in the program's crash using libxml or other possible undefined behaviors.

NVD claims a severity of 9.1 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H)

Fixed by applying https://gitlab.gnome.org/GNOME/libxml2/-/commit/81cef8c5

CVE-2025-49795

A NULL pointer dereference vulnerability was found in libxml2 when processing XPath XML expressions. This flaw allows an attacker to craft a malicious XML input to libxml2, leading to a denial of service.

NVD claims a severity of 7.5 High (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

Fixed by applying https://gitlab.gnome.org/GNOME/libxml2/-/commit/62048278

CVE-2025-49796

A vulnerability was found in libxml2. Processing certain sch:name elements from the input XML file can trigger a memory corruption issue. This flaw allows an attacker to craft a malicious XML input file that can lead libxml to crash, resulting in a denial of service or other possible undefined behavior due to sensitive data being corrupted in memory.

NVD claims a severity of 9.1 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H)

Fixed by applying https://gitlab.gnome.org/GNOME/libxml2/-/commit/81cef8c5

Affected Versions

  • Nokogiri < 1.18.9 when using CRuby (MRI) with vendored libxml2

Patched Versions

  • Nokogiri >= 1.18.9

Mitigation

Upgrade to Nokogiri v1.18.9 or later.

Users who are unable to upgrade Nokogiri may also choose a more complicated mitigation: compile and link Nokogiri against patched external libxml2 libraries which will also address these same issues.

References

🚨 Nokogiri updates packaged libxml2 to v2.13.8 to resolve CVE-2025-32414 and CVE-2025-32415

Summary

Nokogiri v1.18.8 upgrades its dependency libxml2 to v2.13.8.

libxml2 v2.13.8 addresses:

Impact

CVE-2025-32414: No impact

In libxml2 before 2.13.8 and 2.14.x before 2.14.2, out-of-bounds memory access can occur in the Python API (Python bindings) because of an incorrect return value. This occurs in xmlPythonFileRead and xmlPythonFileReadRaw because of a difference between bytes and characters.

There is no impact from this CVE for Nokogiri users.

CVE-2025-32415: Low impact

In libxml2 before 2.13.8 and 2.14.x before 2.14.2, xmlSchemaIDCFillNodeTables in xmlschemas.c has a heap-based buffer under-read. To exploit this, a crafted XML document must be validated against an XML schema with certain identity constraints, or a crafted XML schema must be used.

In the upstream issue, further context is provided by the maintainer:

The bug affects validation against untrusted XML Schemas (.xsd) and validation of untrusted
documents against trusted Schemas if they make use of xsd:keyref in combination with recursively
defined types that have additional identity constraints.

MITRE has published a severity score of 2.9 LOW (CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L) for this CVE.

🚨 Nokogiri updates packaged libxslt to v1.1.43 to resolve multiple CVEs

Summary

Nokogiri v1.18.4 upgrades its dependency libxslt to v1.1.43.

libxslt v1.1.43 resolves:

Impact

CVE-2025-24855

CVE-2024-55549

🚨 Nokogiri updates packaged libxml2 to 2.13.6 to resolve CVE-2025-24928 and CVE-2024-56171

Summary

Nokogiri v1.18.3 upgrades its dependency libxml2 to v2.13.6.

libxml2 v2.13.6 addresses:

Impact

CVE-2025-24928

Stack-buffer overflow is possible when reporting DTD validation errors if the input contains a long (~3kb) QName prefix.

CVE-2024-56171

Use-after-free is possible during validation against untrusted XML Schemas (.xsd) and, potentially, validation of untrusted documents against trusted Schemas if they make use of xsd:keyref in combination with recursively defined types that have additional identity constraints.

🚨 Nokogiri updates packaged libxml2 to v2.12.7 to resolve CVE-2024-34459

Summary

Nokogiri v1.16.5 upgrades its dependency libxml2 to 2.12.7 from 2.12.6.

libxml2 v2.12.7 addresses CVE-2024-34459:

Impact

There is no impact to Nokogiri users because the issue is present only in libxml2's xmllint tool which Nokogiri does not provide or expose.

Timeline

  • 2024-05-13 05:57 EDT, libxml2 2.12.7 release is announced
  • 2024-05-13 08:30 EDT, nokogiri maintainers begin triage
  • 2024-05-13 10:05 EDT, nokogiri v1.16.5 is released and this GHSA made public

🚨 Nokogiri update packaged libxml2 to v2.12.5 to resolve CVE-2024-25062

Summary

Nokogiri upgrades its dependency libxml2 as follows:

  • Nokogiri v1.15.6 upgrades libxml2 to 2.11.7 from 2.11.6
  • Nokogiri v1.16.2 upgrades libxml2 to 2.12.5 from 2.12.4

libxml2 v2.11.7 and v2.12.5 address the following vulnerability:

Please note that this advisory only applies to the CRuby implementation of Nokogiri, and only if the packaged libraries are being used. If you've overridden defaults at installation time to use system libraries instead of packaged libraries, you should instead pay attention to your distro's libxml2 release announcements.

JRuby users are not affected.

Mitigation

Upgrade to Nokogiri ~> 1.15.6 or >= 1.16.2.

Users who are unable to upgrade Nokogiri may also choose a more complicated mitigation: compile
and link Nokogiri against patched external libxml2 libraries which will also address these same
issues.

Impact

From the CVE description, this issue applies to the xmlTextReader module (which underlies Nokogiri::XML::Reader):

When using the XML Reader interface with DTD validation and XInclude expansion enabled, processing crafted XML documents can lead to an xmlValidatePopElement use-after-free.

Timeline

  • 2024-02-04 10:35 EST - this GHSA is drafted without complete details about when the upstream issue was introduced; a request is made of libxml2 maintainers for more detailed information
  • 2024-02-04 10:48 EST - updated GHSA to reflect libxml2 maintainers' confirmation of affected versions
  • 2024-02-04 11:54 EST - v1.16.2 published, this GHSA made public
  • 2024-02-05 10:18 EST - updated with MITRE link to the CVE information, and updated "Impact" section
  • 2024-03-16 09:03 EDT - v1.15.6 published (see discussion at #3146), updated mitigation information
  • 2024-03-18 22:12 EDT - update "affected products" range with v1.15.6 information

🚨 Nokogiri update packaged libxml2 to v2.12.5 to resolve CVE-2024-25062

Summary

Nokogiri upgrades its dependency libxml2 as follows:

  • Nokogiri v1.15.6 upgrades libxml2 to 2.11.7 from 2.11.6
  • Nokogiri v1.16.2 upgrades libxml2 to 2.12.5 from 2.12.4

libxml2 v2.11.7 and v2.12.5 address the following vulnerability:

Please note that this advisory only applies to the CRuby implementation of Nokogiri, and only if the packaged libraries are being used. If you've overridden defaults at installation time to use system libraries instead of packaged libraries, you should instead pay attention to your distro's libxml2 release announcements.

JRuby users are not affected.

Mitigation

Upgrade to Nokogiri ~> 1.15.6 or >= 1.16.2.

Users who are unable to upgrade Nokogiri may also choose a more complicated mitigation: compile
and link Nokogiri against patched external libxml2 libraries which will also address these same
issues.

Impact

From the CVE description, this issue applies to the xmlTextReader module (which underlies Nokogiri::XML::Reader):

When using the XML Reader interface with DTD validation and XInclude expansion enabled, processing crafted XML documents can lead to an xmlValidatePopElement use-after-free.

Timeline

  • 2024-02-04 10:35 EST - this GHSA is drafted without complete details about when the upstream issue was introduced; a request is made of libxml2 maintainers for more detailed information
  • 2024-02-04 10:48 EST - updated GHSA to reflect libxml2 maintainers' confirmation of affected versions
  • 2024-02-04 11:54 EST - v1.16.2 published, this GHSA made public
  • 2024-02-05 10:18 EST - updated with MITRE link to the CVE information, and updated "Impact" section
  • 2024-03-16 09:03 EDT - v1.15.6 published (see discussion at #3146), updated mitigation information
  • 2024-03-18 22:12 EDT - update "affected products" range with v1.15.6 information

🚨 Nokogiri updates packaged libxml2 to v2.10.4 to resolve multiple CVEs

Summary

Nokogiri v1.14.3 upgrades the packaged version of its dependency libxml2 to v2.10.4 from v2.10.3.

libxml2 v2.10.4 addresses the following known vulnerabilities:

  • CVE-2023-29469: Hashing of empty dict strings isn't deterministic
  • CVE-2023-28484: Fix null deref in xmlSchemaFixupComplexType
  • Schemas: Fix null-pointer-deref in xmlSchemaCheckCOSSTDerivedOK

Please note that this advisory only applies to the CRuby implementation of Nokogiri < 1.14.3, and only if the packaged libraries are being used. If you've overridden defaults at installation time to use system libraries instead of packaged libraries, you should instead pay attention to your distro's libxml2 release announcements.

Mitigation

Upgrade to Nokogiri >= 1.14.3.

Users who are unable to upgrade Nokogiri may also choose a more complicated mitigation: compile and link Nokogiri against external libraries libxml2 >= 2.10.4 which will also address these same issues.

Impact

No public information has yet been published about the security-related issues other than the upstream commits. Examination of those changesets indicate that the more serious issues relate to libxml2 dereferencing NULL pointers and potentially segfaulting while parsing untrusted inputs.

The commits can be examined at:

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ racc (indirect, 1.6.1 → 1.8.1) · Repo · Changelog

Release Notes

1.8.1

What's Changed

New Contributors

Full Changelog: v1.8.0...v1.8.1

1.8.0

What's Changed

  • Generate jar to build gem by @nobu in #255
  • Fix trivial typos by @ydah in #257
  • Try to fix test failure with Ruby 3.3 by @hsbt in #260
  • Reformat the rdoc so it renders correctly both locally and on github. by @zenspider in #258
  • Allow racc cmdline to read from stdin if no path specified. by @zenspider in #259
  • Add more grammars by @nurse in #222
  • Exclude 2.5 on macos-latest by @nobu in #263
  • Drop code for Ruby 1.6 by @nobu in #264
  • Refactor command line options by @nobu in #265
  • Change encode EUC-JP to UTF-8 by @ydah in #267
  • Organize README.ja.rdoc by @ydah in #266
  • Support error_on_expect_mismatch declaration in Racc grammar file by @yui-knk in #262
  • Bump up v1.8.0 by @yui-knk in #268

New Contributors

Full Changelog: v1.7.3...v1.8.0

1.7.3

What's Changed

Full Changelog: v1.7.2...v1.7.3

1.7.2

What's Changed

New Contributors

Full Changelog: v1.7.1...v1.7.2

1.7.1

What's Changed

  • Use released version of test-unit-ruby-core by @hsbt in #220
  • Fix place to specify rake-compiler version by @nobu in #223
  • Embedded path by @nobu in #221

Full Changelog: v1.7.0...v1.7.1

1.7.0

What's Changed

New Contributors

Full Changelog: v1.6.2...v1.7.0

1.6.2

What's Changed

Full Changelog: v1.6.1...v1.6.2

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

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ rack (indirect, 2.2.6.4 → 3.2.0) · Repo · Changelog

Security Advisories 🚨

🚨 ReDoS Vulnerability in Rack::Multipart handle_mime_head

Summary

There is a denial of service vulnerability in the Content-Disposition parsing component of Rack. This is very similar to the previous security issue CVE-2022-44571.

Details

Carefully crafted input can cause Content-Disposition header parsing in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. This header is used typically used in multipart parsing. Any applications that parse multipart posts using Rack (virtually all Rails applications) are impacted.

Credits

Thanks to scyoon for reporting this to the Rails security team

🚨 Rack session gets restored after deletion

Summary

When using the Rack::Session::Pool middleware, simultaneous rack requests can restore a deleted rack session, which allows the unauthenticated user to occupy that session.

Details

Rack session middleware prepares the session at the beginning of request, then saves is back to the store with possible changes applied by host rack application. This way the session becomes to be a subject of race conditions in general sense over concurrent rack requests.

Impact

When using the Rack::Session::Pool middleware, and provided the attacker can acquire a session cookie (already a major issue), the session may be restored if the attacker can trigger a long running request (within that same session) adjacent to the user logging out, in order to retain illicit access even after a user has attempted to logout.

Mitigation

  • Update to the latest version of rack, or
  • Ensure your application invalidates sessions atomically by marking them as logged out e.g., using a logged_out flag, instead of deleting them, and check this flag on every request to prevent reuse, or
  • Implement a custom session store that tracks session invalidation timestamps and refuses to accept session data if the session was invalidated after the request began.

Related

As this code was moved to rack-session in Rack 3+, see GHSA-9j94-67jr-4cqj for the equivalent advisory in rack-session (affecting Rack 3+ only).

🚨 Rack has an Unbounded-Parameter DoS in Rack::QueryParser

Summary

Rack::QueryParser parses query strings and application/x-www-form-urlencoded bodies into Ruby data structures without imposing any limit on the number of parameters, allowing attackers to send requests with extremely large numbers of parameters.

Details

The vulnerability arises because Rack::QueryParser iterates over each &-separated key-value pair and adds it to a Hash without enforcing an upper bound on the total number of parameters. This allows an attacker to send a single request containing hundreds of thousands (or more) of parameters, which consumes excessive memory and CPU during parsing.

Impact

An attacker can trigger denial of service by sending specifically crafted HTTP requests, which can cause memory exhaustion or pin CPU resources, stalling or crashing the Rack server. This results in full service disruption until the affected worker is restarted.

Mitigation

  • Update to a version of Rack that limits the number of parameters parsed, or
  • Use middleware to enforce a maximum query string size or parameter count, or
  • Employ a reverse proxy (such as Nginx) to limit request sizes and reject oversized query strings or bodies.

Limiting request body sizes and query string lengths at the web server or CDN level is an effective mitigation.

🚨 Rack has an Unbounded-Parameter DoS in Rack::QueryParser

Summary

Rack::QueryParser parses query strings and application/x-www-form-urlencoded bodies into Ruby data structures without imposing any limit on the number of parameters, allowing attackers to send requests with extremely large numbers of parameters.

Details

The vulnerability arises because Rack::QueryParser iterates over each &-separated key-value pair and adds it to a Hash without enforcing an upper bound on the total number of parameters. This allows an attacker to send a single request containing hundreds of thousands (or more) of parameters, which consumes excessive memory and CPU during parsing.

Impact

An attacker can trigger denial of service by sending specifically crafted HTTP requests, which can cause memory exhaustion or pin CPU resources, stalling or crashing the Rack server. This results in full service disruption until the affected worker is restarted.

Mitigation

  • Update to a version of Rack that limits the number of parameters parsed, or
  • Use middleware to enforce a maximum query string size or parameter count, or
  • Employ a reverse proxy (such as Nginx) to limit request sizes and reject oversized query strings or bodies.

Limiting request body sizes and query string lengths at the web server or CDN level is an effective mitigation.

🚨 Rack has an Unbounded-Parameter DoS in Rack::QueryParser

Summary

Rack::QueryParser parses query strings and application/x-www-form-urlencoded bodies into Ruby data structures without imposing any limit on the number of parameters, allowing attackers to send requests with extremely large numbers of parameters.

Details

The vulnerability arises because Rack::QueryParser iterates over each &-separated key-value pair and adds it to a Hash without enforcing an upper bound on the total number of parameters. This allows an attacker to send a single request containing hundreds of thousands (or more) of parameters, which consumes excessive memory and CPU during parsing.

Impact

An attacker can trigger denial of service by sending specifically crafted HTTP requests, which can cause memory exhaustion or pin CPU resources, stalling or crashing the Rack server. This results in full service disruption until the affected worker is restarted.

Mitigation

  • Update to a version of Rack that limits the number of parameters parsed, or
  • Use middleware to enforce a maximum query string size or parameter count, or
  • Employ a reverse proxy (such as Nginx) to limit request sizes and reject oversized query strings or bodies.

Limiting request body sizes and query string lengths at the web server or CDN level is an effective mitigation.

🚨 Local File Inclusion in Rack::Static

Summary

Rack::Static can serve files under the specified root: even if urls: are provided, which may expose other files under the specified root: unexpectedly.

Details

The vulnerability occurs because Rack::Static does not properly sanitize user-supplied paths before serving files. Specifically, encoded path traversal sequences are not correctly validated, allowing attackers to access files outside the designated static file directory.

Impact

By exploiting this vulnerability, an attacker can gain access to all files under the specified root: directory, provided they are able to determine then path of the file.

Mitigation

  • Update to the latest version of Rack, or
  • Remove usage of Rack::Static, or
  • Ensure that root: points at a directory path which only contains files which should be accessed publicly.

It is likely that a CDN or similar static file server would also mitigate the issue.

🚨 Local File Inclusion in Rack::Static

Summary

Rack::Static can serve files under the specified root: even if urls: are provided, which may expose other files under the specified root: unexpectedly.

Details

The vulnerability occurs because Rack::Static does not properly sanitize user-supplied paths before serving files. Specifically, encoded path traversal sequences are not correctly validated, allowing attackers to access files outside the designated static file directory.

Impact

By exploiting this vulnerability, an attacker can gain access to all files under the specified root: directory, provided they are able to determine then path of the file.

Mitigation

  • Update to the latest version of Rack, or
  • Remove usage of Rack::Static, or
  • Ensure that root: points at a directory path which only contains files which should be accessed publicly.

It is likely that a CDN or similar static file server would also mitigate the issue.

🚨 Local File Inclusion in Rack::Static

Summary

Rack::Static can serve files under the specified root: even if urls: are provided, which may expose other files under the specified root: unexpectedly.

Details

The vulnerability occurs because Rack::Static does not properly sanitize user-supplied paths before serving files. Specifically, encoded path traversal sequences are not correctly validated, allowing attackers to access files outside the designated static file directory.

Impact

By exploiting this vulnerability, an attacker can gain access to all files under the specified root: directory, provided they are able to determine then path of the file.

Mitigation

  • Update to the latest version of Rack, or
  • Remove usage of Rack::Static, or
  • Ensure that root: points at a directory path which only contains files which should be accessed publicly.

It is likely that a CDN or similar static file server would also mitigate the issue.

🚨 Escape Sequence Injection vulnerability in Rack lead to Possible Log Injection

Summary

Rack::Sendfile can be exploited by crafting input that includes newline characters to manipulate log entries.

Details

The Rack::Sendfile middleware logs unsanitized header values from the X-Sendfile-Type header. An attacker can exploit this by injecting escape sequences (such as newline characters) into the header, resulting in log injection.

Impact

This vulnerability can distort log files, obscure attack traces, and complicate security auditing.

Mitigation

  • Update to the latest version of Rack, or
  • Remove usage of Rack::Sendfile.

🚨 Escape Sequence Injection vulnerability in Rack lead to Possible Log Injection

Summary

Rack::Sendfile can be exploited by crafting input that includes newline characters to manipulate log entries.

Details

The Rack::Sendfile middleware logs unsanitized header values from the X-Sendfile-Type header. An attacker can exploit this by injecting escape sequences (such as newline characters) into the header, resulting in log injection.

Impact

This vulnerability can distort log files, obscure attack traces, and complicate security auditing.

Mitigation

  • Update to the latest version of Rack, or
  • Remove usage of Rack::Sendfile.

🚨 Escape Sequence Injection vulnerability in Rack lead to Possible Log Injection

Summary

Rack::Sendfile can be exploited by crafting input that includes newline characters to manipulate log entries.

Details

The Rack::Sendfile middleware logs unsanitized header values from the X-Sendfile-Type header. An attacker can exploit this by injecting escape sequences (such as newline characters) into the header, resulting in log injection.

Impact

This vulnerability can distort log files, obscure attack traces, and complicate security auditing.

Mitigation

  • Update to the latest version of Rack, or
  • Remove usage of Rack::Sendfile.

🚨 Possible Log Injection in Rack::CommonLogger

Summary

Rack::CommonLogger can be exploited by crafting input that includes newline characters to manipulate log entries. The supplied proof-of-concept demonstrates injecting malicious content into logs.

Details

When a user provides the authorization credentials via Rack::Auth::Basic, if success, the username will be put in env['REMOTE_USER'] and later be used by Rack::CommonLogger for logging purposes.

The issue occurs when a server intentionally or unintentionally allows a user creation with the username contain CRLF and white space characters, or the server just want to log every login attempts. If an attacker enters a username with CRLF character, the logger will log the malicious username with CRLF characters into the logfile.

Impact

Attackers can break log formats or insert fraudulent entries, potentially obscuring real activity or injecting malicious data into log files.

Mitigation

  • Update to the latest version of Rack.

🚨 Possible Log Injection in Rack::CommonLogger

Summary

Rack::CommonLogger can be exploited by crafting input that includes newline characters to manipulate log entries. The supplied proof-of-concept demonstrates injecting malicious content into logs.

Details

When a user provides the authorization credentials via Rack::Auth::Basic, if success, the username will be put in env['REMOTE_USER'] and later be used by Rack::CommonLogger for logging purposes.

The issue occurs when a server intentionally or unintentionally allows a user creation with the username contain CRLF and white space characters, or the server just want to log every login attempts. If an attacker enters a username with CRLF character, the logger will log the malicious username with CRLF characters into the logfile.

Impact

Attackers can break log formats or insert fraudulent entries, potentially obscuring real activity or injecting malicious data into log files.

Mitigation

  • Update to the latest version of Rack.

🚨 Rack ReDoS Vulnerability in HTTP Accept Headers Parsing

Summary

A Regular Expression Denial of Service (ReDoS) vulnerability exists in the Rack::Request::Helpers module when parsing HTTP Accept headers. This vulnerability can be exploited by an attacker sending specially crafted Accept-Encoding or Accept-Language headers, causing the server to spend excessive time processing the request and leading to a Denial of Service (DoS).

Details

The fix for GHSA-54rr-7fvw-6x8f was not applied to the main branch and thus while the issue was fixed for the Rack v3.0 release series, it was not fixed in the v3.1 release series until v3.1.5.

🚨 Rack Header Parsing leads to Possible Denial of Service Vulnerability

Possible Denial of Service Vulnerability in Rack Header Parsing

There is a possible denial of service vulnerability in the header parsing
routines in Rack. This vulnerability has been assigned the CVE identifier
CVE-2024-26146.

Versions Affected: All.
Not affected: None
Fixed Versions: 2.0.9.4, 2.1.4.4, 2.2.8.1, 3.0.9.1

Impact

Carefully crafted headers can cause header parsing in Rack to take longer than
expected resulting in a possible denial of service issue. Accept and Forwarded
headers are impacted.

Ruby 3.2 has mitigations for this problem, so Rack applications using Ruby 3.2
or newer are unaffected.

Releases

The fixed releases are available at the normal locations.

Workarounds

There are no feasible workarounds for this issue.

Patches

To aid users who aren't able to upgrade immediately we have provided patches for
the two supported release series. They are in git-am format and consist of a
single changeset.

  • 2-0-header-redos.patch - Patch for 2.0 series
  • 2-1-header-redos.patch - Patch for 2.1 series
  • 2-2-header-redos.patch - Patch for 2.2 series
  • 3-0-header-redos.patch - Patch for 3.0 series

Credits

Thanks to svalkanov for reporting this and
providing patches!

🚨 Rack vulnerable to ReDoS in content type parsing (2nd degree polynomial)

Summary

module Rack
  class MediaType
    SPLIT_PATTERN = %r{\s*[;,]\s*}

The above regexp is subject to ReDos. 50K blank characters as a prefix to the header will take over 10s to split.

PoC

A simple HTTP request with lots of blank characters in the content-type header:

request["Content-Type"] = (" " * 50_000) + "a,"

Impact

It's a very easy to craft ReDoS. Like all ReDoS the impact is debatable.

🚨 Rack vulnerable to ReDoS in content type parsing (2nd degree polynomial)

Summary

module Rack
  class MediaType
    SPLIT_PATTERN = %r{\s*[;,]\s*}

The above regexp is subject to ReDos. 50K blank characters as a prefix to the header will take over 10s to split.

PoC

A simple HTTP request with lots of blank characters in the content-type header:

request["Content-Type"] = (" " * 50_000) + "a,"

Impact

It's a very easy to craft ReDoS. Like all ReDoS the impact is debatable.

🚨 Rack Header Parsing leads to Possible Denial of Service Vulnerability

Possible Denial of Service Vulnerability in Rack Header Parsing

There is a possible denial of service vulnerability in the header parsing
routines in Rack. This vulnerability has been assigned the CVE identifier
CVE-2024-26146.

Versions Affected: All.
Not affected: None
Fixed Versions: 2.0.9.4, 2.1.4.4, 2.2.8.1, 3.0.9.1

Impact

Carefully crafted headers can cause header parsing in Rack to take longer than
expected resulting in a possible denial of service issue. Accept and Forwarded
headers are impacted.

Ruby 3.2 has mitigations for this problem, so Rack applications using Ruby 3.2
or newer are unaffected.

Releases

The fixed releases are available at the normal locations.

Workarounds

There are no feasible workarounds for this issue.

Patches

To aid users who aren't able to upgrade immediately we have provided patches for
the two supported release series. They are in git-am format and consist of a
single changeset.

  • 2-0-header-redos.patch - Patch for 2.0 series
  • 2-1-header-redos.patch - Patch for 2.1 series
  • 2-2-header-redos.patch - Patch for 2.2 series
  • 3-0-header-redos.patch - Patch for 3.0 series

Credits

Thanks to svalkanov for reporting this and
providing patches!

🚨 Rack has possible DoS Vulnerability with Range Header

Possible DoS Vulnerability with Range Header in Rack

There is a possible DoS vulnerability relating to the Range request header in
Rack. This vulnerability has been assigned the CVE identifier CVE-2024-26141.

Versions Affected: >= 1.3.0.
Not affected: < 1.3.0
Fixed Versions: 3.0.9.1, 2.2.8.1

Impact

Carefully crafted Range headers can cause a server to respond with an
unexpectedly large response. Responding with such large responses could lead
to a denial of service issue.

Vulnerable applications will use the Rack::File middleware or the
Rack::Utils.byte_ranges methods (this includes Rails applications).

Releases

The fixed releases are available at the normal locations.

Workarounds

There are no feasible workarounds for this issue.

Patches

To aid users who aren't able to upgrade immediately we have provided patches for
the two supported release series. They are in git-am format and consist of a
single changeset.

  • 3-0-range.patch - Patch for 3.0 series
  • 2-2-range.patch - Patch for 2.2 series

Credits

Thank you ooooooo_q for the report and
patch

🚨 Rack has possible DoS Vulnerability with Range Header

Possible DoS Vulnerability with Range Header in Rack

There is a possible DoS vulnerability relating to the Range request header in
Rack. This vulnerability has been assigned the CVE identifier CVE-2024-26141.

Versions Affected: >= 1.3.0.
Not affected: < 1.3.0
Fixed Versions: 3.0.9.1, 2.2.8.1

Impact

Carefully crafted Range headers can cause a server to respond with an
unexpectedly large response. Responding with such large responses could lead
to a denial of service issue.

Vulnerable applications will use the Rack::File middleware or the
Rack::Utils.byte_ranges methods (this includes Rails applications).

Releases

The fixed releases are available at the normal locations.

Workarounds

There are no feasible workarounds for this issue.

Patches

To aid users who aren't able to upgrade immediately we have provided patches for
the two supported release series. They are in git-am format and consist of a
single changeset.

  • 3-0-range.patch - Patch for 3.0 series
  • 2-2-range.patch - Patch for 2.2 series

Credits

Thank you ooooooo_q for the report and
patch

🚨 Possible Denial of Service Vulnerability in Rack's header parsing

There is a denial of service vulnerability in the header parsing component of Rack. This vulnerability has been assigned the CVE identifier CVE-2023-27539.

Versions Affected: >= 2.0.0 Not affected: None. Fixed Versions: 2.2.6.4, 3.0.6.1

Impact

Carefully crafted input can cause header parsing in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. Any applications that parse headers using Rack (virtually all Rails applications) are impacted.

Workarounds

Setting Regexp.timeout in Ruby 3.2 is a possible workaround.

🚨 Rack has possible DoS Vulnerability in Multipart MIME parsing

There is a possible DoS vulnerability in the Multipart MIME parsing code in Rack. This vulnerability has been assigned the CVE identifier CVE-2023-27530.

Versions Affected: All. Not affected: None Fixed Versions: 3.0.4.2, 2.2.6.3, 2.1.4.3, 2.0.9.3

Impact

The Multipart MIME parsing code in Rack limits the number of file parts, but does not limit the total number of parts that can be uploaded. Carefully crafted requests can abuse this and cause multipart parsing to take longer than expected.

All users running an affected release should either upgrade or use one of the workarounds immediately.

Workarounds

A proxy can be configured to limit the POST body size which will mitigate this issue.

🚨 Denial of service via multipart parsing in Rack

There is a denial of service vulnerability in the multipart parsing component of Rack. This vulnerability has been assigned the CVE identifier CVE-2022-44572.

Versions Affected: >= 2.0.0 Not affected: None. Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.1, 3.0.0.1
Impact

Carefully crafted input can cause RFC2183 multipart boundary parsing in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. Any applications that parse multipart posts using Rack (virtually all Rails applications) are impacted.
Releases

The fixed releases are available at the normal locations.
Workarounds

There are no feasible workarounds for this issue.
Patches

To aid users who aren’t able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.

2-0-Forbid-control-characters-in-attributes.patch - Patch for 2.0 series
2-1-Forbid-control-characters-in-attributes.patch - Patch for 2.1 series
2-2-Forbid-control-characters-in-attributes.patch - Patch for 2.2 series
3-0-Forbid-control-characters-in-attributes.patch - Patch for 3.0 series

🚨 Denial of service via header parsing in Rack

There is a possible denial of service vulnerability in the Range header parsing component of Rack. This vulnerability has been assigned the CVE identifier CVE-2022-44570.

Versions Affected: >= 1.5.0 Not affected: None. Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.2, 3.0.0.1
Impact

Carefully crafted input can cause the Range header parsing component in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. Any applications that deal with Range requests (such as streaming applications, or applications that serve files) may be impacted.
Releases

The fixed releases are available at the normal locations.
Workarounds

There are no feasible workarounds for this issue.
Patches

To aid users who aren’t able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.

2-0-Fix-ReDoS-in-Rack-Utils.get_byte_ranges.patch - Patch for 2.0 series
2-1-Fix-ReDoS-in-Rack-Utils.get_byte_ranges.patch - Patch for 2.1 series
2-2-Fix-ReDoS-in-Rack-Utils.get_byte_ranges.patch - Patch for 2.2 series
3-0-Fix-ReDoS-in-Rack-Utils.get_byte_ranges.patch - Patch for 3.0 series

🚨 Denial of Service Vulnerability in Rack Content-Disposition parsing

There is a denial of service vulnerability in the Content-Disposition parsing component of Rack. This vulnerability has been assigned the CVE identifier CVE-2022-44571.

Versions Affected: >= 2.0.0 Not affected: None. Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.1, 3.0.0.1
Impact

Carefully crafted input can cause Content-Disposition header parsing in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. This header is used typically used in multipart parsing. Any applications that parse multipart posts using Rack (virtually all Rails applications) are impacted.
Releases

The fixed releases are available at the normal locations.
Workarounds

There are no feasible workarounds for this issue.
Patches

To aid users who aren’t able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.

2-0-Fix-ReDoS-vulnerability-in-multipart-parser - Patch for 2.0 series
2-1-Fix-ReDoS-vulnerability-in-multipart-parser - Patch for 2.1 series
2-2-Fix-ReDoS-vulnerability-in-multipart-parser - Patch for 2.2 series
3-0-Fix-ReDoS-vulnerability-in-multipart-parser - Patch for 3.0 series
Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ rack-test (indirect, 1.1.0 → 2.2.0) · Repo · Changelog

Release Notes

2.2.0 (from changelog)

  • Bug fixes:

    • Rack::Test::Cookie now parses cookie parameters using a case-insensitive approach (Guillaume Malette #349)

  • Minor enhancements:

    • Arrays of cookies containing a blank cookie are now handled correctly when processing responses. (Martin Emde #343)
    • Rack::Test::UploadedFile no longer uses a finalizer for named paths to close and unlink the created Tempfile. Tempfile itself uses a finalizer to close and unlink itself, so there is no reason for Rack::Test::UploadedFile to do so (Jeremy Evans #338)

2.1.0 (from changelog)

  • Breaking changes:

    • Digest authentication support, deprecated in 2.0.0, has been removed (Jeremy Evans #307)
    • requiring rack/mock_session, deprecated in 2.0.0, has been removed (Jeremy Evans #307)

  • Minor enhancements:

    • The original_filename for Rack::Test::UploadedFile can now be set even if the content of the file comes from a file path (Stuart Chinery #314)
    • Add Rack::Test::Session#restore_state, for executing a block and restoring current state (last request, last response, and cookies) after the block (Jeremy Evans #316)
    • Make Rack::Test::Methods support default_host method similar to app, which will set the default host used for requests to the app (Jeremy Evans #317 #318)
    • Allow responses to set cookie paths not matching the current request URI. Such cookies will only be sent for paths matching the cookie path (Chris Waters #322)
    • Ignore leading dot for cookie domains, per RFC 6265 (Stephen Crosby #329)
    • Avoid creating empty multipart body if params is empty in Rack::Test::Session#env_for (Ryunosuke Sato #331)

2.0.2 (from changelog)

  • Bug fixes:
    • Fix additional incompatible character encodings error when building uploaded bodies (Jeremy Evans #311)

2.0.1 (from changelog)

  • Bug fixes:
    • Fix incompatible character encodings error when building uploaded file bodies (Jeremy Evans #308 #309)

2.0.0 (from changelog)

  • Breaking changes:

    • Digest authentication support is now deprecated, as it relies on digest authentication support in rack, which has been deprecated (Jeremy Evans #294)
    • Rack::Test::Utils.build_primitive_part no longer handles array values (Jeremy Evans #292)
    • Rack::Test::Utils module methods other than build_nested_query and build_multipart are now private methods (Jeremy Evans #297)
    • Rack::MockSession has been combined into Rack::Test::Session, and remains as an alias to Rack::Test::Session, but to keep some backwards compatibility, Rack::Test::Session.new will accept a Rack::Test::Session instance and return it (Jeremy Evans #297)
    • Previously protected methods in Rack::Test::Cookie{,Jar} are now private methods (Jeremy Evans #297)
    • Rack::Test::Methods no longer defines build_rack_mock_session, but for backwards compatibility, build_rack_test_session will call build_rack_mock_session if it is defined (Jeremy Evans #297)
    • Rack::Test::Methods::METHODS is no longer defined (Jeremy Evans #297)
    • Rack::Test::Methods#_current_session_names has been removed (Jeremy Evans #297)
    • Headers used/accessed by rack-test are now lower case, for rack 3 compliance (Jeremy Evans #295)
    • Frozen literal strings are now used internally, which may break code that mutates static strings returned by rack-test, if any (Jeremy Evans #304)

  • Minor enhancements:

    • rack-test now works with the rack main branch (what will be rack 3) (Jeremy Evans #280 #292)
    • rack-test only loads the parts of rack it uses when running on the rack main branch (what will be rack 3) (Jeremy Evans #292)
    • Development dependencies have been significantly reduced, and are now a subset of the development dependencies of rack itself (Jeremy Evans #292)
    • Avoid creating multiple large copies of uploaded file data in memory (Jeremy Evans #286)
    • Specify HTTP/1.0 when submitting requests, to avoid responses with Transfer-Encoding: chunked (Jeremy Evans #288)
    • Support :query_params in rack environment for parameters that are appended to the query string instead of used in the request body (Jeremy Evans #150 #287)
    • Reduce required ruby version to 2.0, since tests run fine on Ruby 2.0 (Jeremy Evans #292)
    • Support :multipart env key for request methods to force multipart input (Jeremy Evans #303)
    • Force multipart input for request methods if content type starts with multipart (Jeremy Evans #303)
    • Improve performance of Utils.build_multipart by using an append-only design (Jeremy Evans #304)
    • Improve performance of Utils.build_nested_query for array values (Jeremy Evans #304)

  • Bug fixes:

    • The CONTENT_TYPE of multipart requests is now respected, if it starts with multipart/ (Tom Knig #238)
    • Work correctly with responses that respond to to_a but not to_ary (Sergio Faria #276)
    • Raise an ArgumentError instead of a TypeError when providing a StringIO without an original filename when creating an UploadedFile (Nuno Correia #279)
    • Allow combining both an UploadedFile and a plain string when building a multipart upload (Mitsuhiro Shibuya #278)
    • Fix the generation of filenames with spaces to use path escaping instead of regular escaping, since path unescaping is used to decode it (Muir Manders, Jeremy Evans #275 #284)
    • Rewind tempfile used for multipart uploads before it is submitted to the application (Jeremy Evans, Alexander Dervish #261 #268 #286)
    • Fix Rack::Test.encoding_aware_strings to be true only on rack 1.6+ (Jeremy Evans #292)
    • Make Rack::Test::CookieJar#valid? return true/false (Jeremy Evans #292)
    • Cookies without a domain attribute no longer are submitted to requests for subdomains of that domain, for RFC 6265 compliance (Jeremy Evans #292)
    • Increase required rack version to 1.3, since tests fail on rack 1.2 and below (Jeremy Evans #293)

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

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ rails-dom-testing (indirect, 2.0.3 → 2.3.0) · Repo · Changelog

Release Notes

2.3.0

What's Changed

  • Add assert_not_dom, refute_dom, assert_not_select, refute_select & refute_dom_equal by @joshuay03 in #113
  • Raise an error when given a block with a 0 element assertion by @joshuay03 in #116
  • Raise an error when provided an invalid Range, or invalid :minimum and :maximum by @joshuay03 in #115
  • assert_dom :text collapses whitespace by @jyeharry in #123

New Contributors

Full Changelog: v2.2.0...v2.3.0

2.2.0

What's Changed

New Contributors

Full Changelog: v2.1.1...v2.2.0

2.1.1

What's Changed

  • Fix issue when application isn't using minitest.

Full Changelog: v2.1.0...v2.1.1

2.1.0

What's Changed

  • Address warning: mismatched indentations at 'when' with 'case' by @yahonda in #74
  • Make assert_dom_equal ignore insignificant whitespace when walking the node tree by @jduff in #84
  • Expand Substitution Matching Types support by @seanpdoyle in #90
  • Alias assert_select methods to assert_dom versions by @seanpdoyle in #93
  • Raise an error if the last arg is the wrong format by @ghiculescu in #96
  • Fix replacement for multiple substitutions by @speckins in #76
  • Better error message if response.body is blank or not parseable by Nokogiri by @ghiculescu in #97
  • selector_assertions/html_selector: No trailing . on content_mismatch by @issyl0 in #102
  • Use Minitest::Assertion#diff for content failure messages by @flavorjones in #106

New Contributors

Full Changelog: v2.0.3...v2.1.0

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

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ rails-html-sanitizer (indirect, 1.4.4 → 1.6.2) · Repo · Changelog

Security Advisories 🚨

🚨 rails-html-sanitize has XSS vulnerability with certain configurations

Summary

There is a possible XSS vulnerability with certain configurations of Rails::HTML::Sanitizer 1.6.0 when used with Rails >= 7.1.0 and Nokogiri < 1.15.7, or 1.16.x < 1.16.8.

  • Versions affected: 1.6.0
  • Not affected: < 1.6.0
  • Fixed versions: 1.6.1

Please note that the fix in v1.6.1 is to update the dependency on Nokogiri to 1.15.7 or >= 1.16.8.

Impact

A possible XSS vulnerability with certain configurations of Rails::HTML::Sanitizer may allow an attacker to inject content if HTML5 sanitization is enabled and the application developer has overridden the sanitizer's allowed tags in either of the following ways:

  • allow both "math" and "style" elements
  • or allow both "svg" and "style" elements

Code is only impacted if Rails is configured to use HTML5 sanitization, please see documentation for config.action_view.sanitizer_vendor and config.action_text.sanitizer_vendor for more information on these configuration options.

Code is only impacted if allowed tags are being overridden. Applications may be doing this in a few different ways:

  1. using application configuration to configure Action View sanitizers' allowed tags:
# In config/application.rb
config.action_view.sanitized_allowed_tags = ["math", "style"]
# or
config.action_view.sanitized_allowed_tags = ["svg", "style"]

see https://guides.rubyonrails.org/configuring.html#configuring-action-view

  1. using a :tags option to the Action View helper sanitize:
<%= sanitize @comment.body, tags: ["math", "style"] %>
<%# or %>
<%= sanitize @comment.body, tags: ["svg", "style"] %>

see https://api.rubyonrails.org/classes/ActionView/Helpers/SanitizeHelper.html#method-i-sanitize

  1. setting Rails::HTML5::SafeListSanitizer class attribute allowed_tags:
# class-level option
Rails::HTML5::SafeListSanitizer.allowed_tags = ["math", "style"]
# or
Rails::HTML5::SafeListSanitizer.allowed_tags = ["svg", "style"]

(note that this class may also be referenced as Rails::Html::SafeListSanitizer)

  1. using a :tags options to the Rails::HTML5::SafeListSanitizer instance method sanitize:
# instance-level option
Rails::HTML5::SafeListSanitizer.new.sanitize(@article.body, tags: ["math", "style"])
# or
Rails::HTML5::SafeListSanitizer.new.sanitize(@article.body, tags: ["svg", "style"])

(note that this class may also be referenced as Rails::Html::SafeListSanitizer)

  1. setting ActionText::ContentHelper module attribute allowed_tags:
ActionText::ContentHelper.allowed_tags = ["math", "style"]
# or
ActionText::ContentHelper.allowed_tags = ["svg", "style"]

All users overriding the allowed tags by any of the above mechanisms to include (("math" or "svg") and "style") should either upgrade or use one of the workarounds.

Workarounds

Any one of the following actions will work around this issue:

References

Credit

This vulnerability was responsibly reported by So Sakaguchi (mokusou) and taise.

🚨 rails-html-sanitizer has XSS vulnerability with certain configurations

Summary

There is a possible XSS vulnerability with certain configurations of Rails::HTML::Sanitizer 1.6.0 when used with Rails >= 7.1.0.

  • Versions affected: 1.6.0
  • Not affected: < 1.6.0
  • Fixed versions: 1.6.1

Impact

A possible XSS vulnerability with certain configurations of Rails::HTML::Sanitizer may allow an attacker to inject content if HTML5 sanitization is enabled and the application developer has overridden the sanitizer's allowed tags in the following way:

  • the "math" and "style" elements are both explicitly allowed

Code is only impacted if Rails is configured to use HTML5 sanitization, please see documentation for config.action_view.sanitizer_vendor and config.action_text.sanitizer_vendor for more information on these configuration options.

The default configuration is to disallow these elements. Code is only impacted if allowed tags are being overridden. Applications may be doing this in a few different ways:

  1. using application configuration to configure Action View sanitizers' allowed tags:
# In config/application.rb
config.action_view.sanitized_allowed_tags = ["math", "style"]

see https://guides.rubyonrails.org/configuring.html#configuring-action-view

  1. using a :tags option to the Action View helper sanitize:
<%= sanitize @comment.body, tags: ["math", "style"] %>

see https://api.rubyonrails.org/classes/ActionView/Helpers/SanitizeHelper.html#method-i-sanitize

  1. setting Rails::HTML5::SafeListSanitizer class attribute allowed_tags:
# class-level option
Rails::HTML5::SafeListSanitizer.allowed_tags = ["math", "style"]

(note that this class may also be referenced as Rails::Html::SafeListSanitizer)

  1. using a :tags options to the Rails::HTML5::SafeListSanitizer instance method sanitize:
# instance-level option
Rails::HTML5::SafeListSanitizer.new.sanitize(@article.body, tags: ["math", "style"])

(note that this class may also be referenced as Rails::Html::SafeListSanitizer)

  1. setting ActionText::ContentHelper module attribute allowed_tags:
ActionText::ContentHelper.allowed_tags = ["math", "style"]

All users overriding the allowed tags by any of the above mechanisms to include both "math" and "style" should either upgrade or use one of the workarounds.

Workarounds

Any one of the following actions will work around this issue:

References

Credit

This vulnerability was responsibly reported by So Sakaguchi (mokusou) and taise.

🚨 rails-html-sanitizer has XSS vulnerability with certain configurations

Summary

There is a possible XSS vulnerability with certain configurations of Rails::HTML::Sanitizer 1.6.0 when used with Rails >= 7.1.0.

  • Versions affected: 1.6.0
  • Not affected: < 1.6.0
  • Fixed versions: 1.6.1

Impact

A possible XSS vulnerability with certain configurations of Rails::HTML::Sanitizer may allow an attacker to inject content if HTML5 sanitization is enabled and the application developer has overridden the sanitizer's allowed tags in the following way:

  • the "math", "mtext", "table", and "style" elements are allowed
  • and either "mglyph" or "malignmark" are allowed

Code is only impacted if Rails is configured to use HTML5 sanitization, please see documentation for config.action_view.sanitizer_vendor and config.action_text.sanitizer_vendor for more information on these configuration options.

The default configuration is to disallow all of these elements except for "table". Code is only impacted if allowed tags are being overridden. Applications may be doing this in a few different ways:

  1. using application configuration to configure Action View sanitizers' allowed tags:
# In config/application.rb
config.action_view.sanitized_allowed_tags = ["math", "mtext", "table", "style", "mglyph"]
# or
config.action_view.sanitized_allowed_tags = ["math", "mtext", "table", "style", "malignmark"]

see https://guides.rubyonrails.org/configuring.html#configuring-action-view

  1. using a :tags option to the Action View helper sanitize:
<%= sanitize @comment.body, tags: ["math", "mtext", "table", "style", "mglyph"] %>
<%# or %>
<%= sanitize @comment.body, tags: ["math", "mtext", "table", "style", "malignmark"] %>

see https://api.rubyonrails.org/classes/ActionView/Helpers/SanitizeHelper.html#method-i-sanitize

  1. setting Rails::HTML5::SafeListSanitizer class attribute allowed_tags:
# class-level option
Rails::HTML5::SafeListSanitizer.allowed_tags = ["math", "mtext", "table", "style", "mglyph"]
# or
Rails::HTML5::SafeListSanitizer.allowed_tags = ["math", "mtext", "table", "style", "malignmark"]

(note that this class may also be referenced as Rails::Html::SafeListSanitizer)

  1. using a :tags options to the Rails::HTML5::SafeListSanitizer instance method sanitize:
# instance-level option
Rails::HTML5::SafeListSanitizer.new.sanitize(@article.body, tags: ["math", "mtext", "table", "style", "mglyph"])
# or
Rails::HTML5::SafeListSanitizer.new.sanitize(@article.body, tags: ["math", "mtext", "table", "style", "malignmark"])

(note that this class may also be referenced as Rails::Html::SafeListSanitizer)

  1. setting ActionText::ContentHelper module attribute allowed_tags:
ActionText::ContentHelper.allowed_tags = ["math", "mtext", "table", "style", "mglyph"]
# or
ActionText::ContentHelper.allowed_tags = ["math", "mtext", "table", "style", "malignmark"]

All users overriding the allowed tags by any of the above mechanisms to include ("math" and "mtext" and "table" and "style" and ("mglyph" or "malignmark")) should either upgrade or use one of the workarounds.

Workarounds

Any one of the following actions will work around this issue:

References

Credit

This vulnerability was responsibly reported by So Sakaguchi (mokusou) and taise.

🚨 rails-html-sanitizer has XSS vulnerability with certain configurations

Summary

There is a possible XSS vulnerability with certain configurations of Rails::HTML::Sanitizer 1.6.0 when used with Rails >= 7.1.0.

  • Versions affected: 1.6.0
  • Not affected: < 1.6.0
  • Fixed versions: 1.6.1

Impact

A possible XSS vulnerability with certain configurations of Rails::HTML::Sanitizer may allow an attacker to inject content if HTML5 sanitization is enabled and the application developer has overridden the sanitizer's allowed tags in the following way:

  • the "style" element is explicitly allowed
  • the "svg" or "math" element is not allowed

Code is only impacted if Rails is configured to use HTML5 sanitization, please see documentation for config.action_view.sanitizer_vendor and config.action_text.sanitizer_vendor for more information on these configuration options.

The default configuration is to disallow all of these elements. Code is only impacted if allowed tags are being overridden. Applications may be doing this in a few different ways:

  1. using application configuration to configure Action View sanitizers' allowed tags:
# In config/application.rb
config.action_view.sanitized_allowed_tags = ["style"]

see https://guides.rubyonrails.org/configuring.html#configuring-action-view

  1. using a :tags option to the Action View helper sanitize:
<%= sanitize @comment.body, tags: ["style"] %>

see https://api.rubyonrails.org/classes/ActionView/Helpers/SanitizeHelper.html#method-i-sanitize

  1. setting Rails::HTML5::SafeListSanitizer class attribute allowed_tags:
# class-level option
Rails::HTML5::SafeListSanitizer.allowed_tags = ["style"]

(note that this class may also be referenced as Rails::Html::SafeListSanitizer)

  1. using a :tags options to the Rails::HTML5::SafeListSanitizer instance method sanitize:
# instance-level option
Rails::HTML5::SafeListSanitizer.new.sanitize(@article.body, tags: ["style"])

(note that this class may also be referenced as Rails::Html::SafeListSanitizer)

  1. setting ActionText::ContentHelper module attribute allowed_tags:
ActionText::ContentHelper.allowed_tags = ["style"]

All users overriding the allowed tags by any of the above mechanisms to include "style" and omit "svg" or "math" should either upgrade or use one of the workarounds.

Workarounds

Any one of the following actions will work around this issue:

References

Credit

This vulnerability was responsibly reported by So Sakaguchi (mokusou) and taise.

🚨 rails-html-sanitizer has XSS vulnerability with certain configurations

Summary

There is a possible XSS vulnerability with certain configurations of Rails::HTML::Sanitizer 1.6.0 when used with Rails >= 7.1.0.

  • Versions affected: 1.6.0
  • Not affected: < 1.6.0
  • Fixed versions: 1.6.1

Impact

A possible XSS vulnerability with certain configurations of Rails::HTML::Sanitizer may allow an attacker to inject content if HTML5 sanitization is enabled and the application developer has overridden the sanitizer's allowed tags in the following way:

  • the "noscript" element is explicitly allowed

Code is only impacted if Rails is configured to use HTML5 sanitization, please see documentation for config.action_view.sanitizer_vendor and config.action_text.sanitizer_vendor for more information on these configuration options.

The default configuration is to disallow all of these elements. Code is only impacted if allowed tags are being overridden. Applications may be doing this in a few different ways:

  1. using application configuration to configure Action View sanitizers' allowed tags:
# In config/application.rb
config.action_view.sanitized_allowed_tags = ["noscript"]

see https://guides.rubyonrails.org/configuring.html#configuring-action-view

  1. using a :tags option to the Action View helper sanitize:
<%= sanitize @comment.body, tags: ["noscript"] %>

see https://api.rubyonrails.org/classes/ActionView/Helpers/SanitizeHelper.html#method-i-sanitize

  1. setting Rails::HTML5::SafeListSanitizer class attribute allowed_tags:
# class-level option
Rails::HTML5::SafeListSanitizer.allowed_tags = ["noscript"]

(note that this class may also be referenced as Rails::Html::SafeListSanitizer)

  1. using a :tags options to the Rails::HTML5::SafeListSanitizer instance method sanitize:
# instance-level option
Rails::HTML5::SafeListSanitizer.new.sanitize(@article.body, tags: ["noscript"])

(note that this class may also be referenced as Rails::Html::SafeListSanitizer)

  1. setting ActionText::ContentHelper module attribute allowed_tags:
ActionText::ContentHelper.allowed_tags = ["noscript"]

All users overriding the allowed tags by any of the above mechanisms to include "noscript" should either upgrade or use one of the workarounds.

Workarounds

Any one of the following actions will work around this issue:

References

Credit

This vulnerability was responsibly reported by So Sakaguchi (mokusou) and taise.

Release Notes

1.6.2

v1.6.2 / 2024-12-12

  • PermitScrubber fully supports frozen "allowed tags".

    v1.6.1 introduced safety checks that may remove unsafe tags from the allowed list, which
    introduced a regression for applications passing a frozen array of allowed tags. Tags and
    attributes are now properly copied when they are passed to the scrubber.

    Fixes #195.

    Mike Dalessio

1.6.1

1.6.1 / 2024-12-02

This is a performance and security release which addresses several possible XSS vulnerabilities.

  • The dependency on Nokogiri is updated to v1.15.7 or >=1.16.8.

    This change addresses CVE-2024-53985 (GHSA-w8gc-x259-rc7x).

    Mike Dalessio

  • Disallowed tags will be pruned when they appear in foreign content (i.e. SVG or MathML content),
    regardless of the prune: option value. Previously, disallowed tags were "stripped" unless the
    gem was configured with the prune: true option.

    The CVEs addressed by this change are:

    Mike Dalessio

  • The tags "noscript", "mglyph", and "malignmark" will not be allowed, even if explicitly added to
    the allowlist. If applications try to allow any of these tags, a warning is emitted and the tags
    are removed from the allow-list.

    The CVEs addressed by this change are:

    Please note that we may restore support for allowing "noscript" in a future release. We do not
    expect to ever allow "mglyph" or "malignmark", though, especially since browser support is minimal
    for these tags.

    Mike Dalessio

  • Improve performance by eliminating needless operations on attributes that are being removed. #188

    Mike Dalessio

1.6.0

1.6.0 / 2023-05-26

  • Dependencies have been updated:

    • Loofah ~>2.21 and Nokogiri ~>1.14 for HTML5 parser support
    • As a result, required Ruby version is now >= 2.7.0

    Security updates will continue to be made on the 1.5.x release branch as long as Rails 6.1
    (which supports Ruby 2.5) is still in security support.

    Mike Dalessio

  • HTML5 standards-compliant sanitizers are now available on platforms supported by
    Nokogiri::HTML5. These are available as:

    • Rails::HTML5::FullSanitizer
    • Rails::HTML5::LinkSanitizer
    • Rails::HTML5::SafeListSanitizer

    And a new "vendor" is provided at Rails::HTML5::Sanitizer that can be used in a future version
    of Rails.

    Note that for symmetry Rails::HTML4::Sanitizer is also added, though its behavior is identical
    to the vendor class methods on Rails::HTML::Sanitizer.

    Users may call Rails::HTML::Sanitizer.best_supported_vendor to get back the HTML5 vendor if it's
    supported, else the legacy HTML4 vendor.

    Mike Dalessio

  • Module namespaces have changed, but backwards compatibility is provided by aliases.

    The library defines three additional modules:

    • Rails::HTML for general functionality (replacing Rails::Html)
    • Rails::HTML4 containing sanitizers that parse content as HTML4
    • Rails::HTML5 containing sanitizers that parse content as HTML5

    The following aliases are maintained for backwards compatibility:

    • Rails::Html points to Rails::HTML
    • Rails::HTML::FullSanitizer points to Rails::HTML4::FullSanitizer
    • Rails::HTML::LinkSanitizer points to Rails::HTML4::LinkSanitizer
    • Rails::HTML::SafeListSanitizer points to Rails::HTML4::SafeListSanitizer

    Mike Dalessio

  • LinkSanitizer always returns UTF-8 encoded strings. SafeListSanitizer and FullSanitizer
    already ensured this encoding.

    Mike Dalessio

  • SafeListSanitizer allows time tag and lang attribute by default.

    Mike Dalessio

  • The constant Rails::Html::XPATHS_TO_REMOVE has been removed. It's not necessary with the
    existing sanitizers, and should have been a private constant all along anyway.

    Mike Dalessio

1.5.0

1.5.0 / 2023-01-20

  • SafeListSanitizer, PermitScrubber, and TargetScrubber now all support pruning of unsafe tags.

    By default, unsafe tags are still stripped, but this behavior can be changed to prune the element
    and its children from the document by passing prune: true to any of these classes' constructors.

    @seyerian

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

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ railties (indirect, 6.1.5 → 8.0.2.1) · Repo · Changelog

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ sprockets (indirect, 4.0.3 → 4.2.2) · Repo · Changelog

Release Notes

4.2.2 (from changelog)

  • Added missing dependency on logger. #813
  • Fix URI::RFC3986_PARSER warnings. #812
  • Removed dependency on base64. #810

4.2.1

What's Changed

New Contributors

Full Changelog: v4.2.0...v4.2.1

4.2.0 (from changelog)

  • Rack 3 compatibility. #758
  • Fix thread safety of Sprockets::CachedEnvironment and Sprockets::Cache::MemoryStore. #771
  • Add support for Rack 3.0. Headers set by sprockets will now be lower case. #758
  • Make Sprockets::Utils.module_include thread safe on JRuby. #759

4.1.1

  • Fix Sprockets::Server to return response headers to compatible with with Rack::Lint 2.0.

Full Changelog: v4.1.0...v4.1.1

4.1.0

What's Changed

New Contributors

Full Changelog: v4.0.3...v4.1.0

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

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ sprockets-rails (indirect, 3.4.2 → 3.5.2) · Repo · Changelog

Release Notes

3.5.2

What's Changed

New Contributors

Full Changelog: v3.5.1...v3.5.2

3.5.1

What's Changed

  • Handle the gem being loaded via sprockets/railtie rather than the expected sprockets/rails entrypoint. by @mamhoff in #525

New Contributors

Full Changelog: v3.5.0...v3.5.1

3.5.0

What's Changed

  • Add useful message for logger silence error by @rossta in #381
  • Use a dedicated ActiveSupport::Deprecation for Rails 7.2 compatibility by @etiennebarrie in #517
  • Dropped support for Rails versions older than 6.1

New Contributors

Full Changelog: v3.4.2...v3.5.0

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

Commits

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

↗️ thor (indirect, 1.2.1 → 1.4.0) · Repo · Changelog

Release Notes

1.4.0

What's Changed

New Contributors

Full Changelog: v1.3.2...v1.4.0

1.3.2

What's Changed

New Contributors

Full Changelog: v1.3.1...v1.3.2

1.3.1

What's Changed

New Contributors

Full Changelog: v1.3.0...v1.3.1

1.3.0

What's Changed

  • use the correct class for shared namespaces by @Gerst20051 in #754
  • Allow to Override Order of Commands in Help by @alessio-signorini in #642
  • Add support for providing http headers to get by @dnlgrv in #801
  • Don't document negative boolean option named no_* by @BrentWheeldon in #797
  • CreateFile#identical? fixed for files containing multi-byte UTF-8 codepoints by @tomclose in #786
  • Drop support to Ruby 2.6 by @rafaelfranca in #821
  • Fix dashless option usage info by @sambostock in #800
  • Support Range in enum option by @phene in #775
  • Check if type: array values are in enum by @movermeyer in #784
  • Fix inject into file warning by @nicolas-brousse in #709
  • Support Thor::CoreExt::HashWithIndifferentAccess#slice method by @shuuuuun in #812
  • 🌧️ long_desc: new option to disable wrapping by @igneus in #739
  • Print default in help when option type is :boolean and default is false by @nevesenin in #849
  • Silence encoding warnings in specs by @p8 in #857
  • Validate arguments for method_option and class_option by @p8 in #856
  • Fix help for file_collision method without block by @shuuuuun in #858
  • Extract print methods to seperate classes by @p8 in #854
  • Add support for printing tables with borders by @p8 in #855
  • Fix printing tables with borders and indentation by @p8 in #861

New Contributors

Full Changelog: v1.2.2...v1.3.0

1.2.2

What's Changed

New Contributors

Full Changelog: v1.2.1...v1.2.2

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

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ tzinfo (indirect, 2.0.4 → 2.0.6) · Repo · Changelog

Release Notes

2.0.6

  • Eliminate Object#untaint deprecation warnings on JRuby 9.4.0.0. #145.

TZInfo v2.0.6 on RubyGems.org

2.0.5

  • Changed DateTime results to always use the proleptic Gregorian calendar. This affects DateTime results prior to 1582-10-15 and any arithmetic performed on the results that would produce a secondary result prior to 1582-10-15.
  • Added support for eager loading all the time zone and country data by calling either TZInfo::DataSource#eager_load! or TZInfo.eager_load!. Compatible with Ruby On Rails' eager_load_namespaces. #129.
  • Ignore the SECURITY file from Arch Linux's tzdata package. #134.

TZInfo v2.0.5 on RubyGems.org

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

Commits

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

↗️ websocket-driver (indirect, 0.7.5 → 0.8.0) · Repo · Changelog

Release Notes

0.8.0 (from changelog)

  • Emit binary message as a string with Encoding::BINARY instead of an array
  • Add the option :binary_data_format to force the previous behaviour

0.7.7 (from changelog)

  • Add base64 gem to the dependencies to support Ruby 3.4

0.7.6 (from changelog)

  • Fix handling of default ports in Host headers on Ruby 3.1+

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

Commits

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

↗️ zeitwerk (indirect, 2.5.4 → 2.7.3) · Repo · Changelog

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

🆕 base64 (added, 0.3.0)

🆕 benchmark (added, 0.4.1)

🆕 bigdecimal (added, 3.2.2)

🆕 connection_pool (added, 2.5.3)

🆕 date (added, 3.4.1)

🆕 drb (added, 2.2.3)

🆕 erb (added, 5.0.2)

🆕 io-console (added, 0.8.1)

🆕 irb (added, 1.15.2)

🆕 logger (added, 1.7.0)

🆕 net-imap (added, 0.5.9)

🆕 net-pop (added, 0.1.2)

🆕 net-protocol (added, 0.2.2)

🆕 net-smtp (added, 0.5.1)

🆕 pp (added, 0.6.2)

🆕 prettyprint (added, 0.2.0)

🆕 psych (added, 5.2.6)

🆕 rack-session (added, 2.1.1)

🆕 rackup (added, 2.2.1)

🆕 rdoc (added, 6.14.2)

🆕 reline (added, 0.6.2)

🆕 securerandom (added, 0.4.1)

🆕 stringio (added, 3.1.7)

🆕 timeout (added, 0.4.3)

🆕 uri (added, 1.0.3)

🆕 useragent (added, 0.16.11)

🗑️ method_source (removed)