CVE-2025-61770
📋 TL;DR
This vulnerability in Rack (Ruby web server interface) allows remote attackers to cause denial of service through memory exhaustion. By sending multipart/form-data requests with excessively large preambles, attackers can trigger out-of-memory conditions that crash workers or severely degrade performance. All Ruby applications using vulnerable Rack versions for handling multipart requests are affected.
💻 Affected Systems
- Rack (Ruby web server interface)
📦 What is this software?
Rack by Rack
Rack by Rack
Rack by Rack
⚠️ Risk & Real-World Impact
Worst Case
Complete service outage due to worker process crashes from out-of-memory conditions, potentially affecting all application instances simultaneously under coordinated attack.
Likely Case
Performance degradation and intermittent worker crashes leading to service disruption, increased response times, and potential data loss for in-flight requests.
If Mitigated
Minimal impact with proper request size limits and memory monitoring, though some performance degradation may still occur during attack attempts.
🎯 Exploit Status
Exploitation requires only sending specially crafted HTTP requests with large multipart preambles. No authentication or special privileges needed.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: Rack 2.2.19, 3.1.17, or 3.2.2
Vendor Advisory: https://github.com/rack/rack/security/advisories/GHSA-p543-xpfm-54cp
Restart Required: Yes
Instructions:
1. Update Gemfile to specify rack >= 2.2.19, >= 3.1.17, or >= 3.2.2. 2. Run 'bundle update rack'. 3. Restart all application servers and workers. 4. Verify the update with 'bundle show rack'.
🔧 Temporary Workarounds
Limit request body size at proxy/load balancer
allConfigure maximum request size limits upstream to prevent large multipart requests from reaching vulnerable Rack instances
nginx: client_max_body_size 10M;
Apache: LimitRequestBody 10485760
Set per-process memory limits
linuxConfigure OS-level memory limits to prevent complete system exhaustion from OOM conditions
ulimit -v 1000000
systemd: MemoryMax=1G in service unit
🧯 If You Can't Patch
- Implement strict request size limits at reverse proxy/load balancer level (e.g., 10MB max)
- Deploy memory monitoring with automatic restart thresholds and implement rate limiting for multipart endpoints
🔍 How to Verify
Check if Vulnerable:
Check Rack version with 'bundle show rack' or 'gem list rack'. If version is below 2.2.19, 3.1.17, or 3.2.2, the system is vulnerable.Check Version:
bundle show rack | grep rackVerify Fix Applied:
Verify Rack version is 2.2.19+, 3.1.17+, or 3.2.2+ using 'bundle show rack'. Test with multipart requests containing large preambles to ensure they are rejected or handled properly.📡 Detection & Monitoring
Log Indicators:
- Unusually large request sizes (Content-Length)
- Out-of-memory errors in application logs
- Worker process restarts/crashes
- Garbage collection spikes in metrics
Network Indicators:
- Large multipart/form-data requests with Content-Type boundary
- Requests with preamble data before first boundary
SIEM Query:
source="application.log" AND ("out of memory" OR "OOM" OR "MemoryError" OR "Rack::Multipart")