-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
- -------------------------------------------------------------------------
Debian LTS Advisory DLA-4706-1 [email protected]
https://www.debian.org/lts/security/ Abhijith PA
July 31, 2026 https://wiki.debian.org/LTS
- -------------------------------------------------------------------------
Package : ruby-rack
Version : 2.1.4-3+deb11u6 2.2.22-0+deb12u2
CVE ID : CVE-2026-26961 CVE-2026-34230 CVE-2026-34763 CVE-2026-34785
CVE-2026-34786 CVE-2026-34826 CVE-2026-34829 CVE-2026-34830
CVE-2026-34831
Multiple vulnerabilities were found in ruby-rack, a modular Ruby
webserver interface
CVE-2026-26961
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.
CVE-2026-34230
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.
CVE-2026-34763
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.
CVE-2026-34785
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.
CVE-2026-34786
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.
CVE-2026-34826
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.
CVE-2026-34829
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.
CVE-2026-34830
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.
CVE-2026-34831
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.
For Debian 11 bullseye, these problems have been fixed in version
2.1.4-3+deb11u6.
For Debian 12 bookworm, these problems have been fixed in version
2.2.22-0+deb12u2.
We recommend that you upgrade your ruby-rack packages.
For the detailed security status of ruby-rack please refer to
its security tracker page at:
https://security-tracker.debian.org/tracker/ruby-rack
Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE7xPqJqaY/zX9fJAuhj1N8u2cKO8FAmprnBMACgkQhj1N8u2c
KO/+cQ/9FGBAJAUa9oT3Pm4S/YA1YlXmTlHDV0Sr8PKNUV3pLaqfAd1FX6WPa6sE
CK5Qtk72zXV0MIBBeg+wfP1UQ96awQvvXbNFeHc6bgOxICjEHn1EpWQgjr3R1k2u
OjQ9CLuswaYot+S8uAl97FHKS/tk1txQxro2Zox44WVDwCFf1XHjl+jMP9Mruh4P
QnHVBCIHcsQ7nyGb6G8KEDFnSc2KUdXRIxbhaQc/nINugNFDTVgAGT7wtpFPT2WR
YDfMBXIOJA4hv/nlEurQiGgtwEBGj6jA4VAIRsTzJkJU1hUoAsxCq1T0BjbrHRnv
vhZ78rrjk/sg98WfJSi77RrNeX01yxPv5XQZK4IIuBGIXlDYjSBQDqgJt7fyOLRU
Iw1EeumlEWGk0sGmtpWyF4XuE2TjpjUvvj3EHTCY6kzNjnzdgRmQzx/18F8dLZol
Rr2DaxvvSNUVJC7PE8nTCQEsEMJ45Ve3teHf4KRqkNrS1JAtdAYzynC1NhAN1k+o
ZcZso7GBkyNOUZsfXdnkIuN1My2G+AhPa421Q+/9cPQ4OR/fZoYh5LDGZl8WKGx2
J9qPrl3v/fAfwxvoNIxZztjBA5nh04/N6ui9JJuJJGm1UM3bdTbakf886VbQkc8A
CXP8EsYbrjOkWzLOsnKj3v4d/sBt+lVp5suS77uFxrDdO/BFNK4=
=tHdb
-----END PGP SIGNATURE-----
