- Severity: LOW
- CVE: CVE-2026-125108
- Ecosystems: rubygems, rubygems, rubygems
- Packages: rack, rack, rack
## Summary
The guard added for CVE-2026-26961 (GHSA-vgpv-f759-9wx3), which rejects multipart requests with more than one `boundary` parameter, only inspects the part of the `Content-Type` header after the boundary it extracts. A `Content-Type` whose first `boundary` parameter is empty or begins with a quote, semicolon, or comma is skipped by the extraction pattern, so a second `boundary` parameter is accepted silently and Rack parses the body with a boundary that a conforming parser would not derive from the header.
## Details
`Rack::Multipart::Parser.parse_boundary` extracts the boundary with a regular expression that uses a lazy prefix and a value class excluding `”`, `;`, and `,`. For a header such as `multipart/form-data; boundary=”;boundary=AaB03x”` or `multipart/form-data; boundary=; boundary=AaB03x`, the pattern skips the first `boundary=` and anchors on the second, and the subsequent check for another `boundary=` in the remaining text finds nothing. Rack then uses `AaB03x`.
RFC 9110 parses the first header as a single parameter whose value is `;boundary=AaB03x`, which is not a legal boundary under RFC 2046, so the only conformant outcome is rejection. Inspecting intermediaries that implement the standard grammar, such as ModSecurity, see a different boundary or no multipart body at all.
The fix counts `boundary=` occurrences across the entire header value and rejects the request when there is more than one.
## Impact
As with CVE-2026-26961, an attacker can craf…
Source: GitHub Security Advisories · 2026-11-10