Your backup plugin was the way in

Four critical holes turned up in widely-used WordPress plugins in about three weeks. That on its own is an ordinary month on the internet. What makes this batch worth writing about is where they were: three of the four were in software people had installed specifically to be safer, or to build faster. The security dashboard. The backup plugin. The page builder.

What actually happened

The WPMU DEV Dashboard — the plugin agencies install to manage security and updates across client sites — had an authentication bypass that let an unauthenticated attacker install any plugin they liked from a URL they controlled. That is remote code execution, which is the polite term for "they now run whatever they want on your server." It affected sites that had the plugin installed but had never connected it to the WPMU DEV Hub, because the unconnected state left the signing key empty and the signature trivially forgeable. Roughly 350,000 sites run this plugin. It was found by Wordfence's Argus system on 19 August.

Then a second one, in the same plugin, after the first patch. Version 5.0.1 fixed the first hole and still allowed an attacker to capture a valid signature and replay it to land an administrator session. That one scored 9.8 out of 10. You needed 5.0.2.

All-in-One WP Migration and Backup, on more than five million sites, is the one I find genuinely unsettling, and it is worth understanding the mechanism rather than just the headline. An attacker sends crafted trackbacks to any public post on your site. Nothing happens. The data sits in your database, inert, for as long as it takes. It only detonates when an administrator exports the site and imports it again — the plugin mishandles escaped quotes while rewriting the database during a restore, and the injected SQL runs at that moment. It retrieves the key that protects the plugin's own unauthenticated import action, and from there the site is theirs.

Read that once more. The trigger is doing a backup and restore. The safety procedure is the detonator. Exploit code for it is already circulating, and it was reported through the Wordfence bug bounty programme in mid-August.

Elementor Pro rounds it out. Faulty validation on file-upload arrays in its forms: send an empty file as the first item and a PHP file as the second, and the plugin stops checking. The payload lands in your uploads folder and is then simply visited. It scored 9.0, was patched on 19 August, and is being actively exploited right now — Wordfence has blocked something like 200,000 attempts against its own customers since the patch landed.

Why "just keep it updated" isn't a plan

It is the advice everyone gives, it is correct, and on its own it would have failed you three times this month.

It would have failed on WPMU DEV, because the patch was itself vulnerable. Anyone who updated promptly to 5.0.1 and ticked it off their list was still exposed. Being up to date is a moving target, not a state you reach.

It would have failed on All-in-One, because the malicious data was already sitting in the database before anyone knew there was a problem. Updating the plugin today does not remove the trackbacks that are already there waiting.

And it would have failed on Elementor for the most boring reason of all: the gap between a patch existing and a patch being applied. Two hundred thousand blocked attempts, all of them after the fix shipped. Attackers read the changelog too. A patch is a public announcement of exactly where the hole was.

The window between "a fix exists" and "the fix is on your site" is the entire game. If nobody is watching, that window is however long it takes you to notice.

What actually helps

Layers, and the honest position that none of them is sufficient alone.

Somebody whose job it is to notice

Most small business sites are not neglected out of carelessness. They are neglected because the person responsible is busy running a business, and a plugin update is invisible work that nobody thanks you for. That is genuinely most of what a care plan is: someone reads the advisories, knows which of your plugins matter, and applies the update before you have heard of the problem. On the WPMU DEV one, it also means knowing to go back a second time when the first patch turns out to be short.

Backups that live somewhere else, and get restored

This month made the case better than I could. A backup taken by a plugin, stored on the same server, by a plugin with a hole in its restore path, is not a safety net — it is another moving part. Backups want to be off the server, retained far enough back that you can go behind an infection you did not notice for a fortnight, and restored occasionally on purpose. An untested backup is a hypothesis.

Server-level malware detection

Everything above is about stopping the break-in. This is about the part after. Tools like Monarx, which some hosts include and others sell as an add-on, sit at the server rather than inside WordPress and watch how files behave instead of matching them against a list of known-bad signatures. That matters here, because the payload in the Elementor attack is a freshly obfuscated PHP file that no signature list has seen. Behaviour-based detection is what catches the webshell that already landed — and a plugin running inside the site it is meant to protect is in a poor position to notice it has been compromised.

Cloudflare, used properly

Worth being precise about, because it gets oversold. Cloudflare in front of a site does real work: it hides your origin server so attackers cannot bypass you and hit the IP directly, it rate-limits the noisy scanning that finds vulnerable versions in the first place, and its firewall rules can lock wp-admin, xmlrpc.php and the REST API to the handful of people who should ever touch them. Sensible rules there would have made all four of these considerably harder to reach.

But turning it on and leaving it at the defaults is not the same thing. And I would not claim it as a cure — the WPMU DEV attack sends a request carrying what looks like a perfectly valid signature. There is nothing malformed for a firewall to object to. That is the point of defence in depth: the firewall narrows the doorway, the malware scanner catches what gets through, and the backups mean the worst day is an inconvenience instead of a catastrophe.

The uncomfortable bit

Nothing here was exotic. No zero-day held by a nation state. These were reputable, popular plugins from established vendors, doing ordinary things slightly wrong, and the fixes were all available before most site owners had heard a word about it.

That is genuinely good news, because it means the difference between a bad month and an ordinary one is not sophistication or budget. It is attention. Somebody has to be reading, and somebody has to still be there when it does go wrong — because eventually one gets through, and at that point what matters is how fast you can be back up and how far back your clean copy goes.

If you are not sure who that somebody is for your site, that is the answer, and it is worth fixing before you need it rather than at 11pm on a Friday.

← Back to all articles