ModSecurity Vulnerability CVE-2026-104269: WAF File Upload Bypass, an XML Worker Flaw, and the Versions to Install
ModSecurity 3.0.17 fixes two high-severity flaws. One lets attackers upload a file under a name the WAF never checked. Here is what is confirmed, who is affected and what to update this week.
Where Worldwide
On this page 9 sections
ModSecurity is the open-source web application firewall (WAF) that screens traffic for many Apache, Nginx and IIS web servers, and version 3.0.17 fixes two high-severity flaws in it. The worse of the two, CVE-2026-104269, lets an attacker upload a file under a name the WAF never checked. If your business counts on ModSecurity to block dangerous uploads, confirm it is updated this week.
What happened with the ModSecurity vulnerability
The ModSecurity project, now looked after by the OWASP Foundation, released libmodsecurity 3.0.17 and ModSecurity 2.9.15 on September 29, 2026. Each release lists several security fixes. The maintainers published the matching GitHub security advisories the next day, September 30. Two of the high-severity flaws now have CVE records:
| CVE-2026-104269 | CVE-2026-73857 | |
|---|---|---|
| What it is | Upload filename check bypass using the RFC 2231 filename* parameter |
Uninitialized pointer in the XML request body processor |
| Severity (advisory) | High, CVSS 8.6 | High, CVSS 7.5 |
| Affected | ModSecurity 3.0.0 up to, but not including, 3.0.17 (CVE record) | 3.0.15, 3.0.16 and the v3/master branch as it stood when the advisory was written (advisory); the CVE record gives 3.0.15 up to, but not including, 3.0.17 |
| Needs a special setting? | No. It depends on the language your application is written in | Yes. Only when SecParseXmlIntoArgs is set to On or OnlyArgs (the default is Off) |
| Fixed in (CVE record and release notes) | 3.0.17 | 3.0.17 |
| What the advisory page itself says | "Patched versions: None" | "Patched versions: 3.0.17", but its Patches section says "Not yet, next release will contain that" |
| CVE record published | November 5, 2026 | November 9, 2026 |
How the WAF file upload bypass works
When someone uploads a file through a web form, the request labels it with a name such as filename="photo.jpg". An older internet standard, RFC 2231, also allows a second, encoded form of the name: filename*=. According to the advisory, the OWASP Core Rule Set upload rules running on ModSecurity read only the plain filename. Many application frameworks decode filename* and prefer it.
The advisory names the frameworks that do this: Go (net/http), Python (Flask/Werkzeug and FastAPI/Starlette), Node.js (busboy and @fastify/multipart) and Java (Spring). An attacker sends a harmless name for the WAF to inspect and a dangerous one for the application to use. The advisory's own example ends with a PHP file written to disk, which it describes as "RCE if in webroot", meaning remote code execution if that folder is served by the web server.
In plain terms: the guard at the door reads one name tag, and the application behind it reads another. The CVE record states that PHP's native upload parser is not affected.
The fix commit for 3.0.17 changes ModSecurity so that when filename* is present, its value becomes the filename the rules inspect. A duplicated plain filename still triggers a warning.
The second flaw: one XML request can hit a server worker
CVE-2026-73857 sits in the part of ModSecurity v3 that turns XML request bodies into arguments for rules to check. The advisory says a single request, with no login, can make a worker write a fixed value to an address the attacker chooses. It puts the impact as ranging "from denial of service to memory disclosure", with possible redirection of execution. The setting that exposes it, SecParseXmlIntoArgs, is off by default. The CVE record says ModSecurity 2.x and 3.0.x releases before 3.0.15 are not affected. The 2.9.15 release notes also add a guard on the same parser pointer.
What is confirmed and what is not
Confirmed from the primary sources:
- Both advisories, their severity scores and their credits: 0xkalawy and ZeyadZonkorany found the filename flaw, with B0YK4 coordinating; Tobias Klein reported the XML flaw.
- The 3.0.17 and 2.9.15 release notes list fixes for both advisories.
- Debian's security tracker, checked November 10, 2026, marks every listed Debian modsecurity and modsecurity-apache package as vulnerable to CVE-2026-104269, including 3.0.16-1 and 2.9.13-1 in unstable.
Not settled or not known:
- Both advisory pages disagree with their CVE records on patches, as the table shows. The CVE records and the release notes say 3.0.17 fixes both flaws. We treat 3.0.17 as the fix for both, but neither advisory page has been updated to say so consistently.
- The CVE-2026-104269 record lists only version 3. Version 2.9.15 contains the same
filename*handling change, according to its release notes, and Debian lists its version 2 Apache package as vulnerable. Treat version 2 as affected until you run 2.9.15. - We found no report of either flaw being used in attacks, and neither advisory says it has been. The filename advisory includes an example request showing the technique, so the method is public.
Who should check their ModSecurity version
- Anyone running Apache or Nginx with ModSecurity and the OWASP Core Rule Set on their own servers.
- Teams whose upload forms are built on Go, Python, Node.js or Java behind ModSecurity. Those are the backends the bypass works against.
- Businesses on managed hosting or a hosted WAF. Your provider may run ModSecurity for you, so ask which version.
- Anyone relying on Linux distribution packages. On Debian at least, a routine package update does not yet bring you to a fixed version.
What to do this week
| Step | How to check or fix |
|---|---|
| Find out if you run ModSecurity | Apache: run apachectl -M and look for security2_module. Nginx: look for a load_module line naming ngx_http_modsecurity_module in nginx.conf. Hosted: ask your provider |
| Check the version | Run dpkg -l on Debian or Ubuntu, or rpm -qa on Red Hat family systems, and look for the modsecurity packages |
| Update | libmodsecurity 3.0.17 or later; ModSecurity 2.9.15 or later for the Apache v2 module |
| If your distribution has no fixed package | Build from the upstream release, or apply the application steps below until a package lands |
| Check the XML setting | Search your configuration for SecParseXmlIntoArgs and keep it Off unless you need it |
| Harden uploads in the application | Check extension and content using the same filename your code stores, rename files on the server, store uploads outside the web root, block script execution in upload folders |
| Review logs | Look for upload requests that contain both filename= and filename*= |
Why it matters for a company website
Upload forms are everywhere: job applications, customer documents, insurance claims, product photos. Many teams put a WAF in front of them and consider the job done. This flaw shows why that is not enough. If the WAF and the application disagree on what a request says, the WAF can approve something the application then treats very differently. A file that lands as a script in a public folder can give an attacker control of the server and the data on it. Checks inside the application, using the exact filename the application will store, close that gap no matter what the WAF does.
ModSecurity vulnerability questions people are asking
What is CVE-2026-104269?
A high-severity ModSecurity flaw (CVSS 8.6). The WAF checks an upload's plain filename while the application uses the encoded filename*, so a blocked file type can get through.
Which ModSecurity version fixes it?
The CVE record and release notes say 3.0.17. For the older Apache module, update to 2.9.15, which contains the same change. The advisory page still lists no patched version.
Does it affect PHP websites?
The CVE record says PHP's native multipart parser is not affected. The backends named are Go, Python, Node.js and Java. Update anyway, since 3.0.17 fixes several other flaws.
Is the ModSecurity bypass being exploited?
We found no report of attacks, and the advisory does not claim any. An example request is public, so do not wait.
Do I need to change my OWASP Core Rule Set rules?
The fix is in the ModSecurity engine. According to the fix commit, after the update the filename the rules inspect comes from filename* when it is present. Neither the release notes nor the advisory mention a required rule change.
What is SecParseXmlIntoArgs and is it on?
It is a ModSecurity v3 setting that parses XML request bodies into arguments. It is off by default, and the XML flaw only applies when it is set to On or OnlyArgs.
The bigger lesson
A WAF reads a request one way and your application may read it another. Every difference between the two is a possible way in. Treat the WAF as one layer, keep it patched, and make the application check what it actually stores and runs.
Want your web servers and upload forms checked? See security hardening or request a quote.
Get security alerts like this by email, with our free checklist, at security alerts.
Sources: ModSecurity advisory GHSA-5pww-8rfg-9crf; ModSecurity advisory GHSA-jx3r-phvx-2jmj; ModSecurity v3.0.17 release notes; ModSecurity v2.9.15 release notes; ModSecurity fix commit; CVE-2026-104269 record; CVE-2026-73857 record; Debian security tracker.
Have a question about this article?
Ask it here and we will answer you directly by email. Questions are private, never posted.
Security alerts by email
Hear about the next one first.
When attackers start using a flaw in software businesses run on, we email what it is, whether it touches you and what to do that week, with a round-up of our latest security writing. Free, one-click unsubscribe. You get the checklist straight away: 12 things to secure this week.
Want a result like this?
Security alerts, breaches and the technology a business runs on: what happened, who it affects and what to do.
Get a Tech QuoteKeep reading
SonicOS 7.3.4-7013 vs 7015: Which Build to Install for the SonicWall SSL VPN Fix, and What the Release Notes Show
SonicWall lists SonicOS 7.3.4-7013 as fixed, but its release notes show the SSL VPN ticket by number only, whi...
Fireworks AI Breach: A Cloud Provider Incident Reached Billing Records, Datasets and Model Weights, and What Customers Should Do This Week
Fireworks AI has expanded its October security incident. An attacker went through a third-party cloud provider...
Refrigeration Controller Hack: CISA and FBI Warn Attackers Are Targeting Cold Chain Systems, What Is Confirmed and What to Check This Week
US agencies warn that attackers are pushing internet-exposed refrigeration controllers into continuous heating...
