CVE-2025-59830

What it actually does

Rack::QueryParser before version 2.2.18 incorrectly applies its params_limit only when counting query parameters separated with ampersands (&), even though the parser also treats semicolons (;) as valid parameter separators. A remote attacker can send an HTTP request containing a very large number of semicolon-delimited query or form parameters, bypassing the intended parameter-count guardrail. The primary impact is denial of service through excessive CPU, memory allocation, request parsing time, garbage collection pressure, or worker exhaustion in Rack-based Ruby applications and frameworks that rely on Rack request parsing.

Why it matters to the business

Successful exploitation can make affected web applications slow, unstable, or temporarily unavailable without requiring authentication. Public-facing Ruby/Rack services are the highest-risk exposure because attackers can trigger resource exhaustion with crafted HTTP requests. Although this issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has low reported EPSS probability, the CVSS severity is high because exploitation can directly affect service availability.

How an attack unfolds

An attacker identifies an application or API endpoint backed by a vulnerable Rack version. Instead of sending a normal query string such as a=1&b=2, the attacker sends an oversized request with many parameters separated by semicolons, such as a1=x;a2=x;a3=x and so on. Because vulnerable Rack versions split on semicolons but enforce the configured params_limit only against ampersand-separated parameters, the request can cause the application to parse far more parameters than intended. Repeated requests can consume application worker capacity, increase memory and CPU usage, trigger slow responses or timeouts, and potentially cause process restarts or service unavailability.

How to fix it

Upgrade Rack to version 2.2.18 or later, or apply the upstream fix identified by commit 0f76d43c0d5624bd0d325df4f0a63f5e1faa7254 if tracking Rack directly from Git. Rebuild and redeploy applications that vendor or bundle Rack through Ruby gems, framework dependencies, container images, or platform buildpacks. If immediate upgrade is not possible, add compensating controls at the reverse proxy, load balancer, CDN, or WAF to limit maximum URL length, maximum query-string length, request body size, request rate, and the number of semicolon-delimited parameters. Consider rejecting or normalizing semicolon-separated query parameters unless they are explicitly required by the application.

How to confirm the fix worked

Confirm the running application resolves Rack to version 2.2.18 or later, for example by checking Gemfile.lock, bundle info rack, gem list rack, software composition analysis results, container SBOMs, or deployed artifact manifests. Validate that no deployed application image or runtime still contains Rack versions below 2.2.18. In a controlled test environment, send requests with more semicolon-delimited parameters than the configured params_limit and verify the request is rejected, limited, or handled without excessive resource consumption. Review edge controls to ensure maximum query-string length and request-rate policies are active and applied to public endpoints.

Typical attack path

1. Discover a Ruby/Rack-backed web application or API endpoint exposed over HTTP or HTTPS.
2. Send test requests with semicolon-delimited query parameters to confirm the application accepts semicolon separators.
3. Craft requests containing an excessive number of semicolon-separated parameters that exceed the intended Rack params_limit.
4. Send the oversized requests repeatedly or concurrently to increase request parsing cost.
5. Cause elevated CPU, memory pressure, garbage collection overhead, request queueing, 5xx errors, timeouts, or worker exhaustion.

How to detect it

Look for evidence of resource-exhaustion attempts rather than code execution artifacts. Relevant sources include web server access logs, reverse proxy logs, CDN/WAF logs, application logs, APM traces, container or host metrics, process supervisor logs, and load balancer health-check events. Search for HTTP request URIs or query strings containing unusually many semicolon-separated key-value pairs, especially long URLs with repeated patterns like ;name=value. Correlate those requests with increased request duration, elevated CPU or memory, garbage collection spikes, application worker restarts, request timeouts, and bursts of 5xx or 429 responses. Because the vulnerability is in request parsing, successful exploitation may leave only HTTP access log evidence and operational symptoms; there are no expected dropped files, new processes, registry keys, or persistent host artifacts.

• ;
• \?.*=[^ ]*;[^ ]*=
• (;[^=;& ]+=){50,}
• (;[^=;& ]+=){100,}
• (;[^=;& ]+=){500,}
• HTTP request URI with more than 50 semicolon-delimited parameters
• HTTP request URI with more than 100 semicolon-delimited parameters
• HTTP request URI with query string length greater than 8192 bytes and repeated semicolons
• Rack::QueryParser
• params_limit

What your security team should do

• Inventory all Ruby applications, Rails/Sinatra/Rack services, containers, and build artifacts that include Rack versions below 2.2.18.
• Prioritize patching internet-facing services and high-traffic APIs first, then internal services that process untrusted HTTP requests.
• Upgrade Rack to 2.2.18 or later, or apply upstream commit 0f76d43c0d5624bd0d325df4f0a63f5e1faa7254 when using Git-sourced Rack.
• Deploy temporary WAF or reverse-proxy rules that reject unusually long query strings or requests containing very high counts of semicolon-separated parameters.
• Add monitoring for spikes in semicolon-heavy query strings, request parsing latency, 408/429/500/502/503/504 responses, memory usage, CPU usage, and application worker restarts.
• Review access logs for historical evidence of oversized semicolon-delimited requests, especially around periods of degraded availability.