Trustwave achieves verified MXDR solution and FastTrack ready partner status from Microsoft. Learn More

Trustwave achieves verified MXDR solution and FastTrack ready partner status from Microsoft. Learn More

Managed Detection & Response

Eradicate cyberthreats with world-class intel and expertise

Managed Security Services

Expand your team’s capabilities and strengthen your security posture

Consulting & Professional Services

Tap into our global team of tenured cybersecurity specialists

Penetration Testing

Subscription- or project-based testing, delivered by global experts

Database Security

Get ahead of database risk, protect data and exceed compliance requirements

Email Security & Management

Catch email threats others miss with layered security & maximum control

Co-Managed SOC (SIEM)

Eliminate alert fatigue, focus your SecOps team, stop threats fast, and reduce cyber risk

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
The Trustwave Approach
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Platform
SpiderLabs Fusion Center
Security Operations Centers
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

ModSecurity v3: DoS Vulnerability in Four Transformations (CVE-2023-38285)

ModSecurity is an open-source Web Application Firewall (WAF) engine maintained by Trustwave. This blog post discusses an issue with four transformation actions that could enable a Denial of Service (DoS) attack by a malicious actor. The issue has been addressed with fixes in v3.0.10. ModSecurity v2 is not affected. 

Vulnerability Details

Included in ModSecurity functionality are dozens of transformation actions which support altering the representation of values so that further processing can be done on the modified values. This may be either more convenient to work with, or less prone to rule evasion.

The ModSecurity team was recently alerted to a possible DoS issue in four of these transformations in ModSecurity v3. Thanks to the reporter for the investigation and for responsibly disclosing the issue. The affected transformations are: removeWhitespace, removeNull, replaceNull, and removeCommentsChar.

The affected transformations were functionally correct. However, the implemented solutions would be inefficient if a malicious user were to submit a specially crafted HTTP request that triggered worst-case performance.

The most dramatic delays can typically be prevented through common configuration items such as SecRequestBodyNoFilesLimit with the default value of 131072 suggested in modsecurity.conf-recommended. However, even with this limit in place, a dozen or more executions of these transformations could result in multiple seconds of delay for a single HTTP transaction. 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.


For installations where immediate upgrade to the new version of the software is impractical, some mitigation possibilities are available.

The nature of the issue results in large values causing a much greater effect on resources than numerous smaller values. A separate ModSecurity rule could be included to limit the size of each value to be processed, but still allow legitimate content to be processed unimpeded. For example, if there are many rules with the affected transformations executing against the ARGS collection, a rule such as the following could be included before other phase 2 rules:

SecRule ARGS "@gt 16000" "id:1,phase:2,t:length,deny,status:403,msg:’ARG exceeds length limit'"

Optionally, combined with further reducing the configured value for SecRequestBodyNoFilesLimit, potential delays precipitated by worst-case input can be significantly reduced.