Search for packages
| purl | pkg:gem/rack@2.2.19 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
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-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-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. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| VCID-azu5-jcmd-3ufx | 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). |
CVE-2025-61772
GHSA-wpv5-97wm-hp9c |
| VCID-c5sc-7qnn-mkb9 | 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). |
CVE-2025-61771
GHSA-w9pc-fmgc-vxvw |
| VCID-npag-sz7d-v7b6 | 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. |
CVE-2025-61770
GHSA-p543-xpfm-54cp |