Elementor Pro Was Exploited Within Hours. One Server Rule Turns That Attack Into a Dead File.
By Stu 7 min read
On 19 August 2026 Elementor released version 4.2.2 of Elementor Pro. It fixed CVE-2026-32475, an unauthenticated arbitrary file upload in the form widget, rated 9.8 out of 10. Attackers started using it the same day. By 4 September, Defiant's Wordfence firewall had blocked close to two hundred thousand exploit attempts against its own customers alone, and roughly two-thirds of the six million or so sites running Elementor Pro were still on a vulnerable version.
That last number is the one to sit with. Two weeks after a critical patch for one of the most installed premium plugins in WordPress, most sites had not applied it. Some of those sites will have been compromised in that window. Many of them will not find out for months.
This post is about the bug, briefly, and then about the thing that actually decides whether a site like that got hurt, which is not the patch.
The bug
Elementor Pro's form widget can include a file upload field. When a form is submitted, the plugin loops over the uploaded files and validates each one: type, extension, the usual checks.
The flaw was in how that loop handled an array of files. If the first entry in the array was empty, the validation returned an error for that entry and stopped. It did not go on to check the remaining entries. But the remaining entries were still written to disk. So an attacker submits the upload field as an array, puts an empty slot first and a PHP file second, and the PHP file lands in wp-content/uploads/elementor/forms/ without ever being looked at.
From there it is one HTTP request to the file's URL and the attacker's code runs on your server. No account needed. The only precondition is a published form with a file upload field, which is a common configuration on exactly the kind of business site that runs Elementor Pro.
The fix is to update to 4.2.2 or later. If you run Elementor Pro and have not, stop reading and do that.
Why the patch is not the interesting part
Every plugin will have a bug like this eventually. Form plugins in particular, because accepting files from strangers is intrinsically hard to do safely. Forminator and Everest Forms both had unauthenticated upload flaws disclosed in the same few weeks. The pattern is not Elementor-specific and it is not going away.
So the useful question is not "how do I make sure I patch Elementor Pro within hours next time". You will not. Two-thirds of sites did not manage it in two weeks, and those were not all careless people. The useful question is: what state should a site be in so that when the next upload flaw is exploited before you have patched it, the result is nothing?
The answer for this entire class of attack is one rule, and it has been in chapter 2 of the handbook since the first edition.
Block PHP execution in the uploads directory
The wp-content/uploads directory has to be writable by WordPress, because that is where media goes. It has no legitimate reason to ever execute PHP. Every file in it is supposed to be an image, a document, a video. So you tell the web server that any .php file under that path is not to be run, ever, regardless of how it got there.
On nginx:
location ~* /wp-content/uploads/.*\.php$ {
deny all;
}On Apache, in a .htaccess file inside the uploads directory:
<Files "*.php">
Require all denied
</Files>That is the whole rule. With it in place, the Elementor Pro exploit still works, in the sense that the attacker's file still lands in uploads/elementor/forms/. And then nothing happens. The request that is supposed to execute it gets a 403. The attacker has written a file that can never run, and your site is exactly as compromised as it was before, which is to say not at all.
Without it, the very next request runs the payload with the full permissions of your PHP process, and the attacker has a webshell, a way to write files anywhere PHP can, and the beginning of everything described in the self-healing malware post.
The difference between those two outcomes is five lines of server configuration that took about a minute to add and have no effect on anything legitimate. There is no downside. There is no plugin that needs to run PHP from uploads. If you find one that does, that plugin is the problem.
It is also a free indicator of compromise
Once the rule is in place, the uploads directory has a useful property: it should never contain a .php file. Not one. So a very cheap check, over SSH, tells you whether anyone has tried:
find /var/www/html/wp-content/uploads -name '*.php'If that returns anything, somebody got a file in. With the rule, they could not run it, but you still want to know, because it means a vulnerable plugin is installed and being probed, and the attacker will try other things. If you run Elementor Pro, the specific path uploads/elementor/forms/ is where Defiant recommends looking first.
Run that command now, and put it in the monthly checklist.
The other August bug shows the limits of this rule
For balance, one rule does not cover everything, and the same fortnight produced a counter-example.
All-in-One WP Migration, five million installs, patched CVE-2026-19949 on 20 August. It is a second-order SQL injection in the restore function: an attacker plants a payload through trackbacks on a public post, and it does nothing until an administrator later exports and re-imports the site, at which point the plugin's URL rewriting turns the stored payload into live SQL. That leaks the restore key, and with the restore key the attacker imports an archive containing a malicious must-use plugin, which runs on the next page load. As of 3 September about 3.2 million sites were still on a vulnerable version.
The uploads rule does nothing here. The attacker never uploads a PHP file to uploads. The persistence lands in wp-content/mu-plugins, which loads before normal plugins and cannot be deactivated from the dashboard. What catches this one is a different habit from a different chapter: knowing what is in your mu-plugins directory and noticing when something appears there that you did not put there.
That is the general point. No single rule makes a site safe. What the good rules have in common is that they make specific, common attack classes fail silently and cheaply, so that the patch you did not apply in time does not decide the outcome. The uploads rule does that for file upload flaws. The mu-plugins audit does it for restore and import flaws. Blocking PHP in uploads, auditing mu-plugins, keeping wp-config.php unwritable, running the web server as a user that cannot write to plugin directories: each one closes a class, and together they mean the next Elementor Pro is an inconvenience rather than an incident.
Where this fits
Chapter 2 of the Protect My WP handbook is WordPress core hardening: the uploads rule above, the sensitive-file blocks, wp-config.php permissions, the login lockdown, and why point releases are not optional. Chapter 8 covers the mu-plugins and drop-in audit that catches the All-in-One case. Both were updated this month with these two incidents as the worked examples, because a rule is easier to remember when you have seen what it stops.
Get the book for £19.
Get the free WordPress Security Checklist
The security checks I'd run through on any WordPress site, delivered straight to your inbox. Or work through it online.
Want to go deeper?
Protect My WP is the whole handbook: 14 chapters from the server up, kept current as WordPress changes, with a PDF edition included. £19, one payment, every future update. Not sure yet? The foreword and Chapter 1 are free, and the shorter guide walks the same ground faster.