MaxUpload WordPress Plugin CVE-2026-15965

The MaxUpload plugin must be installed and activated on the target WordPress site. The upload endpoint exposed by handle_upload (registered in maxupload-wp.php L88) must be reachable without authentication - the CVE description asserts this is the case for unauthenticated attackers, though the PR:L CVSS metric contradicts this and the actual WordPress action registration (nonce or capability check presence) should be independently verified. The WordPress web server must permit PHP script execution within the wp-content/uploads directory (or wherever the plugin deposits assembled files) - this is the single most significant limiting factor, as hardened WordPress configurations commonly block PHP execution in uploads via .htaccess or server config. Exploitation is limited to web-accessible WordPress installations; sites behind authenticated reverse proxies, private networks, or with the upload directory protected by server-level PHP execution restrictions are not directly exploitable for RCE, though file write still occurs.

There is a notable conflict in the provided data: the CVE description explicitly states 'unauthenticated attackers' can exploit this, while the supplied CVSS 3.1 vector specifies PR:L (low-privilege required). This discrepancy must be resolved with the plugin vendor or by code review of the upload endpoint's authentication gate - if the handle_upload action fires without a nonce or capability check, PR:N is correct and the real-world risk is substantially higher than the 8.8 score implies. No EPSS score or KEV listing was provided, meaning exploitation probability is unquantified and CISA has not confirmed active exploitation. No public POC is referenced in the intelligence data. The attack complexity is genuinely low regardless of auth status: the bypass requires only a crafted multipart POST request with a controlled resumableFilename field. A critical limiting factor is whether the WordPress upload directory permits PHP execution - many hardened installations block this via server configuration (e.g., .htaccess deny rules), which would prevent code execution even after a successful file write. Organizations with default or misconfigured WordPress hosting are at significantly higher risk.

An unauthenticated attacker sends a multipart HTTP POST to the WordPress site targeting the MaxUpload chunked-upload endpoint, uploading a PHP webshell split across one or more chunks with a benign chunk filename (e.g., image.jpg) that passes MIME and extension validation. The attacker includes resumableFilename=shell.php in the POST body; the server assembles the chunks and writes shell.php into the WordPress uploads directory. The attacker then issues a GET request to the predictable assembled file path, executing the webshell and gaining arbitrary command execution as the web server user. No public POC has been confirmed, but the technique requires only standard HTTP tooling.