Modsecurity

ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. From 3.0.0 to before 3.0.15, there is an unhandled exception (std::out_of_range) caused by unsigned integer underflow in libmodsecurity3 if the user (administrator) uses a rule any of @verifySSN, @verifyCPF, or @verifySVNR. This vulnerability is fixed in 3.0.15.

Published: 2026-05-12T21:40:19.031Z
Updated: 2026-05-14T12:34:20.932Z

ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. Libmodsecurity is one component of the ModSecurity v3 project. A segmentation fault occurs when a rule using the t:hexDecode transformation inspects a query string parameter containing a single character. An attacker can exploit this to crash worker processes, causing a denial of service. Service resumes once the attack stops as worker processes recover from the segfault. All versions before 3.0.15 of libModSecurity3 are affected. This has been patched in version 3.0.15.

Published: 2026-05-05T18:46:03.201Z
Updated: 2026-05-05T19:21:08.898Z

ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. In versions 2.9.11 and below, an attacker can override the HTTP response’s Content-Type, which could lead to several issues depending on the HTTP scenario. For example, we have demonstrated the potential for XSS and arbitrary script source code disclosure in the latest version of mod_security2. This issue is fixed in version 2.9.12.

Published: 2025-08-05T23:39:40.712Z
Updated: 2025-11-03T18:13:36.309Z

ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. Versions prior to 2.9.10 contain a denial of service vulnerability similar to GHSA-859r-vvv8-rm8r/CVE-2025-47947. The `sanitiseArg` (and `sanitizeArg` - this is the same action but an alias) is vulnerable to adding an excessive number of arguments, thereby leading to denial of service. Version 2.9.10 fixes the issue. As a workaround, avoid using rules that contain the `sanitiseArg` (or `sanitizeArg`) action.

Published: 2025-06-02T15:46:19.909Z
Updated: 2025-06-09T15:03:29.894Z

ModSecurity / libModSecurity 3.0.0 to 3.0.11 is affected by a WAF bypass for path-based payloads submitted via specially crafted request URLs. ModSecurity v3 decodes percent-encoded characters present in request URLs before it separates the URL path component from the optional query string component. This results in an impedance mismatch versus RFC compliant back-end applications. The vulnerability hides an attack payload in the path component of the URL from WAF rules inspecting it. A back-end may be vulnerable if it uses the path component of request URLs to construct queries. Integrators and users are advised to upgrade to 3.0.12. The ModSecurity v2 release line is not affected by this vulnerability.

Published: 2024-01-30T16:09:42.428Z
Updated: 2025-06-17T21:29:18.248Z

Trustwave ModSecurity 3.x before 3.0.10 has Inefficient Algorithmic Complexity.

Published: 2023-07-26T00:00:00.000Z
Updated: 2024-10-23T15:42:14.669Z

Trustwave ModSecurity 3.0.5 through 3.0.8 before 3.0.9 allows a denial of service (worker crash and unresponsiveness) because some inputs cause a segfault in the Transaction class for some configurations.

Published: 2023-04-28T00:00:00.000Z
Updated: 2025-01-30T20:42:27.303Z

In ModSecurity before 2.9.6 and 3.x before 3.0.8, HTTP multipart requests were incorrectly parsed and could bypass the Web Application Firewall. NOTE: this is related to CVE-2022-39956 but can be considered independent changes to the ModSecurity (C language) codebase.

Published: 2023-01-20T00:00:00.000Z
Updated: 2025-04-03T18:43:26.152Z

ModSecurity 3.x through 3.0.5 mishandles excessively nested JSON objects. Crafted JSON objects with nesting tens-of-thousands deep could result in the web server being unable to service legitimate requests. Even a moderately large (e.g., 300KB) HTTP request can occupy one of the limited NGINX worker processes for minutes and consume almost all of the available CPU on the machine. Modsecurity 2 is similarly vulnerable: the affected versions include 2.8.0 through 2.9.4.

Published: 2021-12-07T21:08:28.000Z
Updated: 2024-08-04T03:38:49.325Z

Trustwave ModSecurity 3.x through 3.0.4 allows denial of service via a special request. NOTE: The discoverer reports "Trustwave has signaled they are disputing our claims." The CVE suggests that there is a security issue with how ModSecurity handles regular expressions that can result in a Denial of Service condition. The vendor does not consider this as a security issue because1) there is no default configuration issue here. An attacker would need to know that a rule using a potentially problematic regular expression was in place, 2) the attacker would need to know the basic nature of the regular expression itself to exploit any resource issues. It's well known that regular expression usage can be taxing on system resources regardless of the use case. It is up to the administrator to decide on when it is appropriate to trade resources for potential security benefit

Published: 2020-10-06T13:38:50.000Z
Updated: 2024-08-04T13:22:30.399Z

ModSecurity 3.x before 3.0.4 mishandles key-value pair parsing, as demonstrated by a "string index out of range" error and worker-process crash for a "Cookie: =abc" header.

Published: 2021-05-06T16:32:34.000Z
Updated: 2024-08-05T03:00:19.051Z

Trustwave ModSecurity 3.0.0 through 3.0.3 allows an attacker to send crafted requests that may, when sent quickly in large volumes, lead to the server becoming slow or unresponsive (Denial of Service) because of a flaw in Transaction::addRequestHeader in transaction.cc.

Published: 2020-01-21T21:59:09.000Z
Updated: 2024-08-05T02:32:09.354Z