ModSecurity, a widely deployed open-source web application firewall (WAF) used with Apache, IIS, and Nginx, has addressed two high-severity vulnerabilities that could allow attackers to bypass the WAF or execute remote code. These flaws, disclosed via GitHub advisories on September 30 by the maintainer “airween,” stem from weaknesses in how ModSecurity handles uploads and certain XML parsing configurations.
Filename Parsing Bypass: CVE-2026-104269
The first flaw arises when ModSecurity fails to properly handle filename parameter encoding under multipart requests. Specifically, its multipart parser doesn’t support RFC 2231’s syntax for encoded header values—while many application frameworks do. An attacker could send a normal filename field declaring something safe like “safe.jpg” alongside an encoded field declaring a different filename, for instance “shell.php.” Because ModSecurity sees only the harmless name and allows the request, the backend framework, which honors the encoded value, then saves the file under the dangerous name. If that file is served, it can be abused for remote code execution. This vulnerability affects all ModSecurity releases starting with version 3.0.0. No patched version is yet confirmed, meaning systems remain vulnerable. Common backend environments including Go, Flask, FastAPI, Node.js, and Java Spring are affected; PHP’s native upload functionality is not vulnerable because it ignores the encoded filename parameter.
XML Parser Bug: CVE-2026-73857
The second issue involves ModSecurity’s XML argument parsing feature. If the configuration directive SecParseXmlIntoArgs is set to “On” or “OnlyArgs,” a specially crafted, unauthenticated request can trigger usage of an uninitialized pointer and allow an out-of-bounds write. The attacker gets to write a fixed value to an address of their choosing, potentially causing a crash, memory leak, or redirecting execution flow—any of which could lead to remote code execution. This vulnerability exists in versions 3.0.15, 3.0.16, and the current master branch. Older 3.0.x versions and the earlier major version, ModSecurity 2, are not affected. The default setting for SecParseXmlIntoArgs is “Off,” which mitigates risk until a patched version is confirmed.
What Admins Should Do Now
For the XML parsing flaw, administrators are urged to ensure SecParseXmlIntoArgs is disabled—that is, set to Off—until an official patched release is available. For the filename parsing bypass, since there is no patch yet, developers must not trust client-supplied filenames. Best practices include generating safe filenames internally, prohibiting dangerous extensions like .php, and storing uploads outside of the web-servable directory.
These flaws reinforce a recurring pattern of bypass issues in ModSecurity. Previous vulnerabilities revealed similar blind spots in request processing and rule enforcement. Given ModSecurity’s role as a frontline defense for many websites, even small implementation details can produce serious gaps.
Analytical Take: These vulnerabilities spotlight how mismatches between protocol parsing standards and framework behavior can undermine even mature security tooling. It’s a reminder that deployment configuration—not just versioning—matters deeply. For organizations using ModSecurity: review your configuration settings, especially SecParseXmlIntoArgs, audit how your backend handles file uploads, and watch closely for the release of official patches. In the broader landscape, expect more focus on these edge-case parser discrepancies as attack surfaces in WAFs and similar defensive tools.
