Rack has a root directory disclosure via unescaped regex interpolation in Rack::Directory

Summary

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:

show_path = Utils.escape_html(path.sub(/\A#{root}/, ''))

Here, root is a developer-configured filesystem path. It is normalized earlier with File.expand_path(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 metacharacters, the generated directory listing may disclose the full server filesystem path instead of only the request-relative path.

This can expose internal deployment details such as directory layout, usernames, mount points, or naming conventions that would otherwise not be visible to clients.

Mitigation

• Update to a patched version of Rack in which the root prefix is removed using an escaped regular expression.
• Avoid using Rack::Directory with a root path that contains regular expression metacharacters.

Rack's multipart parsing without Content-Length header allows unbounded chunked file uploads

Summary

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.

Details

Rack::Multipart::Parser.parse applies BoundedIO only when content_length is not nil:

io = BoundedIO.new(io, content_length) if content_length

When CONTENT_LENGTH is absent, the parser reads the multipart body until EOF without a global byte limit.

Although Rack enforces BUFFERED_UPLOAD_BYTESIZE_LIMIT for retained non-file parts, file uploads are handled differently. When a multipart part includes a filename, the body is streamed to a Tempfile, and the retained-size accounting is not applied to that file content. As a result, file parts are not subject to the same upload size bound.

An attacker can exploit this by sending a chunked multipart/form-data request containing a file part and continuously streaming data without declaring a Content-Length. Rack will continue writing the uploaded data to disk until the client stops or the server exhausts available storage.

Impact

Any Rack application that accepts multipart/form-data uploads may be affected if no upstream component enforces a request body size limit.

An unauthenticated attacker can send a large chunked file upload to consume disk space on the application host. This may cause request failures, application instability, or broader service disruption if the host runs out of available storage.

The practical impact depends on deployment architecture. Reverse proxies or application servers that enforce upload limits may reduce or eliminate exploitability, but Rack itself does not impose a total multipart upload limit in this code path when CONTENT_LENGTH is absent.

Mitigation

• Update to a patched version of Rack that enforces a total multipart upload size limit even when CONTENT_LENGTH is absent.
• Enforce request body size limits at the reverse proxy or application server.
• Isolate temporary upload storage and monitor disk consumption for multipart endpoints.

Rack::Request accepts invalid Host characters, enabling host allowlist bypass

Summary

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.start_with?("myapp.com") can be bypassed with Host: myapp.com@evil.com, and a check such as req.host.end_with?("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.base_url for link generation, redirects, or origin validation.

Details

Rack::Request parses the authority component using logic equivalent to:

AUTHORITY = /
  \A
  (?<host>
    \[(?<address>#{ipv6})\]
    |
    (?<address>[[[:graph:]&&[^\[\]]]]*?)
  )
  (:(?<port>\d+))?
  \z
/x

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 such as the following are accepted and returned through req.host:

myapp.com@evil.com
evil.com/myapp.com
evil.com#myapp.com

Applications that attempt to allowlist hosts using string prefix or suffix checks may therefore treat attacker-controlled hosts as trusted. For example:

req.host.start_with?("myapp.com")

accepts:

myapp.com@evil.com

and:

req.host.end_with?("myapp.com")

accepts:

evil.com/myapp.com

When those values are later used to build absolute URLs or enforce origin restrictions, the application may produce attacker-controlled results.

Impact

Applications that rely on req.host, req.url, or req.base_url may be affected if they perform naive host validation or assume Rack only returns RFC-valid hostnames.

In affected deployments, an attacker may be able to bypass host allowlists and poison generated links, redirects, or origin-dependent security decisions. This can enable attacks such as password reset link poisoning or other host header injection issues.

The practical impact depends on application behavior. If the application or reverse proxy already enforces strict host validation, exploitability may be reduced or eliminated.

Mitigation

• Update to a patched version of Rack that rejects invalid authority characters in Host.
• Enforce strict Host header validation at the reverse proxy or load balancer.
• Do not rely on prefix or suffix string checks such as start_with? or end_with? for host allowlisting.
• Use exact host allowlists, or exact subdomain boundary checks, after validating that the host is syntactically valid.

Rack::Static prefix matching can expose unintended files under the static root

Summary

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#route_file performs static-route matching using logic equivalent to:

@urls.any? { |url| path.index(url) == 0 }

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:

use Rack::Static, urls: ["/css", "/js"], root: "public"

the following path is matched as intended:

/css/style.css

but these paths are also matched:

/css-config.env
/css-backup.sql
/csssecrets.yml

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 /css/... and /js/... may also expose sibling files whose names begin with those same strings.

Impact

An attacker can request files under the configured static root whose names share a configured URL prefix and obtain their contents.

In affected deployments, this may expose configuration files, secrets, backups, environment files, or other unintended static content located under the same root directory.

Mitigation

• Update to a patched version of Rack that enforces a path boundary when matching configured static URL prefixes.
• Match only paths that are either exactly equal to the configured prefix or begin with prefix + "/".
• Avoid placing sensitive files under the Rack::Static root directory.
• Prefer static URL mappings that cannot overlap with sensitive filenames.

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.

Rack has Content-Length mismatch in Rack::Files error responses

Summary

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:

def fail(status, body, headers = {})
  body += "\n"
  [
    status,
    {
      "content-type" => "text/plain",
      "content-length" => body.size.to_s,
      "x-cascade" => "pass"
    }.merge!(headers),
    [body]
  ]
end

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 multibyte characters, while the Content-Length header still reflects character count rather than byte count.

As a result, the server can send more bytes than declared in the response headers.

This violates HTTP message framing requirements, which define Content-Length as the number of octets in the message body.

Impact

Applications using Rack::Files may emit incorrectly framed error responses when handling requests for non-existent paths containing multibyte characters.

In some deployment topologies, particularly with keep-alive connections and intermediaries that rely on Content-Length, this mismatch may lead to response parsing inconsistencies or response desynchronization. The practical exploitability depends on the behavior of downstream proxies, clients, and connection reuse.

Even where no secondary exploitation is possible, the response is malformed and may trigger protocol errors in strict components.

Mitigation

• Update to a patched version of Rack that computes Content-Length using String#bytesize.
• Avoid exposing Rack::Files directly to untrusted traffic until a fix is available, if operationally feasible.
• Where possible, place Rack behind a proxy or server that normalizes or rejects malformed backend responses.
• Prefer closing backend connections on error paths if response framing anomalies are a concern.

Rack:: Static header_rules bypass via URL-encoded paths

Summary

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.

Details

Rack::Static#applicable_rules matches rule types such as :fonts, Array, and Regexp directly against the incoming PATH_INFO. For example:

when :fonts
  /\.(?:ttf|otf|eot|woff2|woff|svg)\z/.match?(path)
when Array
  /\.(#{rule.join('|')})\z/.match?(path)
when Regexp
  rule.match?(path)

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 disk:

/fonts/test.woff
/fonts/test%2Ewoff

but only the unencoded form may receive the headers configured through header_rules.

This creates a canonicalization mismatch between the path used for header policy decisions and the path ultimately used for file serving.

Impact

Applications that rely on Rack::Static header_rules to apply security-relevant headers to static files may be affected.

In affected deployments, an attacker can request an encoded variant of a static file path and receive the same file without the intended headers. Depending on how header_rules are used, this may bypass protections such as clickjacking defenses, content restrictions, or other response policies applied to static content.

The practical impact depends on the configured rules and the types of files being served. If header_rules are only used for non-security purposes such as caching, the issue may have limited security significance.

Mitigation

• Update to a patched version of Rack that applies header_rules to a decoded path consistently with static file resolution.
• Do not rely solely on Rack::Static header_rules for security-critical headers where encoded path variants may reach the application.
• Prefer setting security headers at the reverse proxy or web server layer so they apply consistently to both encoded and unencoded path forms.
• Normalize or reject encoded path variants for static content at the edge, where feasible.

Rack: Forwarded Header semicolon injection enables Host and Scheme spoofing

Summary

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 such as:

Forwarded: for="127.0.0.1;host=evil.com;proto=https"

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.forwarded_values processes the header using logic equivalent to:

forwarded_header.split(';').each_with_object({}) do |field, values|
  field.split(',').each do |pair|
    pair = pair.split('=').map(&:strip).join('=')
    return nil unless pair =~ /\A(by|for|host|proto)="?([^"]+)"?\Z/i
    (values[$1.downcase.to_sym] ||= []) << $2
  end
end

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:

Forwarded: for="127.0.0.1;host=evil.com;proto=https"

is not treated as a single for value. Instead, Rack may interpret it as if the client had supplied separate for, host, and proto directives.

This creates an interpretation conflict when another component in front of Rack treats the quoted value as valid literal content, while Rack reparses it as multiple forwarding parameters.

Impact

Applications that rely on Forwarded to derive request metadata may observe attacker-controlled values for host, proto, for, or related URL components.

In affected deployments, this can lead to host or scheme spoofing in derived values such as req.host, req.scheme, req.base_url, or req.url. Applications that use those values for password reset links, redirects, absolute URL generation, logging, IP-based decisions, or backend requests may be vulnerable to downstream security impact.

The practical security impact depends on deployment architecture. If clients can already supply arbitrary trusted Forwarded parameters directly, this bug may not add meaningful attacker capability. The issue is most relevant where an upstream component and Rack interpret the same Forwarded header differently.

Mitigation

• Update to a patched version of Rack that parses Forwarded quoted-string values before splitting on parameter delimiters.
• Avoid trusting client-supplied Forwarded headers unless they are normalized or regenerated by a trusted reverse proxy.
• Prefer stripping inbound Forwarded headers at the edge and reconstructing them from trusted proxy metadata.
• Avoid using req.host, req.scheme, req.base_url, or req.url for security-sensitive operations unless the forwarding chain is explicitly trusted and validated.

Rack::Sendfile header-based X-Accel-Mapping regex injection enables unauthorized X-Accel-Redirect

Summary

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.

Details

Rack::Sendfile#map_accel_path processes header-supplied mappings using logic equivalent to:

mapping.split(',').map(&:strip).each do |m|
  internal, external = m.split('=', 2).map(&:strip)
  new_path = path.sub(/\A#{internal}/i, external)
  return new_path unless path == new_path
end

Here, internal comes from the HTTP_X_ACCEL_MAPPING 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 mapping such as:

X-Accel-Mapping: .*=/protected/secret.txt

causes the entire source path to match and rewrites the redirect target to a clean attacker-chosen internal path.

This differs from the documented behavior of the header-based mapping path, which is described as a simple substitution. While application-supplied mappings may intentionally support regular expressions, header-supplied mappings should be treated as literal path prefixes.

The issue is only exploitable when untrusted X-Accel-Mapping headers can reach Rack. One realistic case is a reverse proxy configuration that intends to set X-Accel-Mapping itself, but fails to do so on some routes, allowing a client-supplied header to pass through unchanged.

Impact

Applications using Rack::Sendfile with x-accel-redirect may be affected if the backend accepts attacker-controlled X-Accel-Mapping headers.

In affected deployments, an attacker may be able to control the X-Accel-Redirect response header and cause nginx to serve files from internal locations that were not intended to be reachable through the application. This can lead to unauthorized file disclosure.

The practical impact depends on deployment architecture. If the proxy always strips or overwrites X-Accel-Mapping, or if the application uses explicit configured mappings instead of the request header, exploitability may be eliminated.

Mitigation

• Update to a patched version of Rack that treats header-supplied X-Accel-Mapping values as literal strings rather than regular expressions.
• Strip or overwrite inbound X-Accel-Mapping headers at the reverse proxy so client-supplied values never reach Rack.
• Prefer explicit application-configured sendfile mappings instead of relying on request-header mappings.
• Review proxy sub-locations and inherited header settings to ensure X-Accel-Mapping is consistently set on all backend routes.

Rack has quadratic complexity in Rack::Utils.select_best_encoding via wildcard Accept-Encoding header

Summary

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.

Details

Rack::Utils.select_best_encoding 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:

if m == "*"
  (available_encodings - accept_encoding.map(&:first)).each do |m2|
    expanded_accept_encoding << [m2, q, preference]
  end
else
  expanded_accept_encoding << [m, q, preference]
end

Because accept_encoding.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 also performs additional work over expanded_accept_encoding, including per-entry deletion, which further increases the cost for large inputs.

Rack::Deflater invokes this method for each request when the middleware is enabled:

Utils.select_best_encoding(ENCODINGS, Utils.parse_encodings(accept_encoding))

As a result, a client can trigger this expensive code path simply by sending a large Accept-Encoding header containing many repeated wildcard values.

For example, a request with an approximately 8 KB Accept-Encoding header containing about 1,000 *;q=0.5 entries can cause roughly 170 ms of CPU time in a single request on the Rack::Deflater path, compared to a negligible baseline for a normal header.

This issue is distinct from CVE-2024-26146. That issue concerned regular expression denial of service during Accept header parsing, whereas this issue arises later during encoding selection after the header has already been parsed.

Impact

Any Rack application using Rack::Deflater may be affected.

An unauthenticated attacker can send requests with crafted Accept-Encoding headers to trigger excessive CPU usage in the encoding selection logic. Repeated requests can consume worker time disproportionately and reduce application availability.

The attack does not require invalid HTTP syntax or large payload bodies. A single header-sized request is sufficient to reach the vulnerable code path.

Mitigation

• Update to a patched version of Rack in which encoding selection does not repeatedly rescan the parsed header for wildcard entries.
• Avoid enabling Rack::Deflater on untrusted traffic.
• Apply request filtering or header size / format restrictions at the reverse proxy or application boundary to limit abusive Accept-Encoding values.

Rack's multipart header parsing allows Denial of Service via escape-heavy quoted parameters

Summary

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.

Details

Rack::Multipart::Parser#handle_mime_head 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:

name="a\\a\\a\\a\\a\\..."

Under default Rack limits, a request can contain up to 4095 parts. If many of those parts use long quoted values with dense escape characters, the parser performs disproportionately expensive CPU work while remaining within normal request size and part-count limits.

Impact

Any Rack application that accepts multipart/form-data requests may be affected, including file upload endpoints and standard HTML form handlers.

An unauthenticated attacker can send crafted multipart requests that consume excessive CPU time during request parsing. Repeated requests can tie up application workers, reduce throughput, and degrade or deny service availability.

Mitigation

• Update to a patched version of Rack that parses quoted multipart parameters without repeated rescanning and destructive prefix deletion.
• Apply request throttling or rate limiting to multipart upload endpoints.
• Where operationally feasible, restrict or isolate multipart parsing on untrusted high-volume endpoints.

Rack's greedy multipart boundary parsing can cause parser differentials and WAF bypass.

Summary

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:

MULTIPART = %r|\Amultipart/.*boundary=\"?([^\";,]+)\"?|ni

Because the expression is greedy, it matches the last boundary= parameter in a header such as:

Content-Type: multipart/form-data; boundary=safe; boundary=malicious

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 able to place malicious form fields or uploaded content in parts that Rack accepts but the upstream component did not inspect as intended.

This issue is most relevant in layered deployments where security decisions are made before the request reaches Rack.

Impact

Applications that accept multipart/form-data uploads behind an inspecting proxy or WAF may be affected.

In such deployments, an attacker may be able to bypass upstream filtering of uploaded files or form fields by sending a request with multiple boundary parameters and relying on the intermediary and Rack to parse the request differently.

The practical impact depends on deployment architecture. If no upstream component relies on a different multipart interpretation, this behavior may not provide meaningful additional attacker capability.

Mitigation

• Update to a patched version of Rack that rejects ambiguous multipart Content-Type headers or parses duplicate boundary parameters consistently.
• Reject requests containing multiple boundary parameters.
• Normalize or regenerate multipart metadata at the trusted edge before forwarding requests to Rack.
• Avoid relying on upstream inspection of malformed multipart requests unless duplicate parameter handling is explicitly consistent across components.

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:

<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:

<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)

Rack's multipart byte range processing allows denial of service via excessive overlapping ranges

Summary

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.

Details

Rack::Utils.get_byte_ranges 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:

Range: bytes=0-0,0-0,0-0,0-0,...

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 work, including multipart response generation, per-range iteration, file seek and read operations, and temporary string allocation for response size calculation and output. This allows a relatively small request header to trigger disproportionately expensive processing and a much larger multipart response.

The issue is distinct from CVE-2024-26141. That fix prevents range sets whose total byte coverage exceeds the file size, but does not prevent a large number of overlapping ranges whose summed size remains within that limit.

Impact

Applications that expose file-serving paths with byte range support may be vulnerable to denial of service.

An unauthenticated attacker can send crafted Range headers containing many small overlapping ranges to consume excessive CPU time, memory, file I/O, and bandwidth. Repeated requests may reduce application availability and increase pressure on workers and garbage collection.

Mitigation

• Update to a patched version of Rack that limits the number of accepted byte ranges.
• Reject or normalize multipart byte range requests containing excessive range counts.
• Consider disabling multipart range support where it is not required.
• Apply request filtering or header restrictions at the reverse proxy or application boundary to limit abusive Range headers.

Denial of service via header parsing in Rack

There is a possible denial of service vulnerability in the Range header parsing component of Rack. This vulnerability has been assigned the CVE identifier CVE-2022-44570.

Versions Affected: >= 1.5.0 Not affected: None. Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.2, 3.0.4.1

Impact

Carefully crafted input can cause the Range header parsing component in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. Any applications that deal with Range requests (such as streaming applications, or applications that serve files) may be impacted.

Workarounds

There are no feasible workarounds for this issue.

Denial of Service Vulnerability in Rack Content-Disposition parsing

There is a denial of service vulnerability in the Content-Disposition parsing component of Rack. This vulnerability has been assigned the CVE identifier CVE-2022-44571.

Versions Affected: >= 2.0.0 Not affected: None. Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.1, 3.0.4.1

Impact

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.

Workarounds

There are no feasible workarounds for this issue.

Denial of service via multipart parsing in Rack

There is a denial of service vulnerability in the multipart parsing component of Rack. This vulnerability has been assigned the CVE identifier CVE-2022-44572.

Versions Affected: >= 2.0.0 Not affected: None. Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.1, 3.0.4.1

Impact

Carefully crafted input can cause RFC2183 multipart boundary parsing in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. Any applications that parse multipart posts using Rack (virtually all Rails applications) are impacted.

Workarounds

There are no feasible workarounds for this issue.

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.

Possible Denial of Service Vulnerability in Rack’s header parsing

There is a denial of service vulnerability in the header parsing component of Rack. This vulnerability has been assigned the CVE identifier CVE-2023-27539.

Versions Affected: >= 2.0.0 Not affected: None. Fixed Versions: 2.2.6.4, 3.0.6.1

Impact

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.

Denial of Service Vulnerability in Rack Content-Type Parsing

There is a possible denial of service vulnerability in the content type parsing component of Rack. This vulnerability has been assigned the CVE identifier CVE-2024-25126.

Versions Affected: >= 0.4 Not affected: < 0.4 Fixed Versions: 3.0.9.1, 2.2.8.1

Impact

Carefully crafted content type headers can cause Rack’s media type parser to take much longer than expected, leading to a possible denial of service vulnerability.

Impacted code will use Rack’s media type parser to parse content type headers. This code will look like below:

request.media_type

## OR
request.media_type_params

## OR
Rack::MediaType.type(content_type)

Some frameworks (including Rails) call this code internally, so upgrading is recommended!

All users running an affected release should either upgrade or use one of the workarounds immediately.

Releases

The fixed releases are available at the normal locations.

Workarounds

There are no feasible workarounds for this issue.

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.

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.

Rack's unbounded multipart preamble buffering enables DoS (memory exhaustion)

Summary

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:

@sbuf.scan_until(@body_regex)

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 Rack that enforces a preamble size limit (e.g., 16 KiB) or discards preamble data entirely per RFC 2046 § 5.1.1.

• Workarounds:

  • Limit total request body size at the proxy or web server level.
  • Monitor memory and set per-process limits to prevent OOM conditions.

Multipart parser buffers large non‑file fields entirely in memory, enabling DoS (memory exhaustion)

Summary

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:

body = String.new  # non-file → in-RAM buffer
@mime_parts[mime_index].body << content

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 reasonable size cap for non-file fields (e.g., 2 MiB).

• Workarounds:

  • Restrict maximum request body size at the web-server or proxy layer (e.g., Nginx client_max_body_size).
  • Validate and reject unusually large form fields at the application level.

Rack's multipart parser buffers unbounded per-part headers, enabling DoS (memory exhaustion)

Summary

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:

@sbuf.scan_until(/(.*?\r
)\r
/m)

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 maximum request sizes at the proxy or web server layer (e.g., Nginx client_max_body_size).

Rack has a Possible Information Disclosure Vulnerability

Summary

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 protected (such as administrative pages). The vulnerability did not allow arbitrary file reads but could expose sensitive application routes.

This issue only affected systems meeting all of the following conditions:

• The application used Rack::Sendfile with a proxy that supports x-accel-redirect (e.g., Nginx).
• The proxy did not always set or remove the x-sendfile-type and x-accel-mapping headers.
• The application exposed an endpoint that returned a body responding to .to_path.

Mitigation

• Upgrade to a fixed version of Rack which requires explicit configuration to enable x-accel-redirect:

  use Rack::Sendfile, "x-accel-redirect"

• Alternatively, configure the proxy to always set or strip the headers (you should be doing this!):

  proxy_set_header x-sendfile-type x-accel-redirect;
  proxy_set_header x-accel-mapping /var/www/=/files/;

• Or in Rails applications, disable sendfile completely:

  config.action_dispatch.x_sendfile_header = nil

Rack is vulnerable to a memory-exhaustion DoS through unbounded URL-encoded body parsing

Summary

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:

form_vars = get_header(RACK_INPUT).read

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 params_limit. 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 configured, the issue occurs before those limits are enforced.

Mitigation

• Update to a patched version of Rack that enforces form parameter limits using query_parser.bytesize_limit, preventing unbounded reads of application/x-www-form-urlencoded bodies.
• Enforce strict maximum body size at the proxy or web server layer (e.g., Nginx client_max_body_size, Apache LimitRequestBody).

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.\n* Don't name directories with the same prefix as one which is exposed via Rack::Directory."

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:

<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:

<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.