CVE-2026-26961
Multipart Boundary Injection in Rack::Multipart::Parser Enables Request Smuggling
Publication date: 2026-04-02
Last updated on: 2026-04-16
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| rack | rack | From 3.0.0 (inc) to 3.1.21 (exc) |
| rack | rack | From 3.2.0 (inc) to 3.2.6 (exc) |
| rack | rack | to 2.2.23 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-436 | Product A handles inputs or steps differently than Product B, which causes A to perform incorrect actions based on its perception of B's state. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows attackers to bypass upstream inspection by smuggling multipart content that is parsed differently by Rack than by upstream proxies, WAFs, or intermediaries. This discrepancy can lead to malicious form fields or file uploads being accepted without proper filtering.
Such a bypass can undermine security controls designed to protect sensitive data, potentially leading to unauthorized data modification or injection attacks.
While the CVE description and resources do not explicitly mention compliance with standards like GDPR or HIPAA, the integrity impact and potential for bypassing security controls could affect an organization's ability to maintain data integrity and security, which are key requirements under these regulations.
Therefore, failure to patch this vulnerability or mitigate its effects could increase the risk of non-compliance with regulations that mandate strict data protection and integrity controls.
Can you explain this vulnerability to me?
CVE-2026-26961 is a vulnerability in the Rack Ruby gem's multipart form-data parser, specifically in the Rack::Multipart::Parser component.
The issue occurs because Rack uses a greedy regular expression to extract the boundary parameter from the Content-Type header in multipart/form-data requests. When the header contains multiple boundary parameters, Rack selects the last one instead of the first.
For example, if the Content-Type header is `multipart/form-data; boundary=safe; boundary=malicious`, Rack will parse the request body using the "malicious" boundary, while upstream proxies, web application firewalls (WAFs), or intermediaries may interpret the first boundary ("safe").
This mismatch creates an interpretation conflict between Rack and upstream components, allowing attackers to bypass upstream inspection by smuggling multipart content that is parsed differently by Rack than by the intermediary.
This can enable malicious form fields or file uploads to be accepted by the application without proper upstream filtering.
How can this vulnerability impact me? :
This vulnerability can allow an attacker to bypass upstream security inspections such as those performed by proxies, web application firewalls (WAFs), or other intermediaries.
Because Rack parses the multipart form-data using a different boundary parameter than the one inspected upstream, malicious content can be smuggled past these security layers.
As a result, attackers may be able to submit malicious form fields or file uploads that are not detected or blocked by upstream defenses, potentially compromising the integrity of the application.
The vulnerability has a low severity score (CVSS 3.7) with no confidentiality or availability impact, but it does have a low integrity impact.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by inspecting HTTP requests with multipart/form-data Content-Type headers that contain multiple boundary parameters. Specifically, look for requests where the Content-Type header includes more than one boundary parameter, such as: Content-Type: multipart/form-data; boundary=safe; boundary=malicious.
Detection involves identifying requests where the upstream proxy or WAF interprets the first boundary parameter, but the Rack server parses the last one, causing a mismatch.
You can use network traffic inspection tools or command-line utilities like curl, tcpdump, or Wireshark to capture and analyze HTTP headers for multiple boundary parameters.
- Use tcpdump to capture HTTP traffic on port 80 or 443: tcpdump -A -s 0 'tcp port 80 or 443' | grep 'Content-Type'
- Use curl to send a crafted multipart/form-data request with multiple boundary parameters to test if the server is vulnerable.
- Use grep or similar tools on server logs to find requests with multiple boundary parameters in Content-Type headers.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation is to update the Rack Ruby gem to a patched version: 2.2.23, 3.1.21, or 3.2.6 or later.
Additional immediate steps include rejecting HTTP requests that contain multiple boundary parameters in the Content-Type header at the edge or upstream proxies.
Normalize or regenerate multipart metadata at trusted edges before forwarding requests to the Rack server to ensure consistent parsing.
Avoid relying solely on upstream inspection of malformed multipart requests unless all components handle duplicate boundary parameters consistently.