CVE-2025-46727 is a high-severity (CVSS 7.5) Uncontrolled Resource Consumption vulnerability in rack. A fix is available for rack — see the affected versions and patch details below.
Unbounded-Parameter DoS in Rack::QueryParser
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2025-46727.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
rack💎rack💎rackReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects RubyGems packages — download data is not available via public APIs for these ecosystems.
Description
Rack is a modular Ruby web server interface. Prior to versions 2.2.14, 3.0.16, and 3.1.14, Rack::QueryParser parses query strings and application/x-www-form-urlencoded bodies into Ruby data structures without imposing any limit on the number of parameters, allowing attackers to send requests with extremely large numbers of parameters. The vulnerability arises because Rack::QueryParser iterates over each &-separated key-value pair and adds it to a Hash without enforcing an upper bound on the total number of parameters. This allows an attacker to send a single request containing hundreds of thousands (or more) of parameters, which consumes excessive memory and CPU during parsing. An attacker can trigger denial of service by sending specifically crafted HTTP requests, which can cause memory exhaustion or pin CPU resources, stalling or crashing the Rack server. This results in full service disruption until the affected worker is restarted. Versions 2.2.14, 3.0.16, and 3.1.14 fix the issue. Some other mitigations are available. One may use middleware to enforce a maximum query string size or parameter count, or employ a reverse proxy (such as Nginx) to limit request sizes and reject oversized query strings or bodies. Limiting request body sizes and query string lengths at the web server or CDN level is an effective mitigation.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💎RubyGems | rack | all versions | 2.2.14bundle update rack --conservative |
| 💎RubyGems | rack | ≥ 3.0&&< 3.0.16 | 3.0.16bundle update rack --conservative |
| 💎RubyGems | rack | ≥ 3.1&&< 3.1.14 | 3.1.14bundle update rack --conservative |
Affected Products
rackrackDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for rack, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update rack to 2.2.14 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2025-46727 is resolved across your whole dependency graph.
Workarounds
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
This vulnerability is rated as an IMPORTANT severity because the vulnerabilty was found in the Rack::QueryParser component which arises because Rack::QueryParser parses query strings and application/x-www-form-urlencoded bodies into Ruby data structures without imposing any limit on the number of parameters, when an…
This issue can be mitigated without upgrading by preventing oversized requests from reaching Rack. Deploy a reverse proxy (such as Nginx) in front of the application to limit request sizes and reject oversized query strings or bodies, use Rack middleware to enforce a maximum query string size or parameter count, or limit request body sizes and query string lengths at the web server or CDN level. These measures prevent a single request containing an extremely large number of parameters from consuming excessive memory or CPU during query parsing. For a permanent fix, update to a version of Rack that limits the number of parsed parameters (upstream Rack versions 2.2.14, 3.0.16, and 3.1.14…Source: Red Hat security advisory for CVE-2025-46727 (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat Enterprise Linux 10 | pcs-0:0.12.0-3.el10_0.2 | RHSA-2025:8319 |
| Red Hat Enterprise Linux 7 Extended Lifecycle Support | pcs-0:0.9.169-3.el7_9.4 | RHSA-2025:8322 |
| Red Hat Enterprise Linux 8 | pcs-0:0.10.18-2.el8_10.5 | RHSA-2025:8254 |
| Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support | pcs-0:0.10.8-1.el8_4.7 | RHSA-2025:8323 |
| Red Hat Enterprise Linux 8.6 Telecommunications Update Service | pcs-0:0.10.12-6.el8_6.8 | RHSA-2025:8290 |
| Red Hat Enterprise Linux 8.8 Extended Update Support | pcs-0:0.10.15-4.el8_8.6 | RHSA-2025:8279 |
| Red Hat Enterprise Linux 9 | pcs-0:0.11.9-2.el9_6.1 | RHSA-2025:8256 |
| Red Hat Enterprise Linux 9.0 Update Services for SAP Solutions | pcs-0:0.11.1-10.el9_0.8 | RHSA-2025:8291 |
Frequently Asked Questions
Is CVE-2025-46727 in your dependencies?
Find it across RubyGems, including transitive dependencies.