CVE-2026-26961

What it actually does

Rack::Multipart::Parser incorrectly extracts the multipart/form-data boundary value from the Content-Type header using a greedy regular expression. If a request supplies multiple boundary parameters, Rack versions before 2.2.23, 3.1.21, and 3.2.6 select the last boundary, while an upstream proxy, WAF, API gateway, or other intermediary may validate the first. This parser differential can let a crafted multipart request appear benign to upstream inspection but be parsed differently by the Ruby Rack application. The primary impact is integrity-related: bypass of request validation, upload filtering, or parameter inspection in deployments where intermediaries and Rack disagree on the effective boundary. Exploitation requires a specific request-processing chain and parser mismatch, which is reflected in the high attack complexity and low CVSS score.

Why it matters to the business

An attacker may be able to bypass security controls that inspect file uploads or form submissions before they reach a Ruby application, potentially allowing unwanted parameters, unexpected multipart fields, or disallowed uploaded content to reach application logic. The risk is most relevant for internet-facing Ruby applications that rely on WAFs, API gateways, reverse proxies, or upload scanners to enforce multipart request rules before Rack parses the request. The issue is not known to be exploited in the wild, is not in the CISA KEV catalog, has very low EPSS, and has no reported public exploit maturity, so remediation should be scheduled through normal dependency patching unless the application handles high-risk uploads or relies heavily on upstream multipart inspection.

How an attack unfolds

An attacker identifies a Ruby web application using a vulnerable Rack version behind an intermediary that parses multipart/form-data differently from Rack. The attacker crafts an HTTP request with a Content-Type header containing more than one boundary parameter. The upstream device or WAF interprets the first boundary and validates the body according to that structure, potentially seeing only allowed fields or benign content. Rack then receives the same request, selects the last boundary, and parses a different multipart body structure. If the application trusts the intermediary’s validation result, the attacker may be able to smuggle fields or file parts into the application that were not inspected or were interpreted differently upstream. Successful exploitation depends on the presence of a parser differential and on security-relevant behavior tied to multipart parsing.

How to fix it

Upgrade Rack to a patched release: 2.2.23 or later for the 2.2.x branch, 3.1.21 or later for the 3.1.x branch, or 3.2.6 or later for the 3.2.x branch. If Rack is brought in transitively through a Ruby framework, update the application lockfile and redeploy with a dependency resolution that includes a patched Rack version. If immediate upgrade is not possible, configure upstream controls to reject multipart/form-data requests with duplicate boundary parameters in the Content-Type header, normalize malformed Content-Type headers before forwarding, and avoid relying solely on upstream multipart inspection for security decisions. Add application-side validation for uploaded files and multipart parameters so that Rack-parsed content is independently checked after parsing.

How to confirm the fix worked

Confirm the deployed Rack version is 2.2.23, 3.1.21, 3.2.6, or newer, depending on the branch in use. For Bundler-managed applications, verify with dependency inventory tooling, bundle list, bundle info rack, Gemfile.lock, software composition analysis, or runtime package introspection. Test exposure by sending a controlled multipart/form-data request with duplicate boundary parameters and confirming that the request is rejected or consistently parsed by all layers. Validate that reverse proxies, WAFs, API gateways, and application code all reject or handle duplicate boundary parameters consistently. Review CI/CD dependency scans to ensure vulnerable Rack versions cannot be reintroduced.

Typical attack path

1. Find an internet-facing Ruby/Rack application that accepts multipart/form-data requests such as uploads or form submissions.
2. Determine or infer that the application is behind a proxy, WAF, API gateway, or intermediary that inspects multipart bodies.
3. Send crafted multipart requests containing multiple boundary parameters in the Content-Type header.
4. Cause the intermediary to validate the request using the first boundary parameter.
5. Cause vulnerable Rack to parse the request using the last boundary parameter.
6. Deliver multipart fields or file content to the application that were not inspected or were interpreted differently by the upstream control.
7. Abuse the resulting validation bypass to influence application behavior, bypass upload restrictions, or submit unexpected form data.

How to detect it

To assess possible prior exploitation, review HTTP access logs, WAF logs, reverse proxy logs, API gateway logs, and application request logs for multipart/form-data requests where the Content-Type header includes more than one boundary parameter. Focus on upload endpoints, form submission routes, API endpoints accepting multipart payloads, and requests that were allowed by upstream controls but resulted in unusual application behavior. Look for duplicate boundary= tokens, abnormal multipart delimiters, mismatched or repeated boundary strings, unexpected file upload attempts, rejected uploads followed by successful similar requests, and anomalous 4xx/5xx responses around multipart parsing. If full request headers are not logged, use WAF/gateway telemetry, packet capture, request sampling, CDN logs, or application instrumentation to determine whether duplicate boundary parameters were observed. Because no specific public exploit or actor tradecraft is reported, detection should emphasize malformed Content-Type patterns rather than fixed payloads.

• Content-Type: multipart/form-data; boundary=
• multipart/form-data; boundary=.*boundary=
• boundary=.*; boundary=
• Rack::Multipart::Parser
• multipart/form-data

What your security team should do

• Inventory Ruby applications and services using Rack, including transitive dependencies from Rails, Sinatra, Grape, Hanami, and other Rack-based frameworks.
• Prioritize internet-facing applications that accept file uploads, multipart forms, API multipart payloads, or rely on WAF/proxy validation of multipart request bodies.
• Upgrade Rack to 2.2.23, 3.1.21, 3.2.6, or later and redeploy affected applications.
• Add WAF, proxy, or gateway rules to block Content-Type headers containing more than one boundary= parameter for multipart/form-data requests.
• Search recent access logs for multipart/form-data requests with duplicate boundary parameters, especially to upload and form submission endpoints.
• Ensure application-side validation does not assume upstream multipart inspection is authoritative.
• Add regression tests for duplicate boundary parameters and malformed multipart Content-Type headers.
• Track this as normal-priority remediation unless compensating controls are weak or the application handles sensitive uploads, because there is no known KEV listing, ransomware association, or mature public exploit at this time.