Two Critical Flaws in The Events Calendar Let Anyone Take Over Your Site Through a Comment, and 6.17.4 Is Not the Fix

If you run The Events Calendar, open Plugins > Installed Plugins now and read the version number under the plugin name. It needs to say 6.17.4.1 or higher. If it says 6.17.4, or anything lower, your site is open to a critical vulnerability that lets someone with no account take over the site by posting a comment on an event. Update first, then come back.

That is the whole instruction. The rest of this article explains why a version that looks current is not, how the attack works in plain terms, why holding comments for moderation does not help here, and what to check if you think the site was already hit.

TL;DR

• The Events Calendar vulnerability CVE-2026-78006 (CVSS 9.8) affects every version up to and including 6.17.4. It is fixed only in 6.17.4.1, released September 10, 2026.
• A second flaw, CVE-2026-78159 (CVSS 9.8), affects versions up to and including 6.17.3 and was fixed in 6.17.3.1. Version 6.17.4.1 covers both.
• Both let a visitor with no account reach code execution through the comment form on an event page. The comment does not need to be approved.
• The attack needs comments to be enabled and shown on events. Turning that off is a stopgap, not a fix.
• After updating, check your administrator list, confirm your main admin account still logs in with its normal password, and look for plugins you did not install.

What was disclosed

Two separate vulnerability chains in The Events Calendar went public on September 12, 2026, when their CVE records were published, and Wordfence released a full technical write-up shortly after. The plugin lists more than 600,000 active installations on WordPress.org. Its WordPress.org page names the author as Nexcess, while the CVE records and Wordfence's advisory name StellarWP. The plugin's changelog shows the branding moved from StellarWP to Nexcess in version 6.16.0, so both names refer to the same team.

Both records credit Wordfence researcher Chloe Chamberland and Wordfence Argus, the AI research agent Wordfence's threat intelligence team built. That second name is a story of its own and will get its own article. For this one, the only thing that matters is the version number.

Why 6.17.4 looks patched but is not

The version history over the past month is the reason so many site owners will get this wrong. Here is what the plugin's own changelog shows, lined up against the two CVE records.

Version 6.17.3.1 was a security release. Its changelog mentions hardening the validation of copied widget instance data, and Wordfence's timeline says the vendor shipped an initial patch for the object injection bug in late August. A site owner who saw that release, then saw 6.17.4 arrive a week later, would reasonably assume the problem was closed.

It was not. Version 6.17.4 carries no security note at all, and Wordfence's advisory still lists it as affected. The complete fix for CVE-2026-78006 arrived in 6.17.4.1 on September 10, with a one-line changelog entry about strengthening the validation of copied widget instances.

The four-part version number problem

The fix is a fourth-level point release, and a lot of tooling only looks at three levels. Spreadsheets that track "major.minor.patch", inventory dashboards that truncate version strings, and a tired person scanning a plugin list at the end of the day can all read 6.17.4.1 and 6.17.4 as the same thing.

If you compare versions in a script, use a proper version comparison rather than string matching or cutting the string at the third dot. The examples further down use sort -V, which orders 6.17.4 before 6.17.4.1 correctly. If your security scanner or management dashboard reports The Events Calendar as up to date, open the site and read the exact version yourself before you trust it.

How the attack works, without the recipe

Most plugin vulnerabilities ask you to imagine an attacker who already has some kind of foothold, like a contributor account or a stolen session. These two do not. The starting point is a stranger filling in the comment box under an event listing, which is exactly what that box is for.

WordPress core does not run the block parser over comment text. According to Wordfence's analysis, The Events Calendar's single-event template captures the whole rendered page, comments included, and passes all of it through the block parser anyway. That means text a visitor types into a comment can be read as block markup, and one particular kind of block leads into the plugin's widget code.

From there the two chains split. In CVE-2026-78006, a safety check meant to reject dangerous data can be fooled, and the data ends up running system commands with the permissions of the web server user. In CVE-2026-78159, a different input passes the same check honestly and then reaches code that will call a PHP function the attacker names. Wordfence demonstrated using that to reset the password on the site's first user account, then logging in as that administrator and uploading a malicious plugin.

Either way, the result is full site compromise: the attacker can read the database, plant backdoors, change content, and use the server for whatever they like. This article deliberately does not describe the payloads. Public proof-of-concept code already exists, and the only useful thing to do with that fact is update.

Does holding comments for moderation protect you?

No, not against this bug. This is the assumption most careful site owners are relying on, so it is worth being precise.

When someone submits a comment that is held for moderation, WordPress normally sends them to a special preview link so they can see their own pending comment. Nobody else sees it, but the page still renders, and on an event page that rendering runs the comment through The Events Calendar's block processing. The CVE record for CVE-2026-78006 says this is what makes the bug exploitable without approval, and Wordfence's write-up says both chains can be triggered through that pending-comment preview.

