Between March and May 2026, four separate WordPress plugins were found to have flaws rated 9.8 out of 10. Not one. Four, inside eight weeks. On the worst day of the wave, security monitors logged more than seventeen thousand attack attempts in a single day. That is the shape of an automated campaign, not somebody poking around by hand.
If you own a WordPress site and this is the first you are hearing of it, that is the point of this article. Almost nobody outside the security world noticed, and the sites that got hit were not the ones running old software. They were the ones where nobody had the job of looking.
What actually happened
The headline most people half-remember is that “new versions of WordPress got hacked”. That is not what happened, and the difference matters if you are trying to decide what to do about it.
WordPress core had its own problem too: a pair of flaws known together as wp2shell, used to drop a persistent webshell and install malicious plugins. Real, serious, and patched. But core is not where the wave came from.
It came from plugins. One of the worst, in Everest Forms Pro, let an attacker run their own PHP on your server without logging in at all. Every version up to 1.9.12 was affected, and it was being exploited in the wild before most site owners had heard the name.
And in April something worse: the WordPress.org plugin repository itself was attacked. Over seventy-two hours, more than twenty-five plugins were compromised at the source. Roughly eight hundred thousand sites downloaded updates that quietly installed a back door. Not pirated plugins. Not something a user did wrong. The official channel.
The number that should worry you
Through 2026, plugin vulnerabilities have been disclosed at an average of thirty-six a day. Almost half of them need no login at all to exploit.
But here is the one that decides whether it happens to you: a quarter of them are still unpatched a month after being made public.
Read that again, because it reframes the whole problem. The fix existed. It was published. It sat there for thirty days while the site stayed open. Security in WordPress is not really a software problem, because the software gets patched fast and well. It is a maintenance problem wearing a security costume.
Why “update available” is not a plan
Every WordPress dashboard shows update notices. Most site owners see them, mean to get to it, and do not, because updating carries a real risk of breaking the page, and nobody wants to be the person who broke the site on a Tuesday afternoon.
So one of two things happens. Either updates pile up until the site is a year behind, or auto-updates get switched on and everybody stops looking. The second feels safer and is not: an auto-update that breaks a layout is worse than a delayed one, because now the site is broken and nobody noticed.
What works is dull and unglamorous. Somebody reviews what changed, applies it, and checks the page still renders. Backups leave the server, because a backup sitting on a compromised server is gone with it. Logins are limited, file editing is off, and the uploads folder cannot execute code. None of that is clever. It just has to actually happen, every month, whether or not anything is wrong.
If your site is already compromised
Do not start by deleting the file you can see. That is the instinct and it destroys the only evidence you have.
The order that works: take the site offline first, so it stops serving spam and collecting a Google warning label. Copy the files and the database off the server before cleaning anything, because once you clean you can no longer find out how they got in. Then look for the way in: access logs, file modification dates, admin users you do not recognise, scheduled tasks nobody set up, and old backup scripts left in the web root that are still perfectly executable.
Clean by replacing, not by disinfecting. Core, plugins and themes come back from clean copies. The only things kept are your uploads and your database, both scanned. Then rotate everything: security keys, every administrator password, the database user, the server logins. Rotating just the admin password leaves the next door open.
One practical warning, because it surprises people: a plugin cannot rescue a site that will not start. Security plugins live inside WordPress. If WordPress is not running, neither are they. Recovery happens over SSH or SFTP, through the hosting panel, and from a backup that lives somewhere other than the server that just went down. If you do not have those three things today, getting them is the job, not something to work out mid-incident.
What to do this week
Find out who is responsible for updating your site. If the answer is “the person who built it”, check when they last logged in. If the answer is nobody, that is the finding.
Then check that a backup exists somewhere that is not your hosting account, and that somebody has actually restored one at least once. An untested backup is a hope, not a backup.
None of this requires a new tool. It requires the work to have an owner.
On our website plans, the patching, backups, hardening and monitoring are inside the monthly — not an add-on, and not a plugin licence. If your site is not on a plan, a one-off security audit will tell you where you stand, and the rest of the pricing is published in full.
Nobody can promise you will never be hacked, and you should be wary of anyone who does. What can be promised is that the routine runs, and that if the routine ever fails there is a procedure instead of a panic.
