Elementor Pro Patches Critical Vulnerability Allowing Unauthenticated File Upload and RCE

On 19 August 2026, Elementor shipped Pro 4.2.2 and closed a vulnerability that let anyone on the internet write a PHP file into a public folder on a WordPress site and then run it. No account, no nonce, no login of any kind. The Elementor Pro vulnerability is tracked as CVE-2026-32475, it carries a CVSS score of 9.0 on the CVE record, and the only thing a target site had to be doing was running a published page with a form that accepts file attachments.

If you run Elementor Pro, the action is short and you should take it before reading the rest of this: update to 4.2.2 or later, then look inside wp-content/uploads/elementor/forms/ for anything ending in .php. Everything below is about the parts of this disclosure that are easy to get wrong, and there are several. Two security vendors and the vendor itself do not agree on who was exposed. The changelog entry that fixed it does not mention a CVE, a severity, or the words "remote code execution." And a large number of the sites still running the vulnerable version will never be told about the update at all, for a reason that has nothing to do with the bug.

TL;DR

• CVE-2026-32475 affects Elementor Pro 4.2.1 and below. Fixed in 4.2.2, released 19 August 2026. Unauthenticated, CVSS 9.0 on the CVE record, CWE-434.
• The flaw is in the Forms module's File Upload field. Two loops walk the same submitted files under different rules, and the one that checks extensions can be made to stop early while the one that saves files keeps going.
• The result is a .php file in wp-content/uploads/elementor/forms/, placed by an anonymous visitor and reachable over the web.
• Patchstack and Wordfence say the only precondition is a published page with a non-required File Upload field. Elementor told customers a second setting also had to be enabled. Treat the vendors' version as the one to plan around.
• Updating does not remove a file that was already uploaded. Check the folder as well as the version.
• The free Elementor plugin is a different plugin and does not include the Forms widget. It shipped its own unrelated security fix in 4.2.3 on the same day, which adds a version-number trap worth understanding.
• As of 25 August 2026 there is no public proof of concept and no confirmed exploitation in the wild. That is the fastest-moving fact here and it is worth re-checking.

What Elementor Pro 4.2.2 actually fixes

The vulnerability lives in the File Upload field of the Forms widget, which is a Pro feature. When a form is submitted, the plugin does two separate passes over the submitted files: one validates each file's extension against an allowed list and a hardcoded blocklist of executable types, and one moves accepted files into a public uploads directory.

The two passes disagree about what an empty file entry means. An upload part with a blank filename is reported by PHP as an error condition rather than as a file, and the validation pass and the processing pass have different early-exit behaviour when they hit one. The validation pass leaves the whole method. The processing pass skips that single entry and carries on. Patchstack, which published the advisory and assigned the CVE, calls it a "textbook desynchronization flaw": neither pass is wrong when you read it on its own, and the bug only exists in the gap between them.

The practical consequence is that a submission shaped so the validator stops reading before it reaches the payload gets its extension check skipped entirely, while the file still lands on disk. The blocklist is fine. It simply never runs.

I have deliberately kept the mechanism at this level. Patchstack's advisory contains the exact request shape, and there is no reason for a hosting blog to restate it while sites are still unpatched.

Why the usual file-upload defences did not apply here

This is the part worth understanding even if you do not run Elementor, because it explains why several habits that normally protect you were irrelevant.

Elementor Pro discards the submitted filename entirely. Only the extension survives into the name the file is stored under, which is built from PHP's uniqid(). That has two consequences that cut in opposite directions.

The good one: classic tricks are dead on arrival. A double-extension attempt like shell.php.jpg is stored as a .jpg and does nothing. An uploaded .htaccess becomes a file with an .htaccess extension sitting in a directory, not a directory configuration file, so it is inert. Null-byte games on the filename do not survive either. If you have spent years telling people to watch for double extensions, none of that mattered here.

The bad one: because only the extension matters, getting the extension past the check is the entire attack. There is no second gate. The blocklist covers PHP variants and other executable types, and it was the only thing standing between an anonymous form submission and code on the server.

How an attacker locates a file they just uploaded

The upload response does not hand back the stored path, so on paper an attacker still has to find the file. In practice this is cheap, and the reason is a detail worth carrying into your own code review habits.

uniqid() is not random. It is a hex encoding of the current time, seconds followed by microseconds. The seconds portion is effectively published by the server in its own Date: response header. That leaves a small remaining search space, narrowed further by the round-trip window of the request that created the file.