So the comment never has to be approved. It never has to appear publicly. Moderation still does its normal job of keeping spam away from your readers, but it does not stop the plugin from processing what was submitted.

Keep this in proportion. It is true here because this plugin runs comment text through the block parser, which core WordPress does not do. It is not a general rule that moderation is useless.

What about requiring visitors to log in before commenting?

That removes the anonymous route, which is what the CVE records describe. It only helps if registration on your site is closed. If anyone can create an account (Settings > General > Membership set to "Anyone can register"), an attacker can register as a subscriber in a few seconds and then comment as a logged-in user. The CVSS scores assume no login at all, but you should not treat a login wall with open registration as protection.

Is your site exposed?

Three things have to be true for these chains to work, based on the CVE records and Wordfence's advisory:

1. The Events Calendar is installed and active at a vulnerable version (below 6.17.4.1 for CVE-2026-78006, below 6.17.3.1 for CVE-2026-78159).
2. The plugin's own Show comments setting is turned on. In current versions this lives on The Events Calendar's settings screen; the exact tab name has moved between releases, so check the plugin's documentation if you cannot find it.
3. Comments are open on at least one published event.

The setting is off by default in the plugin's historical settings code, so plenty of sites will not meet condition two. Do not use that as a reason to skip the update. Settings get changed, a client or colleague may turn comments on next month, and a site that is safe only because of a checkbox is one click away from not being safe.

It is also worth thinking about which sites you have forgotten. Event calendars often live on side properties: a conference microsite, a regional office site, a staging copy that is still publicly reachable. Those are the installs that miss updates.

How to check your version and update

Take a backup before updating any plugin on a production site. On most hosts this takes a minute; if you are on MagicWP, the backups documentation covers creating one on demand and restoring it.

From the WordPress dashboard

1. Go to Plugins > Installed Plugins.
2. Find The Events Calendar and read the version line. It should say 6.17.4.1 or higher.
3. If an update is offered, run it, then reload the page and read the version again.
4. If you have automatic updates turned on for this plugin, still confirm the version by eye. Automatic updates can fail quietly or be delayed.

With WP-CLI

If you have SSH access, these commands check and update the plugin from the site root:

# Show the installed version
wp plugin get the-events-calendar --field=version

# Update to the latest release
wp plugin update the-events-calendar

# Confirm the result
wp plugin get the-events-calendar --field=version

The first command prints the exact version string, all four parts included. If the plugin is installed but inactive, it is not reachable through these chains, but update it anyway or delete it if you do not use it.

To see whether the plugin's comment setting is turned on:

wp option pluck tribe_events_calendar_options showComments

Depending on the plugin version and how the setting was saved, a value of 1, true, or yes means comments are shown on events. An error saying the key does not exist usually means the setting was never saved, which in the plugin's historical code means the default of off. Treat this as a quick check, not the final word; the settings screen is authoritative.

Across many sites

Agencies and anyone running several installs should check every site rather than trusting a dashboard summary. This loop reads the exact version on each site and compares it properly:

#!/usr/bin/env bash
# Check The Events Calendar version across several WordPress installs.
# Replace the example paths with your own site roots.
MIN="6.17.4.1"
SITES=("/var/www/site-one" "/var/www/site-two")

for site in "${SITES[@]}"; do
  v=$(wp --path="$site" plugin get the-events-calendar --field=version 2>/dev/null)
  if [ -z "$v" ]; then
    echo "$site: not installed"
  elif [ "$(printf '%s\n%s\n' "$MIN" "$v" | sort -V | head -n1)" = "$MIN" ]; then
    echo "$site: OK ($v)"
  else
    echo "$site: UPDATE NEEDED ($v)"
  fi
done

The sort -V comparison is the important part. It puts 6.17.4 before 6.17.4.1, so a site on 6.17.4 is correctly flagged. A check that trims the version to three parts would mark it as fine.

If someone else handles updates for you

If your host, agency, or maintenance provider applies plugin updates, ask them to confirm the exact installed version of The Events Calendar on each of your sites, all four parts. "We're on 6.17.4" is not a yes. You want to hear "6.17.4.1" or a later version.

What about Events Calendar Pro, Event Tickets, and other add-ons?

Wordfence's advisory and WPScan's database both list the free The Events Calendar plugin as the affected software for these two CVEs. At the time of writing, no published advisory or vendor notice located during research for this article lists Events Calendar Pro, Event Tickets, or the other add-ons as separately affected by these bugs. Don't assume they are, and don't assume they aren't; check the vendor's release notes for your add-ons.

