If you run OWASP ModSecurity v3 (libmodsecurity) in front of Nginx, Apache or another web server, two high-severity advisories deserve your attention. CVE-2026-73857, a memory-safety bug in the XML processor, affects versions 3.0.15 and 3.0.16 and is fixed in 3.0.17. CVE-2026-104269 lets attackers bypass filename rules on multipart uploads and has no patch yet, so it has to be mitigated in other ways. Spanish security site OpenSecurity covered both flaws; this is the hands-on part.
Key points on the ModSecurity advisories in 30 seconds
- CVE-2026-73857 (CVSS 7.5): libmodsecurity 3.0.15 and 3.0.16, only with SecParseXmlIntoArgs enabled.
- The fix is libmodsecurity 3.0.17, released on September 29, 2026.
- CVE-2026-104269 (CVSS 8.6): upload-rule bypass using filename*, with no patch.
- It mainly affects Go, Python, Node.js and Java backends; native PHP is not affected.
Start by finding out what you are running. ModSecurity v2 (the classic Apache module) is not affected by the XML bug, and the filename advisory covers the v3 branch.
Check your version and configuration
How you check the libmodsecurity version depends on how it was installed:
# Debian / Ubuntu
dpkg -l | grep -i modsecurity
# RHEL, AlmaLinux, Rocky
rpm -qa | grep -i modsecurity
# Built from source: look for the library
ls -l /usr/local/modsecurity/lib/libmodsecurity.so*Code language: PHP (php)Next, look for the directive that enables the vulnerable code path in CVE-2026-73857. If it does not show up, it is at its default, Off, and the bug is not reachable:
grep -Rni "SecParseXmlIntoArgs" /etc/nginx /etc/apache2 /etc/httpd /etc/modsecurity /usr/local/modsecurity 2>/dev/nullCode language: JavaScript (javascript)If it returns On or OnlyArgs and you are on 3.0.15 or 3.0.16, either upgrade to 3.0.17 or set the directive to Off until you can. After any change, test the configuration and reload (nginx -t && systemctl reload nginx, or apachectl configtest && systemctl reload apache2).
Mitigating the filename* bypass
CVE-2026-104269 exists because ModSecurity’s multipart parser does not implement RFC 2231. A header such as filename="safe.jpg"; filename*=UTF-8''shell.php passes OWASP CRS extension rules (920120, 922100, 922110 and others), because the WAF only sees safe.jpg, while Go, Flask/Werkzeug, FastAPI/Starlette, busboy, @fastify/multipart and Spring use shell.php. Native PHP applications are not affected by this one, since PHP only reads filename.
With no patch available, the real defense lives in the application: ignore the client-supplied filename and generate your own, validate extensions against an allowlist after normalizing the name, check the actual content type, and store uploads outside the web root without execute permissions. As an extra layer, if your apps do not need filename*, you can reject it at the WAF with a custom rule. This is our suggestion, not part of the advisory: make sure your libmodsecurity version supports the MULTIPART_PART_HEADERS variable and test it first with SecRuleEngine DetectionOnly:
SecRule MULTIPART_PART_HEADERS "@rx (?i)filename*s*="
"id:1009901,phase:2,t:none,deny,status:400,log,
msg:'RFC 2231 filename* not allowed (CVE-2026-104269)'"Code language: PHP (php)Watch the logs for a few days before switching to blocking mode. Some legitimate clients send filename* for non-ASCII file names, and blocking it can break uploads from users with accented characters or non-Latin scripts.
Frequently asked questions
How do I know if I am affected by CVE-2026-73857?
You are affected if you run libmodsecurity 3.0.15 or 3.0.16 with SecParseXmlIntoArgs set to On or OnlyArgs. With the directive at its default, Off, the bug is not reachable.
Which version should I install?
libmodsecurity 3.0.17, which fixes CVE-2026-73857. It does not fix CVE-2026-104269, which remains unpatched.
Does OWASP CRS stop CVE-2026-104269?
Not on its own, because its filename rules see the filename parameter and not filename*. You need validation in the application or a custom rule.
Sources: