CVE-2026-26961: 
Ruby vulnerability analysis and mitigation

CVE-2026-26961 is a multipart boundary parsing vulnerability in Rack, the modular Ruby web server interface, that enables HTTP request smuggling and WAF bypass. The root cause is a greedy regular expression in Rack::Multipart::Parser that selects the last boundary parameter from a Content-Type header when multiple are present, while upstream proxies or WAFs typically interpret the first. Affected versions are Rack < 2.2.23, >= 3.0.0.beta1 and < 3.1.21, and >= 3.2.0 and < 3.2.6. The vulnerability was published on April 1–2, 2026, and carries a CVSS v3.1 base score of 5.3 (Medium) per the GitHub Advisory Database, or 3.7 (Low) per the official rack/rack security advisory (GitHub Advisory, Rack Advisory).

The vulnerability is classified as CWE-436 (Interpretation Conflict). Rack's multipart boundary extraction uses a regex equivalent to %r|\Amultipart/.*boundary=\"?([^\";,]+)\"?|ni, which is greedy and therefore matches the last boundary= occurrence in a header like Content-Type: multipart/form-data; boundary=safe; boundary=malicious — causing Rack to parse the body using malicious while an upstream WAF or proxy uses safe (Rack Advisory). No authentication or special privileges are required; an attacker only needs the ability to send HTTP requests to an application behind an inspecting intermediary. The attack complexity is considered low in the GitHub Advisory Database scoring (AC:L) because crafting a request with duplicate boundary parameters is straightforward, though the official advisory rates it AC:H given the dependency on a specific layered deployment architecture (GitHub Advisory, Rack Advisory).

The primary impact is a low-integrity bypass: an attacker can smuggle malicious multipart form fields or file uploads past upstream WAF or proxy inspection, causing the backend Rack application to process content that the security intermediary never validated (GitHub Advisory). There is no direct confidentiality or availability impact. The practical severity is highly architecture-dependent — deployments without an inspecting upstream component are not meaningfully affected, while those relying on WAF-based filtering of uploaded content (e.g., malware scanning, input validation) may have those controls bypassed (Rack Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (GitHub Advisory). The EPSS score is approximately 0.015% (3rd percentile), indicating a very low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported (Feedly).

1. Identify target: Locate a Ruby web application using a vulnerable version of Rack (< 2.2.23, < 3.1.21, or < 3.2.6) that sits behind an upstream WAF, reverse proxy, or security intermediary that inspects multipart/form-data request bodies.
2. Craft malicious Content-Type header: Construct an HTTP request with a Content-Type header containing two boundary parameters — the first (safe) matching what the WAF expects to inspect, and the second (malicious) containing the actual boundary used to delimit the smuggled content: Content-Type: multipart/form-data; boundary=safe; boundary=malicious
3. Structure the request body: Build the multipart body using malicious as the actual boundary delimiter. Place benign content between --safe delimiters (which the WAF will inspect) and embed the malicious payload (e.g., a prohibited file type, XSS payload, or command injection string) in parts delimited by --malicious.
4. Send the request: Transmit the crafted request to the target application. The upstream WAF parses the body using the safe boundary and finds no policy violations; Rack parses using the malicious boundary and processes the smuggled content.
5. Achieve objective: The malicious form field or file upload is accepted and processed by the Rack application without having been inspected by the upstream security control, potentially enabling file upload bypass, input validation evasion, or other application-layer attacks depending on the application's logic (Rack Advisory, GitHub Advisory).

• Network: HTTP POST requests to multipart/form-data endpoints with a Content-Type header containing more than one boundary= parameter (e.g., boundary=safe; boundary=malicious); anomalous multipart body structures where boundary delimiters do not match the first declared boundary.
• Logs: Web server or application access logs showing Content-Type: multipart/form-data requests with duplicate boundary parameters; WAF logs showing a request as clean while the application log records unexpected form field names or file types from the same request.
• Application Behavior: Unexpected file types or form field values appearing in application processing that were not flagged by upstream WAF rules; discrepancies between WAF-logged request content and application-logged received parameters.

Update Rack to a patched version: 2.2.23, 3.1.21, or 3.2.6 depending on the branch in use. The patched versions reject ambiguous multipart Content-Type headers or handle duplicate boundary parameters consistently (Rack Advisory). As a workaround, configure upstream WAFs or proxies to reject or normalize requests containing multiple boundary parameters before forwarding to Rack, or regenerate multipart metadata at the trusted edge. IBM has also released patches for affected downstream products including Aspera Faspex, Aspera Enterprise WebApps, Aspera Shares, API Connect, CloudPak for AIOps, and License Metric Tool (IBM Aspera Faspex, IBM API Connect).

The vulnerability was reported by security researcher CodeByMoriarty and coordinated by jeremyevans (remediation developer ioquatix) through GitHub's security advisory process (Rack Advisory). Ubuntu issued security notice USN-8182-1 and SUSE released updates (SUSE-SU-2026:1745-1 and SUSE-SU-2026:1964-1) addressing this and related Rack vulnerabilities. No significant social media controversy or broad community debate has been observed, consistent with the vulnerability's low-to-moderate severity rating.