ModSecurity CVEs: Patch 3.0.17 Now

ModSecurity is the open-source web application firewall engine that many teams mean when they say “we run a WAF.” It is a cross-platform engine for Apache, Microsoft IIS, and Nginx, and it is the usual runtime for the OWASP Core Rule Set (CRS). Two newly detailed flaws matter because one lets a crafted upload slip past filename rules on several common application stacks, and the other can corrupt a worker’s memory when XML parsing is enabled.

The short version: upgrade libmodsecurity to 3.0.17, or the 2.x branch to 2.9.15. The upload bypass has a public proof of concept; the XML flaw does not, and it is reachable only when SecParseXmlIntoArgs is set to On or OnlyArgs. Neither flaw has been reported as exploited in the wild.

What ModSecurity is, and where it runs

ModSecurity is not a standalone appliance or a cloud service. It is an engine that sits inside a web server or reverse proxy and inspects HTTP traffic against rules. Its main deployments are:

• Apache HTTP Server — the original mod_security2 module, and libmodsecurity v3 through the Apache connector.
• Nginx — libmodsecurity v3 through the ModSecurity-nginx connector, commonly compiled into a reverse proxy or ingress tier.
• Microsoft IIS — the ModSecurity IIS module.
• OWASP Core Rule Set — the ruleset most ModSecurity deployments load for generic attack coverage.

That list matters for triage. A site can be running ModSecurity without running a product called “ModSecurity”: it may be a hosting panel toggle, a distro package, a container image, or a reverse-proxy build. Cloud WAFs such as Cloudflare and AWS WAF are not the same engine, so these specific CVEs do not apply to them; the question is whether the stack in front of the application embeds libmodsecurity or the Apache/IIS module. Our layered WAF architecture guide covers where that engine sits relative to a CDN and an application.

CVE-2026-104269: the WAF and the app read different filenames

The first flaw is an interpretation conflict, CWE-436. A multipart Content-Disposition header can carry both a plain filename parameter and an RFC 2231-encoded filename* parameter. ModSecurity’s multipart parser reads the plain value. Backends in Go, Python, Node.js, and Java implement RFC 2231 and prefer the decoded filename* value. The WAF and the application therefore make a security decision on two different names.

That breaks the filename-inspection rules in OWASP CRS, including 920120, 922100, and 922110. The WAF sees a harmless extension and allows the upload; the application stores the name it decoded from filename*. If that name is used for storage, extension checking, or content-type inference, an attacker can get a file past the WAF with an extension the application will treat as executable. The advisory’s worst case is code execution when the file lands in a web root. The issue is not universal: it depends on the backend, the upload path, and whether the application trusts the decoded filename for a security-relevant operation.

PHP’s native multipart parser is not affected by this discrepancy, according to the advisory. The affected backends are the ones that prefer filename*: common Go, Python, Node.js, and Java application parsers. That list is broad because the flaw is about parser behavior, not a single framework.

The advisory includes a working proof-of-concept request and a table showing the split decision: the WAF extracts a benign image name and allows it; the backend extracts a different name and writes the file. That is why the practical fix has two parts. Upgrade to 3.0.17, which handles filename* and adds MULTIPART_FILENAME_CHARSET and MULTIPART_FILENAME_LANGUAGE, and keep application-side extension and content validation in place. A WAF rule cannot fix an application that trusts a filename the WAF never saw.

CVE-2026-73857: one XML request can corrupt a worker

The second flaw is a memory-safety bug in the ModSecurity v3 XML request body processor. When SecParseXmlIntoArgs is set to On or OnlyArgs, a crafted XML request can leave XMLNodes::parsing_ctx_arg uninitialized in the SAX end-element callback. A remote, unauthenticated attacker can make the worker dereference that pointer, producing a constant-value write to an attacker-controlled address. The advisory describes it as a restricted write-what-where primitive; the impact ranges from denial of service to memory disclosure and execution-flow redirection, possibly remote code execution.

