Summary
Rack::QueryParser in version < 2.2.18 enforces its params_limit only for parameters separated by &, while still splitting on both & and ;. As a result, attackers could use ; separators to bypass the parameter count limit and submit more parameters than intended.
Details
The issue arises because Rack::QueryParser#check_query_string counts only & characters when determining the number of parameters, but the default separator regex DEFAULT_SEP = /[&;] */n splits on both & and ;. This mismatch means that queries using ; separators were not included in the parameter count, allowing params_limit to be bypassed.
Other safeguards (bytesize_limit and key_space_limit) still applied, but did not prevent this particular bypass.
Impact
Applications or middleware that directly invoke Rack::QueryParser with its default configuration (no explicit delimiter) could be exposed to increased CPU and memory consumption. This can be abused as a limited denial-of-service vector.
Rack::Request, the primary entry point for typical Rack applications, uses QueryParser in a safe way and does not appear vulnerable by default. As such, the severity is considered low, with the impact limited to edge cases where QueryParser is used directly.
Mitigation
- Upgrade to a patched version of Rack where both
& and ; are counted consistently toward params_limit.
- If upgrading is not immediately possible, configure
QueryParser with an explicit delimiter (e.g., &) to avoid the mismatch.
- As a general precaution, enforce query string and request size limits at the web server or proxy layer (e.g., Nginx, Apache, or a CDN) to mitigate excessive parsing overhead.
References
kwkr Reporter
jeremyevans Remediation developer
ioquatix Remediation reviewer
Summary
Rack::QueryParserin version< 2.2.18enforces itsparams_limitonly for parameters separated by&, while still splitting on both∧. As a result, attackers could use;separators to bypass the parameter count limit and submit more parameters than intended.Details
The issue arises because
Rack::QueryParser#check_query_stringcounts only&characters when determining the number of parameters, but the default separator regexDEFAULT_SEP = /[&;] */nsplits on both∧. This mismatch means that queries using;separators were not included in the parameter count, allowingparams_limitto be bypassed.Other safeguards (
bytesize_limitandkey_space_limit) still applied, but did not prevent this particular bypass.Impact
Applications or middleware that directly invoke
Rack::QueryParserwith its default configuration (no explicit delimiter) could be exposed to increased CPU and memory consumption. This can be abused as a limited denial-of-service vector.Rack::Request, the primary entry point for typical Rack applications, usesQueryParserin a safe way and does not appear vulnerable by default. As such, the severity is considered low, with the impact limited to edge cases whereQueryParseris used directly.Mitigation
∧are counted consistently towardparams_limit.QueryParserwith an explicit delimiter (e.g.,&) to avoid the mismatch.References