🚨 [security] Update rubocop-rails 2.22.1 → 2.33.4 (minor)

[depfu]

---

🚨 Your current dependencies have known security vulnerabilities 🚨

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

---

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

What changed?

✳️ rubocop-rails (2.22.1 → 2.33.4) · Repo · Changelog

Release Notes

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

Commits

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

✳️ rubocop (1.57.2 → 1.81.1) · Repo · Changelog

Release Notes

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

Commits

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

↗️ ast (indirect, 2.4.2 → 2.4.3) · Repo · Changelog

Commits

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

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

Release Notes

1.3.5

More info than we can show here.

1.3.4

More info than we can show here.

1.3.3

More info than we can show here.

1.3.2

More info than we can show here.

1.3.1

More info than we can show here.

1.2.3

More info than we can show here.

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

Commits

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

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

Release Notes

1.14.7

More info than we can show here.

1.14.6

More info than we can show here.

1.14.5

More info than we can show here.

1.14.4

More info than we can show here.

1.14.3

More info than we can show here.

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

Commits

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

↗️ json (indirect, 2.6.3 → 2.15.0) · Repo · Changelog

Security Advisories 🚨

🚨 Out-of-bounds Read in Ruby JSON Parser

Impact

A specially crafted document could cause an out of bound read, most likely resulting in a crash.

Versions 2.10.0 and 2.10.1 are impacted. Older versions are not.

Patches

Version 2.10.2 fixes the problem.

Workarounds

None.

Release Notes

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

Commits

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

↗️ language_server-protocol (indirect, 3.17.0.3 → 3.17.0.5) · Repo · Changelog

Release Notes

3.17.0.5 (from changelog)

More info than we can show here.

3.17.0.4 (from changelog)

More info than we can show here.

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

Commits

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

↗️ minitest (indirect, 5.20.0 → 5.25.5) · Repo · Changelog

Release Notes

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

Commits

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

↗️ parallel (indirect, 1.23.0 → 1.27.0) · Repo

Commits

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

↗️ parser (indirect, 3.2.2.4 → 3.3.9.0) · Repo · Changelog

Release Notes

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

Commits

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

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

Release Notes

1.8.1

More info than we can show here.

1.8.0

More info than we can show here.

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

Commits

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

↗️ rack (indirect, 2.2.8 → 2.2.18) · Repo · Changelog

Security Advisories 🚨

🚨 Rack has an unsafe default in Rack::QueryParser allows params_limit bypass via semicolon-separated parameters

Summary

Rack::QueryParser in version < 2.2.18 enforces its params_limit only for parameters separated by &, while still splitting on both & and ;. As a result, attackers could use ; separators to bypass the parameter count limit and submit more parameters than intended.

Details

The issue arises because Rack::QueryParser#check_query_string counts only & characters when determining the number of parameters, but the default separator regex DEFAULT_SEP = /[&;] */n splits on both & and ;. This mismatch means that queries using ; separators were not included in the parameter count, allowing params_limit to be bypassed.

Other safeguards (bytesize_limit and key_space_limit) still applied, but did not prevent this particular bypass.

Impact

Applications or middleware that directly invoke Rack::QueryParser with its default configuration (no explicit delimiter) could be exposed to increased CPU and memory consumption. This can be abused as a limited denial-of-service vector.

Rack::Request, the primary entry point for typical Rack applications, uses QueryParser in a safe way and does not appear vulnerable by default. As such, the severity is considered low, with the impact limited to edge cases where QueryParser is used directly.

Mitigation

• Upgrade to a patched version of Rack where both & and ; are counted consistently toward params_limit.
• If upgrading is not immediately possible, configure QueryParser with an explicit delimiter (e.g., &) to avoid the mismatch.
• As a general precaution, enforce query string and request size limits at the web server or proxy layer (e.g., Nginx, Apache, or a CDN) to mitigate excessive parsing overhead.

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

Summary

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

Details

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

Impact

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

Mitigation

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

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

🚨 Rack session gets restored after deletion

Summary

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

Details

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

Impact

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

Mitigation

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

Related

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

🚨 Local File Inclusion in Rack::Static

Summary

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

Details

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

Impact

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

Mitigation

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

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

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

Summary

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

Details

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

Impact

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

Mitigation

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

🚨 Possible Log Injection in Rack::CommonLogger

Summary

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

Details

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

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

Impact

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

