Let’s open with a confession: we tested this ourselves. The AgentOffense team ran a series of experiments against the official WordPress plugin directory, and we found a gap that WordPress only closed this month. The gap sat in the difference between how a brand-new plugin is reviewed and how its later updates are. A fresh version carrying a vulnerability could be delivered to hundreds of thousands of sites through an update, because updates, unlike a first submission, were barely reviewed at all. The good news: as of this month, that changes. The bad news: until now, this is exactly how we got in during the experiment, and exactly how real attackers operate.
What we tested and what we found
The logic of attacking a plugin directory is simple, which is what makes it dangerous. When a plugin is first submitted, it goes through manual review: a human looks at the code and decides whether it belongs in the directory. After that, the plugin lives its own life and ships updates, and that is where the scrutiny fell off a cliff. We set out to measure how far.
We built ten simple plugins, put them honestly through the initial review, and published them in the official directory where they became available to everyone. Then we shipped an update for each one, deliberately planting an obvious, easy-to-spot vulnerability. The result was telling: all ten updates went through without a single question. No dangerous snippet triggered any reaction, because updates were effectively pushed straight to distribution on autopilot.
How we ran it. This was a controlled experiment, not an attack. All ten plugins were test plugins, the code in the updates was purely nominal and could not harm any site — it merely marked a vulnerability rather than exploiting it. We closed every plugin immediately after the check. The goal was not to cause damage but to demonstrate a gap in the process that badly needed to be said out loud.
Why it worked
The problem was that the guard was posted in the wrong place. All of the review effort went into the moment a new plugin was accepted, while updates were treated as an afterthought — the author is already vetted, so why re-check them. But that is precisely how real attackers work. The playbook is years old: publish a clean, genuinely useful plugin, wait until thousands of sites rely on it, then quietly slip malware into an ordinary-looking update. The user sees the familiar “a new version is available,” clicks “update,” and installs a backdoor with their own hands.
We have covered the same disease from a different angle in the ChainDrop npm supply-chain worm, where trojanized updates rode a maintainer’s trust into the next package. A plugin directory is the same kind of trusted source, one that millions of sites rely on by default. And trust that nobody re-verifies eventually turns into a malware delivery channel.
What WordPress just changed
Here is the headline: WordPress introduced an automated security review for every release, and crucially, not only for new plugins but for all updates too. Exactly the piece that was missing. Now any new version, before it fans out to sites, lands in a short cooldown window during which it is examined.
| How the new review works | Detail |
|---|---|
| What is reviewed | every release — new plugins and all subsequent updates |
| Cooldown window | about 6 hours before distribution (down from 24) |
| What analyzes it | several AI models alongside Jetpack Scan |
| Output | a combined security risk score from the findings |
| On high risk | the release is blocked automatically and never ships |
| Notification | the developer gets an email with the findings |
The score measures risk, not intent: an accidental vulnerability and a deliberate backdoor land a similar number, and that is correct, because a site does not care whether it is broken on purpose or by oversight. If a version scores high, it is blocked automatically, without waiting for someone on the Plugins Team to be free to look. The system has already proven itself in the wild. On 28 July a backdoor was committed to an update of a plugin with roughly 20,000 active installs. The automated review caught it right inside the cooldown window, assigned a high score, and the compromised version never reached a single site. The plugin was closed 26 minutes after the team was notified.
Why this matters now
Building a convincing malicious plugin used to be slow work: you had to write the code, learn the WordPress APIs, and disguise the payload. That filtered out the casual attacker. Now the barrier has collapsed. With vibe coding — building software by describing it in plain language and letting an AI write the code — anyone can assemble a working plugin in 20 to 30 minutes, one that would very likely pass directory review. You do not need to be a programmer; you just need to describe what you want.
That changes the scale of the threat. It is one thing when malicious plugins are hand-built by a handful of skilled attackers. It is another when anyone can produce one, fast and cheap, and the AI-written code looks clean enough to avoid suspicion. This is the same shift we keep documenting: AI has collapsed the gap that used to separate skilled operators from everyone else, as we detailed in how attackers automate exploitation with AI and in what an AI coding agent can actually do on your machine. WordPress answered an AI-driven threat with AI-driven defense, and that is the right call.
What to do about it
The new WordPress review is a big step, but it only covers the official channel. Everything else is still on you.
- Do not update blind. Auto-updating everything is convenient, but it is exactly what turns a swapped version into instant compromise. On critical sites, stage updates with a short delay and watch what actually changes.
- Cut the number of plugins. Every third-party plugin is someone else’s code running with full rights on your site. The fewer you run, the smaller your attack surface, and the less trust you are extending blindly.
- Install only from trusted sources, and never from “nulled” bundles or sketchy archives where no review exists at all.
- Treat any code you pull into a build as guilty until proven clean — the threat model for agentic and generative AI starts from exactly that assumption, and it is the right default now that plugins can be generated in half an hour.
- Build the check into the pipeline, not after it. Reviewing every change for injected or malicious code before it ships is what Agentpipe is built to do, so a poisoned update is caught in CI rather than in production.
Bottom line
Our experiment and WordPress’s latest move say the same thing from two directions. We showed that the update channel had been the weak link for years, a path through which a vulnerability could reach live sites with no review at all. WordPress has finally shut that door with automated review of every release. Vibe coding is what turned this from a nice-to-have into a necessity: once a plugin with a backdoor can be assembled in half an hour by anyone, you have to review everything, continuously, not just the newcomers at the gate. For site owners the takeaway is simple: the official directory just got safer, but blind trust in any given update is still a bad idea. And for anyone shipping software, the deeper lesson is the one we keep returning to — the same AI that writes your code writes the attacker’s, so the review has to be built in. It is the logic behind our whole approach to securing AI-driven software, and it is why the recent PaperCut mass-exploitation campaign looked the way it did.