VULNpocalypse
HighVulnerabilityMonitoring

GBHackers reports ModSecurity WAF upload bypass and XML flaw

GBHackers reports two ModSecurity advisories, an upload filter bypass and an XML bug; set SecParseXmlIntoArgs Off and validate decoded filenames.

Published
Fixed in
libmodsecurity3 3.0.17 listed for CVE-2026-73857 (release not confirmed); no patched version listed for CVE-2026-104269
Exploitation
No exploitation reported in the sources; a proof-of-concept request is published in the maintainer advisory for CVE-2026-104269

Live scores

CVE-2026-104269
EPSS
0.006
low predicted chance of attack
VEDAS
0.096
little exploit evidence
On CISA KEV
Not listed
Detection rule
No public rule yet

Live scores

CVE-2026-73857
EPSS
0.000
low predicted chance of attack
VEDAS
0.039
little exploit evidence
On CISA KEV
Not listed
Detection rule
No public rule yet

What happened

According to GBHackers, the ModSecurity maintainers published two high-severity advisories on September 30, 2026. The maintainer advisories on GitHub carry the same date. GBHackers reports that one flaw lets a crafted request slip past upload filters and the other can crash server workers. This page summarises what those sources say. None of the sources report in-the-wild exploitation.

Upload filter bypass. The ModSecurity advisory GHSA-5pww-8rfg-9crf lists the CVE id CVE-2026-104269, with a CVSS score of 8.6 (High). It lists affected versions as 3.0.0 and later, and patched versions as “None”. The advisory says:

  • ModSecurity’s multipart parser does not implement RFC 2231, so OWASP CRS rules such as 920120, 922100 and 922110 see only the plain filename= value.
  • Many RFC-compliant backends prefer the filename* value when both are present.
  • The advisory names Go (net/http), Python (Flask/Werkzeug and FastAPI/Starlette), Node.js (busboy and @fastify/multipart) and Java (Spring) as decoding filename*.
  • PHP’s native multipart handling reads only filename= and is listed as not affected.
  • In its example, the WAF sees safe.jpg while a Go backend returns shell.php. The advisory says remote code execution results if that file lands in a web root.

The advisory credits 0xkalawy and ZeyadZonkorany as finders and B0YK4 as coordinator. GBHackers relates the issue to the parser-differential problem described in the WAFFLED research.

XML request body processor. The ModSecurity advisory GHSA-jx3r-phvx-2jmj lists the CVE id CVE-2026-73857, with a CVSS score of 7.5 (High) and weaknesses CWE-787 and CWE-824. The advisory says:

  • Tobias Klein reported it by e-mail.
  • A single crafted request can make a worker process dereference an uninitialized pointer, giving a restricted write-what-where primitive.
  • Impact ranges from denial of service to memory disclosure and possibly remote code execution.
  • It is reachable only when SecParseXmlIntoArgs is On or OnlyArgs. The default is Off.
  • Affected versions are 3.0.15, 3.0.16 and current v3/master. Earlier 3.0.x releases and ModSecurity v2.x are not affected.

Fix status is unclear. GBHackers says the advisory lists 3.0.17 as the fixed version. The GitHub advisory metadata also lists 3.0.17 as patched, but its Patches section says “Not yet, next release will contain that.” Whether 3.0.17 has been released is not confirmed in the sources.

Am I affected?

  • Upload bypass (CVE-2026-104269): per the maintainer advisory, you may be affected if you run ModSecurity 3.0.0 or later with CRS upload filename rules in front of a backend that decodes filename*. The advisory names Go, Python, Node.js and Java frameworks. It lists PHP native multipart handling as not affected. No patched version is listed.
  • XML flaw (CVE-2026-73857): per the maintainer advisory, you may be affected if you run libmodsecurity3 3.0.15, 3.0.16 or current v3/master with SecParseXmlIntoArgs set to On or OnlyArgs. The advisory says ModSecurity v2.x and earlier 3.0.x releases are not affected.
  • Whether a specific distribution or vendor package is affected is not confirmed in the sources.

What to do now

  1. Check your ModSecurity version and whether SecParseXmlIntoArgs is On or OnlyArgs. The maintainer advisory’s workaround is to keep it Off, and GBHackers repeats this unless XML argument parsing is required.
  2. Upgrade libmodsecurity3 to 3.0.17 once it is available. GBHackers recommends this, but the GitHub advisory text says the patch is not yet released, so confirm the release exists first.
  3. For the filename bypass, GBHackers advises validating file extensions and content on the server, using the same decoded filename the application uses to store the file.
  4. Per the same article, store uploads outside the web root and block script execution in upload directories.
  5. Per the same article, test your upload rules with filename* payloads and review logs for requests containing both filename and filename* parameters.
  6. Watch the two maintainer advisories for a patched version for CVE-2026-104269, which is not confirmed.

Sources