UBUNTU-CVE-2026-34829: High severity ubuntu/ruby-rack vulnerability
Rack is a modular Ruby web server interface. Prior to versions 2.2.23, 3.1.21, and 3.2.6, Rack::Multipart::Parser only wraps the request body in a BoundedIO when CONTENTLENGTH is present. When a multipart/form-data request is sent without a Content-Length header, such as with HTTP chunked transfer encoding, multipart parsing continues until end-of-stream with no total size limit. For file parts, the uploaded body is written directly to a temporary file on disk rather than being constrained by the buffered in-memory upload limit. An unauthenticated attacker can therefore stream an arbitrarily large multipart file upload and consume unbounded disk space. This results in a denial of service condition for Rack applications that accept multipart form data. This issue has been patched in versions 2.2.23, 3.1.21, and 3.2.6.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/ruby-rackto a version that resolves this vulnerability.Fixed in 2.1.4-5ubuntu1.2+esm3 - Upgrade
Upgrade
ubuntu/ruby-rackto a version that resolves this vulnerability.Fixed in 2.2.7-1ubuntu0.7 - Upgrade
Upgrade
ubuntu/ruby-rackto a version that resolves this vulnerability.Fixed in 3.1.16-0.1ubuntu0.3 - Upgrade
Upgrade
Rackto a version that resolves this vulnerability.Fixed in 2.2.23 - Upgrade
Upgrade
Rackto a version that resolves this vulnerability.Fixed in 3.1.21 - Upgrade
Upgrade
Rackto a version that resolves this vulnerability.Fixed in 3.2.6
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Rack applications that accept multipart/form-data requests are exposed when they run Rack versions earlier than 2.2.23, 3.1.21, or 3.2.6. The vulnerable path is specifically multipart parsing without a Content-Length header, including requests using HTTP chunked transfer encoding.
Does exploitation require authentication or user interaction?
No. An unauthenticated attacker can send a multipart upload without Content-Length and stream an arbitrarily large file, consuming disk space until the service is denied.
Are normal upload memory limits sufficient mitigation?
No. For file parts, Rack writes the uploaded body directly to a temporary file on disk, so the buffered in-memory upload limit does not constrain this condition. Update Rack to 2.2.23, 3.1.21, or 3.2.6, as applicable.