As reported by BleepingComputer, a critical vulnerability in the Elementor Pro WordPress plugin — tracked as CVE-2026-32475 — enables unauthenticated remote code execution through a subtle flaw in the plugin's File Upload module. The root cause is a validation-processing loop mismatch: the validation routine exits early on empty filename entries (UPLOAD_ERR_NO_FILE), while the processing loop skips empties but continues moving subsequent parts into a publicly accessible directory. An attacker crafts a multipart upload where the first entry has an empty filename and the second contains a PHP payload. The validator never sees the payload; the mover deposits it in wp-content/uploads/elementor/forms/.
This is a textbook example of a double-fetch / dual-loop inconsistency — a class of bug where two code paths operate on the same data but apply divergent logic. It is particularly insidious because each loop appears correct in isolation. Security code review must trace data through all loops that touch it, not just the one labeled "validation."
Vulnerability Details
| CVE ID | CVE-2026-32475 |
| Severity | Critical (exact CVSS not yet published; RCE with no auth warrants 9.0+) |
| Vendor / Product | Elementor Pro (WordPress page builder plugin) |
| Affected Versions | Elementor Pro < 4.2.2 |
| Patched Version | Elementor Pro 4.2.2 (released August 19, 2026) |
| Exploitation Precondition | Site must have a published Elementor form with a File Upload field |
| Active Exploitation | Not yet observed in the wild (patch released same day as disclosure) |
| Impact | Unauthenticated RCE as web server user; full site compromise |
Why This Matters Beyond WordPress
Elementor's free version has over 10 million active installs; the Pro tier is widely adopted by businesses, e-commerce stores, and agencies managing client portfolios. Any site with a published form containing a file upload field is exposed. The attack surface is significant because file upload forms are common in contact pages, job applications, and customer support workflows — pages that are inherently public-facing and indexed.
The filename prediction vector compounds the risk. The uniqid() function is time-based, not cryptographically random, and Patchstack confirms attackers can brute-force the filename via timing. In some configurations, an autoresponder email leaks the exact URL. This means the "obscurity" of the uploaded filename is not a meaningful barrier.
The deeper lesson: PHP's
$_FILESsuperglobal andUPLOAD_ERR_NO_FILEhandling invite exactly this kind of logic divergence. Any WordPress plugin — or any PHP application — that iterates uploaded files in separate validation and processing loops is a candidate for this pattern of bug.
Who Is Most at Risk
Immediate Actions
- Update Elementor Pro to version 4.2.2 or later immediately. This is the only complete fix.
- If updating is delayed: temporarily remove or disable the File Upload field from all published Elementor forms. Unpublish the form or replace it with a non-Elementor alternative.
- Block direct PHP execution in upload directories. Add a
.htaccessrule inwp-content/uploads/:php_flag engine off(Apache) or the equivalent Nginx configuration denying PHP execution in upload paths. This is a long-overdue hardening step regardless of this CVE. - Check for indicators of compromise: scan
wp-content/uploads/elementor/forms/and other upload directories for.phpfiles. Review web server access logs for POST requests to form endpoints followed by GET requests to.phpfiles in upload paths. - Restrict file permissions so the web server user cannot write to core WordPress directories, limiting post-exploitation lateral movement.
Shield53 Recommendations
Beyond the immediate patch, defenders should treat this as a forcing function for broader WordPress hardening:
- Implement WAF rules that block multipart uploads containing empty filename entries followed by executable extensions. Most modern WAFs can be configured with custom rules targeting this pattern.
- Audit all plugins with file upload functionality — not just Elementor — for similar validation/processing loop inconsistencies. Contact the vendor if the code pattern looks suspicious.
- Deploy file upload hardening at the server level: restrict upload directories to static file serving only, enforce MIME-type allowlists, and store uploads outside the web root where possible.
- Enable PHP
open_basedirrestrictions to limit the directories PHP can access, reducing blast radius if RCE occurs. - For agencies and multi-site operators: inventory all client sites running Elementor Pro, confirm version numbers, and document which sites have file upload forms. This CVE will be weaponized in automated scanners within days.
- Monitor for exploitation attempts: alert on any
.phpfile creation insidewp-content/uploads/and on HTTP requests matching the multipart empty-filename pattern.
The responsible disclosure timeline here was exemplary — Patchstack received the report on July 16, Elementor prepared a fix within a day, and the patch shipped roughly five weeks later. But the window between patch availability and mass exploitation is now measured in hours, not weeks. Sites that delay updating past 48 hours are statistically likely to be scanned and compromised.