The The Events Calendar plugin for WordPress is vulnerable to Remote Code Execution in all versions up to

CVE-2026-78159 is a code-injection flaw in The Events Calendar plugin for WordPress, affecting all versions through 6.17.3. The vulnerable path runs through Element_Classes::parse_array(): insufficient validation of the widget classes map allows a plain-array payload to bypass the is_safe_widget_instance() object check and reach a callable-invocation sink. An unauthenticated attacker submits a comment on a tribe_events post containing a crafted wp:legacy-widget block. When WordPress calls do_blocks() to render the single-event page (including the comment area), the malicious block triggers arbitrary code execution on the server. The fix ships in 6.17.4 (released ~September 11, 2026). Affected version range: ≤ 6.17.3.

The vendor rates this CRITICAL / 9.8 with a vector of AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, which overstates the real-world risk. The CVSS vector claims *no privileges required* and *no user interaction*, but the actual chain demands two non-trivial conditions: (1) comments must be enabled on tribe_events posts — a configurable option many operators disable, and (2) WordPress's default comment-moderation policy holds first-time commenter posts for admin approval, meaning a moderator must unwittingly publish a comment carrying hostile block markup. When moderation is off or auto-approve is configured, the chain does become truly unauthenticated — but that is a subset of the installed base, not the universal case. A HIGH / 7.5 better reflects the real friction.

Why this verdict

• Comment-moderation gate narrows the unauthenticated claim. WordPress default holds first-time commenter posts for admin approval. The CVSS vector's UI:N does not reflect this real-world friction. On default-configured sites, the chain stalls until an admin publishes the comment — this is effectively a social-engineering prerequisite, not a pure zero-click.
• Comments on tribe_events are not universally enabled. The Events Calendar's comment setting is configurable, and many operators disable event comments because they use separate RSVP or ticketing workflows. This shrinks the reachable population below the full 600K install base.
• Blast radius is a single WordPress site, not fleet-scale infrastructure. Successful exploitation yields web-server-user code execution on one host. The Events Calendar is a line-of-business web plugin — it is not a domain controller, hypervisor, identity provider, or backup system.
• Role multiplier: The Events Calendar is deployed almost exclusively as a website content plugin on web-tier servers. (a) *Low-value role:* dev/staging WordPress instances — chain succeeds, blast radius = one sandbox. (b) *Typical role:* production marketing or community site — chain succeeds, blast radius = one web server, potential data breach of site content and DB credentials. (c) *High-value role:* WordPress multisite hosting dozens of tenants — chain succeeds, blast radius scales to all sites on that multisite (still web-tier, not identity/fleet). Less than 5% of installs serve as multisite network hubs. No canonical high-value infrastructure role (not a DC, hypervisor, IdP, CI/CD, or backup server). Floor does not apply.
• No PoC or in-the-wild exploitation confirmed within 24 hours of disclosure. EPSS at 0.00762 is modest. Weaponization is expected but not yet observed.

Why not higher?

The chain is not CRITICAL because the default WordPress comment-moderation policy interposes a human gate between the attacker and code execution. The affected component does not occupy a high-value infrastructure role (no identity, hypervisor, CI/CD, or backup function). Even on sites with moderation disabled, the blast radius is bounded to a single web server — not fleet or domain compromise.

Why not lower?

The chain is not MEDIUM because when moderation *is* disabled (a common convenience configuration), the attack is genuinely unauthenticated, zero-click RCE. The installed base of 600,000+ means even a 20% subset with comments open and moderation off represents ~120,000 targets. Full code execution — not just information disclosure — keeps severity anchored at HIGH.

