A security researcher went public with his concerns, but ModSec maintainers insist that default WAF settings are safe

ModSecurity 3 web application firewall (WAF) installations configured to disable Request Body Access can be bypassed, security researchers warn.

The purported issue in ModSecurity rule sets is restricted to ModSecurity 3 (not the earlier ModSecurity 2 version of the product) and does not affect WAF admins who give the engine access to the request body.

However, for those affected the risk is substantial, according to Christian Folini, a Swiss security researcher and author.

Ervin Hegedüs, the security researcher who identified the problem, reported the issue on the ModSecurity team on December 2.

Despite more than three months of discussion, the issue remains unresolved – an unsatisfactory state of affairs that prompted Folini to go public with his concerns through a technical blog post earlier this week.

Trustwave, the firm behind ModSecurity, denied that there was a vulnerability, describing the issue as a risk inherent only to a particular advanced configuration setting.

WAF time

ModSecurity is a popular open source web application firewall (WAF) that’s designed to work through the application of pre-set rules. The technology is often paired with the Nginx web server.

Security administrators can either create their own custom rules or deploy existing libraries, such as those from the free-to-install OWASP ModSecurity Core Rule Set (CRS) project.

Folini, CRS project co-lead, told The Daily Swig: “If you run CRS or one the known commercial ModSecurity rule sets on ModSecurity 3 and you disable Request Body Access for the WAF, then you have configured a complete WAF bypass.

“This is because skipping request body access is implemented as skipping the
request body phase (= phase 2) of rule processing in ModSecurity 3.”


RELATED ModSecurity maintainers contest denial-of-service vulnerability claims


The ModSecurity WAF engine is maintained by security vendor Trustwave.

In response to queries from The Daily Swig, Trustwave offered a statement denying there was any problem with its technology:

The issue outlined in the Core Rule Set blog post is not a vulnerability. It references an advanced configuration setting, which by default is on and must be disabled to create the behavior mentioned in the blog.

This setting can be used to disable a significant portion of the ModSecurity workflow and should only be used by experienced users, as indicated in the documentation.

This specific issue has been discussed at length in the ModSecurity community forums, and as a result, code changes have been developed to make it clearer that disabling these default settings can have undesired results. These code changes will be part of version 3.1 of ModSecurity, which will be available after testing of the complete release by the open-source community has been finalized.

In response to CVE-2020-15598, we released the following blog post back in September 2020: ModSecurity, Regular Expressions and Disputed CVE-2020-15598

Folini – who confirmed his concerns stand despite Trustwave’s denial of any problem – explained that the issue is difficult to defend against in the absence of a comprehensive fix from ModSecurity/Trustwave.

“The ModSecurity developers have not provided a fix for this problem, despite
 being informed about it on December 2,” according to Folini.


Read more of the latest security vulnerability news


Folini reckons that less than a fifth of all global ModSecurity installations have been set up with this ‘vulnerable’ configuration.

Administrators might disable Request Body Access for “performance reasons at times (trading security for performance, while retaining some security), or they are only interested in certain types of rules”.

Body heat

The security researchers went on to suggest possible workarounds to address the configuration-dependent security issue in ModSecurity 3.

“Enabling Request Body Access is the best approach,” Folini said. “Yet people usually disable it for a reason, so this might not be viable.”

Folini continued: “Shifting as many rules from phase 2 to phase 1 is another alternative. We tried to do this for CRS, planning to release that as v 3.3.1, yet we had to give up that plan due to the many different negative side effects it provoked and more ModSecurity3 bugs that surfaced along the way.”


YOU MIGHT ALSO LIKE Vulnerabilities in Smarty PHP template engine renders popular CMS platforms open to abuse