HKCERT warned on 9th November, 2026 that proof-of-concept exploit code is public for CVE-2026-104269, a ModSecurity upload bypass with no patched version listed. The bug lets a file named like a JPG reach the app as a PHP script.
At a Glance
- HKCERT rated CVE-2026-104269 a Medium Risk security restriction bypass and flagged public proof-of-concept exploit code.
- ModSecurity versions 3.0.0 and later carry the filename bug, and its GitHub advisory lists no patched release.
- Go, Python, Node.js, and Java Spring parsers can read a different filename than the one the firewall checked.
- A second bug, CVE-2026-73857, hits 3.0.15, 3.0.16, and the v3 master only when SecParseXmlIntoArgs is switched on.
ModSecurity checks one filename, the app saves another
ModSecurity is the open-source web application firewall (WAF) that runs with Apache, IIS, and Nginx and blocks requests that look harmful. Its weak spot here is the multipart parser, the code that reads file uploads. That parser doesn’t support RFC 2231, a standard for encoded values in headers.
Many app frameworks do support it. When an upload carries both a plain filename and an encoded filename*, those frameworks prefer the encoded one. The WAF and the backend end up reading two different names from one request.
The attack is short. An attacker sends filename=”safe.jpg” together with filename*=UTF-8”shell.php, and the OWASP Core Rule Set sees a harmless JPG and lets it through. A Go backend reads the name as shell.php and may save it to disk. If the web server serves that folder, the attacker can run code on it.
The bulletin from HKCERT (Hong Kong’s computer emergency response team) frames the damage around what the app does with that name. Apps that use the backend-selected name for storage, extension checks, or content-type inference “can therefore receive a filename that bypassed WAF inspection,” the bulletin said.
The GitHub advisory, GHSA-5pww-8rfg-9crf, names Go, Python (Flask and FastAPI), Node.js, and Java Spring parsers as the ones that behave this way. PHP’s native upload handling reads only filename=, so it isn’t affected. Researchers 0xkalawy and ZeyadZonkorany found the issue, and B0YK4 coordinated the report.
The XML bug needs a non-default switch
Maintainer airween published both GitHub advisories on September 30. The second, CVE-2026-73857 (GHSA-jx3r-phvx-2jmj), came from researcher Tobias Klein. A single crafted request from an unauthenticated remote user can push a worker process into using an uninitialized pointer. That request can then write a fixed value to an address the sender picks.
The fallout ranges from a crash or memory leak to a redirect of program flow, which could lead to remote code execution. The advisory lists the weaknesses as CWE-787 (out-of-bounds write) and CWE-824 (access of uninitialized pointer).
Exposure is narrow, though. The bug is reachable only when SecParseXmlIntoArgs is set to On or OnlyArgs, and the setting ships Off by default. The code path arrived in 3.0.15, so 3.0.15, 3.0.16, and the current v3 master are affected. Earlier 3.0.x releases and ModSecurity v2 are not.
Patch status for this one is muddled. The advisory lists 3.0.17 as the patched version. Yet its text also says a fix is “not yet” available and will come in the next release.
Exploit code lands before the upload fix
HKCERT’s note changes the math on the filename bug more than on the XML one. CVE-2026-104269 needs no login, reaches every release from 3.0.0 onward, and now has public exploit code, while its advisory still lists no fix. The XML bug, by contrast, sleeps unless an admin turned a specific setting on.
The upload bypass also defeats WAF-side extension filtering. A rule can’t block shell.php when the firewall never sees that name, so the backend’s own handling becomes the real control.
Teams running ModSecurity in front of Go, Python, Node.js, or Java Spring apps can reduce risk with these general hardening steps:
- Ignore the client-supplied filename and generate a safe name on the server.
- Block script extensions such as .php at the application layer.
- Store uploads outside the web root, so the web server doesn’t serve them directly.
- Confirm SecParseXmlIntoArgs is set to Off, the workaround from the CVE-2026-73857 advisory.
What’s Next?
Two questions sit open in the public record. When will a release fix CVE-2026-104269? And does 3.0.17 actually ship the XML fix, given the advisory’s conflicting text?
The next marker for admins is that 3.0.17 release on the official ModSecurity project page. Until it lands and the notes confirm the XML fix, SecParseXmlIntoArgs stays Off and upload names stay server-generated.