There is a second route that removes even that work. Elementor Pro's default form notification includes every submitted field, and for a file upload field that means the URL of the stored file. On a form that also sends an autoresponder to the submitted address, which is common on exactly the job-application and support-ticket forms that carry upload fields, the site emails the path to the attacker. If your form sends confirmations, it was potentially telling attackers where the file went.

Who was actually exposed, and why the answer depends on who you ask

This is where the coverage of this vulnerability diverges, and it matters more than any other detail in the story.

Patchstack's advisory states that the only prerequisite is a published Elementor page containing a Form widget with a File Upload field, and specifically notes that the field's Required toggle being off is its default state, so nothing unusual had to be configured. The Repository reports that Wordfence agrees, describing the precondition as a published page with a Form widget containing a non-required File Upload field.

Elementor told its own customers something narrower. In an email to subscribers reported by The Repository, the company said the vulnerability only affected sites using a form with a file upload field and the multiple file upload option enabled, which is off by default, and that all other Elementor sites were unaffected.

Those are not the same claim, and the gap between them is the difference between "most sites with a contact form that takes attachments" and "a small subset that switched on a specific option."

Two things are worth saying plainly. First, the Required toggle genuinely is part of the mechanism: the validation pass's early exit on an empty entry is conditional on the field not being marked required, which is why every account of this vulnerability mentions non-required fields. Second, nothing in the published advisory names the multiple-upload option as a precondition, and the field's submission format is an array whether or not the editor exposes multiple selection in the browser. A browser-side setting and a server-side one are different things.

There is one supporting data point on Elementor's side, and it deserves an honest mention rather than being quietly dropped: the CVE record's own vector rates attack complexity as high, and the CNA record does not explain what makes it high. That could reflect the filename-recovery step, or it could reflect a configuration precondition. Nobody has published which.

The practical position: plan around the vendors' description, not the narrower one. If your site ran 4.2.1 or below and had any published page with a form containing a file upload field, treat it as having been reachable and do the checks below. Being wrong in that direction costs you twenty minutes. Being wrong in the other direction costs you a server.

The changelog said almost nothing

Elementor Pro 4.2.2 lists three items. Two are security entries. One of them reads, in full, "Improved code security enforcement in Form widget". The other says the same thing about Dynamic Tags. No CVE, no severity, no indication that one of those lines closes an unauthenticated path to remote code execution.

This creates a specific and unfair trap. Reading the changelog before you update is careful behaviour. It is the behaviour anyone who has ever been broken by a bad plugin release learns to adopt, and it is the behaviour this blog recommends. Someone doing exactly that on the evening of 19 August would have read two lines of boilerplate and reasonably decided it could wait until Monday.

There are legitimate reasons for a vendor to leave detail out of a changelog while a fix is rolling out. There is no good reason for a security entry to be indistinguishable from every other security entry in the file. Elementor's changelog has used the same phrasing for years across dozens of releases of wildly different severity, which means it carries no information at all about urgency. The fair position is that the thirty-four days between a prepared patch and a public release are defensible, and that the wording is not: telling users which of those two lines was the critical one would have cost a sentence.

The blind spot: Elementor Pro does not update from WordPress.org

Here is the part that a hosting blog should say and most coverage of this vulnerability skipped.

Elementor Pro is not in the WordPress.org plugin directory. It cannot be, because it is commercial software. It updates from Elementor's own servers, and only for sites with an active, connected licence. When a licence lapses, the plugin keeps working. Pages keep rendering, forms keep accepting submissions, and the site looks entirely normal.

What stops is updates. There is no red badge on the Plugins screen, no update-available count in the admin bar, no nag. A site whose licence expired eight months ago sits on whatever version it had at the time, and on 19 August it stayed there while every article about this vulnerability told its owner to update.

That is not an edge case. It is the predictable end state of every client site an agency stopped invoicing for, every business that changed hands, and every "we built it once in 2023" project. If you manage sites for other people, the check is:

1. In wp-admin, go to Elementor → License and confirm the licence shows as active and connected.
2. If it is not active, either renew it or take any form with a file upload field offline until you do. Removing the upload field from the form is enough; you do not have to take the whole page down.
3. Check the actual installed version, not the update screen, because the update screen will not tell you anything if the licence is inactive.

wp plugin get elementor-pro --field=version

If that returns 4.2.1 or lower, the site is running vulnerable code regardless of what the dashboard says.

An expired licence on a plugin with a critical vulnerability is not a billing problem. It is a security incident with a date on it that has not arrived yet.

