A critical flaw in one form plugin exposed 600,000 sites. The plugin was not the problem.

Today Wordfence published details of a critical vulnerability in Forminator Forms, a WordPress form builder running on more than 600,000 sites. It is rated 9.8 out of 10, and an unauthenticated stranger could use it to upload an executable file to your server and take over the site. If you use this plugin, the check takes two minutes and it is at the top of this article. Then the part worth arguing about, which is not the part you are expecting.

If you use Forminator, do this first

The plugin is Forminator Forms, sometimes listed as "Contact Form, Payment Form & Custom Form Builder". Check your WordPress plugins page.

Vulnerable versions are 1.56.1 and earlier. The fix is 1.56.2. Update to that version or later, today.

You are only exploitable if a form has both a File Upload field and a Select field on it. That combination is the trigger. If you have the plugin but no form with both, you are not currently exposed, and you should still update, because the next form somebody builds might have both and nobody will remember this article.

If you cannot update immediately, take down any form with both field types until you can. That removes the condition the attack needs.

If the site may already have been compromised, updating does not undo it. An attacker who uploaded a file before you patched still has the file. That is a different job: look for unexpected PHP files in your uploads directory, check for admin accounts nobody created, and if you find either, get somebody who does incident response rather than guessing.

What the vulnerability actually is

The technical detail matters here, because it explains why the trigger condition is so odd.

The flaw is tracked as CVE-2026-15748. Wordfence describes it as an unauthenticated arbitrary file upload via forged upload field configuration, in the plugin's handle_file_upload function.

Two weaknesses combine. The first is that the check on dangerous file extensions used exact-key matching, which could be bypassed with pipe-alternative MIME type keys. The second is more interesting: the plugin's generic request sanitiser deliberately returns the full nested value of select, radio and checkbox fields unchanged, leaving those field types to be handled properly later.

That second behaviour is not obviously wrong on its own. It becomes wrong when combined with an upload handler that trusts the field configuration it is handed. An attacker could use a harmless Select field as a carrier, smuggling in a forged record that declared itself to be an upload and supplied its own configuration. The Select field has no functional relationship to file uploads at all. It was simply the field type whose data survived the sanitiser intact.

That is what real vulnerabilities usually look like. Not one catastrophic mistake, but two reasonable decisions that were never considered together.

Give the vendor their due

The reflex here is to say something dismissive about WordPress. It would be cheap, and on the facts it would be wrong.

A researcher found this and reported it responsibly through a bug bounty programme, earning $2,048 for it. Wordfence passed full details to the Forminator team on 14 July 2026. The developer acknowledged it on 20 July, six days later, and shipped a fully patched version on 31 July, seventeen days after disclosure.

Seventeen days from report to patch on a critical bug is a good response. Plenty of commercial software vendors are slower than that. The disclosure process worked exactly as it is supposed to: found privately, fixed quietly, published once a fix existed.

So the story is not that WordPress plugin developers are careless. The story is what happens next.

The bit nobody puts in the headline

Here is the sequence. Patch available 31 July. Public technical write-up today, 17 August.

That gap exists for a good reason: give site owners time to update before you hand attackers a map. But it means that as of today, the full mechanism is public, and every site still running 1.56.1 is now a documented target rather than an unknown one.

This is the actual argument, and it is not about code quality. Plugin code is not worse than bespoke code. Bespoke code has bugs too, and ours will as well. The difference is arithmetic.

When a bug exists in software running on 600,000 sites, one working exploit opens 600,000 identical doors, and somebody publishes the shape of the key. Nobody needs to be interested in your dental practice specifically. They scan for the version string, and the scan is cheap.

When a bug exists in a system built for one business, an attacker has to be interested in that business, find the flaw themselves, and do it without a public advisory explaining where to look. The code is not necessarily better. The target list is shorter, and there is no advisory.

That is a real and defensible security difference, and it is worth being precise about, because the vaguer version of this claim is what other people sell.

The question this should actually raise

Forget the plugin for a moment. Answer this instead.

When 1.56.2 shipped on 31 July, whose job was it to install it on your site?

For a great many small businesses the honest answer is that it was nobody's. The person who built the site finished eighteen months ago and was never on a retainer. The owner has other things to do. Updates arrive as notification badges in an admin panel that somebody logs into when they need to change the opening hours.

That is the actual exposure. Not that a plugin had a bug, because plugins will always have bugs and so will everything else. The exposure is the seventeen days between a patch existing and a patch being applied, multiplied by however many months pass before anybody looks.

A site is not a thing you buy. It is a thing that needs somebody watching it, which is the whole argument in why your website is a decay curve.

What to actually do

If you are on WordPress and staying there, that is a legitimate choice and there is a lot of it about. Then: turn on automatic updates for plugins, keep the plugin count as low as you can genuinely justify, delete deactivated plugins rather than leaving them installed, and decide explicitly whose job patching is. Write the name down. If the name is nobody, that is your finding.

If you are choosing what to build next, the question to ask is not which platform is more secure in the abstract. It is how many third-party components will end up in the finished thing, and who is responsible for each of them for as long as the site is live. Every dependency is a subscription to somebody else's security decisions. Sometimes that trade is worth it. It should be a decision rather than a default, which is the argument in composable beats CMS.

And whatever you run, know what is on it. You cannot patch software you have forgotten you installed.

One honest caveat

There is no indication in the advisory that this vulnerability is being actively exploited, and this article does not claim it is. What is true is that the technical details are now public and the patch has been available since 31 July. Those two facts together are the reason to check today rather than at the weekend.

Our free X-Ray reads your live site and reports what it can see from the outside: your security headers, your certificate, what your pages disclose about the software behind them. It cannot tell you which plugin versions you are running, because nothing from the outside honestly can, and we would rather say that than pretend otherwise. For that, log in and look.

Source: Wordfence, 17 August 2026. Reported by the researcher daroo through the Wordfence Bug Bounty Program.