Mitigation

• Update to the latest version of Rack.

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

Summary

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

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

PoC

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

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

Impact

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

🚨 Rack Header Parsing leads to Possible Denial of Service Vulnerability

Possible Denial of Service Vulnerability in Rack Header Parsing

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

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

Impact

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

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

Releases

The fixed releases are available at the normal locations.

Workarounds

There are no feasible workarounds for this issue.

Patches

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

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

Credits

Thanks to svalkanov for reporting this and
providing patches!

🚨 Rack has possible DoS Vulnerability with Range Header

Possible DoS Vulnerability with Range Header in Rack

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

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

Impact

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

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

Releases

The fixed releases are available at the normal locations.

Workarounds

There are no feasible workarounds for this issue.

Patches

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

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

Credits

Thank you ooooooo_q for the report and
patch

Release Notes

2.2.16 (from changelog)

More info than we can show here.

2.2.15 (from changelog)

More info than we can show here.

2.2.14 (from changelog)

More info than we can show here.

2.2.13 (from changelog)

More info than we can show here.

2.2.12 (from changelog)

More info than we can show here.

2.2.10 (from changelog)

More info than we can show here.

2.2.8.1

More info than we can show here.

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

Commits

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

↗️ regexp_parser (indirect, 2.8.2 → 2.11.3) · Repo · Changelog

Release Notes

2.11.3 (from changelog)

More info than we can show here.

2.11.2 (from changelog)

More info than we can show here.

2.11.1 (from changelog)

More info than we can show here.

2.11.0 (from changelog)

More info than we can show here.

2.10.0 (from changelog)

More info than we can show here.

2.9.3 (from changelog)

More info than we can show here.

2.9.2 (from changelog)

More info than we can show here.

2.9.1 (from changelog)

More info than we can show here.

2.9.0 (from changelog)

More info than we can show here.

2.8.3 (from changelog)

More info than we can show here.

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

Commits

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

↗️ rexml (indirect, 3.2.6 → 3.4.4) · Repo · Changelog

Security Advisories 🚨

🚨 REXML has DoS condition when parsing malformed XML file

Impact

The REXML gems from 3.3.3 to 3.4.1 have a DoS vulnerability when parsing XML containing multiple XML declarations.
If you need to parse untrusted XMLs, you may be impacted to these vulnerabilities.

Patches

REXML gems 3.4.2 or later include the patches to fix these vulnerabilities.

Workarounds

Don't parse untrusted XMLs.

References

• https://www.ruby-lang.org/en/news/2025/09/18/dos-rexml-cve-2025-58767/ : An announcement on www.ruby-lang.org

🚨 REXML ReDoS vulnerability

Impact

The REXML gem before 3.3.9 has a ReDoS vulnerability when it parses an XML that has many digits between &# and x...; in a hex numeric character reference (&#x...;).

This does not happen with Ruby 3.2 or later. Ruby 3.1 is the only affected maintained Ruby. Note that Ruby 3.1 will reach EOL on 2025-03.

Patches

The REXML gem 3.3.9 or later include the patch to fix the vulnerability.

Workarounds

Use Ruby 3.2 or later instead of Ruby 3.1.

References

• https://www.ruby-lang.org/en/news/2024/10/28/redos-rexml-cve-2024-49761/: An announce on www.ruby-lang.org

🚨 REXML denial of service vulnerability

Impact

The REXML gem before 3.3.6 has a DoS vulnerability when it parses an XML that has many deep elements that have same local name attributes.

If you need to parse untrusted XMLs with tree parser API like REXML::Document.new, you may be impacted to this vulnerability. If you use other parser APIs such as stream parser API and SAX2 parser API, this vulnerability is not affected.

Patches

The REXML gem 3.3.6 or later include the patch to fix the vulnerability.

Workarounds

Don't parse untrusted XMLs with tree parser API.

References

• https://www.ruby-lang.org/en/news/2024/08/22/dos-rexml-cve-2024-43398/ : An announce on www.ruby-lang.org

🚨 REXML DoS vulnerability

Impact

The REXML gem before 3.3.2 has a DoS vulnerability when it parses an XML that has many entity expansions with SAX2 or pull parser API.

If you need to parse untrusted XMLs with SAX2 or pull parser API, you may be impacted to this vulnerability.

Patches

The REXML gem 3.3.3 or later include the patch to fix the vulnerability.

