🛡️ Patchstack Monthly: What's happening with all the WordPress vulnerabilities?

🛡️ IN THIS ISSUE

What is going on?

Hey,

If you feel update fatigue after all the vulnerabilities (Core and plugin) over the last 2 months, you're not alone.

Core vulnerabilities and highly exploitable plugin vulnerabilities are rising in the WordPress ecosystem. And for this issue, I sat down to look at the patterns our research team identified to help you stay safe:

1. Attacks start within hours of a fix. Attackers now read the patch, work out what it fixed, and start attacking the same day. For WordPress 7.1.2, that took about 6 hours. By the next day, a ready-made attack tool was publicly available.

2. Attackers log in instead of breaking in. Stolen keys, a link an admin clicks, a script that waits for an admin to open a form entry. None of these break a lock. They borrow someone’s access.

3. Updating doesn’t clean up a break-in. These attacks leave hidden accounts and backdoors behind. Update the plugin afterward, and the attacker still has a way back in.

Why there’s suddenly so much of it

Three things changed at once:

AI finds bugs faster. Look at who reported the core vulnerabilities: AI-assisted research shows up again and again, including Anthropic on 5 of them. More eyes, faster, means more bugs found. That’s good news long term. Short term, it means more patches, more often.

New features mean new ways in. 7 of the 17 advisories in WordPress 7.1.4 came from one newer feature, the Interactivity API. Fresh code hasn’t had years of people poking at it yet.

Attacking got easier. Turning a patch into a working attack used to take skill and time. Now it takes hours, and the tools get shared publicly. You no longer need to be good at this to do damage.

The result: the window between “a fix exists” and “attackers are using it” has shrunk from weeks to hours. Most update routines haven’t caught up.

What you can do

1. Know that (auto)updating is not a security strategy: Yes, update as soon as possible, but know that plugin vulnerabilities are still held back by the 6-hour delay of Protect the Shire. Attackers see the changelog before you can apply the update.
2. Check for UpdraftCentral keys on every site, even if you’ve never used it. Delete them if you find any.
3. Don’t trust the Users screen. Some of these attacks hide admin accounts from it. Check the database, or ask your host to.
4. Review who has Contributor access or higher. Almost all of the new core bugs start there.

Patchstack sites had protection against the WordPress 7.1.2 bug before the first attack landed, and against Bricksforge before anyone exploited it. No code changes, no waiting for the update.

Because nobody wants to explain to a client that their site got hacked through a plugin they didn’t write.

Were you affected by any of these vulnerabilities? What happened? Hit 'Reply' and let me know - I'd love to hear your story.