The Events Calendar Unauthenticated RCE: What to Patch Now

The Events Calendar shipped two quiet security patches before anyone outside StellarWP knew why they mattered: 6.17.3.1 on August 26, 2026, and 6.17.4.1 on September 10, 2026. Wordfence explained the reason on September 11. Both releases closed unauthenticated remote code execution bugs, CVE-2026-78159 and CVE-2026-78006, in a plugin WordPress.org lists with more than 600,000 active installs.

Neither bug needs a login. Both need one setting most event sites already have on: comments. If visitors can comment on your events, someone can trigger either flaw with no account and no moderator ever clicking approve.

What's Affected in The Events Calendar

CVE-2026-78159 hits every version up to and including 6.17.3. The plugin's legacy widget system builds a classes map from stored widget instance data, and it doesn't validate that map strictly enough. A crafted, plain-array payload slips past the is_safe_widget_instance() check and reaches a callable-invocation sink inside Element_Classes::parse_array(), letting an attacker run arbitrary code. NVD rates it CVSS 9.8 and files it under CWE-94, code injection. It's fixed in 6.17.3.1.

CVE-2026-78006 hits every version up to and including 6.17.4, one release later. Here the bypass works through PHP itself: PHP fires magic methods while pre-parsing serialized data, before is_safe_widget_instance() ever runs its check. A function called enable_rendering_widget_copied() forges a valid wp_hash integrity attribute, so the forged data looks legitimate by the time unserialize() processes it. That's a textbook PHP object injection path, similar in shape to the gadget chain we broke down in GiveWP's CVE-2026-82222, just with a different delivery mechanism. NVD rates this one 9.8 too, filed under CWE-502, deserialization of untrusted data. It's fixed in 6.17.4.1.

Wordfence credits researcher Chloe Chamberland, working through its Argus vulnerability-research system, with finding both chains. Wordfence's timeline shows StellarWP was notified on August 21, 2026 for CVE-2026-78006 and August 23 for CVE-2026-78159, and both fixes shipped before the public disclosure on September 11.

How the Comment Preview Trick Delivers the Payload

Both bugs are delivered through event comments, and the delivery is the part worth understanding even if you never touch The Events Calendar's code. WordPress lets an unapproved commenter preview their own pending comment before a moderator sees it, through a moderation-hash link WordPress generates automatically. That link is a normal, documented WordPress core behavior. It exists so people don't feel like their comment vanished into a void.

The Events Calendar's V2 single-event template runs do_blocks() over the buffered HTML for the comments area, including comments that haven't been approved yet. An attacker leaves a comment containing a crafted wp:legacy-widget block, then opens their own moderation-hash preview link. WordPress renders the comment, do_blocks() processes the malicious widget block, and the vulnerable code runs. Nobody had to approve anything. The CVE-2026-78006 record spells out this preview route explicitly; the CVE-2026-78159 record describes the same trigger, a crafted wp:legacy-widget block in a submitted comment that do_blocks() processes on the event page.

That's what makes these two bugs unauthenticated. The path traversal bug we covered on this plugin back in March needed an Author-level account; these need nothing but a comment box that accepts input. If your events have comments enabled and visible, that's the only door these bugs need.

Disclosure Timeline and Exploitation Status

StellarWP patched both issues before Wordfence went public. Version 6.17.3.1, which closed CVE-2026-78159, shipped August 26, 2026, three days after StellarWP was notified about that bug. Version 6.17.4.1, which closed CVE-2026-78006, shipped September 10, 2026. Wordfence disclosed both on September 11, about three weeks after first contact, which is a normal responsible-disclosure window.

Neither CVE appears in CISA's Known Exploited Vulnerabilities catalog, and available scoring puts the near-term exploitation probability low. We found no public report of active exploitation as of this post. That's a meaningfully different situation from a bug under live attack, but it's not a reason to leave a site unpatched. The technical detail is now public, including the widget-classes mechanism and the comment-preview delivery trick, and a working proof of concept is usually just a matter of time once details like this circulate.

Wordfence's paying customers had firewall coverage from the point of discovery, ahead of the public patch, which is standard for bugs its own research team finds. Free-tier Wordfence users get the same firewall rule later, on Wordfence's usual delay behind paid tiers. If you run the free version, don't treat the firewall as your protection plan here. Update the plugin.

How to Check Your Site

Start with the version:

wp plugin get the-events-calendar --field=version

Anything before 6.17.4.1 needs an update. If you're between 6.17.3.1 and 6.17.4, you closed CVE-2026-78159 but are still open to CVE-2026-78006.

Next, check whether comments are even a live attack surface on your site:

wp option get default_comment_status

If that returns open, new posts, including events, accept comments by default. Then check how many comments are sitting unmoderated right now, since any of them could carry a payload if your site was ever on a vulnerable version:

wp comment list --status=hold --format=count

A non-zero count doesn't confirm an attack. It does mean you have unreviewed comment content worth a manual look before you approve anything in bulk.

What to Do Right Now

Update first:

wp plugin update the-events-calendar

That takes you to 6.17.4.1 or later, closing both chains.

If you can't update immediately, turn off comments on events until you can. In Events, then Settings, turn off the option that shows comments on event pages, or close comments on individual events from the editor. With comments off or not displayed, neither bug has anything to attach to, since both need visible, renderable comment content to reach the vulnerable code.

If your site ran an unpatched version with comments open at any point before you updated, treat it the way you'd treat any exposure window. Check for signs someone already got in, and if anything looks off, don't stop at deleting one file. A real cleanup means checking for a backdoor left behind for persistence, not just the payload that got you looking.

This isn't the plugin's first security disclosure this year. Our March writeup covered CVE-2026-3585, an authenticated path traversal bug that needed an Author-level account. These two are worse: no account required, just a comment box. Popular plugins draw more research attention precisely because of their install base, which is a good reason to watch their changelogs closely.

Run a scan on your site to check your Events Calendar version against our vulnerability database.

References

• WordPress.org: The Events Calendar changelog and install stats
• Wordfence Intelligence: CVE-2026-78159
• Wordfence Intelligence: CVE-2026-78006
• NVD: CVE-2026-78159 record
• NVD: CVE-2026-78006 record
• Freshy Security Bulletin: The Events Calendar Plugin Vulnerability (CVE-2026-78159)
• Strix: CVE-2026-78159, The Events Calendar Code Injection
• Strix: CVE-2026-78006, The Events Calendar Insecure Deserialization
• CVE Brief: CVE-2026-78159 analyst report
• KMO.partners: The Events Calendar up to 6.17.4, update to 6.17.4.1 against site takeover