Two high-severity flaws in the open-source ModSecurity web application firewall (WAF) let attackers slip past upload filters or crash server workers with a single crafted HTTP request. Maintainers published both advisories on September 30, 2026, as part of a larger batch that also covers multiple ModSecurity vulnerabilities that enable WAF bypass.
ModSecurity WAF Vulnerability
The first flaw, GHSA-5pww-8rfg-9crf, is tracked as CVE-2026-104269 and scores 8.6 (High). It affects ModSecurity 3.0.0 and later, and the advisory lists no patched version.
The problem is a parser mismatch. ModSecurity’s multipart parser does not implement RFC 2231, which defines the extended filename* parameter in the Content-Disposition header. OWASP CRS rules such as 920120, 922100 and 922110 therefore inspect only the plain filename value.
Many RFC-compliant backends prefer filename* when both parameters are present. The advisory confirms this for Go (net/http), Python (Flask/Werkzeug and FastAPI/Starlette), Node.js (busboy and @fastify/multipart) and Java (Spring). PHP’s native multipart handling reads only filename= and is not affected.
An attacker can send filename=”safe.jpg”; filename*=UTF-8”shell.php. CRS sees a harmless .jpg and allows the upload, while the backend decodes shell.php and writes it to disk.
If that file lands in a web-accessible directory, it results in remote code execution. The CVSS vector is AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N, meaning no authentication or user interaction is needed. Researchers 0xkalawy and ZeyadZonkorany found the flaw, and B0YK4 coordinated disclosure.
This is another example of the parser-differential problem seen in the WAFFLED research, where WAFs and web frameworks interpret the same request differently.
The second flaw, GHSA-jx3r-phvx-2jmj, is tracked as CVE-2026-73857 and scores 7.5 (High). The issue involves an uninitialized pointer dereference in the ModSecurity v3 XML request body processor, categorized under CWE-787 and CWE-824.
Tobias Klein reported this vulnerability via email. With a single request, an attacker can manipulate a worker process to write a constant value to a memory address that they control, leading to a restricted write-what-where scenario. The potential impacts range from denial of service and memory disclosure to possible code execution.
This bug can only be triggered when the SecParseXmlIntoArgs directive is set to “On” or “OnlyArgs”; it is turned off by default. The affected versions are 3.0.15, 3.0.16, and the current v3/master branch. Earlier releases of 3.0.x and ModSecurity v2.x are not affected. The advisory lists version 3.0.17 as the fixed version.
Administrators should upgrade libmodsecurity3 to version 3.0.17 and keep the SecParseXmlIntoArgs directive set to Off unless XML argument parsing is required.
To counter the filename bypass, they should validate file extensions and content on the server side, using the same decoded filename the application uses to store the file. They should also store uploads outside the web root and block script execution in upload directories.
Finally, they should test their upload rules with filename* payloads and review logs for requests that contain both filename and filename* parameters.
Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.
