CVE-2025-46727

What it actually does

Rack::QueryParser parses URL query strings and application/x-www-form-urlencoded request bodies into Ruby data structures without enforcing a maximum parameter count. An unauthenticated remote attacker can submit requests containing an extremely large number of parameters, causing excessive CPU work, memory allocation, garbage collection pressure, request worker exhaustion, and potentially process or service unavailability. The flaw is availability-only; it does not directly enable code execution, authentication bypass, or data disclosure.

Why it matters to the business

Applications built on affected Rack versions can be made slow or unavailable using comparatively simple HTTP requests, which may interrupt customer-facing web services, APIs, background integrations, and operational workflows that depend on Ruby Rack-based applications. Although EPSS is low and there is no known CISA KEV listing or public exploit maturity reported, the vulnerability has a high CVSS availability impact and is easy to trigger once an exposed Rack endpoint is identified, so internet-facing services should be prioritized for remediation.

How an attack unfolds

An attacker identifies a Rack-based web application or API endpoint that accepts query-string parameters or form-encoded POST bodies. The attacker sends one or more HTTP requests containing an unusually high number of distinct parameters, such as thousands or tens of thousands of key/value pairs. Vulnerable Rack::QueryParser instances attempt to parse all supplied parameters into Ruby objects without a parameter-count ceiling. This can consume large amounts of memory and CPU, increase garbage collection overhead, and tie up application server workers. Repeated requests can amplify the impact until legitimate requests time out, return 5xx errors, or the application process is killed or restarted by process supervision.

How to fix it

Upgrade Rack to a version containing the upstream fix. For source-based deployments, ensure rack/rack includes commit d0dcf75706d72d7e874ee31934a97881c1a439ce or a later release that incorporates it. Rebuild and redeploy all applications that vendor, bundle, or indirectly depend on Rack. If immediate upgrade is not possible, apply compensating controls at the reverse proxy, load balancer, WAF, or application middleware layer: enforce a maximum query-string length, maximum request body size, maximum number of form parameters, request rate limits, and timeouts for slow or resource-intensive requests. Prefer rejecting requests with abnormally high parameter counts before they reach the Ruby application process.

How to confirm the fix worked

Confirm the deployed Rack version or source revision includes commit d0dcf75706d72d7e874ee31934a97881c1a439ce or a later fixed release. Review dependency lockfiles and runtime package inventory to ensure all Rack copies were updated, including transitive dependencies. In a controlled non-production environment, send requests with parameter counts above the intended threshold and verify they are rejected quickly with a 4xx response or equivalent proxy rejection rather than being fully parsed by the application. Monitor application metrics during validation to confirm CPU, memory, garbage collection, and worker utilization remain stable under malformed high-parameter requests.

Typical attack path

1. Discover a Ruby Rack-based web application or API exposed over HTTP or HTTPS.
2. Select endpoints that accept GET query strings or POST requests with Content-Type: application/x-www-form-urlencoded.
3. Generate requests containing an extremely large number of parameters, often as repeated key/value pairs or many unique keys.
4. Send the oversized parameter requests directly or through parallel connections to increase parsing workload.
5. Rack::QueryParser attempts to parse the full parameter set, consuming CPU and memory and exhausting application workers.
6. The target application becomes slow, returns errors, restarts, or becomes unavailable to legitimate users.

How to detect it

To determine whether this was already exploited, review reverse proxy, load balancer, WAF, CDN, and application access logs for requests containing unusually long query strings or form-encoded bodies with very large numbers of parameters. Focus on spikes in requests where the URL query contains excessive '&' and '=' delimiters, POST requests with Content-Type: application/x-www-form-urlencoded and abnormally large bodies, repeated requests from the same source to a small set of endpoints, and requests followed by HTTP 500, 502, 503, 504, upstream timeout, or connection reset errors. Correlate these with application telemetry showing high CPU, memory growth, Ruby garbage collection spikes, increased request latency, application server worker exhaustion, process restarts, container OOM kills, or autoscaling events. For Ruby application logs, look for request timeout messages, Rack/Rails parameter parsing errors, memory allocation failures, killed workers, and abrupt restarts during the same time windows. Because exploitation does not require writing files or spawning unusual processes, network and application-layer request patterns are the most useful evidence.

• Content-Type: application/x-www-form-urlencoded
• upstream timed out
• upstream prematurely closed connection
• client intended to send too large body
• HTTP/1.1" 500
• HTTP/1.1" 502
• HTTP/1.1" 503
• HTTP/1.1" 504
• Rack::QueryParser
• Rack::Utils::ParameterTypeError
• Rack::Utils::InvalidParameterError
• ActionDispatch::ParamsParser
• ActionController::BadRequest
• Puma::WorkerKiller
• worker timeout
• OutOfMemoryError
• Cannot allocate memory
• Killed
• OOMKilled
• Memory limit exceeded
• GC.stat
• application/x-www-form-urlencoded

What your security team should do

• Inventory internet-facing and internal Ruby applications that use Rack, including Rails, Sinatra, Hanami, Grape, and custom Rack middleware stacks.
• Patch or rebuild affected applications so Rack includes commit d0dcf75706d72d7e874ee31934a97881c1a439ce or a later fixed release.
• Prioritize externally reachable applications, authentication endpoints, API gateways, and high-traffic services where denial of service would have the greatest operational impact.
• Add edge controls to limit query-string length, form body size, parameter count, request rate, and concurrent requests per source.
• Create detection for requests with unusually high counts of '&' or '=' characters in query strings or form-encoded bodies, especially when followed by 5xx responses, elevated latency, worker restarts, or memory spikes.
• Review historical web, proxy, WAF, and application logs for high-parameter requests around any unexplained availability incident.
• Ensure application performance monitoring alerts cover memory growth, CPU saturation, garbage collection spikes, request queue depth, worker exhaustion, and abnormal 4xx/5xx rates.