A stranger leaves a comment on an event page. You never approve it. It sits in moderation, invisible to normal visitors, while you get on with running the business.
Safe, right?
Not with two recently fixed vulnerabilities in The Events Calendar. Under a specific vulnerable setup, that pending comment could be rendered by the site and turned into a full WordPress takeover. One chain can reach operating-system commands on the server. The other can reset an administrator password, let the attacker log in, and then install a malicious plugin.
No account. No comment approval. No administrator clicking a mysterious link.
If your site uses The Events Calendar, check the version now. The common safe destination is 6.17.4.1 or newer. Watch all four numbers: version 6.17.4 is still vulnerable to one of the two chains.
Why comment moderation didn’t stop this
Most WordPress owners assume a pending comment is inert until an administrator approves it. Usually that assumption is reasonable. Here, WordPress itself gives the commenter a moderation-hash preview URL so they can view their own pending comment. The comment does not need to become public for its author to render it.
The Events Calendar then adds the dangerous part. Its V2 event template buffers the rendered event page, including comments, and runs the page through do_blocks(). A crafted pending comment containing wp:legacy-widget block markup can therefore reach WordPress widget processing.
In plain English, text that should have been treated as an untrusted comment gets a turn inside machinery meant to process site-building blocks and widgets. That’s a bad boundary to cross.
Both disclosed delivery paths need the same setup: comments must be enabled on the tribe_events post type, and The Events Calendar’s Show comments on event pages option must be active so comments appear on event pages. If event comments were disabled or hidden, these published paths did not work as described.
Two different roads to takeover
Wordfence disclosed the two independent chains on September 14, after patched versions were available. Its technical account of both Events Calendar vulnerabilities includes public proof-of-concept mechanics. Each vulnerability has a CVSS score of 9.8.
CVE-2026-78006 affects versions up to and including 6.17.4. The crafted legacy-widget block can enter a PHP object-injection path involving unsafe deserialization and callable behaviour, ultimately allowing operating-system commands to run. That’s direct server-level impact, not just someone defacing an event description.
CVE-2026-78159 affects versions up to and including 6.17.3. This second route does not need the same PHP object trick. It uses a plain-array callable path. In Wordfence’s proof of concept, the callable invokes wp_update_user() to reset an administrator password. The attacker can then sign in as an administrator and upload a malicious plugin, which leads to remote code execution.
Different mechanics, same ugly finish.
600,000 installations does not mean 600,000 vulnerable sites
The Events Calendar has more than 600,000 active installations across all versions. That number shows why this disclosure matters. It does not tell us that every one of those sites was exposed.
A site needed an affected plugin version plus the event-comment configuration described above. Sites already on 6.17.4.1 are patched against both chains. Sites that never displayed comments on event pages did not match the disclosed delivery conditions either.
As of September 17, public technical details exist, so this isn’t a vulnerability to leave on next month’s list. At the same time, Wordfence’s original reporting did not identify confirmed mass exploitation, and neither CVE appears in CISA’s Known Exploited Vulnerabilities catalogue. Don’t label every odd event comment as an attack. Do patch before that calm window shrinks.
A WordPress vulnerability scanner can help flag the installed version, but configuration and incident evidence still need a human look. A version number alone can’t tell you whether event comments were visible or whether a crafted pending comment was rendered before the update.
What to do today
- Update The Events Calendar to 6.17.4.1 or newer. If an affected version overlapped with exposed event comments, take the evidence snapshot described below before updating. Version 6.17.4.1 was released on September 10 and is the current WordPress.org version as of September 17. Do not stop at 6.17.4.
- Check the result. Confirm the four-part version in the Plugins screen, then test event pages and any booking or ticket flow your business relies on.
- If you cannot patch immediately, close both comment paths. Disable comments on
tribe_eventsposts and switch off Show comments on event pages. This is temporary risk reduction, not a substitute for the update. - Keep a tested backup before changing production. Use a staging copy for a busy ticketing or events site where a template change could affect sales. Our guide to safely updating WordPress plugins and themes gives a practical sequence.
If plugin checks, backups, staging, and post-update testing keep slipping between customer work, regular WordPress maintenance puts them into a routine instead of a Friday-night scramble.
If event comments were exposed, preserve the clues
Was the site running 6.17.4 or older while event comments were visible? Don’t begin by emptying spam, deleting pending comments, and clearing every log. Take a snapshot first. Preserve the current files, database, suspicious comments, and available web, security, and authentication logs.
Then triage the specific trail:
- pending and spam comments attached to event posts, especially content containing
wp:legacy-widget; - new or altered administrator accounts, password changes, and unfamiliar active sessions;
- newly installed plugins or plugins reactivated without a clear business reason;
- recently changed PHP files in plugins, themes, uploads, and other writable locations;
- unexpected scheduled tasks in WordPress cron or the server’s cron system;
- requests around suspicious comment times in web-server, firewall, and login logs.
The order matters. Our guide to the first 24 hours after a WordPress hack explains why evidence comes before enthusiastic deleting.
Updating closes these routes going forward. It does not remove an administrator the attacker already created, a malicious plugin they installed, or a backdoor tucked into PHP. If the evidence points to compromise, proper WordPress site cleaning has to inspect the wider site and server. After preserving evidence and cleaning the site, rotate all relevant credentials and WordPress salts, then invalidate active sessions.
The version number is the easy part
This is a strange bug because the comment never needed your approval. The moderation preview was enough to render attacker-controlled block markup under the vulnerable event template.
So check for 6.17.4.1 or newer, verify the event-comment settings, and update now. If the old version and exposed settings overlapped, preserve first and investigate second.
Moderation was never the patch.