1. Disable comments on all tribe_events posts immediately — This eliminates the attack vector entirely by removing the comment-rendering path that triggers do_blocks() on attacker-controlled content. Deploy within the noisgate mitigation SLA of 30 days — but given the simplicity of this control, aim for same-day. Can be done via The Events Calendar settings or add_filter('comments_open', '__return_false') scoped to tribe_events post type.
2. Enable strict comment moderation — Ensure Settings → Discussion → Comment must be manually approved is checked. This gates any surviving attack path behind admin review. Train moderators to reject comments containing block markup like <!-- wp:legacy-widget -->.
3. Deploy WAF rule blocking wp:legacy-widget in comment submissions — Add a WAF rule (ModSecurity, Cloudflare WAF, Wordfence) that blocks POST requests to wp-comments-post.php where the body contains wp:legacy-widget. This is a precise, low-false-positive rule. Deploy within the noisgate mitigation SLA of 30 days.
4. Update to The Events Calendar 6.17.4.1 — This is the definitive fix. Apply within the noisgate remediation SLA of 180 days. Given the RCE severity and large install base, prioritize this in your next maintenance window.

Run this script on each WordPress host (or via SSH across your fleet). It checks the installed version of The Events Calendar plugin and whether comments are enabled on tribe_events posts. Requires read access to the WordPress installation directory. Example: bash check_cve_2026_78159.sh /var/www/html

#!/usr/bin/env bash
# check_cve_2026_78159.sh — Detect CVE-2026-78159 exposure
# Usage: bash check_cve_2026_78159.sh <WORDPRESS_ROOT>
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

WP_ROOT="${1:-/var/www/html}"
PLUGIN_DIR="$WP_ROOT/wp-content/plugins/the-events-calendar"
VERSION_FILE="$PLUGIN_DIR/the-events-calendar.php"

if [ ! -d "$PLUGIN_DIR" ]; then
  echo "UNKNOWN — The Events Calendar plugin not found at $PLUGIN_DIR"
  exit 2
fi

if [ ! -f "$VERSION_FILE" ]; then
  # Try readme.txt fallback
  VERSION_FILE="$PLUGIN_DIR/readme.txt"
  if [ ! -f "$VERSION_FILE" ]; then
    echo "UNKNOWN — Cannot determine plugin version"
    exit 2
  fi
fi

# Extract version
VERSION=$(grep -i 'Version:' "$VERSION_FILE" | head -1 | sed 's/.*Version:[[:space:]]*//' | tr -d '[:space:]')

if [ -z "$VERSION" ]; then
  echo "UNKNOWN — Could not parse version from $VERSION_FILE"
  exit 2
fi

echo "Detected The Events Calendar version: $VERSION"

# Compare versions (vulnerable: <= 6.17.3)
# Using sort -V for version comparison
FIXED="6.17.4"
if printf '%s\n%s\n' "$FIXED" "$VERSION" | sort -V | head -1 | grep -q "^${FIXED}$"; then
  echo "PATCHED — Version $VERSION >= $FIXED (CVE-2026-78159 fix applied)"
  exit 0
else
  echo "VULNERABLE — Version $VERSION < $FIXED"
  echo "  Checking comment status on tribe_events..."
  # Check if wp-cli is available for deeper inspection
  if command -v wp &>/dev/null; then
    COMMENTS_OPEN=$(wp post list --post_type=tribe_events --field=comment_status --path="$WP_ROOT" 2>/dev/null | grep -c 'open' || true)
    if [ "$COMMENTS_OPEN" -gt 0 ]; then
      echo "  WARNING: $COMMENTS_OPEN tribe_events posts have comments OPEN — actively exploitable"
    else
      echo "  INFO: No tribe_events posts with open comments found (reduced risk)"
    fi
  else
    echo "  INFO: wp-cli not found; manually verify comment status on tribe_events posts"
  fi
  exit 1
fi

Sources

1. OffSeq Threat Radar — CVE-2026-78159 Detail
2. Shenlong CVE Platform — TEC ≤6.17.3 RCE & Patch 6.17.4
3. WordPress.org — The Events Calendar Plugin Page
4. VulDB — CVE-2026-78159
5. GitHub — The Events Calendar Releases
6. The Events Calendar Knowledgebase — Settings Overview
7. GHSA-9c57-9fxg-8x9j (GitHub Security Advisory)