The important qualifier is the configuration. SecParseXmlIntoArgs is Off by default, and the flaw is reachable only when it is enabled. The affected range is narrow: 3.0.15 and 3.0.16. Earlier 3.0.x releases and the 2.x branch do not use the affected code path. No public exploit is documented for this one, unlike the upload bypass. That lowers the immediate exploitation risk but not the patching priority, because a memory-corruption bug in a WAF worker is exactly the kind of defect that becomes more valuable once someone publishes a trigger.

Patch and mitigation

Upgrade libmodsecurity to 3.0.17, released September 29, 2026. The release fixes both CVEs and six other ModSecurity vulnerabilities, including a response body inspection bypass with mixed-case Content-Type values, a null-pointer issue in @rx/@rxGlobal handling, and HTML entity decoding gaps. Staying on an older 3.x build leaves those fixes on the table as well.

If the deployment is on the 2.x branch, 2.9.15 carries the multipart filename* fix and the XML parser guard. The NVD advisory for the upload bypass lists the 3.x range from 3.0.0 through 3.0.16; the v2.9.15 release notes show the same multipart change, so v2 operators should treat 2.9.15 as the fixed release rather than assume the v2 branch is out of scope.

If an immediate upgrade is not possible:

• Set SecParseXmlIntoArgs to Off. This removes the XML flaw’s reachable path without disabling the rest of the WAF.
• Do not rely on filename rules alone. Validate file extensions and content in the application, and store uploads outside the web root with a generated filename.
• Check whether the CRS version in use predates the filename* handling change; updating ModSecurity without updating the rule set can leave the rule logic behind.
• Review upload directories for executable files and unexpected content, especially in applications on Go, Python, Node.js, or Java backends.

Detection and inventory

Start with the version, not the vendor name. Run the package query for libmodsecurity, the Apache module, or the IIS module, then check the connector version. A reverse proxy can run an older libmodsecurity inside a container image that the application team does not own, so check the ingress and sidecar images too.

For the upload flaw, look for multipart requests that carry both filename parameters, or filenames whose extension changes after decoding. The WAF logs may show only the benign name, so correlate the WAF log with the application’s upload log rather than trusting one side. For the XML flaw, confirm whether SecParseXmlIntoArgs is enabled and review worker crashes or restarts that coincide with XML traffic. A worker that dies on a single request is an availability signal, not just a tuning problem.

No in-the-wild exploitation has been reported for either CVE. CISA’s SSVC entry for CVE-2026-104269 marks the exploitation status as “poc,” not “active.” That is a reason to patch on a normal emergency cadence, not a reason to wait for a campaign report. The public proof of concept lowers the cost of trying the upload bypass; the XML flaw’s narrow configuration keeps its exposure smaller, but the fix is in the same release.

The bottom line

ModSecurity 3.0.17 is the fixed release for both flaws. The v2 branch should move to 2.9.15. The upload bypass is the more urgent of the two because a public PoC exists and it can turn a WAF filename rule into a split decision between the firewall and the application. The XML flaw is narrower but more severe in the worst case, and it disappears from reach when SecParseXmlIntoArgs is off. Patch the engine, keep application-side upload validation, and inventory the places where ModSecurity runs: Apache, Nginx, IIS, and the OWASP CRS deployments that depend on them.

Sources and References

• SecurityOnline: ModSecurity Vulnerability Details and PoC Published for WAF Bypass and XML Memory Flaw
• NVD: CVE-2026-104269
• NVD: CVE-2026-73857
• GitHub advisory: RFC 2231 filename* bypass (GHSA-5pww-8rfg-9crf)
• GitHub advisory: XML request body processor (GHSA-jx3r-phvx-2jmj)
• ModSecurity v3.0.17 release
• ModSecurity v2.9.15 release
• OWASP ModSecurity repository and README

Verification note: CVE IDs, CVSS scores, affected ranges, and fixed versions were checked against NVD and the two GitHub security advisories. The public-PoC and exploitation-status claims come from the advisories and NVD’s SSVC entry. The product list reflects the ModSecurity project’s supported Apache, IIS, and Nginx integrations and the OWASP CRS runtime. This post does not include a weaponized upload payload.