CVE-2025-59830

An unsafe default behavior in Rack::QueryParser allows bypass of the params_limit parameter count restriction when query string parameters are delimited by semicolons (;) rather than ampersands (&). The parser counts only & when enforcing the limit, while still splitting on both & and ;. As a result, an attacker can supply a crafted HTTP query using ; delimiters to exceed the intended parameter count, potentially causing performance degradation or exhaustion of resources (denial of service).

The overall severity of this flaw is Moderate, because most Rack applications are not directly impacted. The vulnerability primarily affects applications or middleware that invoke Rack::QueryParser directly using its default configuration, which accepts both & and ; as parameter delimiters. This behavior can lead to excessive CPU or memory consumption, resulting only a limited denial-of-service condition.

For typical applications using Rack::Request, the default request-handling flow applies safe parsing logic and does not exhibit the vulnerable behavior.

In summary, while the theoretical severity is High, the practical impact is generally Moderate to Low for standard configurations.

Affectedness:

It should be noted that starting from Rack v3.x, the framework no longer splits query parameters on semicolons. This change was introduced in commit ef1fc0c44e6a4b77c8fcf9b4f3bfa09f04ae8482, effectively mitigating this issue in newer releases.

Rack 1.x is also not affected by this vulnerability. The vulnerable parsing logic was introduced in Rack 2.x; earlier versions use a simpler query parsing mechanism that does not expose the same resource exhaustion risk.

Additionally, Ruby 2.x and 3.x versions shipped with Red Hat Enterprise Linux are not affected, as they do not bundle the rack RubyGem by default. Rack is a third-party gem that must be installed separately.

The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.

No action is required for typical Rack applications that use the framework’s default request-handling mechanisms, as these are not impacted.

For custom implementations or middleware that directly invoke Rack::QueryParser, administrators should:

Use explicit delimiters: Configure QueryParser to use a specific delimiter (e.g. &) rather than accepting both & and ;.

Limit request size and parameters: Enforce request size and parameter count limits at upstream layers (such as a web server, reverse proxy, or WAF) to prevent excessive resource consumption.

Prefer safe APIs: Use Rack::Request or other higher-level request parsing APIs, which apply safe defaults and avoid this vulnerability.