MaxUpload for WordPress: Unauthenticated File Upload

CVE-2026-15965 affects the MaxUpload plugin for WordPress — a file-size extension that enables large-file handling through a chunked transfer mechanism. The flaw is in the upload handler’s validation logic: it applies extension and MIME-type checks to the incoming chunk’s filename, but not to the filename that determines where the assembled file ultimately lands on the server. Because the upload handler requires no authentication to reach, any internet-facing WordPress site with MaxUpload 1.4.0 or earlier installed is in scope. CVSS 8.8, High.

What “arbitrary file upload” means here

Chunked upload implementations have a surface that single-file handlers don’t. When a file is split into pieces for transfer and assembled server-side, there are two filename contexts involved: the chunk and the output. A check applied to one but not the other leaves a gap. The practical question for any deployment is whether that gap can be converted to code execution — which depends on whether the server can be made to execute a file placed in the upload path.

WordPress installations on PHP hosting environments, which is most of them, typically can. The upload directory and its server configuration are the relevant variables. A plugin that bypasses extension validation shifts that exposure from “depends on your hardening” to “reachable by anyone on the internet.”

Arbitrary file upload bugs appear often enough in WordPress plugin advisories that they’ve become a familiar entry in the ecosystem’s threat surface. They show up in upload handlers, image processors, form builders — wherever a plugin accepts a file from a user and does something with it server-side. The MaxUpload case has a specific shape: a chunked implementation that checks one filename context but misses the other. It’s a design-level oversight, not an edge case.

Status

CVE-2026-15965 was published to NVD on August 15. Affected versions: all through 1.4.0. No patched version has been confirmed in the WordPress plugin repository as of this writing. No active exploitation has been reported.

The absence of confirmed exploitation is worth noting without over-relying on it. Chunked upload vulnerabilities with unauthenticated reach have attracted opportunistic scanning before, particularly once a CVE ID and advisory are public.

What to do

Check your WordPress plugin inventory for MaxUpload. If you’re running any version through 1.4.0, deactivate it until a patched release is confirmed. There is no configuration-level workaround for the flaw in affected versions — the only safe posture is not running the affected code.

Monitor the WordPress plugin page directly for update status. As a secondary measure, confirm with your host that your WordPress uploads directory is not configured to serve executable scripts — a hardening step that limits the blast radius of file upload vulnerabilities regardless of the specific plugin involved.

Earlier this week, a separate batch of critical authentication bypass flaws hit the WordPress plugin ecosystem with CVSS scores of 9.8. The MaxUpload flaw is a different class of vulnerability but sits in the same patch cycle for WordPress site operators.