What is clear is that the premium calendar add-ons run on top of The Events Calendar and require it, so updating The Events Calendar itself is what closes these holes. Past releases have included minimum-version requirements between the core plugin and its add-ons, so if you are several versions behind on Pro or Event Tickets, update those too and test on a staging copy if you can.

If you cannot update immediately

Updating is the fix. If something genuinely blocks it today, such as a heavily customized site that needs testing first, these steps reduce exposure while you work on it:

• Turn off Show comments in The Events Calendar's settings. Based on the advisory, this stops event pages from rendering comments, which is where both chains start.
• Close comments on events. This stops new comments from being submitted. Record the current state first so you can restore it later:

# Save each event's current comment status
wp post list --post_type=tribe_events --post_status=any --fields=ID,comment_status --format=csv > tec-comment-status-backup.csv

# Close comments on all events
wp post list --post_type=tribe_events --post_status=any --format=ids | xargs -r wp post update --comment_status=closed

• Check for comments that already contain block markup (see the compromise section below) and remove any you find. A malicious comment that was submitted before you closed comments is still sitting in the database.
• Check your firewall coverage, but don't lean on it. Wordfence says its Premium, Care, and Response customers got a firewall rule for known exploits of both chains on August 22, 2026, and free Wordfence users are scheduled to get the same rule on September 21, 2026. If you use the free version, you are not covered by that rule yet. For any other firewall, ask the vendor directly whether it has a rule for these CVEs.

None of this replaces the update. Plan to be on 6.17.4.1 or later within the day.

Three critical CVEs in about three weeks

These two are not the first recent critical bug in this plugin. CVE-2026-78265, reported through Patchstack and published on August 24, 2026, is an unauthenticated PHP object injection flaw rated CVSS 9.8, affecting versions up to and including 6.17.2 and fixed in 6.17.3. That makes three unauthenticated critical CVEs in The Events Calendar between August 24 and September 12.

The changelog entries for 6.17.3, 6.17.3.1, and 6.17.4.1 all describe hardening the validation of copied widget instances, so the fixes are concentrated in the same area of the code. The vendor has shipped a fix for each report, and Wordfence's timeline shows it acknowledged both of Wordfence's reports within a few days of receiving them.

What you make of that cluster is your call. The practical point is narrower: when a plugin has a run of security releases in quick succession, any changelog line that starts with "Security" is a reason to update that day, not at the next maintenance window. And a vulnerability scanner that reports the plugin as patched against the August CVE is telling you nothing about the September ones.

Is it being exploited?

Public proof-of-concept code exists, according to CyCognito's September 14 advisory. That alone is enough reason to update now.

