Search for packages
| purl | pkg:deb/debian/ruby-rack@3.1.18-1~deb13u1?distro=trixie |
| Next non-vulnerable version | 3.1.20-0+deb13u1 |
| Latest non-vulnerable version | 3.2.6-2 |
| Risk | 4.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-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-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-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 |
|---|---|---|
| VCID-35e6-cpn8-w7h1 | Symlink path traversal in Rack::File Affected versions allows attackers to access arbitrary files outside the intended root directory via a crafted PATH_INFO environment variable, probably a directory traversal vulnerability that is remotely exploitable, aka "symlink path traversals." |
CVE-2013-0262
GHSA-85r7-w5mv-c849 OSV-89938 |
| VCID-3ycr-9smk-uqdc | Potential Denial of Service Vulnerability Carefully crafted requests can cause a `SystemStackError` and potentially cause a denial of service attack. |
CVE-2015-3225
GHSA-rgr4-9jh5-j4j6 |
| VCID-47ja-djzb-2bbw | 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. |
CVE-2025-46727
GHSA-gjh7-p2fx-99vx |
| VCID-6c1k-vgv4-93ad | Duplicate This advisory duplicates another. |
CVE-2022-44570
GHSA-65f5-mfpf-vfhj GMS-2023-64 |
| VCID-7p12-ejdu-uqgy | 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`. |
CVE-2025-27111
GHSA-8cgq-6mh2-7j6v |
| VCID-7wvj-9h3p-23am | 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 |
CVE-2025-49007
GHSA-47m2-26rw-j2jw |
| VCID-7zgg-tvu3-r7gt | 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. |
CVE-2024-25126
GHSA-22f2-v57c-j9cx |
| VCID-8zkw-y3yd-yuft | Directory traversal in Rack::Directory app bundled with Rack A directory traversal vulnerability exists in rack < 2.2.0 that allows an attacker perform directory traversal vulnerability in the Rack::Directory app that is bundled with Rack which could result in information disclosure. |
CVE-2020-8161
GHSA-5f9h-9pjv-v6j7 |
| VCID-91xe-ev7t-akb9 | Uncontrolled Resource Consumption lib/rack/multipart.rb in Rack uses an incorrect regular expression, which allows remote attackers to cause a denial of service (infinite loop) via a crafted Content-Disposion header. |
CVE-2012-6109
GHSA-h77x-m5q8-c29h OSV-89317 |
| VCID-9rpp-9xss-duf6 | 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`. |
CVE-2026-22860
GHSA-mxw3-3hh2-x2mh |
| VCID-9uh8-upzm-7bgd | Uncontrolled Resource Consumption Unspecified vulnerability in Rack::Auth::AbstractRequest in Rack allows remote attackers to cause a denial of service via unknown vectors related to "symbolized arbitrary strings." |
CVE-2013-0184
GHSA-v882-ccj6-jc48 OSV-89327 |
| VCID-9xy8-h3y1-mubv | Cross-site Scripting There is a possible XSS vulnerability in Rack. Carefully crafted requests can impact the data returned by the `scheme` method on `Rack::Request`. Applications that expect the scheme to be limited to HTTP or HTTPS and do not escape the return value could be vulnerable to an XSS attack. Note that applications using the normal escaping mechanisms provided by Rails may not be impacted, but applications that bypass the escaping mechanisms, or do not use them may be vulnerable. |
CVE-2018-16471
GHSA-5r2p-j47h-mhpg |
| VCID-arac-j5h5-zkcu | 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 |
CVE-2024-26141
GHSA-xj5v-6v4g-jfw6 |
| 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-c21j-snf1-d3cb | Duplicate This advisory duplicates another. |
CVE-2022-44572
GHSA-rqv2-275x-2jq5 GMS-2023-66 |
| 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-d58r-22kr-9bct | 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. |
CVE-2025-61780
GHSA-r657-rxjc-j557 |
| VCID-fpg2-nhey-rkcc | Rack has possible DoS Vulnerability in Multipart MIME parsing There is a possible DoS vulnerability in the Multipart MIME parsing code in Rack. This vulnerability has been assigned the CVE identifier CVE-2023-27530. Versions Affected: All. Not affected: None Fixed Versions: 3.0.4.2, 2.2.6.3, 2.1.4.3, 2.0.9.3 # Impact The Multipart MIME parsing code in Rack limits the number of file parts, but does not limit the total number of parts that can be uploaded. Carefully crafted requests can abuse this and cause multipart parsing to take longer than expected. All users running an affected release should either upgrade or use one of the workarounds immediately. # Workarounds A proxy can be configured to limit the POST body size which will mitigate this issue. |
CVE-2023-27530
GHSA-3h57-hmj3-gj3p GMS-2023-663 |
| VCID-gdhf-e8q1-kbat | 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. |
CVE-2025-59830
GHSA-625h-95r8-8xpm |
| VCID-ge4d-a8z8-m3c6 | Hash Collision Form Parameter Parsing Remote DoS This package contains a flaw that may allow a remote denial of service. The issue is triggered when an attacker sends multiple crafted parameters which trigger hash collisions, and will result in loss of availability for the program via CPU consumption. |
CVE-2011-5036
GHSA-v6j3-7jrw-hq2p OSV-78121 |
| VCID-gtzk-m9rm-57hw | 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! |
CVE-2024-26146
GHSA-54rr-7fvw-6x8f |
| 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 |
| VCID-qt1u-2p37-xfet | Multiple vulnerabilities have been discovered in Rack, the worst of which can lead to sequence injection in logging compontents. |
CVE-2022-30122
GHSA-hxqx-xwvh-44m2 GMS-2022-1643 |
| VCID-s971-gkdg-jkhc | 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. |
CVE-2025-61919
GHSA-6xw4-3v39-52mm |
| VCID-skxv-7he3-xqgc | 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) |
CVE-2026-25500
GHSA-whrj-4476-wvmp |
| VCID-stpq-7qys-t3cf | Rack ReDoS Vulnerability in HTTP Accept Headers Parsing ### Summary A Regular Expression Denial of Service (ReDoS) vulnerability exists in the `Rack::Request::Helpers` module when parsing HTTP Accept headers. This vulnerability can be exploited by an attacker sending specially crafted `Accept-Encoding` or `Accept-Language` headers, causing the server to spend excessive time processing the request and leading to a Denial of Service (DoS). ### Details The fix for https://github.com/rack/rack/security/advisories/GHSA-54rr-7fvw-6x8f was not applied to the main branch and thus while the issue was fixed for the Rack v3.0 release series, it was not fixed in the v3.1 release series until v3.1.5. |
CVE-2024-39316
GHSA-cj83-2ww7-mvq7 |
| VCID-sw69-1r7d-kkht | Uncontrolled Resource Consumption There is a possible DoS vulnerability in the multipart parser in Rack. Specially crafted requests can cause the multipart parser to enter a pathological state, causing the parser to use CPU resources disproportionate to the request size. |
CVE-2018-16470
GHSA-hg78-4f6x-99wq |
| VCID-teq8-nqhf-xbbq | Improper Restriction of Operations within the Bounds of a Memory Buffer multipart/parser.rb in Rack allows remote attackers to cause a denial of service (memory consumption and out-of-memory error) via a long string in a Multipart HTTP packet. |
CVE-2013-0183
GHSA-3pxh-h8hw-mj8w OSV-89320 |
| VCID-udc4-7jnt-y3fu | Multiple vulnerabilities have been discovered in Rack, the worst of which can lead to sequence injection in logging compontents. |
CVE-2022-30123
GHSA-wq4h-7r42-5hrr GMS-2022-1644 |
| VCID-vkrw-y1j6-6fe7 | Duplicate This advisory duplicates another. |
CVE-2022-44571
GHSA-93pm-5p5f-3ghx GMS-2023-65 |
| VCID-w732-52bx-2qf8 | 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. |
CVE-2025-25184
GHSA-7g2v-jj9q-g3rg |
| VCID-wt7k-s1yd-nke6 | 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. |
CVE-2025-27610
GHSA-7wqh-767x-r66v |
| VCID-xazq-qrm1-9ff6 | 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). |
CVE-2025-32441
GHSA-vpfw-47h7-xj4g |
| VCID-xkah-9nv9-wufd | 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. |
CVE-2023-27539
GHSA-c6qg-cjj8-47qp GMS-2023-769 |
| VCID-xnz5-gv2x-17bk | Rack allows Percent-encoded cookies to overwrite existing prefixed cookie names A reliance on cookies without validation/integrity check security vulnerability exists in rack < 2.2.3, rack < 2.1.4 that makes it possible for an attacker to forge a secure or host-only cookie prefix. |
CVE-2020-8184
GHSA-j6w9-fv6q-3q52 |
| VCID-y12d-fjpf-uubh | Timing attack against Rack::Session::Cookie Affected versions allows remote attackers to guess the session cookie, gain privileges, and execute arbitrary code via a timing attack involving am HMAC comparison function that does not run in constant time. |
CVE-2013-0263
GHSA-xc85-32mf-xpv8 OSV-89939 |
| VCID-yw62-qbkq-9ygq | Possible Information Leak / Session Hijack Vulnerability in Rack There's a possible information leak / session hijack vulnerability in Rack. Attackers may be able to find and hijack sessions by using timing attacks targeting the session id. Session ids are usually stored and indexed in a database that uses some kind of scheme for speeding up lookups of that session id. By carefully measuring the amount of time it takes to look up a session, an attacker may be able to find a valid session id and hijack the session. The session id itself may be generated randomly, but the way the session is indexed by the backing store does not use a secure comparison. ### Impact The session id stored in a cookie is the same id that is used when querying the backing session storage engine. Most storage mechanisms (for example a database) use some sort of indexing in order to speed up the lookup of that id. By carefully timing requests and session lookup failures, an attacker may be able to perform a timing attack to determine an existing session id and hijack that session. ## Releases The 1.6.12 and 2.0.8 releases are available at the normal locations. ### Workarounds There are no known workarounds. ### 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. * 1-6-session-timing-attack.patch - Patch for 1.6 series * 2-0-session-timing-attack.patch - Patch for 2.6 series ### Credits Thanks Will Leinweber for reporting this! |
CVE-2019-16782
GHSA-hrqr-hxpp-chr3 |