Two high-severity flaws have been disclosed in ModSecurity, the open-source web application firewall used with Apache, IIS, and Nginx. One issue can let malicious uploads pass filename checks, and the other can crash a worker process in a way that could lead to remote code execution.
What the upload flaw allows
CVE-2026-104269, also listed as GHSA-5pww-8rfg-9crf, affects ModSecurity 3.0.0 and later. It allows unauthenticated network attacks that bypass file checks and compromise integrity, and no patched version is available.
The flaw comes from a mismatch between how ModSecurity and an application read upload data. ModSecurity’s multipart parser does not support RFC 2231, which is a standard for encoded values in headers, while many application frameworks do. When a request includes both a plain filename and an encoded filename*, those frameworks prefer the encoded value. In the example from the advisory, an attacker sends filename=”safe.jpg” together with filename*=UTF-8”shell.php, the OWASP Core Rule Set treats the file as a harmless JPG, and a Go backend reads it as shell.php and may save it to disk. If the web server serves that folder, the attacker can run code on it.
The advisory says Go, Python with Flask and FastAPI, Node.js, and Java Spring parsers behave this way. PHP’s native upload handling reads only filename=, so it is not affected. Researchers 0xkalawy and ZeyadZonkorany found the issue, and B0YK4 coordinated the report.
Worker process flaw and its limits
The second flaw is CVE-2026-73857, also listed as GHSA-jx3r-phvx-2jmj. Tobias Klein reported it. A single crafted request from an unauthenticated remote user can make a worker process use an uninitialized pointer, which lets the request write a fixed value to an address chosen by the sender.
That can cause a crash, a memory leak, or a redirect of program flow, and that could lead to remote code execution. The weaknesses are classified as CWE-787, out-of-bounds write, and CWE-824, access of uninitialized pointer. The CVSS vector rates the impact as high for availability only, and the score is near 7.5.
The exposure is narrower than it first appears. The flaw can be reached only when SecParseXmlIntoArgs is set to On or OnlyArgs, and that setting is Off by default. The code path was added in version 3.0.15, so 3.0.15, 3.0.16, and the current v3 master are affected. Earlier 3.0.x releases and ModSecurity v2 are not affected.
What admins need to verify
The advisory lists 3.0.17 as the patched version, but it also says a fix is “not yet” available and will come in the next release. Administrators should confirm the release on the official project page before assuming they are protected.
For the XML flaw, the advisory gives SecParseXmlIntoArgs Off as the workaround. It says to upgrade once the fixed release is confirmed. For the filename flaw, no patch is listed, so the WAF should not be the only control used to judge uploads. The article also says applications should ignore the client-supplied name and create their own safe name, block script extensions such as.php, and store uploads outside the web root, but it adds that these are general good practice and not part of the advisory.
Recent ModSecurity bypass history
ModSecurity has had other bypass problems recently. Cyber Security News has also covered earlier ModSecurity firewall bypass bugs and multiple ModSecurity rule bypass flaws.
Licensed under CC BY-ND 4.0 International