This is also the honest limit of what managed hosting can do for you. Automatic core updates with rollback cover WordPress itself, and daily off-site backups mean you have a restore point that predates a disclosure. Neither of those installs a licensed commercial plugin on your behalf, and no host can, because the update requires your licence key. What a host can reasonably do is scan for what appeared in your uploads directory rather than only checking plugin checksums, and help you keep track of which of your plugins update from outside WordPress.org, because that is the population this vulnerability lived in.

Free Elementor and Elementor Pro are different plugins with nearly the same version numbers

Both plugins released on 19 August 2026, and the version numbers are close enough to cause real confusion on a plugins screen that lists two entries both starting with "Elementor."

Three things follow from that table.

The Forms widget is a Pro feature, so a site running only the free plugin does not have the vulnerable code path. The free plugin has more than ten million active installations, and the vast majority of those sites were never exposed to this particular issue.

The free plugin's own 4.2.3 release does carry a security entry, in template handling rather than forms. There is no CVE attached to it that I could find, and no advisory explaining it, so treat it as a separate matter and update anyway.

And the version numbers collide. Free 4.2.2 shipped on 6 August and has nothing to do with the security release. If you check a site, confirm you are reading the right row: Elementor Pro must be 4.2.2 or higher, and the free plugin should be 4.2.3 or higher for unrelated reasons.

wp plugin list --fields=name,version,status,update

How to check whether your site was reached

Updating closes the hole. It does not undo an upload that already succeeded, because the file is sitting on your disk and the plugin has no idea it is there.

Start with the directory Patchstack named. Anything with a .php extension in there is not a form submission:

find wp-content/uploads/elementor/forms -type f -name '*.php'

Widen it to the whole uploads tree, because there is no legitimate reason for executable PHP to live under a media directory on a normal WordPress site:

find wp-content/uploads -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' \)

Now the honest caveats, because a clean result is reassuring rather than conclusive.

An attacker who got code execution had no need to leave anything behind in that folder. The uploaded file is a foothold, not the destination; the usual next step is to write a persistent backdoor somewhere less obvious and delete the original. An attacker who cleaned up properly leaves that directory looking exactly as it should.

So if the site ran a vulnerable version with a public upload form for any meaningful length of time, run the wider checks as well:

• Administrator accounts. Look for accounts you do not recognise, and for existing accounts whose role changed. wp user list --role=administrator --fields=ID,user_login,user_email,user_registered gives you the list quickly.
• wp-content/mu-plugins. Must-use plugins load on every request and never appear as something you can deactivate. On most sites this directory should be empty or contain only files you put there.
• Scheduled tasks. wp cron event list will show hooks that do not belong to any plugin you recognise.
• Recently modified files. Compare modification times against the date you last deployed. Anything in wp-includes or wp-admin with a recent timestamp deserves attention.
• Uploads with recent write times that are not media. Sort the uploads tree by modification time and look at the top.

If you find something, resist the urge to delete it and move on. Deleting a webshell removes the symptom and destroys the evidence of how it got there and what else was done. Take a copy of the file and the surrounding directory listing first, check your access logs for requests to that filename, and work out whether anything else changed. If the site handles customer data or payments, that log check is not optional.

Restoring from a backup taken before the disclosure date is the cleanest recovery if you have one and can tolerate the data loss, which is one of the few situations where daily off-site backups with a one-click restore earn their keep in a single afternoon.

What holds the line between disclosure and update

There is always a gap between an advisory going public and a site actually being patched, and for commercial plugins that gap is wider than usual because someone has to log in and click, and no host can do it for them.

Two things narrow the risk in that window. A web application firewall with a rule for the specific request shape blocks the attempt before it reaches PHP; both Patchstack and Wordfence shipped mitigations to their customers before most sites had updated. And configuring the server so that PHP is never executed from inside wp-content/uploads turns this entire class of vulnerability from remote code execution into a useless file sitting in a folder. That second one is a permanent change that costs nothing and pays out every time a plugin makes this mistake, which is roughly every few months somewhere in the ecosystem. It is a topic in its own right and worth setting up properly rather than pasting a snippet you found, because getting it wrong can break legitimate plugins that ship PHP inside upload paths.

Neither of those is a substitute for updating. They buy you the hours between the advisory and your maintenance window.

Two researchers found the same bug eight days apart

The disclosure history is unusual enough to be worth recording.

Tin Pham, who works under the handle TF1T, reported the vulnerability to Patchstack on 16 July 2026, and Patchstack disclosed it to Elementor the same day and assigned the CVE. Elementor prepared a patch the next day. Patchstack verified the fix on 3 August. The release went out on 19 August.

