Why Won't WordPress Just Patch Our Plugins For Us?

If you run a Shopify store or a Squarespace site, you almost never hear about a security incident. Not because these platforms are magically immune to vulnerabilities (they aren’t), but because you’re not supposed to hear about it. They’re closed, proprietary systems. When something needs fixing, the platform fixes it, silently, on infrastructure you never touch, and the update simply happens. There’s no plugin ecosystem of a hundred thousand independently-authored add-ons for a bad actor to sift through, and there’s no changelog for you to read because there’s no code for you to manage in the first place.

WordPress is the opposite kind of animal. It’s open source, it’s self-hosted (even when a host is doing the hosting for you), and its power comes from an ecosystem of tens of thousands of plugins written by tens of thousands of different people and companies, at wildly different skill levels, with wildly different levels of ongoing maintenance. That openness is also why WordPress security is so visible. Every vulnerability gets a CVE. Every patch gets a changelog. Every forced update makes tech news. It looks messier than Shopify not because it’s necessarily less secure, but because the whole system is out in the open.

Which brings us to the question a lot of site owners quietly ask themselves: if WordPress.org already knows how to patch a plugin, and it already has the technical ability to push that patch to every affected site, why doesn’t it just do that every time, instead of leaving us to subscribe to third-party services to cover the gap?

It’s a fair question. The honest answer is: they can, they do, but only rarely, and the reasons they don’t do it routinely say a lot about what kind of project WordPress actually is.

WordPress.org already has the kill switch, and has used it

This isn’t hypothetical. WordPress.org has forced updates onto sites multiple times, without anyone opting in:

In 2011, several popular plugin repositories (AddThis, WPtouch, W3 Total Cache) were compromised with backdoors slipped into legitimate commits. WordPress.org rolled back the malicious code, pushed clean versions, and reset every WordPress.org account password as a precaution.
In 2022, a critical vulnerability in Ninja Forms, being actively exploited in the wild, triggered a forced update.
In 2023, a serious flaw in Jetpack, installed on more than five million sites, was patched retroactively across every release going back to version 2.0, and pushed out automatically.
Most recently, a critical SQL injection and access-control issue in WordPress core itself (CVE-2026-60137 and CVE-2026-63030) led WordPress.org to enable forced updates for every affected site running the vulnerable core version, within roughly 24 hours of disclosure, and exploitation attempts followed almost immediately once the patch was public.

So the mechanism absolutely exists. There’s a flag in the plugin/theme update API that the WordPress.org security team can set, and when they set it, the update lands whether or not you’ve enabled auto-updates. It gets logged differently, it shows up as a “security auto-update” rather than a routine one, and it happens without asking permission.

The question isn’t “can they patch plugins directly.” They can, and they occasionally do, for the plugins with millions of installs, tied to the most severe, actively-exploited vulnerabilities. The real question is why that mechanism stays reserved for genuine emergencies rather than becoming the default response to every CVE.

Why it isn’t the default

Scale and ownership. Core is one codebase, maintained by one coordinated team who wrote it. The plugin directory is closer to a hundred thousand separate pieces of software, most of them written and owned by someone who isn’t WordPress.org. A security team can reasonably audit and patch its own code at speed. Auditing and safely rewriting someone else’s plugin, one they didn’t design, whose edge cases they don’t know, potentially interacting with dozens of other plugins on a given site, is a fundamentally bigger and riskier job. The “patch” WordPress.org pushes in an emergency is often a narrow, surgical fix (disable this one function, neutralize this one endpoint) rather than a proper rewrite, precisely because a deeper fix from someone who isn’t the original author is more likely to break something.

Auto-updates already have a bad track record for breaking sites, even when nothing malicious is involved. The community doesn’t have to imagine this risk in the abstract, it’s watched it happen with legitimate updates. When the All in One SEO plugin quietly turned on automatic updates without clearly notifying users, the resulting version broke layouts and wiped out metadata on sites that hadn’t asked for the change, and the backlash was immediate and angry. If a routine update from a plugin’s own author can do that, the risk multiplies when you’re talking about WordPress.org pushing a fix, under time pressure, into code it doesn’t own, on a stranger’s site it’s never seen, with a theme and a dozen other plugins it also didn’t write.

Not every vulnerability even has a patch available to push. A meaningful share of disclosed plugin vulnerabilities never receive an official fix at all: the developer is unresponsive, the plugin is abandoned, or the plugin has already been pulled from the directory. WordPress.org can force an update that exists; it can’t force one into existence. This is a big part of why the “why don’t they always patch it” question doesn’t have a single clean answer: sometimes there is nothing to force.