On actual attacks, the available sources measure different things and should not be merged into one sentence. CyCognito, writing on September 14, said publicly available data showed a low observed exploitation rate, with an EPSS score (a model's estimate of how likely a vulnerability is to be exploited soon) under 1 percent. SecurityOnline, writing on September 15, reported that attackers are actively targeting the flaws and quoted Wordfence as having blocked 1,113 attacks against the vulnerability in the previous 24 hours. That figure could not be confirmed against Wordfence's published advisory at the time of writing.

Both can be true at once: a probability model and a count of blocked attempts are not the same measurement. For a site owner the answer is the same either way. Exploit code is public, the attack needs no account, and the fix has been out for six days.

Signs your site may already be compromised

If your site ran a vulnerable version with event comments enabled, updating closes the door but does not remove anything an attacker may have left behind. These checks are signposts, not a full incident response. Run them from the site root.

Administrator accounts. Look for admins you do not recognize:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

The main admin account. The demonstrated attack in CVE-2026-78159 resets the password of the site's first user. If that account suddenly cannot log in with its usual password, or its owner received a "password changed" email they did not trigger, treat that as a strong warning sign. WordPress normally sends that notice when a password is changed this way, unless mail delivery is broken or a plugin suppresses it.

Plugins and core files. Look for plugins you did not install, and compare files against the official checksums:

wp plugin list --fields=name,status,version
wp core verify-checksums
wp plugin verify-checksums --all

Plugin checksum verification only works for plugins hosted on WordPress.org, so premium plugins will be reported as unverifiable rather than clean.

PHP files where they should not be. WordPress does not put PHP files in the uploads folder. Any you find there deserve a close look:

find wp-content/uploads -type f -name '*.php'

Scheduled tasks. Look for hooks you do not recognize:

wp cron event list --fields=hook,next_run_relative,recurrence

Comments on events that contain block markup. Normal visitor comments almost never include block delimiters. This query lists any on event posts, including pending, spam, and trashed ones:

wp db query "SELECT c.comment_ID, c.comment_post_ID, c.comment_approved, c.comment_date_gmt, c.comment_author_IP FROM $(wp db prefix)comments c JOIN $(wp db prefix)posts p ON p.ID = c.comment_post_ID WHERE p.post_type = 'tribe_events' AND c.comment_content LIKE '%<!-- wp:%';"

Access logs. Pending-comment previews carry a moderation-hash parameter in the URL. Log locations vary by host, and the event URL prefix depends on your plugin settings (/event/ is the default):

grep 'moderation-hash=' /path/to/access.log | grep '/event/'

Real commenters produce these requests too. You are looking for bursts from unfamiliar addresses, or preview requests on events that should not be getting comments at all.

If any of these turn something up, updating is not enough. Restore from a clean backup taken before the earliest sign of trouble, update The Events Calendar before turning comments back on, change every administrator password, and rotate the secret keys in wp-config.php so existing sessions are logged out:

wp config shuffle-salts

Also check each administrator for application passwords you did not create (wp user application-password list 1, replacing 1 with each admin's user ID), since an attacker with admin access can add one to keep a way back in. For anything beyond these signposts, work through a proper incident response rather than a checklist.

Frequently Asked Questions

Is The Events Calendar 6.17.4 safe to run?

No. Version 6.17.4 is still affected by CVE-2026-78006, a critical unauthenticated remote code execution flaw. It is protected against CVE-2026-78159, which was fixed in 6.17.3.1, but that is not enough. The version that fixes both is 6.17.4.1, released on September 10, 2026. If your plugins page or management tool shows 6.17.4, update. Read all four parts of the version number, because many dashboards and spreadsheets only show three.

Which version of The Events Calendar fixes both vulnerabilities?

Version 6.17.4.1 or any later release. That version completes the fix for CVE-2026-78006 and also includes the earlier fix for CVE-2026-78159 from 6.17.3.1. Check the exact installed version in Plugins > Installed Plugins or with wp plugin get the-events-calendar --field=version. If a newer release has come out since this article was published, updating to the latest version is still the right move.

Does holding comments for moderation protect my site?

Not against these two bugs. WordPress normally lets a commenter preview their own pending comment, and on an event page that preview still runs through the plugin's vulnerable processing. Wordfence says both chains can be triggered this way without moderator approval. Moderation still keeps spam off your public pages, but it does not stop the plugin from processing what an attacker submits. This applies to this plugin specifically, not to WordPress comments in general.

I don't allow comments on events. Am I affected?

Based on the CVE records and Wordfence's advisory, both chains need comments enabled and shown on event pages, so a site with comments fully off is not exploitable through these routes. You should still update. Settings change, someone may enable comments later, and a vulnerable plugin sitting on a site is a risk you do not need to carry when a fix is available and free.

Do I need to update Events Calendar Pro or Event Tickets too?

The published advisories list the free The Events Calendar plugin as the affected software. The premium calendar add-ons depend on it, so updating The Events Calendar is what closes these holes. It is still good practice to bring your add-ons up to date at the same time, because releases in this plugin family have required matching minimum versions in the past. If you are several versions behind, test the combined update on a staging copy first.

Are attackers actively exploiting these flaws?

Sources differ. CyCognito reported on September 14 that observed exploitation was low, with an EPSS score under 1 percent, while noting that proof-of-concept code is public. SecurityOnline reported on September 15 that attackers are targeting the flaws, citing a Wordfence count of blocked attacks. Whichever picture is closer to the truth today, public exploit code and no login requirement make this a same-day update.

I use the free version of Wordfence. Am I protected?

Not by the dedicated firewall rule yet. Wordfence says paid customers received protection on August 22, 2026, and free users are scheduled to get the same rule on September 21, 2026. Until then, the free firewall should not be counted on for these specific chains. Even after the rule arrives, a firewall rule blocks known exploit patterns; updating removes the vulnerable code. Update the plugin regardless of which security tools you run.

Should I uninstall The Events Calendar?

Not because of these vulnerabilities. They are fixed in 6.17.4.1, and a patched plugin is not the problem. Uninstalling a calendar that your site depends on creates its own mess with event data and URLs. Update, confirm the version, and run the compromise checks above. If you have The Events Calendar installed on a site where it is not used, deleting it is reasonable general housekeeping.

Conclusion

The Events Calendar vulnerability disclosed this month is serious because of how little it asks of an attacker: no account, no approval, just a comment on an event page. It is easy to miss because the fix hides in a fourth version segment, and a site on 6.17.4 looks up to date when it is not.

Update to 6.17.4.1 or later, and read the version number with your own eyes. Then check your administrator list and confirm the main admin account still logs in normally. Everything else in this article is there for the sites where those two checks turn up something wrong.

If you host with MagicWP, the WP-CLI commands above run over SSH as written, and daily off-site backups with one-click restore give you a clean point to go back to if the checks find something. The MagicWP security documentation covers the platform's firewall and malware scanning.