CVE-2024-1019 is a high severity WAF bypass, scored 8.6, in libModSecurity 3.0.0 through 3.0.11. Crafted URL paths can hide a payload from path inspecting rules. Upgrade to 3.0.12, which the project advisory names as the fix, and the v2 line is unaffected.
What's affected
Affected: libModSecurity (ModSecurity v3) 3.0.0 through 3.0.11. The record's CVSS 3.1 score is 8.6 (high), with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N. The record says percent encoded characters in the URL are decoded before the path and query string are separated. The weakness is filed as CWE-20.
The project advisory is the authority on versions. It lists libModSecurity 3.0.0 to 3.0.11 as affected and says the ModSecurity v2 release line is not affected. NVD and the project agree on the score of 8.6.
Fixed version: Upgrade to libModSecurity 3.0.12. The ModSecurity v2 line is not affected.
How to check if you're exposed
- List every ModSecurity v3 deployment. Check the Nginx connector, the Apache module, container images and packaged builds from your operating system vendor.
- Run your package manager's query for the library, for example
dpkg -l | grep -i modsecurityorrpm -qa | grep -i modsecurity, and compare against 3.0.12. - Confirm you run v3 and not v2.9.x. The v2 line is not affected.
- Note which back ends build queries from the URL path, because those are the applications the bypass can reach.
What to do now
- Upgrade libModSecurity to 3.0.12 or later, and rebuild any connector or image that bundles it.
- If you cannot upgrade yet, the project notes that deriving path variables from
REQUEST_URI_RAWis an option. It is cumbersome and tends to cause false positives, so treat it as a stopgap. - Review back ends that use the URL path to build queries, and fix them to validate input themselves. A WAF is a second layer, not the only one.
- Run your dependency inventory through the free in-browser dependency scan to find bundled copies you may have missed.
Why it matters
ModSecurity v3 decodes percent encoded characters in the request URL before it separates the path from the query string. A back end that follows the standards parses the same URL differently, so a payload placed in the path can look harmless to the WAF rules while the back end reads it as something else.
This mismatch between two parsers is called an impedance mismatch. The advisory says a back end may be vulnerable if it uses the path component of request URLs to construct queries. The WAF is not the thing being exploited. It is the control that stops working, which means every rule that inspects the path is less trustworthy on affected versions.
Try it yourself
See how a pull request gate stops a vulnerable change.
Click through it at your own pace, or open it full screen.
Quick check
Is this CVE exploited in the wild?
The record's kev flag is false, so it is not in the CISA Known Exploited Vulnerabilities catalog, and no source I read reports active exploitation. The record does not mention a public exploit. That is a reason to patch or contain it soon, not a report of attacks.
Does moving to ModSecurity v2 help?
The project advisory says the v2 release line is not affected. Upgrading v3 to 3.0.12 is the documented fix, and any move between lines needs rule testing first.
Sources
Last reviewed: 19 October 2026.
