ModSecurity web application firewall: bypass and crash flaws fixed in 3.0.17 and 2.9.15, one filename bypass still unpatched

ModSecurity web application firewall: bypass and crash flaws fixed in 3.0.17 and 2.9.15, one filename bypass still unpatched

2 October 2026 — ModSecurity, the open-source web application firewall engine maintained under OWASP and built into many commercial WAFs, load balancers and hosting control panels, published seven security advisories on 30 September 2026. Most are ways to get malicious requests or responses past the firewall's rules. Uzbekistan's national CERT, UZ-CERT, has since issued an alert on them.

Not yet independently verified. This rests on the ModSecurity project’s own advisories, read through GitHub’s advisory API, and on UZ-CERT’s alert; no exploitation has been reported, and the multipart filename advisory names no fixed version. We will update this when it can be confirmed, and remove this note.

The advisories

High severity:

• CVE-2026-104269 (8.6): an RFC 2231 filename* parameter in a multipart upload bypasses rules on uploaded file names, when the application behind the firewall is written in a framework that honours that parameter (Go, Python, Node or Java). It affects ModSecurity 3.0.0 and later, and the advisory lists no fixed version yet.
• CVE-2026-73856 (8.6): a bypass of response-body inspection in libmodsecurity 3.0.0 to 3.0.16, so data-leak rules on responses can be evaded.
• CVE-2026-73857 (7.5): a crash in the version 3 XML request-body processor (an uninitialised pointer dereference), a denial of service, before 3.0.17.

Medium and low: a base64 decoding transformation that discards the whole value on malformed padding, a comment-removal transformation that leaves adjacent comments (CVE-2026-104259), PCRE2 match-limit errors treated as "no match" (CVE-2026-103932), and a libcurl TLS hostname-verification setting in a download helper (CVE-2026-61813). Most are fixed in libmodsecurity 3.0.17 and ModSecurity 2.9.15.

Why it matters

A firewall bypass does not break anything visible: traffic simply stops being checked. Organisations that rely on a WAF to cover for unpatched applications, a common practice, lose that cover without noticing. Many products embed ModSecurity, so the fix often arrives through a vendor rather than from the project directly.

What to do

• Update libmodsecurity to 3.0.17, or ModSecurity 2 to 2.9.15, wherever you run it directly (for example with nginx or Apache).
• Ask your WAF, load-balancer, CDN or hosting-panel vendor whether its product embeds ModSecurity and when it will ship these fixes.
• For the unpatched filename bypass, add rules that inspect the filename* parameter as well as filename, or block it where your applications do not need it, and keep upload validation in the application itself.
• Review rules that rely on response-body inspection for data-leak protection until you are on 3.0.17.

Sources

• OWASP ModSecurity security advisories (GitHub), including GHSA-5pww-8rfg-9crf, GHSA-vmg8-j66p-vgvw and GHSA-jx3r-phvx-2jmj — 30 September 2026
• UZ-CERT (Uzbekistan national CERT): advisory on ModSecurity vulnerabilities (read 2 October 2026) — 2 October 2026