Two unauthenticated 9.8 remote code execution flaws in a plugin on more than 600,000 sites became public this morning, and the changelog entries that fixed them describe hardened validation in releases dated August 26 and September 10.
What happened
NVD published CVE-2026-78006 and CVE-2026-78159 at 8:16 a.m. UTC on Saturday, September 12, 2026, both sourced to [email protected]. Both affect The Events Calendar, the StellarWP plugin that WordPress.org reports on more than 600,000 active installations. Both are rated 9.8 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, meaning network-reachable, no privileges, no user interaction, full compromise.
CVE-2026-78006 is described as “The Events Calendar plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 6.17.4 via the is_safe_widget_instance function,” classed CWE-502, deserialization of untrusted data. CVE-2026-78159 is the same product “vulnerable to Remote Code Execution in all versions up to, and including, 6.17.3 via the parse_array function,” classed CWE-94, code injection. In both records the described path to the flaw runs through comment processing — an attacker submits crafted content and the plugin executes code when the comment is rendered.
Neither flaw is new to the code. Both were fixed before the CVEs existed. What arrived today is the record.
Three releases, one fix
Put the affected ranges next to the plugin’s own changelog and a pattern falls out.
6.17.3, August 20, 2026: “Hardened validation of copied legacy widget instances.” Not labeled a security fix.
6.17.3.1, August 26, 2026: “Security – Harden capability checks on REST API archive endpoints” and “Security – Harden validation of copied widget instance data.”
6.17.4, September 3, 2026: no security entries at all. Recurring-event day views and a fatal error with persistent object caching.
6.17.4.1, September 10, 2026: “Security – Strengthened validation of copied widget instances.”
That is three separate rounds of hardening on copied widget instance data across three weeks. CVE-2026-78159’s affected range ends at 6.17.3, so by the record’s own boundary the August 20 hardening did not close it and the August 26 release did. CVE-2026-78006’s range ends at 6.17.4, so neither August release closed that one; it survived until September 10.
The inference direction matters and we want to be explicit about it: we are reading fix versions off the affected ranges, because Wordfence’s own advisory pages would not render for us. Neither the plugin’s changelog nor its release notes name a CVE or the phrase “remote code execution” anywhere in that sequence.
The September 3 release is the one worth sitting with. A site administrator who updated The Events Calendar on September 3, saw a changelog about day views and object caching, and concluded there was nothing security-relevant in it was, on the CVE record’s account, running an unauthenticated 9.8 remote code execution flaw for another seven days.
Why it matters
WordPress plugin security has a structural problem that these two records illustrate cleanly: the changelog is the only channel most site owners ever read, and it is written by the same people who would rather not advertise that their plugin had a pre-authentication RCE.
“Strengthened validation of copied widget instances” is not false. It is a fair one-line description of the code change. But it gives the reader no way to distinguish a defensive tidy-up from an emergency, and the person receiving it is usually not a security engineer — it is a marketing manager, an office administrator, or an agency running forty client sites who has to decide which of this week’s eleven plugin updates justify pushing outside a maintenance window. Given that changelog line, no reasonable person prioritizes it.
The delay compounds the problem. WordPress’s auto-update mechanism helps here, and sites with plugin auto-updates enabled are likely already on 6.17.4.1. But agencies and managed hosts routinely disable auto-updates precisely because plugin updates break things, and those are the environments with the most sites behind one decision-maker. For them the CVE publication is the trigger, and it arrived twenty-three days after the first fix attempt.
There is a second-order effect that is easy to miss. Because the fixes shipped quietly and the CVEs published late, the window that matters is not the one before the patch — it is the one that opens now. The commits are public in the plugin repository, the CVE records point directly at the changed files and line numbers, and the function names are in the descriptions. Anyone who wants to build an exploit for the unpatched population now has both halves: the vulnerable code and a precise diff showing what was wrong with it. The population that has not updated in three weeks is exactly the population that is going to stay unpatched.
Nothing suggests exploitation yet. There is no KEV listing, no federal deadline, and no public proof-of-concept we could find for either CVE. This is a patch-and-move-on story, not an emergency — provided the patching actually happens, which is the part the changelog worked against.
It is also worth noting what the record does well. Both CVE entries carry direct links into the plugin’s source tree at specific lines and to the exact changesets, which is more transparency than most vendor advisories offer. The problem is not that the technical record is thin. It is that the technical record is excellent and arrives three weeks after the audience that needed it made its decision.
What to do
Update The Events Calendar to 6.17.4.1, the current stable release. Anything at 6.17.4 or below is affected by at least one of these two flaws, and anything at 6.17.3 or below is affected by both.
If you manage sites for others, this is worth an out-of-band push rather than waiting for the next maintenance window, on the strength of the score and the public diff rather than any evidence of attack.
The described entry point for both flaws is comment processing on pages that render calendar views. A site with comments disabled site-wide is in a materially different position from one that accepts them, though we would not treat that as a substitute for updating — the descriptions are summaries, not a complete account of reachable paths.
After updating, the standard post-RCE checks apply for anything that ran an affected version with public commenting: review the uploads directory and the plugin and theme directories for files modified in the past month, check for administrator accounts created since August 20, 2026, and review scheduled tasks. There are no published indicators of compromise for either flaw, so this is generic hygiene rather than targeted hunting.
Sourcing note
Checked: the NVD records for CVE-2026-78006 and CVE-2026-78159, both published 2026-09-12T08:16:24 and sourced to [email protected], including their CVSS vectors, CWE classes, affected ranges, and reference lists; and the plugin’s listing and changelog on WordPress.org, which gives 6.17.4.1 as stable, 600,000+ as the active-installation count, and the release dates and entries quoted above.
Could not reach: Wordfence’s threat-intelligence pages for either CVE, which returned no readable content to automated fetching, so the researcher credit, the disclosure timeline, and Wordfence’s own stated “patched version” were not available. The WordPress plugin repository’s Trac browser was likewise unreadable, so the referenced changesets were not inspected. StellarWP’s release-notes knowledge base article returned a 404.
Unresolved: which release Wordfence itself names as the fix for each CVE. This story derives that from the affected ranges in the CVE records and the dated changelog, which is a sound inference but not a vendor statement. Also unresolved: whether the three consecutive widget-validation hardening entries represent two incomplete fixes for one underlying defect or three separate issues that happen to touch the same code. The changelog does not say, and neither CVE record addresses the other.
