Updated advisory posts against rubysec/ruby-advisory-db@b694a68

Author: flavorjones

advisories/_posts/2026-04-02-CVE-2026-26961.md

@@ -0,0 +1,92 @@
+---
+layout: advisory
+title: 'CVE-2026-26961 (rack): Rack''s greedy multipart boundary parsing can cause
+  parser differentials and WAF bypass.'
+comments: false
+categories:
+- rack
+advisory:
+  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
+---

advisories/_posts/2026-04-02-CVE-2026-26962.md

@@ -0,0 +1,90 @@
+---
+layout: advisory
+title: 'CVE-2026-26962 (rack): Rack''s improper unfolding of folded multipart headers
+  preserves CRLF in parsed parameter values'
+comments: false
+categories:
+- rack
+advisory:
+  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
+---

advisories/_posts/2026-04-02-CVE-2026-32762.md

@@ -0,0 +1,108 @@
+---
+layout: advisory
+title: 'CVE-2026-32762 (rack): Rack - Forwarded Header semicolon injection enables
+  Host and Scheme spoofing'
+comments: false
+categories:
+- rack
+advisory:
+  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
+---