Skip to content

🚨 [security] [ruby] Update rack-session 2.0.0 → 2.1.1 (minor) #135

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

🚨 [security] [ruby] Update rack-session 2.0.0 → 2.1.1 (minor) #135

wants to merge 1 commit into from

Conversation

depfu[bot]
Copy link
Contributor

@depfu depfu bot commented May 8, 2025

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

↗️ rack-session (indirect, 2.0.0 → 2.1.1) · Repo · Changelog

Security Advisories 🚨

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

This code was previously part of rack in Rack < 3, see GHSA-vpfw-47h7-xj4g for the equivalent advisory in rack (affecting Rack < 3 only).

Release Notes

2.1.1

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

2.1.0

Full Changelog: v2.0.0...v2.1.0

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

Commits

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

↗️ rack (indirect, 3.1.7 → 3.1.14) · Repo · Changelog

Security Advisories 🚨

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

Summary

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

Details

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

Impact

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

Mitigation

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

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

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

3.1.14 (from changelog)

Security

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

3.1.13 (from changelog)

  • Ensure Rack::ETag correctly updates response body. (#2324, @ioquatix)

3.1.12 (from changelog)

Security

3.1.11 (from changelog)

Security

3.1.9 (from changelog)

Fixed

  • Rack::MediaType#params now handles parameters without values. (#2263, @AllyMarthaJ)

3.1.8 (from changelog)

Fixed

  • Resolve deprecation warnings about uri DEFAULT_PARSER. (#2249, @earlopain)

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

Commits

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

Depfu Status

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 depfu bot added the depfu label May 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
depfu
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
0 participants