Elementor Pro CVE-2026-32475: Form Upload Flaw Exploited

If your site runs Elementor Pro and has any form with a file upload field, make sure you’re on 4.2.2 or later, and then check whether someone got in before you updated. CVE-2026-32475 lets anyone on the internet upload a PHP file through an ordinary contact or job-application form and run it. The fix shipped on August 19, and attacks started the same day. Ten weeks later it’s still one of the most attacked bugs in the WordPress world, because the sites that haven’t updated are exactly the sites nobody is watching.

At a glance

CVE	CVE-2026-32475
Plugin	Elementor Pro (more than 6 million active installs). The free Elementor plugin is not affected
Type	Unauthenticated arbitrary file upload in the Forms module, leading to remote code execution
Severity	CVSS 9.0 per Patchstack, 9.8 per Wordfence. Critical either way
Affected	Elementor Pro 4.2.1 and earlier, on sites with a published form that has a File Upload field
Fixed	4.2.2, released August 19, 2026. Updating does not remove a file that was already uploaded
Status	Exploited. Wordfence reports more than 190,000 blocked attempts, starting the day the patch shipped

What’s wrong

Elementor Pro’s Form widget can include a File Upload field, for CVs, screenshots, support attachments and so on. When someone submits the form, two separate pieces of code handle the files. One checks each file’s extension against a blocklist that includes php. The other moves the accepted files into wp-content/uploads/elementor/forms/, a public folder.

The bug is that the two loops disagree about an empty file slot. Tin Pham (TF1T), who reported it through Patchstack’s bug bounty, found that in the checking loop an empty slot ends the check with an early return, so nothing after it is examined. In the moving loop, the same empty slot is just skipped with continue, and the next file is moved as normal.

So the attack is one request:

Find a form. The form’s post ID, form ID and field ID are all visible in the page’s HTML. No login, cookie or nonce is needed.
Submit two files in the upload field. The first is empty. The second is a PHP file.
Slip past the check. The validator hits the empty slot and stops. The mover skips it and writes the PHP file to the forms folder.
Find the file and run it. Elementor names uploads with PHP’s uniqid(), which is based on the current time. The server’s Date header gives away the second, and the rest can be guessed. If the form sends an autoresponder with the default [all-fields] content, it emails the attacker the exact URL.

From there the attacker requests the file, and it runs as code on your server, with everything that follows: a web shell, new admin accounts, stolen data, malware that outlives the update.

Version 4.2.2 makes both loops treat an empty slot the same way and checks the extension again right before the file is moved.

What the attacks look like

A .php file in wp-content/uploads/elementor/forms/, with a random-looking name like 66c3a1f2b4e7d.php. That folder only ever holds form attachments. Any PHP file there is a compromise, not a false positive.
POST requests to /wp-admin/admin-ajax.php using the elementor_pro_forms_send_form action, especially bursts of them from one address. The action name is in the request body, so most access logs only show the AJAX URL.
GET requests to /wp-content/uploads/elementor/forms/ ending in .php in your access logs. That’s the attacker running the file, and it’s the clearest sign of all.
Form submissions with an empty attachment next to a second one, if your form entries or notification emails keep them.

Wordfence published the addresses behind the most attacks. These are the ones listed in Hive Pro’s advisory, which draws on that list:

185.196.220.85
103.84.230.85
103.90.148.202
216.126.225.208
167.254.240.75
167.254.241.119
114.10.17.253
114.10.45.151
2602:fa59:10:7a1::1
2406:ef80:2:7d19::1

Use them to search your logs. Blocking them won’t protect an unpatched site, because the attack fits in one request from any address.

What to do

1. Check your version

In Plugins, look at Elementor Pro’s version number. With WP-CLI:

wp plugin get elementor-pro --field=version

Anything below 4.2.2 is vulnerable. One catch: Elementor Pro isn’t on WordPress.org, and its updates come through your Elementor license. A site whose license lapsed, or that was built by an agency and handed over, may have been showing no update at all. If the version is old and the update button isn’t there, the license is the first thing to check.

