CVE-2025-61771

What it actually does

Rack::Multipart::Parser keeps multipart/form-data parts that do not include a filename parameter fully in process memory as Ruby String objects. An unauthenticated remote client can send a multipart request containing a very large ordinary text field, causing the Rack-based application process to allocate memory roughly proportional to the field size. If request-size controls are absent or too permissive, one or more such requests can exhaust worker memory, trigger Ruby NoMemoryError conditions or operating-system OOM kills, and make the application unavailable. The flaw affects rack/rack from source builds or downstream packages that include the vulnerable parser behavior; the upstream Git fix is commit 4c4ea296fdfd115377912aa7dbcb55b83bf2888e.

Why it matters to the business

Successful exploitation can cause customer-facing Ruby web applications, APIs, or internal Rack-based services to slow down, restart repeatedly, or become unavailable, creating operational disruption without requiring account access. Although EPSS is currently low and the issue is not in CISA KEV, the CVSS 7.5 availability impact means internet-exposed upload or form endpoints should be prioritized, especially where Rack is widely embedded through Ruby frameworks and middleware stacks.

How an attack unfolds

An attacker first identifies a Rack-backed endpoint that accepts POST requests with multipart/form-data, such as upload, form submission, import, support, or profile endpoints. Instead of uploading a file part with a filename, the attacker submits a multipart body containing one or more very large non-file fields. The vulnerable parser treats those fields as normal form parameters and stores their entire contents in Ruby heap memory. As the request body is parsed, application worker memory rises sharply. If the request is large enough, or if several requests are sent concurrently, the Ruby process may raise memory allocation errors, the container or host may OOM-kill workers, upstream proxies may return 500/502/503/504 responses, and the service may degrade or go offline until workers are restarted and traffic is controlled.

How to fix it

Upgrade Rack to a version or source revision that includes the upstream fix for Rack::Multipart::Parser, specifically rack/rack commit 4c4ea296fdfd115377912aa7dbcb55b83bf2888e or a released package version that contains that commit. Rebuild and redeploy applications that vendor Rack or pin it through Gemfile.lock, package locks, containers, base images, or framework dependencies. In parallel, enforce defense-in-depth request limits at the earliest layer possible: CDN/WAF/load balancer maximum body size, reverse proxy client body limits, application server limits, Rack middleware limits, multipart part count limits, per-field size limits, and sane upload limits per endpoint. Return 413 Payload Too Large for oversized requests before they reach Rack parsing. For containerized deployments, set memory limits and autoscaling/restart policies, but do not rely on restarts as the primary mitigation.

How to confirm the fix worked

Confirm dependency resolution shows Rack built from, or upgraded to, a release containing commit 4c4ea296fdfd115377912aa7dbcb55b83bf2888e. Review Gemfile.lock, package manifests, vendored source, container image SBOMs, and framework transitive dependencies for vulnerable Rack copies. Validate edge and application limits by sending a controlled multipart/form-data request with an oversized non-file text field in a staging environment and confirming it is rejected with 413 or equivalent before application memory grows materially. Monitor process RSS/heap during the test and confirm no worker crash, NoMemoryError, OOM kill, or 5xx spike occurs. Verify production proxy, WAF, and application server configurations are actually enforcing the intended maximum request body and multipart field sizes.

Typical attack path

1. Discover a Rack-based web application or API endpoint that accepts multipart/form-data requests.
2. Send a crafted multipart/form-data POST request containing a very large text field without a filename attribute.
3. Cause Rack::Multipart::Parser to allocate the full field contents as an in-memory Ruby String.
4. Repeat or parallelize requests to drive worker, container, or host memory consumption upward.
5. Trigger NoMemoryError, worker crashes, OOM kills, restarts, elevated latency, or upstream 5xx errors.
6. Maintain denial of service by continuing to submit oversized multipart requests until request limits or patches are applied.

How to detect it

To determine whether this was already exploited, correlate web access logs, reverse-proxy logs, WAF/CDN logs, application logs, container runtime events, and host kernel logs. Look for large POST requests with Content-Type multipart/form-data, especially requests to form or upload endpoints that returned 500, 502, 503, 504, connection reset, timeout, or no response. Pay attention to requests with very large request_body_bytes, request_length, bytes_received, or upstream_request_time values, and repeated requests from the same source IP, ASN, user agent, or session shortly before worker crashes or memory spikes. In Ruby and application logs, search for Rack::Multipart::Parser exceptions, NoMemoryError, failed memory allocation, worker timeout, and process restart messages. In Linux, container, Kubernetes, and orchestration logs, search for OOMKilled, oom-kill, Killed process, exit code 137, and sudden restarts of Ruby, Puma, Unicorn, Passenger, Thin, or other Rack application workers. Absence of a unique exploit payload means detection should focus on the behavioral chain: oversized multipart request followed by rapid memory growth, process termination, and service errors.

• Content-Type: multipart/form-data
• Rack::Multipart::Parser
• NoMemoryError
• failed to allocate memory
• Out of memory
• oom-kill
• OOMKilled
• Killed process
• exit code 137
• signal SIGKILL
• HTTP/1.1" 413
• HTTP/1.1" 500
• HTTP/1.1" 502
• HTTP/1.1" 503
• HTTP/1.1" 504
• client intended to send too large body
• request entity too large
• Payload Too Large
• multipart/form-data; boundary=
• puma: cluster worker
• unicorn worker
• Passenger AppPreloader

What your security team should do

• Inventory internet-exposed and business-critical Ruby/Rack applications, including applications that receive Rack transitively through Rails, Sinatra, Hanami, Grape, or custom Rack middleware stacks.
• Patch Rack to a fixed release or source revision containing commit 4c4ea296fdfd115377912aa7dbcb55b83bf2888e, and rebuild all affected containers or deployment artifacts.
• Immediately enforce maximum request body size and multipart field size controls at CDN, WAF, load balancer, reverse proxy, and application layers.
• Prioritize endpoints that accept uploads, imports, web forms, large POST bodies, or unauthenticated multipart/form-data traffic.
• Add monitoring and alerts for large multipart POST requests, sudden Ruby worker memory growth, OOM kills, NoMemoryError events, and correlated 5xx/latency spikes.
• Create temporary WAF or reverse-proxy rules to reject multipart/form-data requests above approved endpoint-specific sizes until all affected applications are patched.
• Review historical logs around availability incidents for unusually large multipart/form-data POST requests and repeated client sources causing memory pressure.
• Document expected maximum upload and form sizes per application so future changes can be validated against abuse-resistant limits.