GHSA/SYNC: 10 brand new (rack) advisories

Author: jasnow

gems/rack/CVE-2026-26961.yml

@@ -0,0 +1,84 @@
+---
+gem: rack
+cve: 2026-26961
+ghsa: vgpv-f759-9wx3
+url: https://github.com/rack/rack/security/advisories/GHSA-vgpv-f759-9wx3
+title: Rack's greedy multipart boundary parsing can cause parser
+  differentials and WAF bypass.
+date: 2026-04-02
+description: |
+  ## 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:
+
+  ```ruby
+  MULTIPART = %r|\Amultipart/.*boundary=\"?([^\";,]+)\"?|ni
+  ```
+
+  Because the expression is greedy, it matches the last `boundary=`
+  parameter in a header such as:
+
+  ```http
+  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.
+cvss_v3: 3.7
+patched_versions:
+  - "~> 2.2.23"
+  - "~> 3.1.21"
+  - ">= 3.2.6"
+related:
+  url:
+    - https://nvd.nist.gov/vuln/detail/CVE-2026-26961
+    - https://github.com/rack/rack/security/advisories/GHSA-vgpv-f759-9wx3
+    - https://github.com/advisories/GHSA-vgpv-f759-9wx3

gems/rack/CVE-2026-26962.yml

@@ -0,0 +1,82 @@
+---
+gem: rack
+cve: 2026-26962
+ghsa: rx22-g9mx-qrhv
+url: https://github.com/rack/rack/security/advisories/GHSA-rx22-g9mx-qrhv
+title: Rack's improper unfolding of folded multipart headers
+  preserves CRLF in parsed parameter values
+date: 2026-04-02
+description: |
+  ## Summary
+
+  `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:
+
+  ```http
+  Content-Disposition: form-data; name="file"; filename="test\r
+   foo.txt"
+  ```
+
+  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 security-sensitive context, such as constructing an HTTP
+  response header, the preserved CRLF may alter downstream header parsing.
+
+  Affected values may include multipart parameters such as
+  `filename`, `name`, or similar parsed header attributes.
+
+  ## Impact
+
+  Applications that accept multipart form uploads may be affected if
+  they later reuse parsed multipart metadata in HTTP headers or other
+  header-sensitive contexts.
+
+  In affected deployments, an attacker may be able to supply a multipart
+  parameter value containing folded line breaks and cause downstream
+  header injection, response splitting, cache poisoning, or related
+  response parsing issues.
+
+  The practical impact depends on application behavior. If parsed
+  multipart metadata is not reused in HTTP headers, the issue may
+  be limited to incorrect parsing behavior rather than a direct
+  exploit path.
+
+  ## Mitigation
+
+  * Update to a patched version of Rack that removes CRLF correctly
+    when unfolding folded multipart header values.
+  * Avoid copying upload metadata such as `filename` directly into
+    HTTP response headers without sanitization.
+  * Sanitize or reject carriage return and line feed characters in
+    multipart-derived values before reusing them in response headers,
+    logs, or downstream protocol contexts.
+  * Where feasible, normalize uploaded filenames before storing or
+    reflecting them.
+cvss_v3: 4.8
+unaffected_versions:
+  - "< 3.2.0"
+patched_versions:
+  - ">= 3.2.6"
+related:
+  url:
+    - https://nvd.nist.gov/vuln/detail/CVE-2026-26962
+    - https://github.com/rack/rack/security/advisories/GHSA-rx22-g9mx-qrhv
+    - https://github.com/advisories/GHSA-rx22-g9mx-qrhv

gems/rack/CVE-2026-32762.yml

@@ -0,0 +1,101 @@
+---
+gem: rack
+cve: 2026-32762
+ghsa: qfgr-crr9-7r49
+url: https://github.com/rack/rack/security/advisories/GHSA-qfgr-crr9-7r49
+title: Rack - Forwarded Header semicolon injection enables
+  Host and Scheme spoofing
+date: 2026-04-02
+description: |
+  ## 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:
+
+  ```http
+  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:
+
+  ```ruby
+  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:
+
+  ```http
+  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.
+cvss_v3: 4.8
+unaffected_versions:
+  - "< 3.0.0.beta1"
+patched_versions:
+  - "~> 3.1.21"
+  - ">= 3.2.6"
+related:
+  url:
+    - https://nvd.nist.gov/vuln/detail/CVE-2026-32762
+    - https://github.com/rack/rack/security/advisories/GHSA-qfgr-crr9-7r49
+    - https://github.com/advisories/GHSA-qfgr-crr9-7r49

gems/rack/CVE-2026-34230.yml

@@ -0,0 +1,99 @@
+---
+gem: rack
+cve: 2026-34230
+ghsa: v569-hp3g-36wr
+url: https://github.com/rack/rack/security/advisories/GHSA-v569-hp3g-36wr
+title: Rack has quadratic complexity in Rack::Utils.select_best_encoding
+  via wildcard Accept-Encoding header
+date: 2026-04-02
+description: |
+  ## 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:
+
+  ```ruby
+  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:
+
+  ```ruby
+  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.
+cvss_v3: 5.3
+patched_versions:
+  - "~> 2.2.23"
+  - "~> 3.1.21"
+  - ">= 3.2.6"
+related:
+  url:
+    - https://nvd.nist.gov/vuln/detail/CVE-2026-34230
+    - https://github.com/rack/rack/security/advisories/GHSA-v569-hp3g-36wr
+    - https://github.com/advisories/GHSA-v569-hp3g-36wr