Elementor Pro RCE: unvalidated file uploads fixed in version 4.2.2

A return where a continue belonged

Elementor Pro, the paid page-builder plugin running on millions of WordPress sites, shipped a flaw that turns a routine form upload into unauthenticated remote code execution. Tracked as CVE-2026-32475 and rated CVSS 9.0 under CWE-434, it affects versions up to and including 4.2.1 and was fixed in 4.2.2, according to a technical writeup published on dev.to.

The defect sits in the Form widget's upload path. For each file-upload field, PHP hands the plugin an array of files, and a validation loop walks that array checking extensions and MIME types. The bug: when the first entry in the array is empty — signalled by PHP's UPLOAD_ERR_NO_FILE constant — the code exits the entire validation function with a return statement instead of skipping that single entry with a continue. Every file after the empty slot therefore skips extension and MIME checks entirely. Meanwhile, the separate loop that moves files to disk handles empty entries correctly, so it writes the remaining, never-validated files without complaint.

How the attack works

Per the writeup, the request observed in the wild by Wordfence is a plain POST to wp-admin/admin-ajax.php with the action parameter elementor_pro_forms_send_form. The multipart body carries two files for one field: the first with an empty filename, which trips the early return, and the second named something like x1.php — a webshell that is never inspected.

The file lands under wp-content/uploads/elementor/forms/ with a name derived from PHP's uniqid() but keeping the attacker-supplied .php extension. The upload response does not reveal the path, so the attacker must first work out the filename, a step Patchstack describes as cheap. A single GET request to the file then executes it. No authentication and no nonce bypass are needed, because admin-ajax.php exposes the form handler to unauthenticated callers by design.

Reporting, credits and a duplicate CVE

Tin Pham (TF1T) reported the issue via Patchstack on July 16, and Austin Ginder independently reported it through the Wordfence Bug Bounty Program around July 24, earning a $15,600 bounty. Wordfence rejected its own CVE identifier in favour of Patchstack's, and a duplicate, CVE-2026-17590, was rejected outright — the writeup advises mapping any scanner hits on that number to CVE-2026-32475.

Who is actually exposed

The precondition is precise: a published page carrying an Elementor Form widget with at least one File Upload field that is not marked required. Since required is off by default, most upload fields qualify. Sites with the plugin installed but no upload-enabled form still contain the vulnerable code, but the entry point for this chain is not reachable there.

Wordfence's telemetry, cited in the writeup, counts more than 190,000 blocked exploit attempts since the August 19 disclosure, concentrated between August 19 and 23, against a plugin with over 6 million installs.

Checking and fixing

The writeup's triage sequence, using WP-CLI and shell access:

wp plugin get elementor-pro --field=version # want 4.2.2 or later find wp-content/uploads/elementor/forms/ -type f -name "*.php" -ls grep "elementor_pro_forms_send_form" /var/log/nginx/access.log | tail -n 50

Any PHP file found under the forms upload directory should be treated as evidence of compromise, not a cleanup-and-done situation. Conversely, absent log matches prove nothing, given log rotation and fast-changing attacker IPs; Wordfence maintains a live offending-IP list in its advisory rather than a static copy.

The fix itself is a plugin update: wp plugin update elementor-pro, then confirm the version is 4.2.2 or newer. For defence in depth, deny PHP execution under the upload directory at the web-server layer — an nginx location block or an Apache .htaccess FilesMatch rule — so the next validation bug in any uploader buys an attacker nothing. Wordfence paid-tier users should confirm the "Disable Code Execution for Uploads directory" firewall option is enabled; the free tier receives new firewall rules roughly 30 days after paid tiers, so free-tier sites had no firewall cover during the late-August attack peak and updating was the only immediate protection. Patchstack offers a virtual patch for sites that cannot update right away.

A final hardening pass suggested in the writeup: enumerate pages carrying Form widgets, restrict accepted file types to what the workflow actually needs (for example PDFs and images for application forms), and remove upload fields that are no longer necessary.

Why it matters

Two things make this more than a routine plugin patch. First, the timeline: same-day weaponization of internet-facing unauthenticated flaws is now normal, with nearly 200,000 blocked attempts within days of disclosure. If you run Elementor Pro with upload forms on a public page, updating is not optional.

Second, the root cause is a classic split-loop pattern — two passes over the same array disagreeing about what "empty" means. Anyone writing upload handling should validate and move files in a single pass, fuzz validators with permutations such as empty-valid-malicious, allowlist extensions, randomize stored names without preserving attacker-supplied extensions, and block code execution in upload directories at the web-server layer. That layered discipline is what turns the next CVSS 9.0 into a non-event.