Two WordPress form plugins in three days, both handing over the server

Three days ago a critical flaw in Forminator Forms exposed 600,000 WordPress sites. Yesterday Patchstack published a second one, in Elementor Pro, scoring 9.0. Same category of attack, same corner of the software, three days apart. If you use Elementor Pro the fix is at the top of this article. Then the part that matters more than either bug.

If you use Elementor Pro, do this now

Update to Elementor Pro 4.2.2 or later. Everything up to and including 4.2.1 is vulnerable. The patch shipped on 19 August 2026.

You are exposed if you have a published Elementor page with a Form widget containing a File Upload field. That is the only prerequisite, and the field's Required toggle being off is its default state, so nothing unusual has to have been configured. Job application forms, "attach a photo or receipt" forms and support tickets are the common cases.

If you cannot update today, unpublish those forms. Removing the file upload field, or taking the page down, removes the condition the attack needs.

Then check wp-content/uploads/elementor/forms/ for anything that is not a document or image your forms actually accept. Look for .php files in particular. Updating closes the hole; it does not remove a file somebody already placed. If you find one, that is an incident, and it needs somebody who does incident response rather than a guess.

What the bug is, and why it is worth understanding

The technical shape of this one is unusually clean, and it teaches something.

Elementor Pro's upload field has a proper defence. It checks every uploaded file's extension against an allowed list, and against a blocklist that explicitly covers php, phtml, phps, asp, exe and the rest. Reading that function, there is nothing wrong with it.

The problem is that it never ran.

The plugin handles an upload in two separate passes. One loop validates the extensions. A different loop moves the files into a public directory. The two loops disagreed about what an empty file entry means. The validator hit an empty entry and returned, leaving the whole method and never checking anything after it. The mover hit the same empty entry and continued, skipping just that one and carrying on with the rest.

One keyword apart. return in one place, continue in the other.

So an attacker submits two file parts for the same field: an empty one first, then the PHP payload. The validator stops reading and reports a clean submission. The mover skips the empty part and writes the payload to wp-content/uploads/elementor/forms/, which is publicly reachable over the web. No login, no cookie, no nonce. Every value the request needs is sitting in the page HTML for anyone to read.

Getting to the file afterwards is not much harder. The stored name comes from PHP's uniqid(), which is time-based rather than random, so the server's own Date response header gives most of it away. And on forms with an autoresponder enabled, which is exactly the configuration job application and support forms tend to use, the default notification template emails the uploaded file's URL straight back to the address the attacker supplied.

This is what Patchstack calls a desynchronisation flaw, and the description is precise: two pieces of code walking the same data with different rules. Neither loop is wrong on its own. The bug exists only in the gap between them, which is why reading either function in isolation shows nothing alarming.

Why this is the second time this week

Look at what these two vulnerabilities have in common, because it is not "WordPress".

Both are in a form plugin. Both are in the file upload field. Both are unauthenticated, needing no account. Both end in arbitrary PHP on the server. And both have the same underlying character: a security check that was correctly written and simply did not get applied to the thing it was guarding.

In the Forminator case, a sanitiser deliberately passed nested field data through untouched and an upload handler trusted that data as configuration. Here, a validator and a mover disagreed about an empty array entry. Different code, different vendors, same shape.

That shape is not a WordPress phenomenon. It is what happens in any codebase where the thing that decides and the thing that acts are far apart. The reason it keeps surfacing in plugins is not that plugin authors are worse engineers. It is that a file upload field accepting anonymous submissions is one of the most dangerous things a website can offer, it appears in almost every form builder, and the same feature is being independently reimplemented by dozens of vendors, each of them alone with a hard problem.

The part that should actually change your mind

Elementor Pro is the paid product. This is not a free plugin from a hobbyist. It is the premium tier of one of the most widely used page builders in the world, from a well-resourced company, and the flaw sat in its forms module.

So the comforting story people tell themselves, that you avoid this by paying for quality plugins and sticking to reputable vendors, does not survive this week. Both plugins are reputable. One of them is paid.

The realistic position is less flattering and more useful: you cannot audit the code you install, and you were never going to. Nobody running a dental practice is going to read upload.php and notice that one loop returns where the other continues. Your actual defences are narrower than the marketing suggests: install less, know exactly what you have installed, and patch fast.

About the timeline, fairly

The disclosure worked. A researcher, Tin Pham, reported it to Patchstack on 16 July. Patchstack confirmed it and assigned the CVE the same day. The vendor had a patch prepared the next day, which is genuinely fast and deserves saying.

The patch was released on 19 August.

Patchstack reviewed and confirmed the vendor's fix on 3 August, so part of that gap is verification. The rest is presumably release scheduling, and vendors do batch releases for sensible reasons. But the practical fact for a site owner is that a fix for an unauthenticated remote code execution flaw existed in July and reached sites in the second half of August.

And then the clock starts again on your side, because a released patch is not an installed one. That gap is the one you control, and in most small businesses nobody owns it. Which is the same conclusion as three days ago, arrived at from a different direction.

What to actually do

Turn on automatic updates for plugins. Almost every argument against doing so is really an argument that your site has no staging environment and nobody who could fix a broken update. Both of those are worth solving, but neither is a reason to sit on a critical patch for a month.

Audit what you have installed, and delete what you are not using. A deactivated plugin still has files on disk. Every plugin is a standing subscription to somebody else's security decisions, and most sites are subscribed to far more than anybody chose.

Know where your file upload fields are. After this week, that is a specific and useful question with a short answer. If a form accepts anonymous file uploads, it deserves more attention than the rest of your site combined.

And decide whose job patching is. Write the name down. If there is no name, that is the finding, and it is the same finding for the majority of small business websites in the country.

And then a third

A day later came a third, and it broke the advice this article ends with. Two critical flaws in miniOrange SAML SSO let an unauthenticated attacker log in as an administrator, and because that plugin ships seven separately versioned editions under one listing, every paid install read as already patched. Knowing what you have installed was not enough, because the version number itself was misleading.

The honest caveat

There is no indication in the advisory that this is being exploited in the wild, and this article does not claim there is. Patchstack has issued mitigation rules for its own customers. What is true is that a patch has existed since July, the technical details are now fully public, and the affected configuration is an ordinary one.

Our free X-Ray reads what your site exposes from the outside: security headers, certificate, what your pages disclose about the software behind them. It cannot tell you which plugin versions you run, because nothing from outside honestly can. For that, log in and look at your plugins page. It takes a minute and this week it is worth it.

Source: Patchstack, 19 August 2026. Reported by Tin Pham, also known as TF1T.