Wordfence published its attack data for a critical file upload flaw in Elementor Pro on September 2, two weeks after the vulnerability was publicly disclosed on August 19. The vulnerability is not the new part; the record of how attackers targeted it is. According to that data, attackers began hunting for vulnerable sites the same day the flaw was described publicly, and the company’s firewall has blocked more than 190,000 exploit attempts since, with the heaviest traffic in the first five days. The fix was included in version 4.2.2. Sites still on 4.2.1 or earlier remain at risk if they meet the exploit preconditions and are not protected by a separate mitigation.
Key facts
- CVE-2026-32475: unauthenticated arbitrary file upload leading to remote code execution in Elementor Pro up to 4.2.1, fixed in 4.2.2.
- Not every site: exploitation requires a published page carrying an Elementor Pro Form widget with at least one non-required File Upload field.
- Attack window: Wordfence records attempts starting August 19, the disclosure date, peaking on August 20 and falling close to zero by the end of the month.
- How to check: Wordfence calls any .php file in wp-content/uploads/elementor/forms/ a strong indicator of compromise, because the directory is only meant to hold form submissions.
Six Million Installs, but Not Every Site Was Exposed
Wordfence puts Elementor Pro at more than 6 million active installations, and that figure has been the headline number. It is the install base, and not the same as the number of sites exposed to this particular flaw. Both security companies that documented the flaw describe the same precondition: the site must have published a page containing an Elementor Pro Form widget with a File Upload field that is not marked as required. Patchstack, which assigned the CVE, notes that the required toggle sits off by default, so a form built without changing that setting matches. But a site with no public form, or with forms that take no uploads, was never reachable through this path.
For anyone running a fleet, that turns into a sequence. Identify the sites on an affected version, narrow those to the ones publishing a Form widget with a non-required File Upload field, and treat any site meeting both conditions as requiring a check for indicators of compromise.
Elementor Prepared the Fix Within a Day
The patch history is worth setting out, because it shapes who was exposed and for how long. The flaw was reported to Patchstack on July 16 through its bug bounty program, credited in the CVE record to researcher Tin Pham, with Wordfence’s entry also naming Austin Ginder; the vendor had a patch ready the following day and validation finished on August 3. The fix is in 4.2.2. Elementor’s changelog lists 4.2.2 under August 6 and 4.2.3 under August 19, while Patchstack and Wordfence date the patched release to August 19, the day the advisory was published. The 4.2.2 changelog entry mentions an editor top-bar fix but does not identify a security change. The public sources do not explain the discrepancy.
Disclosure Day Was Attack Day
What is not ambiguous is what happened on August 19. Wordfence reports that attempts began the same day the vulnerability was described publicly, that the heaviest activity ran from August 19 to 23, and its published chart shows the volume peaking on August 20 at roughly 90,000 requests, before falling away to almost nothing after August 26. Ten IP addresses dominate its list, led by one with more than 28,000 attempts. Those ten account for at least 138,000 of the more than 190,000 attempts in Wordfence’s data, by our arithmetic, indicating that the activity it observed was highly concentrated.
For anyone maintaining sites on someone else’s behalf, that curve shows why critical security updates may need to be applied outside a routine weekly patch cycle. There was no quiet period after the publication of this flaw in which to schedule an update. Automated attacks arrived with the advisory itself.
What to Check on a Site You Manage
Wordfence’s data shows the initial spike had largely subsided by the end of August, but unpatched sites can still be targeted, so the work runs in both directions: update what is affected, and inspect what may have been exposed. Three checks cover it:
- Version. Confirm Elementor Pro is at 4.2.2 or later. Any site running 4.2.1 or earlier with a published form containing a non-required File Upload field should be treated as potentially exposed for the period that form was public.
- The uploads directory. Look in wp-content/uploads/elementor/forms/ for any file that is not one of the document or image types the site’s forms accept. Wordfence puts it plainly: that directory should never contain PHP files, so any .php there is a strong indicator of compromise.
- Access logs. Search for requests to wp-admin/admin-ajax.php carrying the action elementor_pro_forms_send_form. Wordfence publishes the ten addresses it saw most often, which gives a starting filter, and also warns that finding nothing in the logs does not prove a site was not compromised.
If a suspicious file turns up, the usual rule applies: an uploaded web shell is an entry point rather than the whole incident, so the site needs a review for additional backdoors and for anything the attacker may have written elsewhere.
How the Upload Check Was Bypassed
The bug is easy to describe. Elementor Pro’s form handler ran two loops over the files in an upload field: one to validate them, one to move them into place. In Patchstack’s account, the validation loop used return where the processing loop used continue. An attacker who submitted an empty first file and a second file named with a .php extension caused validation to exit on the empty entry, skipping the extension and file type checks for everything after it, while the processing loop carried on and wrote the remaining file to disk.
No login and no nonce were needed, and the values required to build the request, the post ID, the form ID and the field names, are all visible in the public page source. The uploaded file lands in wp-content/uploads/elementor/forms/ under what Wordfence describes as a randomly generated filename with the attacker’s chosen extension. Once that filename is determined, the file can be requested directly to run commands on the server.
The two companies score it differently, which is worth knowing if a client asks why the numbers do not match. The CVE record, assigned by Patchstack, rates it 9.0 and treats the attack complexity as high. Wordfence’s own intelligence entry rates it 9.8. Both are in the critical band, and both describe the same potential outcome: complete compromise of the site.
About the Data
The vulnerability details, versions and disclosure timeline come from the CVE record and from Patchstack’s technical write-up. The attack volumes, the addresses involved and the indicators of compromise come from Wordfence’s analysis of September 2, read in full. Version dates are from Elementor’s own changelog, which differs from the security vendors on when 4.2.2 shipped, and we have reported both rather than choosing between them. We have not tested any of this, and none of the parties has published a figure for how many sites were actually compromised.
