CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway. Learn More

CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

ModSecurity DoS Vulnerability in JSON Parsing (CVE-2021-42717)

ModSecurity is an open-source WAF engine maintained by Trustwave. This blog post discusses an issue with JSON parsing that could enable a Denial of Service (DoS) attack by a malicious actor. The issue has been addressed with fixes in both v2 and v3.

JSON Parsing in ModSecurity

ModSecurity includes a JSON parser to allow for parsing of HTTP request bodies that are in the JSON format. Most commonly, the parser is activated when the HTTP Content-Type request header is of type 'application/json'. However, the JSON parser can optionally be engaged for other Content-Type values as well.

ModSecurity is distributed with a file called 'modsecurity.conf-recommended'. It includes a small number of configuration directives and rules that are typically desirable. This configuration file includes rule 200001 which enables the JSON request body processor, and this rule is enabled by default. The vulnerability described herein is not dependent on any other ruleset being installed. For a particular installation of ModSecurity, unless either (1) any rules that activate the JSON parser have been removed or commented out, or (2) ModSecurity was built without the JSON parser code (yajl), then it is likely vulnerable.

Vulnerability Details

The ModSecurity team recently received a responsible disclosure from Andrea "theMiddle" Menin about a use case that could facilitate a DoS attack. Thank you to the researcher for discovering and responsibly disclosing the issue, as well as for assisting with the verification of the eventual fix. Thanks also to Ervin Hegedüs for confirming the issue in v2 and for assisting with validating the fix in that branch.

Valid JSON can include nesting. As an example, the following is valid JSON with a maximum depth of three:


The use case of concern here is when the greatest depth in the JSON request body is very large. Once the depth is in the many tens of thousands, resource consumption escalates considerably and ModSecurity may delay a request for an excessive period while performing the JSON parsing. If a large enough number of such malicious requests are running simultaneously, this could render the webserver unable to respond to legitimate requests in a timely manner.

The negative performance impact on ModSecurity continues to increase as the parsing depth grows larger.  Since increasing the JSON parsing depth requires adding additional characters ( e.g. '{' ), this means an attacker who wants to increase the parsing depth must also make the overall request body larger. This has implications for the non-upgrade mitigation strategies suggested in the final section of this document.

The ModSecurity Fixes: v2.9.5, v3.0.6

ModSecurity v2.9.5 and v3.0.6 address this issue with a configurable limit on the maximum depth that will be accepted during JSON parsing. If that maximum is exceeded, the JSON parsing will halt immediately, while setting ModSecurity's standard REQBODY_ERROR. There is a default depth limit of 10,000, but this can be customized -- either higher or lower -- with a new Configuration item:  SecRequestBodyJsonDepthLimit. It is expected that most installations should find the default value to be sufficient.

Releases for v3.0.6 for Nginx and v2.9.5 for Apache are available immediately, v2.9.5 for IIS will be available in the next few days. Users of ModSecurity that can’t update immediately may wish to consult the following section covering other mitigation strategies.

Other Ways to Mitigate the JSON Parsing Depth Issue

Upgrading to an updated version of the software is advisable, but that may not be possible for all users in the short term.  While there is no universally suitable substitute to upgrading, some installations may be able to mitigate this issue with a rule update. Some example scenarios:

1) None of my web applications accept JSON request bodies

Possible Mitigation:  Disable any ModSecurity rules that activate the JSON parser.

2) Some of my web applications accept JSON request bodies but they are all small

Possible Mitigation:  Create a phase:1 chained rule that will reject requests that would use the JSON parser if the Content-Length exceeds a certain size (10,000 to 20,000 bytes is likely safe in most installations).  Some v2 users may alternatively be able to make use of the SecRequestBodyNoFilesLimit configuration item if other non-file request bodies are likewise expected to be below similar thresholds. Special note to users with ModSecurity <v2.9.3:  although the problem exists in earlier versions like v2.9.2, it appears to require a larger request body size to trigger problematic delays, which means that limits involving the request body size can probably be larger (perhaps 40,000 to 50,000 bytes) and still provide decent protection in most installations.

3) A few of my web applications expect larger JSON request bodies

Possible Mitigation:  Consider creating a rule as in (2) above but do not have it run for the cases where such larger request bodies are expected. Limiting the application could be done either with an additional rule in the chain, or by removing the rule at runtime (e.g. ctl:ruleRemoveById) when relevant conditions have been met. This approach does not provide robust protection, but it may provide reasonable protection against less-motivated attackers.

Latest SpiderLabs Blogs

The Secret Cipher: Modern Data Loss Prevention Solutions

This is Part 7 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here. Far too many organizations place Data Loss Prevention (DLP) and Data...

Read More

CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway

Overview A command injection vulnerability has been discovered in the GlobalProtect feature within Palo Alto Networks PAN-OS software for specific versions that have distinct feature configurations...

Read More


We all know the cybersecurity industry loves its acronyms, but just because this fact is widely known doesn’t mean everyone knows the story behind the alphabet soup groups of letters, we must deal...

Read More