Debian alert DLA-4706-1 (ruby-rack)

From:
             
 
Abhijith PA <abhijith@debian.org>
To:
             
 
debian-lts-announce@lists.debian.org
Subject:
             
 
[SECURITY] [DLA 4706-1] ruby-rack security update
Date:
             
 
Fri, 31 Jul 2026 00:16:50 +0530
Message-ID:
             
 
<amucGv10h5APBmGL@debian.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

- -------------------------------------------------------------------------
Debian LTS Advisory DLA-4706-1                debian-lts@lists.debian.org
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-----