Workarounds

Don't parse untrusted XMLs with SAX2 or pull parser API.

References

• https://www.ruby-lang.org/en/news/2008/08/23/dos-vulnerability-in-rexml/ : This is a similar vulnerability
• https://www.ruby-lang.org/en/news/2024/08/01/dos-rexml-cve-2024-41946/: An announce on www.ruby-lang.org

🚨 REXML DoS vulnerability

Impact

The REXML gem before 3.3.2 has some DoS vulnerabilities when it parses an XML that has many specific characters such as whitespace character, >] and ]>.

If you need to parse untrusted XMLs, you may be impacted to these vulnerabilities.

Patches

The REXML gem 3.3.3 or later include the patches to fix these vulnerabilities.

Workarounds

Don't parse untrusted XMLs.

References

• GHSA-vg3r-rm7w-2xgh : This is a similar vulnerability
• GHSA-4xqq-m2hx-25v8 : This is a similar vulnerability
• https://www.ruby-lang.org/en/news/2024/08/01/dos-rexml-cve-2024-41123/: An announce on www.ruby-lang.org

🚨 REXML denial of service vulnerability

Impact

The REXML gem before 3.3.1 has some DoS vulnerabilities when it parses an XML that has many specific characters such as <, 0 and %>.

If you need to parse untrusted XMLs, you may be impacted to these vulnerabilities.

Patches

The REXML gem 3.3.2 or later include the patches to fix these vulnerabilities.

Workarounds

Don't parse untrusted XMLs.

References

• GHSA-vg3r-rm7w-2xgh : This is a similar vulnerability
• https://www.ruby-lang.org/en/news/2024/07/16/dos-rexml-cve-2024-39908/

🚨 REXML contains a denial of service vulnerability

Impact

The REXML gem before 3.2.6 has a DoS vulnerability when it parses an XML that has many >s in an attribute value.

If you need to parse untrusted XMLs, you may be impacted to this vulnerability.

Patches

The REXML gem 3.2.7 or later include the patch to fix this vulnerability.

Workarounds

Don't parse untrusted XMLs.

References

• https://www.ruby-lang.org/en/news/2024/05/16/dos-rexml-cve-2024-35176/

Release Notes

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

Commits

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

↗️ rubocop-ast (indirect, 1.30.0 → 1.47.1) · Repo · Changelog

Release Notes

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

Commits

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

↗️ unicode-display_width (indirect, 2.5.0 → 3.2.0) · Repo · Changelog

Release Notes

3.2.0 (from changelog)

More info than we can show here.

3.1.5 (from changelog)

More info than we can show here.

3.1.4 (from changelog)

More info than we can show here.

3.1.3 (from changelog)

More info than we can show here.

3.1.2 (from changelog)

More info than we can show here.

3.1.1 (from changelog)

More info than we can show here.

3.1.0 (from changelog)

More info than we can show here.

3.0.1 (from changelog)

More info than we can show here.

3.0.0 (from changelog)

More info than we can show here.

2.6.0 (from changelog)

More info than we can show here.

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

Commits

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

↗️ zeitwerk (indirect, 2.6.12 → 2.7.3) · Repo · Changelog

Release Notes

2.7.3 (from changelog)

More info than we can show here.

2.7.2 (from changelog)

More info than we can show here.

2.7.1 (from changelog)

More info than we can show here.

2.7.0 (from changelog)

More info than we can show here.

2.6.18 (from changelog)

More info than we can show here.

2.6.17 (from changelog)

More info than we can show here.

2.6.16 (from changelog)

More info than we can show here.

2.6.15 (from changelog)

More info than we can show here.

2.6.14 (from changelog)

More info than we can show here.

2.6.13 (from changelog)

More info than we can show here.

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

Commits

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

🆕 lint_roller (added, 1.1.0)

🆕 prism (added, 1.5.1)

🆕 unicode-emoji (added, 4.1.0)

---

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

All Depfu comment commands

@​depfu rebase

Rebases against your default branch and redoes this update

@​depfu recreate

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

@​depfu merge

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

@​depfu cancel merge

Cancels automatic merging of this PR

@​depfu close

Closes this PR and deletes the branch

@​depfu reopen

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

@​depfu pause

Ignores all future updates for this dependency and closes this PR

@​depfu pause [minor|major]

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

@​depfu resume

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

[depfu]

Closed in favor of #641.