RACK · CVE-2026-125108 · Package
FIX → 3.2.8 · 2.2.25 +1
Rack's guard against multipart requests with two boundary parameters misses a Content-Type whose first boundary is empty or starts with a quote, semicolon or comma. An attacker can send a body that a web application firewall reads differently from Rack, so uploads and form fields reach the app without inspection.
first public Oct 30, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Applications built on Rack (Rails, Sinatra and similar) that accept multipart uploads or form posts and sit behind a WAF or inspecting proxy that relies on the standard multipart parsing. The advisory says all supported versions including 2.2 are affected. Apps with no inspecting proxy in front, or that reject multiple boundary parameters at the reverse proxy, are less exposed.
Not affected if no-waf-in-front, proxy-rejects-multiple-boundaries
Who cares rack, rails, ruby, self-hosted
Gemfile.lock for rack (bundle exec ruby -e 'require "rack"; puts Rack.release' to print the loaded versionThe 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.
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 and anchors on the second, and the subsequent check for another in the remaining text finds nothing. Rack then uses .
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
Upgrade to 3.2.8 · 2.2.25 +1
rack 2.2 line: 2.2.25rack 3.1 line: 3.1.23rack 3.2 line: 3.2.8boundary=boundary=AaB03xRFC 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.
As with CVE-2026-26961, an attacker can craft a multipart request that a web application firewall or other inspecting proxy in front of a Rack application interprets differently from Rack, so form fields and file uploads reach the application without inspection. Rack itself grants no capability beyond that of a well-formed request with the same body. All supported versions, including 2.2, are affected.
Content-Type contains more than one boundary parameter at the reverse proxy.