CVE-2026-104269 in ModSecurityinfo

Summary

by MITRE • 11/05/2026

ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. From 3.0.0 until 3.0.17, ModSecurity's multipart parser does not apply the RFC 2231 filename* parameter precedence used by common Go, Python, Node.js, and Java application parsers. A Content-Disposition header can provide a benign filename parameter for ModSecurity and a different encoded filename* value that the backend prefers, causing MULTIPART_FILENAME rules and the application to make security decisions on different names. Applications that use the backend-selected name for storage, extension checks, or content-type inference can therefore receive a filename that bypassed WAF inspection. PHP's native multipart parser is not affected by this discrepancy. This issue is fixed in version 3.0.17.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Analysis

by VulDB Data Team • 11/05/2026

ModSecurity serves as a critical open-source web application firewall engine deployed across major HTTP servers such as Apache, IIS, and Nginx to inspect incoming traffic for malicious patterns. A significant architectural inconsistency was identified within the multipart parser logic in versions ranging from 3.0.0 through 3.0.17. This vulnerability stems from a deviation in how ModSecurity handles RFC 2231 filename parameters compared to standard application parsers found in languages like Go, Python, Node.js, and Java. The core technical flaw lies in the precedence rules applied when parsing multipart form data containing file uploads. According to RFC 2231, if both a standard filename parameter and an encoded filename parameter are present in the Content-Disposition header, the backend application typically prioritizes the filename value due to its support for extended character sets and encoding schemes. ModSecurity, however, failed to adhere to this precedence rule, instead relying on the benign filename parameter while ignoring or deprioritizing the potentially malicious filename*.

This discrepancy creates a severe security gap known as WAF bypass through multipart parsing inconsistency. An attacker can craft a specially designed HTTP request containing a file upload where the Content-Disposition header includes two conflicting values: one that appears safe and compliant with ModSecurity rules, and another encoded value that reflects the actual intent of the payload. Because ModSecurity inspects the traffic based on the benign filename it parses, it may allow the request to pass through the firewall without triggering MULTIPART_FILENAME rules or other security checks designed to block dangerous file types such as executable scripts or web shells. Consequently, when the backend application processes the same request using its native parser, it accepts the encoded filename* value. If this backend-selected name is used for storage decisions, extension validation, or content-type inference, the system effectively stores and executes a malicious file that was never inspected by the WAF layer.

The operational impact of this vulnerability allows attackers to bypass security controls designed to prevent remote code execution via file uploads. By exploiting the difference in parsing logic between the firewall and the application server, an attacker can upload files with extensions or names that would normally be blocked if processed consistently across both layers. This undermines the primary function of the web application firewall, leaving the underlying infrastructure exposed to attacks such as arbitrary file write, remote code execution, and subsequent system compromise. It is important to note that PHP applications utilizing their native multipart parser are not affected by this specific discrepancy because they do not exhibit the same parsing divergence relative to ModSecurity in this context.

To mitigate this risk, organizations running ModSecurity versions prior to 3.0.17 must upgrade immediately to version 3.0.17 or later where the parsing logic has been corrected to align with RFC 2231 standards and match common application behaviors. In addition to upgrading, administrators should implement defense-in-depth strategies by ensuring that backend applications perform strict validation of file types based on content inspection rather than relying solely on filename extensions. This includes verifying magic numbers or MIME types against a whitelist of allowed formats. Furthermore, deploying additional runtime protection mechanisms such as input validation rules and output encoding can help mitigate the impact if similar parsing inconsistencies exist in other components of the stack.

This vulnerability is categorized under CWE-693 which refers to Protection Mechanism Failure due to inconsistent interpretation of inputs across different system components. It also aligns with MITRE ATT&CK technique T1505.003, specifically Web Shell: Multipart Parser Parsing Discrepancy, where attackers exploit differences in how parsers interpret multipart data to bypass security controls. Understanding these parsing discrepancies is essential for maintaining the integrity of layered defense architectures and ensuring that web application firewalls provide consistent protection relative to the applications they are designed to shield.

Responsible

GitHub M

Reservation

10/01/2026

Disclosure

11/05/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

very low

Sources

Interested in the pricing of exploits?

See the underground prices here!