CVE-2026-26962.yml

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