Search for packages
| purl | pkg:gem/rack@3.0.0.rc1 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
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 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-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. |
|
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 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 4 other vulnerabilities. |
|
VCID-c21j-snf1-d3cb
Aliases: CVE-2022-44572 GHSA-rqv2-275x-2jq5 GMS-2023-66 |
Duplicate This advisory duplicates another. |
Affected by 17 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 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 2 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 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 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 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. |
|
VCID-vkrw-y1j6-6fe7
Aliases: CVE-2022-44571 GHSA-93pm-5p5f-3ghx GMS-2023-65 |
Duplicate This advisory duplicates another. |
Affected by 17 other vulnerabilities. |
|
VCID-xkah-9nv9-wufd
Aliases: CVE-2023-27539 GHSA-c6qg-cjj8-47qp GMS-2023-769 |
Possible Denial of Service Vulnerability in Rack’s header parsing There is a denial of service vulnerability in the header parsing component of Rack. Carefully crafted input can cause header parsing in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. Any applications that parse headers using Rack (virtually all Rails applications) are impacted. Workarounds Setting `Regexp.timeout` in Ruby 3.2 is a possible workaround. |
Affected by 15 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| This package is not known to fix vulnerabilities. | ||