CVE-2025-61919

What it actually does

Rack::Request#POST can read an entire HTTP request body into memory when handling requests with Content-Type: application/x-www-form-urlencoded. Because the read path calls rack.input.read(nil) without a reliable maximum size cap, an unauthenticated remote client can send very large form-encoded POST bodies that are fully buffered by the Ruby/Rack process before parsing. This can exhaust process or host memory, trigger garbage collection pressure, raise allocation errors, cause worker crashes, or lead the operating system/container runtime to kill the process. The vulnerability affects Rack-based applications that parse form POST bodies through vulnerable rack/rack code prior to the fixed commit 6ef591522bb44f80654ad1a80654ba46cafdc7c1.

Why it matters to the business

Successful exploitation can make Rack-based web applications slow, unstable, or unavailable by consuming memory with oversized HTTP requests. Internet-facing services are the highest concern because exploitation does not require authentication and can be repeated or distributed to cause sustained denial of service. Although EPSS is currently low and the issue is not listed in CISA KEV or known ransomware use, the CVSS 7.5 availability impact and the broad use of Rack in Ruby web stacks make remediation important for public-facing and business-critical applications.

How an attack unfolds

An attacker identifies a Rack-based application endpoint that accepts or causes parsing of application/x-www-form-urlencoded POST data. The attacker sends one or more HTTP POST requests with an extremely large request body and the form URL-encoded content type. When the vulnerable Rack request parsing path is invoked, Rack reads the body without an enforced cap and buffers it into application process memory. As memory consumption rises, the process may become unresponsive, spend excessive time in garbage collection, raise Ruby memory allocation errors, or be terminated by the container runtime or operating system OOM killer. The attacker can repeat the requests or use multiple clients to keep workers recycling and degrade or fully deny service.

How to fix it

Upgrade rack/rack to a version that includes the fix at commit 6ef591522bb44f80654ad1a80654ba46cafdc7c1, or use a vendor/package release that incorporates that commit. If using Rack through a framework or platform, update the framework bundle, lockfile, container image, and runtime dependencies so the effective Rack version contains the fix. As defense in depth, enforce maximum request body sizes at the earliest possible layer, such as CDN, WAF, reverse proxy, ingress controller, load balancer, application server, and Rack middleware. Configure web servers such as NGINX, Apache, Envoy, HAProxy, or cloud load balancers to reject oversized POST bodies before they reach Ruby application workers. Apply request rate limits, per-client connection limits, and worker memory limits with safe restart behavior. Ensure application endpoints that do not require large form submissions explicitly reject them with 413 Payload Too Large.

How to confirm the fix worked

Confirm the deployed Rack code includes commit 6ef591522bb44f80654ad1a80654ba46cafdc7c1 or a package release containing it. Validate dependency resolution using the application lockfile, software composition analysis, container image scan, or runtime package inspection rather than only checking source manifests. Test that oversized application/x-www-form-urlencoded POST requests are rejected with 413 or equivalent before significant application memory growth occurs. Monitor memory usage during controlled testing to ensure request bodies are capped at the edge or middleware layer. Confirm reverse proxy, ingress, WAF, and application server maximum body-size settings are active in production-equivalent configuration. Re-run regression tests for legitimate large form submissions to ensure business workflows still function within approved limits.

Typical attack path

1. Discover or select a Rack/Ruby web application exposed over HTTP or HTTPS.
2. Find an endpoint that accepts POST requests or otherwise triggers Rack::Request#POST form parsing.
3. Send a POST request with Content-Type: application/x-www-form-urlencoded and an abnormally large request body.
4. Force the vulnerable Rack code path to call rack.input.read(nil) and buffer the full body into memory.
5. Repeat or parallelize requests until application workers exhaust memory, crash, or are killed.
6. Maintain pressure to cause intermittent or sustained service unavailability.

How to detect it

Investigate historical web access logs, reverse proxy logs, WAF/CDN logs, application logs, container runtime events, process supervisor logs, and host kernel logs. Look for unusually large POST requests with Content-Type: application/x-www-form-urlencoded, especially to unauthenticated endpoints, followed by increased latency, 5xx responses, worker restarts, memory allocation errors, or OOM-kill events. In proxy logs, correlate high request body sizes, long request times, upstream connection resets, 502/503/504 responses, or repeated requests from the same source addresses. In Ruby/Rack application logs, search for NoMemoryError, failed memory allocation messages, abrupt worker exits, and request-processing failures around the same timestamps. In Kubernetes or containerized deployments, review pod events and container status for OOMKilled, restart count increases, and memory-limit terminations. In host-based telemetry, correlate Ruby process RSS growth and kernel OOM killer messages with inbound large form POST traffic. Because exploit attempts may use otherwise normal HTTP semantics, behavioral correlation between oversized form bodies and memory-related service failure is more reliable than a single static indicator.

• Content-Type: application/x-www-form-urlencoded
• application/x-www-form-urlencoded
• NoMemoryError
• failed to allocate memory
• out of memory
• Out of memory
• OOMKilled
• Killed process
• Memory cgroup out of memory
• rack.input.read(nil)
• POST

What your security team should do

• Prioritize patching internet-facing Rack-based applications and any service with unauthenticated POST endpoints.
• Upgrade rack/rack or dependent framework packages to include fixed commit 6ef591522bb44f80654ad1a80654ba46cafdc7c1.
• Add or verify maximum HTTP request body-size limits at CDN, WAF, reverse proxy, ingress, and application layers.
• Deploy rate limiting for repeated large POST requests, especially from unauthenticated clients and new source IPs.
• Review application and infrastructure logs for large form-encoded POST requests followed by memory spikes, worker crashes, 5xx errors, or OOM events.
• Create monitoring alerts for abnormal Ruby process RSS growth, container memory-limit kills, worker restarts, and elevated 413/499/500/502/503 responses.
• Include this issue in dependency governance for Ruby/Rack applications so vulnerable transitive Rack versions are not reintroduced.