WordPress’s New Malware Filter Is Good. It’s Not a Reason to Stop Testing.

WordPress just gave every site owner a good reason to feel safer. It also gave them a worse reason to feel much safer than that. The new automated review of WordPress plugin vulnerabilities caught a real backdoor before it reached 20,000 sites. That is a genuine win. But treating it as proof that plugin risk is now handled would be a mistake, and a common one. The review only watches the door plugins walk through from now on.

It says nothing about the WordPress plugin vulnerabilities already sitting on your server. Those were installed years before this system existed, and nobody has touched them since. That gap matters more than the headline suggests. It is worth working through properly before anyone updates their risk assessment.

What actually happened

Since June, every plugin and theme release has sat in a cooldown of six hours before distribution. During that window, several AI models and Jetpack Scan check the code for trouble. They look for SQL injection, unsafe file operations, unchecked unserialize() calls, endpoints with no access control, and obfuscation. Cross-checked results become a security score. A high score blocks the release on its own. The WordPress Plugins Team said as much on 9 September.

On 28 July, the system proved itself. A backdoor landed in a release of a plugin with about 20,000 active installs. The review flagged it at once, so the compromised version never left cooldown. Wordfence spotted the same issue and alerted the team directly. The team pulled the plugin 26 minutes later.

Where WordPress Plugin Vulnerabilities Still Hide

Here is where the enthusiasm needs a limit. This review only looks at code from June onward. It has nothing to say about the plugin you installed two years ago and never touched since. It has nothing to say about the plugin with a known flaw either. Some of those were patched last year, yet the fix never reached half the sites that had the flawed version installed.

In our experience running penetration tests, most WordPress breaches do not trace back to a fresh attack on a well-known plugin. Far more often, they trace back to old, abandoned, or simply unpatched code. It sits quietly on a server nobody is watching closely. An automated review of new releases does not touch any of that. It was never designed to.

There is also a subtler risk in how comforting this news sounds. David Perez, co-lead of the Plugin Review Team, was honest about the limits. “A plugin can be secure today and introduce a vulnerability, or malicious code, in a future release,” he wrote. That is exactly right, but it cuts both ways. A plugin can pass every automated check today. It can still be running exploitable code from before the review existed.

Worth noticing: how the system is run

A blocked developer gets an email spelling out exactly which check fired. They fix the code and resubmit, going through the same cooldown as anyone else. The Plugins Team actively pushes authors toward fixing the problem rather than appealing the block. Their reasoning is simple: a manual review of an appeal takes longer than a corrected release does. That keeps the system fast. But it also means judgement calls sit with an algorithm rather than a person, at least in this first pass.

The bigger risk

Ask a penetration tester which finding shows up most often on a WordPress site. It is rarely a malicious plugin update slipping through in real time. Far more often, it is an outdated plugin nobody updated or a default configuration nobody changed. Sometimes it is simply an admin account with a password that was never rotated. None of that is new. It is exactly the kind of everyday WordPress plugin vulnerabilities this review was never built to catch.

The WordPress team plans to keep refining the checks as more data comes in. That is a sensible, honest approach to a system that is still young. It is also an admission that today’s version is a first pass, not a finished shield.

None of that is a criticism of the engineering. Checking several models against Jetpack Scan is a good way to cut false alarms. Blocking on its own, rather than waiting on a human, is the only way to move fast enough to matter. The point here is about how this news gets read, not how the system was built.

The right takeaway

Welcome the change. It closes a real gap and it clearly works, at least once. But do not let a headline about automated screening replace the boring, proven work. Patch what is already installed. Remove plugins nobody uses. Get an independent vulnerability scan of the site as it actually stands, not as WordPress.org hopes it stands. The new review protects the front door. It says nothing about the WordPress plugin vulnerabilities behind the windows you left open years ago.