Vulnerable versions

• Confirmed in ModSecurity 2.6.5; earlier versions likely to be vulnerable
• Confirmed in ModSecurity Core Rule Set 2.2.4; earlier versions likely to be vulnerable.

Users are advised to upgrade to ModSecurity 2.6.6 and ModSecurity Core Rule Set 2.2.5, which are thought to fix the issues documented here. Further, those who are not deploying the CRS should check that in their configuration they have rules that check REQBODY_ERROR and MULTIPART_STRICT_ERROR, configured to block requests that have either of these flags set. For guidance on how to write such rules refer to the recommended default configuration file, which is included with ModSecurity.

Problem #1: Multipart bypass in ModSecurity with PHP in the backend

A mismatch between how multipart content is parsed in ModSecurity and PHP enables an attacker to perform a full rule set bypass.

PHP has a very lax multipart/form-data parser. Traditionally, securing ModSecurity against evasion in this parser is where a lot of development time was spent. In 2009, Stefan Esser published an evasion technique that relies on the use of single quotes—which are supported by PHP but were not supported by ModSecurity at the time—to trick ModSecurity into treating a request parameter as a file. This results in a bypass because ModSecurity uses separate mechanisms for the inspection of request parameter and file content, and files are often left uninspected.

This issue was addressed in November 2009 in ModSecurity 2.5.11, which started to accept single quotes for quoting. However, upon further examination of the PHP source code, we determined that the fix was not sufficient. PHP will not only allow a single quote to be used at the beginning of a string, but also at any other position within the string. ModSecurity, on the other hand, expects quote characters only at the first position. With some creativity, the impedance mismatch issue can be exploited to perform a bypass of the rules.


The issue was confirmed against PHP 5.4.3, but it's very likely that earlier versions can be used too. We are not releasing a proof of concept at this time, but the vulnerability is easy to exploit.

The users of ModSecurity CRS may be protected from this attack, depending on the exact deployment configuration. After the original issue had been reported, a defence-in-depth rule was added to CRS to detect side effects of a bypass attempt. This rule is effective when CRS is deployed in the traditional blocking mode, but not when anomaly scoring mode is used.

This issue should be addressed in ModSecurity's multipart parser. In addition, we recommend the following:

• Short term, improve the recommended default configuration to include the same defense in depth rule as the CRS.
• Long term, implement full request body rewriting. If the multipart payloads are fully rewritten according to how ModSecurity understands them, then any missed attack payloads will not be passed through to the backend. Such approach may require more processing, but we do not believe that this improvement would cause any practical performance issues because multipart content types are infrequent on average.

Problem #2: Content type bypass in ModSecurity CRS with certain backends

When the ModSecurity CRS is used to protect certain permissive backend applications, supplying an invalid content type can be used for a complete bypass.