A WordPress Plugin on 600,000 Sites Has Two Unauthenticated Paths to Full Takeover. Patch Today, Not This Week.
Two days ago, security researchers disclosed a pair of unauthenticated vulnerability chains in The Events Calendar, a WordPress plugin running on more than 600,000 sites. No login required, no other plugin needed, no admin approval to trigger. One chain runs arbitrary commands on the server. The other resets the site's admin password. Both are rated 9.8 out of 10 on the CVSS scale, which is about as close to "drop what you're doing" as a vulnerability rating gets.
What's actually broken
CVE-2026-78006 uses PHP object injection to execute arbitrary operating system commands on the server. The bug lives in how the plugin validates widget instances: a function meant to confirm a widget is safe can be bypassed because PHP fires certain methods before that check ever runs, and a separate function forges the integrity attribute the safety check relies on. An attacker who finds the right request doesn't need your login, your two-factor code, or any credential at all to start running commands as your web server user.
CVE-2026-78159 abuses an arbitrary-callable function, reachable through crafted widget data, to invoke WordPress functions with attacker-supplied arguments, including resetting the site administrator's password directly. Once an attacker controls the admin account, the rest is routine: upload a malicious plugin, get code execution through the normal plugin-upload path, and the site is fully theirs. Neither chain requires the attacker to register an account, guess a password, or wait for you to click anything.
One real caveat, per Wordfence's disclosure: exploitation requires comments to be enabled and displayed on event posts. It doesn't require an approved comment or a registered account, an attacker can reach the vulnerable code through the pending-comment moderation-preview flow, but if you've turned comments off on events entirely, you're not exposed to this specific path. Everyone else running the plugin should treat this as live.
StellarWP, the plugin's maker, shipped the full fix in version 6.17.4.1 on September 10, four days before Wordfence's public advisory went out on September 14. If you or a client is running The Events Calendar and hasn't updated since then, this is the actual priority for the next twenty minutes of your day, ahead of whatever else is on the list.
This is not an isolated incident, it's a pattern
The Events Calendar is at least the fourth major unauthenticated WordPress remote-code-execution disclosure since early September, each on a different plugin. A caching plugin on roughly 70,000 sites had one. WordPress core itself had a no-password, no-plugin takeover bug. A backup plugin running on 3.25 million sites had one that two-thirds of site owners still hadn't patched two weeks after disclosure. Now an events-calendar plugin on 600,000 sites joins the list.
None of these are the same bug wearing a different name. They're independent vulnerabilities in independent codebases, which is the actually alarming part: this isn't one bad plugin author having a rough month, it's a signal that the WordPress plugin ecosystem is producing critical, unauthenticated, full-takeover bugs at a rate of roughly one major disclosure a week right now. If you manage more than one or two WordPress sites, the odds that none of your installed plugins will be the next one on this list are not great.
Why "I'll patch when I see the news" doesn't scale
If you're running WordPress for yourself, checking your plugin list against a headline once a week is annoying but survivable. If you're a solo consultant managing WordPress for five, ten, or twenty clients, reactive patching means you're one missed newsletter away from being the last to know that a plugin one of your clients runs just became a 9.8 CVSS liability. I found this out the hard way in July, when a client's contact form plugin had a critical bug for eleven days before I noticed, because I was checking security news for plugins I remembered being installed rather than plugins that were actually installed on that specific site.
The fix isn't vigilance, vigilance doesn't scale past a handful of sites. The fix is a system: a scheduled task, even a simple one, that pulls the installed plugin list and version numbers across every site you're responsible for and checks them against a vulnerability feed automatically. WPScan and Patchstack both publish machine-readable feeds specifically for this. It's an afternoon of setup, once, against an unbounded number of "did I miss one" moments for the rest of the year.
The honest take
I don't think WordPress itself is getting less secure. Auto-updates for core, better plugin review processes, and faster disclosure-to-patch timelines have all improved over the past few years. What's changed is scale and attention: WordPress still runs something like 40% of the web, which makes every plugin with a meaningful install base a standing target, and security researchers (and attackers) both know it. More disclosures partly means more scrutiny, not necessarily a worse ecosystem.
That framing doesn't change what you should actually do this week. If you're managing WordPress for clients as any part of your business, treat automated vulnerability monitoring as infrastructure, not a nice-to-have you'll get to eventually. A single 9.8 CVSS incident on a client site, traced back to a plugin update you could have caught with an automated feed, costs you a lot more than the afternoon it takes to set one up. Patch The Events Calendar to 6.17.4.1 today if you're running it, then spend the rest of the week building the system that means you don't find the next one from a news article.
Author
Lukas
@lukcombinator