2. Find out whether you’re exposed

The attack needs a published form with a File Upload field. To list the pages that have one:

wp db query "SELECT post_id FROM $(wp db prefix)postmeta
  WHERE meta_key = '_elementor_data'
  AND meta_value LIKE '%\"field_type\":\"upload\"%';"

Check templates and popups too, not just pages, because a form in a site-wide footer or popup counts. If you can’t update today, remove the File Upload field from every form, or unpublish those forms, until you can. Elementor’s own notice says the risk applies when the field’s multiple-file option is turned on, but Patchstack and Wordfence describe it as working on an ordinary upload field, so don’t count on that setting to protect you.

3. Update

Update Elementor Pro to 4.2.2 or later, or to the latest version. If you have staging, test there first, but with a bug this actively attacked, don’t let testing turn into weeks.

4. Check whether you were hit

If the site ran a vulnerable version with an upload form at any point since August 19, look, even after updating:

find wp-content/uploads/elementor/forms -type f \( -name "*.php*" -o -name "*.phtml" -o -name "*.phar" \)
find wp-content/uploads -type f -name "*.php" -newermt "2026-08-19"

Files: any PHP file in the forms folder, and any PHP file anywhere in uploads/. WordPress never puts code there.
Users: new administrators, and editors or other roles that have quietly been given extra capabilities.
Code: plugins you didn’t install, including on the Must-Use tab, and changed core or theme files.
Logs: the access-log patterns and addresses above, saved somewhere safe before they rotate out.

If you find a web shell, treat the whole site as compromised. Deleting the one file isn’t enough, because it was a way in, not the whole visit. Restore from a backup taken before the upload, change every password, log out all sessions, rotate the salts in wp-config.php, and replace any API keys the site held. Our remote-access audit covers the places an attacker likes to leave a key behind.

5. Stop PHP running in uploads

This is the setting that would have turned this bug from a takeover into a stray file. Nothing in wp-content/uploads/ ever needs to run as PHP, so tell the web server not to. On Apache or LiteSpeed, create wp-content/uploads/.htaccess with:

# Never execute scripts from the uploads folder.
<FilesMatch "\.(php|phtml|phar|php\d)$">
  Require all denied
</FilesMatch>

On Nginx, in the server block:

location ~* ^/wp-content/uploads/.*\.(php|phtml|phar|php\d)$ {
  deny all;
}

Then upload a test file such as test.php containing <?php echo "ran"; to the uploads folder and request it. You want a 403, not the word “ran.” Delete the test file afterwards. Some security plugins and hosts set this for you, but check rather than assume.

Where sources disagree

Severity. Patchstack scores it 9.0. Wordfence scores it 9.8.
What has to be switched on. Elementor’s customer notice says the risk applies to forms with the multiple file upload option enabled, which is off by default. Patchstack describes the vulnerable path as an upload field that isn’t marked “Required,” which is also the default, and calls that an everyday configuration. Treat any form with an upload field as exposed.
When attacks started. Wordfence says the day the patch shipped, August 19, with a spike through August 23. Some later write-ups date active exploitation to September 7.
How many sites. Reports cite more than 6 million Elementor Pro installs, and some quote the free plugin’s 10 million instead. Nobody has published how many sites have an upload form, and that’s the number that matters.

The bigger lesson

Patchstack had the report on July 16. Elementor had a fix ready the next day. Users were protected from the day it shipped, August 19, if they updated. Attackers were exploiting it the same day, because a patch shows anyone who compares versions exactly where the bug is. That’s the same pattern we saw with PHP2Shell, and it means the clock starts at the release, not at the first news story.

The sites still being hit ten weeks later mostly aren’t sites whose owners decided not to update. They’re sites where updates quietly stopped: an expired license, a hand-off from an agency, a build that nobody owns any more. A premium plugin is only as patched as the license that delivers its updates. If you can’t say who renews it and who applies its updates, it hasn’t earned its place on a public site, especially one that accepts files from strangers.

Elementor Pro CVE-2026-32475: Form Uploads Turned Into Site Takeovers