WordPress Has Had a Rough Few Months. Here's What Happened and What It Means for Your Site

I've been building WordPress sites for almost 15 years. For most of that time, security conversations with clients were short. Keep everything updated. Use decent hosting. Don't install plugins from places you wouldn't trust with your bank details.

That advice still holds. Since the summer, though, it hasn't been enough on its own.

Over the past few weeks I've been helping former clients get their sites back online after they were compromised. [Add a short, anonymised example here: what you found, how it got in, how long recovery took.] None of these owners had done anything reckless. They had simply fallen a little behind on updates, and a little behind is now enough.

So here's a plain-English rundown of what's been going on, why it's different from the usual noise, and what I'd want any site owner to do today.

Two flaws that have been used in real attacks

wp2shell (CVE-2026-63030 and CVE-2026-60137)

This pair of flaws shows why website security isn't just about the website.

Security firm GreyNoise tracked one attacker using wp2shell to break into at least 49 organisations across 29 countries, mostly small businesses and government bodies. Two of those victims were in the UK.

The worst case was a western government organisation. GreyNoise hasn't named it, for obvious reasons. On 22 July the attacker planted a web shell on its WordPress site. Within about ten minutes they had dumped the user table and taken 13 administrator accounts. They then created a new admin account made to look like a legitimate staff address, and even backdated it so it would blend in.

Then they went looking for passwords. They found database credentials sitting in readable files, used them to reach an internal SQL server, and walked off with 18,566 records. Those included plaintext passwords and personal data linked to law enforcement and government staff. The whole thing took around three hours.

The WordPress site wasn't the target. It was the front door.

CVE-2026-87902

This is the newest, patched on 22 September. According to WordPress's own advisory, it lets an attacker who isn't logged in trick WordPress into loading a PHP file from outside your theme. Under the right conditions, that gives them full control of the server. It carries a severity score of 9.2 out of 10.

Two things need to be true for it to work:

• Your active theme (or its parent) has a top-level folder whose name starts with page-. A page-templates folder is a common convention, so this isn't rare.
• A suitable PHP file exists on the server and the web server can read it. Attackers are using pearcmd.php, which ships with PHP's PEAR tooling on many servers.

The first attack was logged the same day the fix came out. Both Patchstack and Previdian have since seen attackers using it to write their own PHP files onto servers. The fixed versions are 7.1.2, 7.0.6, 6.9.9 and 6.8.10.

Previdian's CEO expects lots of attempts but relatively few successful break-ins, because WordPress has automatic updates switched on by default. That's a fair point. It only holds if automatic updates are actually on. In my experience that's often where things fall down. Hosts pin versions. Developers switch updates off to avoid breaking something. Sites managed through deployment pipelines only update when someone pushes a change. Any of those can leave you exposed for weeks without anyone noticing.

What's actually changed

Two things.

The first is speed. The gap between a fix being published and attackers using the flaw has shrunk from weeks to hours. A monthly maintenance check used to be reasonable. For critical issues, it no longer is.

The second is where the problems are. For years, "my WordPress site got hacked" almost always meant an abandoned plugin or a dodgy theme. WordPress core had a strong record. This summer broke that pattern, and it caught out people who were doing the sensible things.

Where AI comes into it

There's a detail in the GreyNoise report that stuck with me. The researchers didn't find a specific AI tool, but they believe the attacker used one to write their hacking tools. The code kept changing in ways that made no practical difference, which is typical of AI-generated code and a waste of time for a human.

That matters for small businesses. Writing custom attack tools used to take real skill and time. AI lowers both. More attackers can now move faster against more targets, and that fits the "hours not weeks" pattern above.

It cuts the other way too. More websites are being built with AI-generated code by people who can't properly review it. Code that works isn't the same as code that's safe. I expect we'll see more sites compromised through their own custom code over the next few years, WordPress or not.

None of this is a reason to panic. It is a reason to stop treating security as something you look at once a year.

Is WordPress still the right choice?

For most of the businesses I work with, yes. I don't say that lightly.

Look at how these issues were handled. Fixes were published quickly and backported to older versions. Security firms were tracking attacks within hours. The problem is rarely that a fix doesn't exist. It's that the fix never reaches the site.

Any platform running on a large share of the web will attract this kind of attention. What I won't do is pretend a WordPress site is a set-and-forget purchase. It's software running on a server. It needs someone looking after it.

What I'd check today

If you own a WordPress site, here's where I'd start:

1. Check your version. You want 7.1.2, or the latest release in the branch you're on (7.0.6, 6.9.9 or 6.8.10).
2. Confirm security updates install automatically. Don't assume. Check with your host or developer.
3. Review your admin users. Remove anyone you don't recognise, and be suspicious of accounts that look almost right.
4. Look for PHP files that shouldn't be there, particularly in the uploads folder and temporary directories.
5. Rotate passwords and secrets. Admin passwords, database credentials and WordPress salts. Then log everyone out.
6. Stop reusing passwords. If your WordPress password also opens your email, one breach becomes several.
7. Turn on two-factor authentication for every admin account.
8. Keep backups off the server, and test them. A backup you've never restored is a hope, not a plan.

If you think your site has already been compromised, don't just delete the suspicious file you found and move on. Attackers usually leave more than one way back in. Take the site offline, find out how they got in, and restore from a backup you know is clean.

How I look after client sites

That list is a lot to keep on top of alongside running a business. So for clients who take their security seriously, I offer [Service name] to handle it for them. It includes:

• Automatic updates for WordPress core, themes and plugins, monitored so that when a critical fix lands, it's applied in hours rather than weeks.
• A WordPress-specific firewall that blocks known attack patterns before they reach your site, which buys valuable time when a new flaw is published.
• Regular malware scanning, so anything unexpected, like a rogue PHP file or a new admin account, is picked up quickly.
• Daily offsite backups, stored away from your server, so a compromise means a restore rather than a rebuild.

No setup makes a site unhackable, and I'd be wary of anyone who tells you otherwise. What these do is shrink the window attackers rely on and make recovery quick if something does get through.

If you don't know which version of WordPress your site runs, or you're not sure who is responsible for updating it, that's your answer. Get in touch and I'll take a look.