Search for packages
| purl | pkg:gem/rack@3.2.0 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-1j61-5e8x-7fbd
Aliases: CVE-2026-34829 GHSA-8vqr-qjwx-82mw |
Rack is a modular Ruby web server interface. Prior to versions 2.2.23, 3.1.21, and 3.2.6, Rack::Multipart::Parser only wraps the request body in a BoundedIO when CONTENT_LENGTH is present. When a multipart/form-data request is sent without a Content-Length header, such as with HTTP chunked transfer encoding, multipart parsing continues until end-of-stream with no total size limit. For file parts, the uploaded body is written directly to a temporary file on disk rather than being constrained by the buffered in-memory upload limit. An unauthenticated attacker can therefore stream an arbitrarily large multipart file upload and consume unbounded disk space. This results in a denial of service condition for Rack applications that accept multipart form data. This issue has been patched in versions 2.2.23, 3.1.21, and 3.2.6. |
Affected by 0 other vulnerabilities. |
|
VCID-2p73-rc9t-rudb
Aliases: CVE-2026-34831 GHSA-q2ww-5357-x388 |
Rack is a modular Ruby web server interface. Prior to versions 2.2.23, 3.1.21, and 3.2.6, Rack::Files#fail sets the Content-Length response header using String#size instead of String#bytesize. When the response body contains multibyte UTF-8 characters, the declared Content-Length is smaller than the number of bytes actually sent on the wire. Because Rack::Files reflects the requested path in 404 responses, an attacker can trigger this mismatch by requesting a non-existent path containing percent-encoded UTF-8 characters. This results in incorrect HTTP response framing and may cause response desynchronization in deployments that rely on the incorrect Content-Length value. This issue has been patched in versions 2.2.23, 3.1.21, and 3.2.6. |
Affected by 0 other vulnerabilities. |
|
VCID-2qba-a6bp-ryak
Aliases: CVE-2026-34785 GHSA-h2jq-g4cq-5ppq |
Rack is a modular Ruby web server interface. Prior to versions 2.2.23, 3.1.21, and 3.2.6, Rack::Static determines whether a request should be served as a static file using a simple string prefix check. When configured with URL prefixes such as "/css", it matches any request path that begins with that string, including unrelated paths such as "/css-config.env" or "/css-backup.sql". As a result, files under the static root whose names merely share the configured prefix may be served unintentionally, leading to information disclosure. This issue has been patched in versions 2.2.23, 3.1.21, and 3.2.6. |
Affected by 0 other vulnerabilities. |
|
VCID-5twm-pqc2-xyfn
Aliases: CVE-2026-34835 GHSA-g2pf-xv49-m2h5 |
Rack is a modular Ruby web server interface. From versions 3.0.0.beta1 to before 3.1.21, and 3.2.0 to before 3.2.6, Rack::Request parses the Host header using an AUTHORITY regular expression that accepts characters not permitted in RFC-compliant hostnames, including /, ?, #, and @. Because req.host returns the full parsed value, applications that validate hosts using naive prefix or suffix checks can be bypassed. This can lead to host header poisoning in applications that use req.host, req.url, or req.base_url for link generation, redirects, or origin validation. This issue has been patched in versions 3.1.21 and 3.2.6. |
Affected by 0 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. |
|
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. |
|
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. |
|
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. |
|
VCID-dh75-6jyw-1ke2
Aliases: CVE-2026-34827 GHSA-v6x5-cg8r-vv6x |
Rack is a modular Ruby web server interface. From versions 3.0.0.beta1 to before 3.1.21, and 3.2.0 to before 3.2.6, Rack::Multipart::Parser#handle_mime_head parses quoted multipart parameters such as Content-Disposition: form-data; name="..." using repeated String#index searches combined with String#slice! prefix deletion. For escape-heavy quoted values, this causes super-linear processing. An unauthenticated attacker can send a crafted multipart/form-data request containing many parts with long backslash-escaped parameter values to trigger excessive CPU usage during multipart parsing. This results in a denial of service condition in Rack applications that accept multipart form data. This issue has been patched in versions 3.1.21 and 3.2.6. |
Affected by 0 other vulnerabilities. |
|
VCID-j34j-bgfd-8fez
Aliases: CVE-2026-32762 GHSA-qfgr-crr9-7r49 |
Rack is a modular Ruby web server interface. From versions 3.0.0.beta1 to before 3.1.21 and 3.2.0 to before 3.2.6, Rack::Utils.forwarded_values parses the RFC 7239 Forwarded header by splitting on semicolons before handling quoted-string values. Because quoted values may legally contain semicolons, a header can be interpreted by Rack as multiple Forwarded directives rather than as a single quoted for value. In deployments where an upstream proxy, WAF, or intermediary validates or preserves quoted Forwarded values differently, this discrepancy can allow an attacker to smuggle host, proto, for, or by parameters through a single header value. This issue has been patched in versions 3.1.21 and 3.2.6. |
Affected by 0 other vulnerabilities. |
|
VCID-jg77-mm5c-gydu
Aliases: CVE-2026-34763 GHSA-7mqq-6cf9-v2qp |
Rack is a modular Ruby web server interface. Prior to versions 2.2.23, 3.1.21, and 3.2.6, Rack::Directory interpolates the configured root path directly into a regular expression when deriving the displayed directory path. If root contains regex metacharacters such as +, *, or ., the prefix stripping can fail and the generated directory listing may expose the full filesystem path in the HTML output. This issue has been patched in versions 2.2.23, 3.1.21, and 3.2.6. |
Affected by 0 other vulnerabilities. |
|
VCID-m98a-mcyb-c7fm
Aliases: CVE-2026-34786 GHSA-q4qf-9j86-f5mh |
Rack is a modular Ruby web server interface. Prior to versions 2.2.23, 3.1.21, and 3.2.6, Rack::Static#applicable_rules evaluates several header_rules types against the raw URL-encoded PATH_INFO, while the underlying file-serving path is decoded before the file is served. As a result, a request for a URL-encoded variant of a static path can serve the same file without the headers that header_rules were intended to apply. In deployments that rely on Rack::Static to attach security-relevant response headers to static content, this can allow an attacker to bypass those headers by requesting an encoded form of the path. This issue has been patched in versions 2.2.23, 3.1.21, and 3.2.6. |
Affected by 0 other vulnerabilities. |
|
VCID-metf-cghw-p3b5
Aliases: CVE-2026-34826 GHSA-x8cg-fq8g-mxfx |
Rack is a modular Ruby web server interface. Prior to versions 2.2.23, 3.1.21, and 3.2.6, Rack::Utils.get_byte_ranges parses the HTTP Range header without limiting the number of individual byte ranges. Although the existing fix for CVE-2024-26141 rejects ranges whose total byte coverage exceeds the file size, it does not restrict the count of ranges. An attacker can supply many small overlapping ranges such as 0-0,0-0,0-0,... to trigger disproportionate CPU, memory, I/O, and bandwidth consumption per request. This results in a denial of service condition in Rack file-serving paths that process multipart byte range responses. This issue has been patched in versions 2.2.23, 3.1.21, and 3.2.6. |
Affected by 0 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. |
|
VCID-p3dk-p1gb-kkem
Aliases: CVE-2026-34230 GHSA-v569-hp3g-36wr |
Rack is a modular Ruby web server interface. Prior to versions 2.2.23, 3.1.21, and 3.2.6, Rack::Utils.select_best_encoding processes Accept-Encoding values with quadratic time complexity when the header contains many wildcard (*) entries. Because this method is used by Rack::Deflater to choose a response encoding, an unauthenticated attacker can send a single request with a crafted Accept-Encoding header and cause disproportionate CPU consumption on the compression middleware path. This results in a denial of service condition for applications using Rack::Deflater. This issue has been patched in versions 2.2.23, 3.1.21, and 3.2.6. |
Affected by 0 other vulnerabilities. |
|
VCID-pbu7-4hdm-s3a6
Aliases: CVE-2026-34830 GHSA-qv7j-4883-hwh7 |
Rack is a modular Ruby web server interface. Prior to versions 2.2.23, 3.1.21, and 3.2.6, Rack::Sendfile#map_accel_path interpolates the value of the X-Accel-Mapping request header directly into a regular expression when rewriting file paths for X-Accel-Redirect. Because the header value is not escaped, an attacker who can supply X-Accel-Mapping to the backend can inject regex metacharacters and control the generated X-Accel-Redirect response header. In deployments using Rack::Sendfile with x-accel-redirect, this can allow an attacker to cause nginx to serve unintended files from configured internal locations. This issue has been patched in versions 2.2.23, 3.1.21, and 3.2.6. |
Affected by 0 other vulnerabilities. |
|
VCID-pnz8-yes1-pfc7
Aliases: CVE-2026-26962 GHSA-rx22-g9mx-qrhv |
Affected by 0 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. |
|
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. |
|
VCID-wvs1-dhwp-ebat
Aliases: CVE-2026-26961 GHSA-vgpv-f759-9wx3 |
Rack is a modular Ruby web server interface. Prior to versions 2.2.23, 3.1.21, and 3.2.6, Rack::Multipart::Parser extracts the boundary parameter from multipart/form-data using a greedy regular expression. When a Content-Type header contains multiple boundary parameters, Rack selects the last one rather than the first. In deployments where an upstream proxy, WAF, or intermediary interprets the first boundary parameter, this mismatch can allow an attacker to smuggle multipart content past upstream inspection and have Rack parse a different body structure than the intermediary validated. This issue has been patched in versions 2.2.23, 3.1.21, and 3.2.6. |
Affected by 0 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| This package is not known to fix vulnerabilities. | ||