CVE-2025-61919 Overview
CVE-2025-61919 is a memory exhaustion denial of service (DoS) vulnerability in Rack, a modular Ruby web server interface. The vulnerability exists in Rack::Request#POST which reads the entire request body into memory for requests with Content-Type: application/x-www-form-urlencoded. The function calls rack.input.read(nil) without enforcing a length or cap, allowing attackers to buffer arbitrarily large request bodies into process memory before parsing. This can lead to complete memory exhaustion and service unavailability.
Critical Impact
Unauthenticated attackers can remotely cause denial of service by sending large HTTP POST requests, exhausting server memory and crashing Ruby web applications that rely on Rack.
Affected Products
- Rack versions prior to 2.2.20
- Rack versions 3.0.0 to 3.1.17
- Rack versions 3.2.0 to 3.2.2
Discovery Timeline
- October 10, 2025 - CVE-2025-61919 published to NVD
- November 3, 2025 - Last updated in NVD database
Technical Details for CVE-2025-61919
Vulnerability Analysis
This vulnerability represents a classic resource exhaustion flaw (CWE-400: Uncontrolled Resource Consumption) in HTTP request body handling. When a Ruby web application built on Rack receives a POST request with the application/x-www-form-urlencoded content type, the Rack::Request#POST method processes the request body by calling rack.input.read(nil). The nil parameter instructs the method to read the entire input stream without any size limitation.
The absence of a byte size limit means that an attacker can craft a malicious HTTP POST request with an extremely large body. The server will attempt to load this entire body into memory before any parsing or validation occurs. In environments with limited memory resources or where multiple such requests are made concurrently, this behavior can rapidly exhaust available system memory, causing the application to crash or become unresponsive.
Root Cause
The root cause of this vulnerability is the lack of input validation on request body size within the Rack::Request#POST method. The method unconditionally reads the entire input stream by passing nil to rack.input.read(), trusting that incoming data will be reasonably sized. This violates the security principle of validating all external input before processing. The fix introduces enforcement of form parameter limits using query_parser.bytesize_limit, which caps the amount of data that can be read from application/x-www-form-urlencoded bodies.
Attack Vector
The attack vector is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by:
- Sending HTTP POST requests to any endpoint of a vulnerable Rack-based application
- Setting the Content-Type header to application/x-www-form-urlencoded
- Including an extremely large request body (potentially gigabytes of data)
- Repeating requests to accelerate memory exhaustion
The vulnerability is particularly dangerous because the application/x-www-form-urlencoded content type is commonly used in web forms, meaning most Rack applications accept this content type by default. No special characters or encoding tricks are required—simple repetition of any character in the body is sufficient to trigger the memory exhaustion condition.
Detection Methods for CVE-2025-61919
Indicators of Compromise
- Unusual spikes in memory consumption on Ruby/Rack application servers
- High number of incoming POST requests with Content-Type: application/x-www-form-urlencoded headers
- HTTP requests with abnormally large Content-Length values targeting application endpoints
- Application crashes or out-of-memory (OOM) errors in server logs
Detection Strategies
- Implement network monitoring to detect HTTP POST requests with excessively large Content-Length headers
- Configure web application firewalls (WAF) to alert on requests exceeding normal body size thresholds
- Monitor application performance metrics for sudden memory usage spikes correlated with incoming requests
- Review web server access logs for patterns of repeated large POST requests from single IP addresses or ranges
Monitoring Recommendations
- Set up alerts for memory utilization exceeding baseline thresholds on application servers
- Enable detailed logging of request sizes at the reverse proxy or load balancer level
- Implement rate limiting for POST requests to prevent rapid-fire exploitation attempts
- Deploy application performance monitoring (APM) tools to correlate memory events with specific request patterns
How to Mitigate CVE-2025-61919
Immediate Actions Required
- Upgrade Rack to version 2.2.20, 3.1.18, or 3.2.3 immediately
- Review and audit all Ruby web applications using Rack as a dependency
- Implement request body size limits at the web server or reverse proxy layer as defense-in-depth
- Monitor application servers for signs of exploitation attempts during the remediation window
Patch Information
The Rack maintainers have released patched versions that enforce form parameter limits using query_parser.bytesize_limit, preventing unbounded reads of application/x-www-form-urlencoded bodies. Users should upgrade to:
- Version 2.2.20 for the 2.x release line
- Version 3.1.18 for the 3.1.x release line
- Version 3.2.3 for the 3.2.x release line
For detailed information about the fix, refer to the GitHub Security Advisory GHSA-6xw4-3v39-52mm and the associated fix commits:
Workarounds
- Configure Nginx with client_max_body_size directive to limit incoming request body sizes
- Configure Apache with LimitRequestBody directive to enforce maximum request body limits
- Deploy a reverse proxy or load balancer with request size filtering capabilities
- Implement application-level middleware to reject oversized requests before they reach Rack processing
# Nginx configuration example - limit request body to 1MB
# Add to server or location block in nginx.conf
client_max_body_size 1m;
# Apache configuration example - limit request body to 1MB (1048576 bytes)
# Add to httpd.conf or virtual host configuration
LimitRequestBody 1048576
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
