The Events Calendar

CVE-2026-78006 and CVE-2026-78159 affect The Events Calendar. Update to 6.17.4.1 or later immediately.

Two critical unauthenticated remote code execution issues have been disclosed in The Events Calendar, a widely installed WordPress events plugin. Patchstack lists both issues as CVSS 9.8 and high priority, and the WordPress.org changelog shows version 6.17.4.1 as a security release that strengthens validation of copied widget instances.

Table of Contents

Affected versions

The Events Calendar up to and including 6.17.3: CVE-2026-78159, unauthenticated code injection to remote code execution through widget classes map handling.
The Events Calendar up to and including 6.17.4: CVE-2026-78006, unauthenticated PHP object injection to remote code execution through widget instance validation.
Fixed version: 6.17.4.1 or later.
Required privilege: unauthenticated.
CISA KEV status checked during this run: not listed.

Exploit path

The vulnerable code path is tied to copied legacy widget instance processing in The Events Calendar. Public vulnerability records describe two related attack paths: unsafe handling of the widget classes map reaching Element_Classes::parse_array(), and insufficient protection around is_safe_widget_instance() before unserialize() is reached.

The most important operational detail is that exploitation depends on event comment rendering. The reported chain uses event comment HTML that is processed through do_blocks() on single-event templates. Sites that allow comments on event posts are higher risk, especially if pending comments can be previewed by the commenter before moderation.

Immediate remediation

Update The Events Calendar to 6.17.4.1 or later immediately.
If you cannot update immediately, disable comments on tribe_events posts and remove public comment forms from event templates.
Delete suspicious pending comments on event posts, especially comments containing block markup, legacy widget blocks, serialized-looking strings, or unexpected shortcode/widget data.
Review administrator accounts, recently modified plugin/theme files, mu-plugins, and web server logs for unusual POST requests to event pages.
Keep a clean backup before cleanup, but do not restore an old backup without patching first.

WP-CLI checks

wp plugin get the-events-calendar --fields=name,status,version,update_version --format=table
wp plugin update the-events-calendar
wp comment list --post_type=tribe_events --status=hold --fields=comment_ID,comment_post_ID,comment_author,comment_date --format=table
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered --format=table

Temporary hardening

If the update cannot be applied immediately, disable comments on event posts as a temporary mitigation. This does not replace patching, but it removes the reported unauthenticated comment-to-rendering path while you schedule the update.

<?php
add_filter( 'comments_open', function ( $open, $post_id ) {
    return get_post_type( $post_id ) === 'tribe_events' ? false : $open;
}, 10, 2 );

add_filter( 'pings_open', function ( $open, $post_id ) {
    return get_post_type( $post_id ) === 'tribe_events' ? false : $open;
}, 10, 2 );

SQL review query

Use read-only SQL to locate pending event comments that need manual review:

wp db query "SELECT c.comment_ID, c.comment_post_ID, c.comment_author, c.comment_date, LEFT(c.comment_content, 160) AS sample FROM {prefix}comments c JOIN {prefix}posts p ON p.ID = c.comment_post_ID WHERE p.post_type = 'tribe_events' AND c.comment_approved IN ('0','hold') ORDER BY c.comment_date DESC LIMIT 50;"