Separately, Austin Ginder of Anchor Hosting found the same flaw independently and reported it to Wordfence on 24 July, earning a $15,600 bounty through the Wordfence Bug Bounty Program, as reported by The Repository. Wordfence dropped its own CVE assignment once Elementor confirmed the prior report and adopted the identifier from Patchstack's disclosure.

Two independent researchers landing on the same logic error within eight days is not a coincidence, and it is the most useful thing in this whole story for anyone assessing risk. It means the bug was findable. Anyone reading upload.php with the right question in mind was going to see it, and the assumption that a vulnerability stays private until it is disclosed does not hold up well when two people trip over it in a fortnight.

As of 25 August 2026 there is no public proof-of-concept exploit and no confirmed exploitation in the wild. That is a genuinely good outcome and it reflects a disclosure process that worked. It is also a snapshot, not a guarantee, and the published advisory is detailed enough that the practical barrier to writing an exploit is now low.

Frequently Asked Questions

Which Elementor Pro version fixes CVE-2026-32475?

Elementor Pro 4.2.2, released 19 August 2026, or any later version. Every release up to and including 4.2.1 contains the vulnerable code. Check the version directly with wp plugin get elementor-pro --field=version or on the Plugins screen in wp-admin, rather than relying on the update notice, because a site with a lapsed licence will not show an update as available even though one exists.

Is the free Elementor plugin affected?

No. The Forms widget, including the File Upload field where this flaw lives, is an Elementor Pro feature, and Patchstack's advisory and the CVE record both name Elementor Pro specifically. The free plugin did ship its own release on the same day, version 4.2.3, which contains an unrelated security entry in template handling. Update it too, but for different reasons and with different urgency.

I updated to 4.2.2. Am I safe now?

You are safe from further exploitation of this flaw, but updating does not remove a file that was uploaded while the site was vulnerable. If you ran 4.2.1 or below with a published form containing a file upload field, check wp-content/uploads/elementor/forms/ for .php files, then run the wider compromise checks in this article. A clean folder is reassuring but not proof, because an attacker who gained code execution could have written a backdoor elsewhere and removed the original.

Does the multiple file upload option have to be enabled for a site to be vulnerable?

The sources disagree. Patchstack's advisory and Wordfence, as reported by The Repository, describe the only precondition as a published page with a Form widget containing a non-required File Upload field. Elementor told customers by email that the multiple file upload option also had to be enabled, and that it is off by default. Neither party has published a technical explanation reconciling the two. Plan around the vendors' broader description and verify your own configuration rather than assuming you were out of scope.

Was this vulnerability exploited in the wild?

As of 25 August 2026 there are no public reports of exploitation and no public proof-of-concept exploit, according to reporting from BleepingComputer, Orca Security and others in the days after disclosure. This is the single fastest-moving fact about this vulnerability and it can change without warning. Check current advisories from Patchstack and Wordfence before concluding that your unpatched site was not reached.

My Elementor Pro licence has expired. What should I do right now?

Renewing is the correct fix, because an expired licence means no security updates for as long as it stays expired. If renewal is not immediate, remove the File Upload field from any published form, or unpublish those pages. That closes the entry point without taking the site down. Do not assume you are on a safe version: an expired licence produces no update notices at all, so the admin screen will look completely normal on a site running two-year-old code.

Would a WordPress security plugin or a host firewall have stopped this?

Products with a rule for this specific request shape blocked it, and both Patchstack and Wordfence shipped mitigations to customers around disclosure. Generic protection is less reliable, because the request looks like an ordinary form submission until you inspect how the file parts are arranged. The durable defence is at the server level: if PHP cannot execute from inside wp-content/uploads, an uploaded payload has nowhere useful to run, regardless of which plugin let it through.

Conclusion

The Elementor Pro vulnerability patched in 4.2.2 is a clean example of how a serious flaw reaches a site owner: a two-line changelog entry that reads like every other release, a licensing model that quietly stops delivering updates when an invoice goes unpaid, and two plugins with almost the same name and nearly the same version numbers. The code bug was fixed in a day. The parts around it are what determined whether anyone found out in time.

If you take one thing from this beyond updating, make it the licence audit. Go through the sites you are responsible for and list every plugin that updates from somewhere other than WordPress.org, then confirm each one still has an active licence. That list is short on most sites and it is exactly where the next version of this story will happen.

If you would rather not be the one tracking all of this by hand, MagicWP includes managed security with malware scanning and a WAF, and daily off-site backups with one-click restore, so there is always a restore point that predates the advisory you have not read yet. It does not remove the need to keep your commercial plugin licences current, and nothing does.