CVE-2025-61770

What it actually does

Rack's multipart parser buffers all bytes that appear before the first multipart boundary, known as the multipart preamble, into process memory without enforcing a size limit. An unauthenticated client can send an HTTP request with Content-Type: multipart/form-data, include a very large preamble, and then eventually provide a valid boundary so the request remains syntactically acceptable. Because the preamble is accumulated in memory, each malicious request can drive excessive heap growth in the Ruby/Rack application process, causing garbage-collection pressure, latency spikes, worker crashes, or operating-system out-of-memory termination. The impact is denial of service rather than code execution or data compromise.

Why it matters to the business

Public-facing applications that accept multipart form uploads through affected Rack code can be made slow or unavailable with comparatively simple HTTP traffic. The likely consequences are service disruption, failed uploads or form submissions, elevated infrastructure costs from memory exhaustion and autoscaling, increased error rates, and possible cascading outages if application workers are repeatedly killed and restarted. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS, but it has been public for a long period, so internet-facing services should still be patched as part of normal vulnerability management.

How an attack unfolds

An attacker identifies a Ruby/Rack-backed endpoint that accepts multipart/form-data, such as a file upload or form submission path. The attacker opens one or more HTTP connections and sends a multipart request whose body starts with a very large preamble before the first declared boundary. Vulnerable Rack::Multipart::Parser behavior stores that preamble in memory while waiting for the boundary. Once the boundary is sent, the request can continue to be parsed, but by then the worker may have consumed substantial memory. Repeating this across concurrent requests or connections can exhaust available memory, trigger Ruby NoMemoryError conditions, cause application server workers to be killed by the operating system or container runtime, and make the application unavailable to legitimate users.

How to fix it

Upgrade Rack to a release or source revision that includes the fix for Rack::Multipart::Parser preamble size handling. For rack/rack from Git, ensure the deployed code includes commit 4c4ea296fdfd115377912aa7dbcb55b83bf2888e or a later trusted version containing that change. Rebuild and redeploy all applications that vendor, bundle, or indirectly depend on affected Rack code. As compensating controls, enforce maximum request body sizes at the reverse proxy, load balancer, CDN, web server, and application server; set strict upload size limits; reduce request read timeouts; limit concurrent requests per client; and ensure containers or services have memory limits plus healthy restart policies. Do not rely only on application-level validation, because the vulnerable buffering occurs during multipart parsing before application handlers may run.

How to confirm the fix worked

Confirm the deployed Rack dependency or vendored source includes commit 4c4ea296fdfd115377912aa7dbcb55b83bf2888e or a release that incorporates it. Review lockfiles, dependency manifests, container images, and runtime package inventories to ensure no vulnerable Rack copy remains. Exercise upload and multipart endpoints in a staging environment with oversized multipart preambles and verify the request is rejected, bounded, or handled without unbounded memory growth. Confirm reverse proxies and application servers enforce request size limits before traffic reaches Rack. Monitor memory usage, worker restarts, HTTP 5xx rates, and request rejection logs during validation to ensure controls are effective and do not break legitimate uploads.

Typical attack path

1. Discover an application endpoint that accepts multipart/form-data requests.
2. Send an HTTP request with a valid multipart Content-Type header and boundary value.
3. Place an unusually large amount of data before the first multipart boundary in the request body.
4. Optionally complete the request with the expected boundary so parsing proceeds far enough to trigger the vulnerable buffering behavior.
5. Repeat the request or run multiple concurrent requests to increase memory pressure.
6. Cause application workers, containers, or hosts to slow down, restart, or terminate from out-of-memory conditions.

How to detect it

Look for evidence of denial-of-service activity rather than data theft. Useful sources include reverse proxy and load balancer access logs, web application firewall logs, application server logs, Ruby/Rack exception logs, container runtime events, kernel or host OOM logs, APM traces, and infrastructure metrics. Focus on multipart/form-data requests with unusually large request bodies, long request durations, incomplete uploads, repeated requests from the same source, spikes in HTTP 499/500/502/503/504 responses, and time-correlated increases in application memory usage. On containerized platforms, search for OOMKilled events or restarts of Ruby application containers around bursts of multipart traffic. In host logs, search for operating-system out-of-memory messages that reference Ruby, Puma, Unicorn, Passenger, or other Rack-hosting processes. Because exploitation may leave no unique payload marker after the request body is discarded, correlation between large multipart requests and memory exhaustion is the strongest indicator.

• Content-Type: multipart/form-data; boundary=
• Rack::Multipart::Parser
• NoMemoryError
• failed to allocate memory
• Cannot allocate memory
• Out of memory
• out of memory: Kill process
• Killed process
• OOMKilled
• SIGKILL
• worker timeout
• PumaWorkerKiller
• puma: cluster worker
• unicorn worker
• passenger-status
• HTTP 503
• HTTP 502
• HTTP 504

What your security team should do

• Prioritize patching internet-facing Ruby/Rack applications that accept file uploads or multipart forms.
• Update Rack to a fixed release or ensure source deployments include commit 4c4ea296fdfd115377912aa7dbcb55b83bf2888e or later.
• Inventory transitive Rack usage across Ruby applications, containers, and vendored dependencies; do not assume only directly declared Rack packages are affected.
• Enforce maximum request body size and upload size limits at the edge before requests reach the Rack application.
• Add rate limiting and connection concurrency controls for multipart/form-data endpoints, especially unauthenticated paths.
• Tune container, process manager, and application server memory limits so individual worker failures do not destabilize the full service.
• Review historical logs and runtime telemetry for unexplained memory spikes, OOM kills, worker restarts, and large multipart requests.
• Create SIEM or observability alerts for multipart requests with unusually large request bodies, high request duration, client disconnects, and correlated application memory growth.