Where
-Infinity
0
Severity
6.6
EPSS
0.06%
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

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

Details

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

Credits

Thanks to scyoon for reporting this to the Rails security team

1 / 2
Source: GitHub
First published (updated )
Severity
4.2
Race Condition
AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N

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 loggedout 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 <https://github.com/rack/rack-session/security/advisories/GHSA-9j94-67jr-4cqj> for the equivalent advisory in rack-session (affecting Rack 3+ only).

1 / 2
Source: GitHub
First published (updated )
Severity
7.5
Input Validation
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

A DoS vulnerability exists in Rack <v3.0.4.2, <v2.2.6.3, <v2.1.4.3 and <v2.0.9.3 within in the Multipart MIME parsing code in which could allow an attacker to craft requests that can be abuse to cause multipart parsing to take longer than expected.

1 / 5
First published (updated )
Severity
4

James Tucker (raggi) reports:

CVE: CVE-2013-0262 Software: Rack (rack.github.com) Type of vulnerability: Information Disclosure Vulnerable code: https://github.com/rack/rack/blob/master/lib/rack/file.rb#L56 Patch: https://github.com/rack/rack/commit/6f237e4c9fab649d3750482514f0fde76c56ab30 Versions affected: All versions after 1.4.0 Versions fixed: 1.4.5, 1.5.2 Reporter: Ben Murphy

First published (updated )
Severity
4

James Tucker (raggi) reports:

CVE: CVE-2013-0263 Software: Rack (rack.github.com) Type of vulnerability: Timing attack, leading to potential RCE

Vulnerable code: https://github.com/rack/rack/blob/master/lib/rack/session/cookie.rb#L149 Patch: https://github.com/rack/rack/commit/0cd7e9aa397f8ebb3b8481d67dbac8b4863a7f07 https://github.com/rack/rack/commit/9a81b961457805f6d1a5c275d053068440421e11

Versions affected: All prior versions. Versions fixed: 1.1.6, 1.2.8, 1.3.10, 1.4.5, 1.5.2 Reporter: Ben Murphy

Reference: http://seclists.org/oss-sec/2013/q1/271

First published (updated )
Severity
4

A flaw that was fixed in 1.4.4, 1.3.9, 1.2.7, and 1.1.5 was also announced [4] that creates a minor denial of service condition, this time in the Rack::Auth::AbstractRequest, where it symbolized arbitrary strings (apparently this has something to do with authentication, but there is no further information provided other than the fix [5] itself, which is noted as "a breaking API change").

[4] https://groups.google.com/forum/#!topic/rack-devel/ImYOqcGiksw/discussion [5] https://github.com/rack/rack/commit/0c76175fcccad74ba2f991c487d3669c28a297c8

First published (updated )
Severity
4

Upstream released [1] Rack 1.4.3 and 1.3.8 to fix a denial of service condition due to a malicious client sending excessively long lines that trigger an out-of-memory error in Rack.

This has been fixed in git [2].

[1] https://groups.google.com/forum/#!topic/rack-devel/-MWPHDeGWtI/discussion [2] https://github.com/rack/rack/commit/f95113402b7239f225282806673e1b6424522b18

First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203