Liability and consent. WordPress core is famously insistent that the person running the site is the one in control of it. Auto-updates for major versions are opt-in by design; the project has resisted making that mandatory precisely because so many businesses run older, customized, or highly specific configurations where an unannounced change could cause real financial damage. Even WordPress.org’s own 2026 “Protect the Shire” policy, which holds new plugin releases back for up to 24 hours before they go live to give the security team a window to catch bad actors, shows how cautious the project has become about pushing code to the world’s sites even through completely normal channels, let alone forced ones.

It would still only be a stopgap, not a cure. Plugins account for the overwhelming majority of all WordPress vulnerabilities: well over 90% of everything disclosed in a typical year comes from the plugin layer rather than core. Even a WordPress.org team fully dedicated to nothing but plugin patching would be triaging thousands of new disclosures a year across code they don’t own. Realistically, it can only ever intervene in the most severe, most widely-installed cases, which is exactly the pattern you see in the incidents above.

Which is why the rest of the ecosystem exists

Because WordPress.org’s forced-update lever is reserved for the rare five-alarm fire, a whole layer of tooling has grown up to cover everything underneath that threshold:

Vulnerability intelligence and virtual patching, from companies like Patchstack, works differently to a core patch: instead of editing the plugin’s code, it sits in front of your site and blocks the specific request pattern that exploits a known, unpatched flaw, a firewall rule rather than a rewrite, deployable within hours of disclosure regardless of whether the plugin author has fixed anything yet. It’s genuinely useful, though it’s worth knowing its limits too: virtual patches aren’t produced for every disclosed vulnerability, and blocking a known exploit pattern isn’t identical to actually fixing the underlying flaw.
Malware detection and cleanup, from companies like MalCare (built by the same team behind BlogVault), scans installed sites for signs of compromise and helps remove infections after the fact, a different job again, closer to the “we got hacked, now what” end of the problem rather than prevention.
Server-level protection, from tools like Monarx or Blackwall, sits below WordPress entirely, watching how PHP actually executes on the server or filtering traffic before it ever reaches your application. This catches things a WordPress-aware plugin can’t, such as obfuscated web shells or zero-days with no known signature yet, but by design it doesn’t know anything about your specific plugin’s business logic the way a WordPress-native tool does.

None of these layers are competing to do WordPress.org’s job for it. They’re covering the enormous space WordPress.org’s own policy deliberately leaves uncovered.

So why doesn’t the community push harder for WordPress.org to just do it all?

This is really where the interesting part of the question lives. The capability is there. The project has used it. So why isn’t there a louder, more organized push from site owners and agencies to say: “please, just patch known critical vulnerabilities in our plugins automatically, all the time, not just in the worst cases”?

A few honest reasons keep surfacing whenever this gets debated in the community:

Control is the whole point of self-hosted WordPress. People choose WordPress over a proprietary, locked-down platform specifically because they get to decide what runs on their site and when it changes. Ceding that control back to WordPress.org, even for something as reasonable-sounding as “just security fixes,” is a step toward the very model people picked WordPress to avoid.
Trust in whose patch it is. A patch written by the plugin’s own author, tested against the plugin’s own feature set, is a different proposition to a patch written by a third party under time pressure. Site owners who’ve been burned by a “safe” update breaking their checkout flow are understandably wary of anyone else making that call for them by default.
Nobody wants to own the liability. If WordPress.org force-patched a plugin and that patch broke ten thousand stores mid-Black-Friday, the fallout (support tickets, lost sales, reputational damage) lands somewhere. Right now that risk sits with plugin developers and site owners, in a system everyone at least nominally consented to. Centralizing that decision doesn’t remove the risk; it just moves who’s responsible for it, and nobody involved seems eager to volunteer for that.
The market has already filled the gap, and habits follow incentives. Once Patchstack, MalCare, Wordfence, and hosting-level tools exist and work reasonably well, there’s less organized pressure on WordPress.org to take on a job those companies are already doing, imperfectly, sure, but as paid businesses with support teams and SLAs attached, which a volunteer-driven open-source security team doesn’t have the same capacity to offer at scale.

None of that means the current split is optimal. It’s reasonable to ask whether WordPress.org’s threshold for intervention is set too high, or whether a middle tier, something less than a silent forced core rewrite but more than “we hope the developer patches it soon,” could exist. But it does explain why “just patch everything automatically” isn’t the easy, obviously-correct answer it sounds like at first. WordPress’s whole architecture is a trade: enormous flexibility and an enormous ecosystem, in exchange for a security model that’s necessarily distributed across the core team, the plugin author, the host, and a layer of third-party vendors, rather than concentrated in one company that can quietly fix everything overnight.

That’s the trade Shopify and Squarespace users never had to think about, because they never had the flexibility in the first place.