Search for packages
| purl | pkg:gem/rack@2.2.7 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-47ja-djzb-2bbw
Aliases: CVE-2025-46727 GHSA-gjh7-p2fx-99vx |
Rack has an Unbounded-Parameter DoS in Rack::QueryParser ## Summary `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. ## Details 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. ## Impact 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. ## Mitigation - Update to a version of Rack that limits the number of parameters parsed, or - 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 by 9 other vulnerabilities. Affected by 8 other vulnerabilities. Affected by 8 other vulnerabilities. |
|
VCID-7p12-ejdu-uqgy
Aliases: CVE-2025-27111 GHSA-8cgq-6mh2-7j6v |
Escape Sequence Injection vulnerability in Rack lead to Possible Log Injection ## Summary `Rack::Sendfile` can be exploited by crafting input that includes newline characters to manipulate log entries. ## Details The `Rack::Sendfile` middleware logs unsanitized header values from the `X-Sendfile-Type` header. An attacker can exploit this by injecting escape sequences (such as newline characters) into the header, resulting in log injection. ## Impact This vulnerability can distort log files, obscure attack traces, and complicate security auditing. ## Mitigation - Update to the latest version of Rack, or - Remove usage of `Rack::Sendfile`. |
Affected by 12 other vulnerabilities. Affected by 26 other vulnerabilities. Affected by 10 other vulnerabilities. Affected by 10 other vulnerabilities. |
|
VCID-7wvj-9h3p-23am
Aliases: CVE-2025-49007 GHSA-47m2-26rw-j2jw |
ReDoS Vulnerability in Rack::Multipart handle_mime_head ### Summary There is a denial of service vulnerability in the Content-Disposition parsing component of Rack. This is very similar to the previous security issue CVE-2022-44571. ### Details Carefully crafted input can cause Content-Disposition header parsing in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. This header is used typically used in multipart parsing. Any applications that parse multipart posts using Rack (virtually all Rails applications) are impacted. ### Credits Thanks to [scyoon](https://hackerone.com/scyoon) for reporting this to the Rails security team |
Affected by 8 other vulnerabilities. |
|
VCID-7zgg-tvu3-r7gt
Aliases: CVE-2024-25126 GHSA-22f2-v57c-j9cx |
Rack vulnerable to ReDoS in content type parsing (2nd degree polynomial) ### Summary ```ruby module Rack class MediaType SPLIT_PATTERN = %r{\s*[;,]\s*} ``` The above regexp is subject to ReDos. 50K blank characters as a prefix to the header will take over 10s to split. ### PoC A simple HTTP request with lots of blank characters in the content-type header: ```ruby request["Content-Type"] = (" " * 50_000) + "a," ``` ### Impact It's a very easy to craft ReDoS. Like all ReDoS the impact is debatable. |
Affected by 14 other vulnerabilities. Affected by 12 other vulnerabilities. |
|
VCID-9rpp-9xss-duf6
Aliases: CVE-2026-22860 GHSA-mxw3-3hh2-x2mh |
Rack has a Directory Traversal via Rack:Directory ## Summary `Rack::Directory`’s path check used a string prefix match on the expanded path. A request like `/../root_example/` can escape the configured root if the target path starts with the root string, allowing directory listing outside the intended root. ## Details In `directory.rb`, `File.expand_path(File.join(root, path_info)).start_with?(root)` does not enforce a path boundary. If the server root is `/var/www/root`, a path like `/var/www/root_backup` passes the check because it shares the same prefix, so `Rack::Directory` will list that directory also. ## Impact Information disclosure via directory listing outside the configured root when `Rack::Directory` is exposed to untrusted clients and a directory shares the root prefix (e.g., `public2`, `www_backup`). ## Mitigation * Update to a patched version of Rack that correctly checks the root prefix. * Don't name directories with the same prefix as one which is exposed via `Rack::Directory`. |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-arac-j5h5-zkcu
Aliases: CVE-2024-26141 GHSA-xj5v-6v4g-jfw6 |
Rack has possible DoS Vulnerability with Range Header # Possible DoS Vulnerability with Range Header in Rack There is a possible DoS vulnerability relating to the Range request header in Rack. This vulnerability has been assigned the CVE identifier CVE-2024-26141. Versions Affected: >= 1.3.0. Not affected: < 1.3.0 Fixed Versions: 3.0.9.1, 2.2.8.1 Impact ------ Carefully crafted Range headers can cause a server to respond with an unexpectedly large response. Responding with such large responses could lead to a denial of service issue. Vulnerable applications will use the `Rack::File` middleware or the `Rack::Utils.byte_ranges` methods (this includes Rails applications). Releases -------- The fixed releases are available at the normal locations. Workarounds ----------- There are no feasible workarounds for this issue. Patches ------- To aid users who aren't able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset. * 3-0-range.patch - Patch for 3.0 series * 2-2-range.patch - Patch for 2.2 series Credits ------- Thank you [ooooooo_q](https://hackerone.com/ooooooo_q) for the report and patch |
Affected by 14 other vulnerabilities. Affected by 12 other vulnerabilities. |
|
VCID-azu5-jcmd-3ufx
Aliases: CVE-2025-61772 GHSA-wpv5-97wm-hp9c |
Rack's multipart parser buffers unbounded per-part headers, enabling DoS (memory exhaustion) `Rack::Multipart::Parser` can accumulate unbounded data when a multipart part’s header block never terminates with the required blank line (`CRLFCRLF`). The parser keeps appending incoming bytes to memory without a size cap, allowing a remote attacker to exhaust memory and cause a denial of service (DoS). |
Affected by 4 other vulnerabilities. Affected by 26 other vulnerabilities. Affected by 4 other vulnerabilities. Affected by 4 other vulnerabilities. |
|
VCID-c5sc-7qnn-mkb9
Aliases: CVE-2025-61771 GHSA-w9pc-fmgc-vxvw |
Rack: Multipart parser buffers large non‑file fields entirely in memory, enabling DoS (memory exhaustion) `Rack::Multipart::Parser` stores non-file form fields (parts without a `filename`) entirely in memory as Ruby `String` objects. A single large text field in a multipart/form-data request (hundreds of megabytes or more) can consume equivalent process memory, potentially leading to out-of-memory (OOM) conditions and denial of service (DoS). |
Affected by 4 other vulnerabilities. Affected by 26 other vulnerabilities. Affected by 4 other vulnerabilities. Affected by 4 other vulnerabilities. |
|
VCID-d58r-22kr-9bct
Aliases: CVE-2025-61780 GHSA-r657-rxjc-j557 |
Rack has a Possible Information Disclosure Vulnerability A possible information disclosure vulnerability existed in `Rack::Sendfile` when running behind a proxy that supports `x-sendfile` headers (such as Nginx). Specially crafted headers could cause `Rack::Sendfile` to miscommunicate with the proxy and trigger unintended internal requests, potentially bypassing proxy-level access restrictions. |
Affected by 2 other vulnerabilities. Affected by 26 other vulnerabilities. Affected by 2 other vulnerabilities. Affected by 2 other vulnerabilities. |
|
VCID-gdhf-e8q1-kbat
Aliases: CVE-2025-59830 GHSA-625h-95r8-8xpm |
Rack has an unsafe default in Rack::QueryParser allows params_limit bypass via semicolon-separated parameters `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. |
Affected by 7 other vulnerabilities. Affected by 26 other vulnerabilities. |
|
VCID-gtzk-m9rm-57hw
Aliases: CVE-2024-26146 GHSA-54rr-7fvw-6x8f |
Rack Header Parsing leads to Possible Denial of Service Vulnerability # Possible Denial of Service Vulnerability in Rack Header Parsing There is a possible denial of service vulnerability in the header parsing routines in Rack. This vulnerability has been assigned the CVE identifier CVE-2024-26146. Versions Affected: All. Not affected: None Fixed Versions: 2.0.9.4, 2.1.4.4, 2.2.8.1, 3.0.9.1 Impact ------ Carefully crafted headers can cause header parsing in Rack to take longer than expected resulting in a possible denial of service issue. Accept and Forwarded headers are impacted. Ruby 3.2 has mitigations for this problem, so Rack applications using Ruby 3.2 or newer are unaffected. Releases -------- The fixed releases are available at the normal locations. Workarounds ----------- There are no feasible workarounds for this issue. Patches ------- To aid users who aren't able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset. * 2-0-header-redos.patch - Patch for 2.0 series * 2-1-header-redos.patch - Patch for 2.1 series * 2-2-header-redos.patch - Patch for 2.2 series * 3-0-header-redos.patch - Patch for 3.0 series Credits ------- Thanks to [svalkanov](https://hackerone.com/svalkanov) for reporting this and providing patches! |
Affected by 14 other vulnerabilities. Affected by 12 other vulnerabilities. |
|
VCID-npag-sz7d-v7b6
Aliases: CVE-2025-61770 GHSA-p543-xpfm-54cp |
Rack's unbounded multipart preamble buffering enables DoS (memory exhaustion) `Rack::Multipart::Parser` buffers the entire multipart **preamble** (bytes before the first boundary) in memory without any size limit. A client can send a large preamble followed by a valid boundary, causing significant memory use and potential process termination due to out-of-memory (OOM) conditions. |
Affected by 4 other vulnerabilities. Affected by 26 other vulnerabilities. Affected by 4 other vulnerabilities. Affected by 4 other vulnerabilities. |
|
VCID-s971-gkdg-jkhc
Aliases: CVE-2025-61919 GHSA-6xw4-3v39-52mm |
Rack is vulnerable to a memory-exhaustion DoS through unbounded URL-encoded body parsing `Rack::Request#POST` reads the entire request body into memory for `Content-Type: application/x-www-form-urlencoded`, calling `rack.input.read(nil)` without enforcing a length or cap. Large request bodies can therefore be buffered completely into process memory before parsing, leading to denial of service (DoS) through memory exhaustion. |
Affected by 2 other vulnerabilities. Affected by 26 other vulnerabilities. Affected by 2 other vulnerabilities. Affected by 2 other vulnerabilities. |
|
VCID-skxv-7he3-xqgc
Aliases: CVE-2026-25500 GHSA-whrj-4476-wvmp |
Stored XSS in Rack::Directory via javascript: filenames rendered into anchor href ## Summary `Rack::Directory` generates an HTML directory index where each file entry is rendered as a clickable link. If a file exists on disk whose basename begins with the `javascript:` scheme (e.g. `javascript:alert(1)`), the generated index includes an anchor whose `href` attribute is exactly `javascript:alert(1)`. Clicking this entry executes arbitrary JavaScript in the context of the hosting application. This results in a client-side XSS condition in directory listings generated by `Rack::Directory`. ## Details `Rack::Directory` renders directory entries using an HTML row template similar to: ```html <a href='%s'>%s</a> ``` The `%s` placeholder is populated directly with the file’s basename. If the basename begins with `javascript:`, the resulting HTML contains an executable JavaScript URL: ```html <a href='javascript:alert(1)'>javascript:alert(1)</a> ``` Because the value is inserted directly into the `href` attribute without scheme validation or normalization, browsers interpret it as a JavaScript URI. When a user clicks the link, the JavaScript executes in the origin of the Rack application. ## Impact If `Rack::Directory` is used to expose filesystem contents over HTTP, an attacker who can create or upload files within that directory may introduce a malicious filename beginning with `javascript:`. When a user visits the directory listing and clicks the entry, arbitrary JavaScript executes in the application's origin. Exploitation requires user interaction (clicking the malicious entry). ## Mitigation * Update to a patched version of Rack in which `Rack::Directory` prefixes generated anchors with a relative path indicator (e.g. `./filename`). * Avoid exposing user-controlled directories via `Rack::Directory`. * Apply a strict Content Security Policy (CSP) to reduce impact of potential client-side execution issues. * Where feasible, restrict or sanitize uploaded filenames to disallow dangerous URI scheme prefixes. HackerOne profile: https://hackerone.com/thesmartshadow GitHub account owner: Ali Firas (@thesmartshadow) |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-w732-52bx-2qf8
Aliases: CVE-2025-25184 GHSA-7g2v-jj9q-g3rg |
Possible Log Injection in Rack::CommonLogger ## Summary `Rack::CommonLogger` can be exploited by crafting input that includes newline characters to manipulate log entries. The supplied proof-of-concept demonstrates injecting malicious content into logs. ## Details When a user provides the authorization credentials via `Rack::Auth::Basic`, if success, the username will be put in `env['REMOTE_USER']` and later be used by `Rack::CommonLogger` for logging purposes. The issue occurs when a server intentionally or unintentionally allows a user creation with the username contain CRLF and white space characters, or the server just want to log every login attempts. If an attacker enters a username with CRLF character, the logger will log the malicious username with CRLF characters into the logfile. ## Impact Attackers can break log formats or insert fraudulent entries, potentially obscuring real activity or injecting malicious data into log files. ## Mitigation - Update to the latest version of Rack. |
Affected by 13 other vulnerabilities. Affected by 26 other vulnerabilities. Affected by 11 other vulnerabilities. Affected by 11 other vulnerabilities. |
|
VCID-wt7k-s1yd-nke6
Aliases: CVE-2025-27610 GHSA-7wqh-767x-r66v |
Local File Inclusion in Rack::Static ## Summary `Rack::Static` can serve files under the specified `root:` even if `urls:` are provided, which may expose other files under the specified `root:` unexpectedly. ## Details The vulnerability occurs because `Rack::Static` does not properly sanitize user-supplied paths before serving files. Specifically, encoded path traversal sequences are not correctly validated, allowing attackers to access files outside the designated static file directory. ## Impact By exploiting this vulnerability, an attacker can gain access to all files under the specified `root:` directory, provided they are able to determine then path of the file. ## Mitigation - Update to the latest version of Rack, or - Remove usage of `Rack::Static`, or - Ensure that `root:` points at a directory path which only contains files which should be accessed publicly. It is likely that a CDN or similar static file server would also mitigate the issue. |
Affected by 11 other vulnerabilities. Affected by 26 other vulnerabilities. Affected by 9 other vulnerabilities. Affected by 9 other vulnerabilities. |
|
VCID-xazq-qrm1-9ff6
Aliases: CVE-2025-32441 GHSA-vpfw-47h7-xj4g |
Rack session gets restored after deletion ### Summary When using the `Rack::Session::Pool` middleware, simultaneous rack requests can restore a deleted rack session, which allows the unauthenticated user to occupy that session. ### Details [Rack session middleware](https://github.com/rack/rack/blob/v2.2.13/lib/rack/session/abstract/id.rb#L263-L270) prepares the session at the beginning of request, then saves is back to the store with possible changes applied by host rack application. This way the session becomes to be a subject of race conditions in general sense over concurrent rack requests. ### Impact When using the `Rack::Session::Pool` middleware, and provided the attacker can acquire a session cookie (already a major issue), the session may be restored if the attacker can trigger a long running request (within that same session) adjacent to the user logging out, in order to retain illicit access even after a user has attempted to logout. ## Mitigation - Update to the latest version of `rack`, or - Ensure your application invalidates sessions atomically by marking them as logged out e.g., using a `logged_out` flag, instead of deleting them, and check this flag on every request to prevent reuse, or - Implement a custom session store that tracks session invalidation timestamps and refuses to accept session data if the session was invalidated after the request began. ### Related As this code was moved to `rack-session` in Rack 3+, see <https://github.com/rack/rack-session/security/advisories/GHSA-9j94-67jr-4cqj> for the equivalent advisory in `rack-session` (affecting Rack 3+ only). |
Affected by 9 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| This package is not known to fix vulnerabilities. | ||