Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
50 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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. For example, a check such as req.host.startwith?("myapp.com") can be bypassed with Host: myapp.com@evil.com, and a check such as req.host.endwith?("myapp.com") can be bypassed with Host: evil.com/myapp.com. This can lead to host header poisoning in applications that use req.host, req.url, or req.baseurl for link generation, redirects, or origin validation. Details Rack::Request parses the authority component using logic equivalent to: The character class used for non-IPv6 hosts accepts nearly all printable characters except [ and ]. This includes reserved URI delimiters such as @, /, ?, and #, which are not valid hostname characters under RFC 3986 host syntax. As a result, values…
Recommended action: Upgrade to 3.2.6 or 3.1.21 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details Rack::Files#fail constructs error responses using logic equivalent to: Here, body.size returns the number of characters, not the number of bytes. For multibyte UTF-8 strings, this produces an incorrect Content-Length value. Rack::Files includes the decoded request path in 404 responses. A request containing percent-encoded UTF-8 path components therefore causes the response body to contain…
Recommended action: Upgrade to 3.2.6, 3.1.21 or 2.2.23 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Rack::Sendfile#mapaccelpath 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. Details Rack::Sendfile#mapaccelpath processes header-supplied mappings using logic equivalent to: Here, internal comes from the HTTPXACCELMAPPING request header and is inserted directly into a regular expression without escaping. This gives the header value regex semantics rather than treating it as a literal prefix. As a result, an attacker can supply metacharacters such as . or capture groups to alter how the path substitution is performed. For example, a…
Recommended action: Upgrade to 3.2.6, 3.1.21 or 2.2.23 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Rack::Multipart::Parser only wraps the request body in a BoundedIO when CONTENTLENGTH 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. Details Rack::Multipart::Parser.parse applies BoundedIO only when contentlength is not nil: When CONTENTLENGTH is absent, the parser reads the multipart body until EOF without a global byte limit. Although Rack enforces BUFFEREDUPLOADBYTESIZELIMIT for retained non-file parts, file uploads are handled differently.…
Recommended action: Upgrade to 3.2.6, 3.1.21 or 2.2.23 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details Rack::Directory::DirectoryBody#each computes the visible path using code equivalent to: Here, root is a developer-configured filesystem path. It is normalized earlier with File.expandpath(root) and then inserted directly into a regular expression without escaping. Because the value is treated as regex syntax rather than as a literal string, metacharacters in the configured path can change how the prefix match behaves. When that happens, the expected root prefix is not removed from path, and the absolute filesystem path is rendered into the HTML directory listing. Impact If Rack::Directory is configured to serve a directory whose absolute path contains regex…
Recommended action: Upgrade to 3.2.6, 3.1.21 or 2.2.23 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Rack::Utils.selectbestencoding 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. Details Rack::Utils.selectbestencoding expands parsed Accept-Encoding values into a list of candidate encodings. When an entry is , the method computes the set of concrete encodings by subtracting the encodings already present in the request: Because acceptencoding.map(&:first) is evaluated inside the loop, it is recomputed for each wildcard entry. If the request contains N wildcard entries, this produces repeated scans over the full parsed header and causes quadratic behavior. After expansion, the method…
Recommended action: Upgrade to 3.2.6, 3.1.21 or 2.2.23 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Rack::Utils.forwardedvalues parses the RFC 7239 Forwarded header by splitting on semicolons before handling quoted-string values. Because quoted values may legally contain semicolons, a header such as: 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. Details Rack::Utils.forwardedvalues processes the header using logic equivalent to: The method splits on ; before it parses individual name=value pairs. This is inconsistent with RFC 7239, which permits quoted-string values, and quoted strings may contain semicolons as literal content. As a result, a header value such as: is not treated as a single for value. Instead, Rack may interpret it as if the client had supplied separate for, host, and…
Recommended action: Upgrade to 3.2.6 or 3.1.21 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Rack::Multipart::Parser unfolds folded multipart part headers incorrectly. When a multipart header contains an obs-fold sequence, Rack preserves the embedded CRLF in parsed parameter values such as filename or name instead of removing the folded line break during unfolding. As a result, applications that later reuse those parsed values in HTTP response headers may be vulnerable to downstream header injection or response splitting. Details Rack::Multipart::Parser accepts folded multipart header values and unfolds them during parsing. However, the unfolding behavior does not fully remove the embedded line break sequence from the parsed value. This means a multipart part header such as: can result in a parsed parameter value that still contains CRLF characters. The issue is not that Rack creates a second multipart header field. Rather, the problem is that CRLF remains embedded in the parsed metadata value after unfolding. If an application later uses that value in a…
Recommended action: Upgrade to 3.2.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details Rack identifies the multipart boundary using logic equivalent to: Because the expression is greedy, it matches the last boundary= parameter in a header such as: As a result, Rack parses the request body using malicious, while another component may interpret the same header using safe. This creates an interpretation conflict. If an upstream WAF or proxy inspects multipart parts using the first boundary and Rack later parses the body using the last boundary, a client may be…
Recommended action: Upgrade to 3.2.6, 3.1.21 or 2.2.23 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Rack::Multipart::Parser#handlemimehead 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. Details Rack::Multipart::Parser#handlemimehead parses quoted parameter values by repeatedly: 1. Searching for the next quote or backslash, 2. Copying the preceding substring into a new buffer, and 3. Removing the processed prefix from the original string with slice!. An attacker can exploit this by sending a multipart request with many parts whose name parameters contain long escape-heavy values such as: Under…
Recommended action: Upgrade to 3.2.6 or 3.1.21 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Rack::Utils.getbyteranges 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. Details Rack::Utils.getbyteranges accepts a comma-separated list of byte ranges and validates them based on their aggregate size, but does not impose a limit on how many individual ranges may be supplied. As a result, a request such as: can contain thousands of overlapping one-byte ranges while still satisfying the total-size check added for CVE-2024-26141. When such a header is processed by Rack’s file-serving code, each range causes additional…
Recommended action: Upgrade to 3.2.6, 3.1.21 or 2.2.23 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Rack::Static#applicablerules evaluates several headerrules types against the raw URL-encoded PATHINFO, 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 headerrules 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. Details Rack::Static#applicablerules matches rule types such as :fonts, Array, and Regexp directly against the incoming PATHINFO. For example: These checks operate on the raw request path. If the request contains encoded characters such as %2E in place of ., the rule may fail to match even though the file path is later decoded and served successfully by the static file server. For example, both of the following requests may resolve to the same file on…
Recommended action: Upgrade to 3.2.6, 3.1.21 or 2.2.23 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details Rack::Static#routefile performs static-route matching using logic equivalent to: This checks only whether the request path starts with the configured prefix string. It does not require a path segment boundary after the prefix. For example, with: the following path is matched as intended: but these paths are also matched: If such files exist under the configured static root, Rack forwards the request to the file server and serves them as static content. This means a configuration intended to expose only directory trees such as…
Recommended action: Upgrade to 3.2.6, 3.1.21 or 2.2.23 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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: 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.…
Recommended action: Upgrade to 3.2.5, 3.1.20 or 2.2.22 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Rack::Directory’s path check used a string prefix match on the expanded path. A request like /../rootexample/ 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.expandpath(File.join(root, pathinfo)).startwith?(root) does not enforce a path boundary. If the server root is /var/www/root, a path like /var/www/rootbackup 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, wwwbackup). 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.
Recommended action: Upgrade to 3.2.5, 3.1.20 or 2.2.22 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details When handling non-multipart form submissions, Rack’s request parser performs: Since read is called with no argument, the entire request body is loaded into a Ruby String. This occurs before query parameter parsing or enforcement of any paramslimit. As a result, Rack applications without an upstream body-size limit can experience unbounded memory allocation proportional to request size. Impact Attackers can send large application/x-www-form-urlencoded bodies to consume process memory, causing slowdowns or termination by the operating system (OOM). The effect scales linearly with request size and concurrency. Even with parsing limits…
Recommended action: Upgrade to 3.2.3, 3.1.18 or 2.2.20 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details When Rack::Sendfile received untrusted x-sendfile-type or x-accel-mapping headers from a client, it would interpret them as proxy configuration directives. This could cause the middleware to send a "redirect" response to the proxy, prompting it to reissue a new internal request that was not subject to the proxy's access controls. An attacker could exploit this by: 1. Setting a crafted x-sendfile-type: x-accel-redirect header. 2. Setting a crafted x-accel-mapping header. 3. Requesting a path that qualifies for proxy-based acceleration. Impact Attackers could bypass proxy-enforced restrictions and access internal endpoints intended to be…
Recommended action: Upgrade to 3.2.3, 3.1.18 or 2.2.20 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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). Details While reading multipart headers, the parser waits for CRLFCRLF using: If the terminator never appears, it continues appending data (@sbuf.concat(content)) indefinitely. There is no limit on accumulated header bytes, so a single malformed part can consume memory proportional to the request body size. Impact Attackers can send incomplete multipart headers to trigger high memory use, leading to process termination (OOM) or severe slowdown. The effect scales with request size limits and concurrency. All applications handling multipart uploads may be affected. Mitigation Upgrade to a patched Rack version that caps per-part header size (e.g., 64 KiB). Until then, restrict…
Recommended action: Upgrade to 3.2.2, 3.1.17 or 2.2.19 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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). Details During multipart parsing, file parts are streamed to temporary files, but non-file parts are buffered into memory: There is no size limit on these in-memory buffers. As a result, any large text field—while technically valid—will be loaded fully into process memory before being added to params. Impact Attackers can send large non-file fields to trigger excessive memory usage. Impact scales with request size and concurrency, potentially leading to worker crashes or severe garbage-collection overhead. All Rack applications processing multipart form submissions are affected. Mitigation Upgrade: Use a patched version of Rack that enforces a…
Recommended action: Upgrade to 3.2.2, 3.1.17 or 2.2.19 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details While searching for the first boundary, the parser appends incoming data into a shared buffer (@sbuf.concat(content)) and scans for the boundary pattern: If the boundary is not yet found, the parser continues buffering data indefinitely. There is no trimming or size cap on the preamble, allowing attackers to send arbitrary amounts of data before the first boundary. Impact Remote attackers can trigger large transient memory spikes by including a long preamble in multipart/form-data requests. The impact scales with allowed request sizes and concurrency, potentially causing worker crashes or severe slowdown due to garbage collection. Mitigation Upgrade: Use a patched version of…
Recommended action: Upgrade to 3.2.2, 3.1.17 or 2.2.19 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Rack::QueryParser in version < 2.2.18 enforces its paramslimit 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. Details The issue arises because Rack::QueryParser#checkquerystring counts only & characters when determining the number of parameters, but the default separator regex DEFAULTSEP = /[&;] /n splits on both & and ;. This mismatch means that queries using ; separators were not included in the parameter count, allowing paramslimit to be bypassed. Other safeguards (bytesizelimit and keyspacelimit) still applied, but did not prevent this particular bypass. Impact Applications or middleware that directly invoke Rack::QueryParser with its default configuration (no explicit delimiter) could be exposed to increased CPU and memory consumption. This can be abused as a limited denial-of-service vector. Rack::Request, the primary…
Recommended action: Upgrade to 2.2.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 for reporting this to the Rails security team
Recommended action: Upgrade to 3.1.16 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 3.1.14, 3.0.16 or 2.2.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 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 loggedout flag, instead of…
Recommended action: Upgrade to 2.2.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 3.1.12, 3.0.14 or 2.2.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.