CVE-2025-61772

What it actually does

Rack::Multipart::Parser mishandles malformed multipart/form-data requests when a multipart part begins a header block that never terminates with the required blank line sequence. Instead of enforcing a bounded header-size limit or rejecting the malformed part promptly, the parser can continue appending incoming bytes to an in-memory buffer. A remote unauthenticated client that can reach an endpoint using Rack multipart parsing can therefore cause process memory growth, garbage-collection pressure, worker crashes, or host/container out-of-memory termination. The impact is denial of service rather than code execution or data disclosure.

Why it matters to the business

Public or internal Ruby applications that accept file uploads or multipart form submissions through affected Rack code may be made slow or unavailable by relatively simple malformed HTTP requests. This can interrupt customer-facing services, APIs, administrative portals, CI/CD callbacks, or any application workflow that relies on multipart request handling. The vulnerability is not in CISA KEV, has no known mature public exploitation in the provided data, and has a low EPSS score of 0.00868, but it has been public for 306 days, so internet-exposed upload endpoints should still be treated as practical denial-of-service risk.

How an attack unfolds

An attacker first identifies a Rack-backed application endpoint that accepts multipart/form-data, commonly an upload or form submission route. The attacker then opens one or more HTTP requests declaring a multipart body and sends a part whose header section is intentionally malformed so the expected header terminator is never reached. As the request body continues, Rack::Multipart::Parser keeps accumulating bytes in memory while waiting for the missing terminator. Repeating this across concurrent connections or with sufficiently large bodies can consume application worker memory, trigger Ruby NoMemoryError conditions, cause container or process OOM kills, or make the service unresponsive until workers restart or traffic is blocked.

How to fix it

Update Rack to a fixed revision or release containing the upstream fix. For deployments tracking rack/rack from Git, ensure the code includes commit 4c4ea296fdfd115377912aa7dbcb55b83bf2888e or a later commit/release that incorporates it. Rebuild and redeploy applications that vendor Rack or bundle it through dependency lockfiles, and verify that transitive dependencies do not pin an affected Rack version. As compensating controls, enforce request body size limits, multipart header/field limits, upload size limits, request timeouts, and connection rate limits at the reverse proxy, load balancer, WAF, or application server. Disable or restrict multipart upload endpoints that are not required, and ensure process supervisors/container orchestrators have sane memory limits and restart policies to reduce outage duration.

How to confirm the fix worked

Confirm the deployed Rack code includes commit 4c4ea296fdfd115377912aa7dbcb55b83bf2888e or a package release known to include that fix. Review Gemfile.lock, vendored source, container images, and build artifacts to ensure the runtime application is not still using an affected Rack parser. In a controlled test environment, send malformed multipart requests with non-terminating part headers and verify they are rejected or bounded without unbounded memory growth. Monitor application memory during the test and confirm workers remain stable. Also verify upstream controls such as maximum request body size, header limits, upload limits, and request timeouts are active and applied before traffic reaches the application.

Typical attack path

1. Identify a Rack-based web application or API endpoint that accepts multipart/form-data requests.
2. Send a multipart request with a valid-looking boundary and a part header block that does not terminate correctly with the required blank line.
3. Continue streaming or sending body bytes so the parser accumulates data while waiting for the missing header terminator.
4. Repeat the malformed requests concurrently or over time to increase memory pressure on application workers.
5. Cause degraded performance, request failures, worker crashes, container restarts, or host-level out-of-memory events.

How to detect it

Look for evidence of denial-of-service activity rather than a unique exploit artifact. Review web server, reverse proxy, WAF, application server, Rack/Ruby application, container runtime, and host kernel logs for bursts of multipart/form-data requests that end in 4xx/5xx responses, unusually long request durations, client disconnects, or large request bodies. Correlate those requests with memory spikes, Ruby worker crashes, application restarts, container restarts, kernel OOM-killer messages, and Ruby NoMemoryError or failed allocation errors. Pay particular attention to POST or PUT requests to upload/form endpoints where Content-Type is multipart/form-data and the request size or duration is abnormal. Because the malformed condition may not be fully logged by default, absence of a distinctive payload string does not rule out exploitation; correlation between multipart traffic and memory exhaustion is the strongest indicator.

• Content-Type: multipart/form-data
• multipart/form-data; boundary=
• Rack::Multipart::Parser
• NoMemoryError
• failed to allocate memory
• Cannot allocate memory
• out of memory
• OOMKilled
• oom-kill
• Killed process
• signal 9
• worker timeout
• worker restart
• upstream prematurely closed connection
• client prematurely closed connection

What your security team should do

• Inventory Rack-based applications, especially Ruby/Rails services, APIs, and upload-enabled endpoints that parse multipart/form-data.
• Prioritize patching internet-facing and high-traffic services even though the provided EPSS is low and the issue is not listed in KEV.
• Upgrade Rack or ensure deployments include commit 4c4ea296fdfd115377912aa7dbcb55b83bf2888e or later fixed code.
• Add or verify reverse-proxy, WAF, load-balancer, and application-server limits for request size, upload size, request duration, and concurrent connections.
• Search recent logs and telemetry for abnormal spikes in multipart POST requests, long-running upload requests, memory exhaustion, worker restarts, and OOM-kill events.
• Create monitoring alerts for sudden memory growth in Ruby application workers correlated with multipart/form-data traffic.
• If immediate patching is not possible, temporarily restrict upload endpoints, require authentication where feasible, and apply aggressive request limits at the edge.