CVE-2026-78159: Critical Unauthenticated RCE in The Events Calendar WordPress Plugin — Public PoC, Patch Now

TL;DR

CVE-2026-78159 is a critical (CVSS 9.8) unauthenticated remote code execution vulnerability in The Events Calendar plugin for WordPress, affecting all versions up to and including 6.17.3. A public proof-of-concept (PoC) is available on GitHub, and CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalog on 2026-09-12, signaling confirmed in-the-wild exploitation. The attack chain requires comments to be enabled on tribe_events posts and at least one crafted comment containing a wp:legacy-widget block to exist in the database — approval is not required. If you run WordPress with this plugin on an internet-facing site, treat it as an emergency: patch to 6.17.4 or later immediately, then hunt for compromise.

What is CVE-2026-78159?

CVE-2026-78159 is a remote code execution (RCE) vulnerability in The Events Calendar, a popular WordPress plugin used by event, ticketing, and community sites. The flaw resides in the Element_Classes::parse_array() method and stems from insufficient validation of the widget classes map. An attacker can supply a plain-array payload that bypasses the is_safe_widget_instance() object check and reaches a callable-invocation sink, resulting in arbitrary code execution on the server.

The vulnerability is classified as CWE-94 (Improper Control of Generation of Code / Code Injection). It carries a CVSS v3.1 base score of 9.8 (Critical) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — network-reachable, low complexity, no privileges required, no user interaction, and high impact across confidentiality, integrity, and availability.

According to Wordfence, the plugin has over 600,000 active installations, making the potential attack surface substantial. The vulnerability was publicly disclosed on 2026-09-12, the same day CISA added it to KEV. A public PoC repository (abraxas/CVE-2026-78159) is available on GitHub.

Why this vulnerability matters right now

Three factors elevate CVE-2026-78159 to emergency status:

1. Unauthenticated RCE: No login or user interaction is required. Any internet-facing WordPress site with the vulnerable plugin and comments enabled on event posts is a candidate target.
2. Public PoC: A working proof-of-concept is publicly available, lowering the barrier to exploitation for both sophisticated and opportunistic attackers.
3. KEV listing: CISA's addition to the Known Exploited Vulnerabilities catalog on 2026-09-12 confirms real-world exploitation. This is not a theoretical risk.

While the EPSS score at the time of writing is 0.00762 (53.8th percentile) — relatively low — the KEV listing is the stronger and more actionable signal. EPSS measures predicted exploitation probability over the next 30 days; KEV confirms it has already happened. For defenders, KEV should drive prioritization.

Technical root cause: array confusion in Element_Classes::parse_array()

The vulnerability lives in common/src/Tribe/Utils/Element_Classes.php at line 211, inside the parse_array() method. The plugin's widget rendering pipeline includes a safety check, is_safe_widget_instance(), intended to ensure that only legitimate widget instances are processed. However, this check operates on the assumption that the classes attribute is an object. When an attacker supplies a plain PHP array instead, the check is bypassed.

Once past the check, the attacker-controlled classes map flows into a callable-invocation sink inside parse_array(). In PHP, arrays can represent callables (e.g., ['system', 'id'] or ['ClassName', 'method']). Because the plugin fails to validate the type and contents of the classes map, an attacker can inject a callable that executes arbitrary PHP functions or system commands.

The attack chain is triggered when WordPress's do_blocks() function processes the single-event post HTML, including the comment area. A crafted wp:legacy-widget block submitted as a comment is parsed during rendering, reaching the vulnerable sink. Critically, the comment does not need to be approved by a moderator — it only needs to exist in the database. This makes the attack stealthy: a pending comment in the moderation queue is enough to trigger code execution when the event page is rendered.

Wordfence's Argus system identified two distinct unauthenticated RCE chains leveraging this mechanism, underscoring the severity and the creativity of the attack vector.

Preconditions for exploitation

Exploitation requires two conditions to be met on the target site:

1. Comments enabled on tribe_events posts: The plugin must be configured to allow comments on event post types. This is common on community-oriented event sites.
2. At least one crafted comment containing a wp:legacy-widget block: The attacker must submit a comment with the malicious block. The comment does not need to be approved; it only needs to be stored in the database.

If both conditions are met, an attacker can trigger code execution by causing the single-event page to be rendered — for example, by requesting the event URL. The do_blocks() function processes the comment area, parses the malicious block, and invokes the attacker-controlled callable.

Exposure validation: how to check if you're affected

Defenders should take the following steps to validate exposure:

1. Inventory WordPress sites running The Events Calendar. Check plugin versions via the WordPress admin, WP-CLI (wp plugin list), or by inspecting the plugin's readme.txt file. Any version ≤ 6.17.3 is vulnerable.
2. Check comment settings on tribe_events post types. In WordPress admin, navigate to Events → Settings or the post type configuration to confirm whether comments are enabled. You can also query the database: SELECT * FROM wp_posts WHERE post_type = 'tribe_events' AND comment_status = 'open';.
3. Search for malicious comments in the database. Look for comments containing wp:legacy-widget blocks, especially those with classes attributes that appear to be arrays or contain callable names. Example query: SELECT * FROM wp_comments WHERE comment_content LIKE '%wp:legacy-widget%';.
4. Review web server and WAF logs for POST requests to wp-comments-post.php with unusually large or structured payloads, followed by GET requests to single-event URLs. Correlate timestamps with the KEV listing date (2026-09-12) and the public PoC release.
5. Scan for post-exploitation indicators (see IoC section below). If you find evidence of compromise, assume full server compromise and initiate incident response.

Detection and hunting guidance

Beyond exposure validation, security teams should hunt for signs of active exploitation. The following indicators are drawn from Wordfence's analysis and community reporting:

• Network: Unexpected outbound connections from the web server process to external IPs (reverse shell callbacks); unusual HTTP POST requests to wp-comments-post.php containing wp:legacy-widget block markup with array-type classes values.
• Logs: WordPress access logs showing POST requests to wp-comments-post.php with unusually large or encoded comment bodies; PHP error logs referencing Element_Classes::parse_array() or is_safe_widget_instance() with unexpected callable types; web server logs showing requests to event pages immediately after suspicious comment submissions.
• File system: Newly created PHP files in the WordPress uploads directory, plugin directories, or web root (web shells); modified wp-config.php or .htaccess files; unexpected cron jobs or scheduled tasks added under the web server user account.
• Process: Unusual child processes spawned by the PHP-FPM or Apache/Nginx worker process (e.g., bash, sh, curl, wget, python, nc); unexpected network connections initiated by the web server process.

Additionally, monitor for new administrative users, password resets, and changes to plugin/theme files. Any of these could indicate successful exploitation.

Impact: what an attacker can do

Successful exploitation grants an unauthenticated remote attacker full code execution on the web server, typically under the context of the web server user (e.g., www-data, apache, nginx). This translates to complete compromise of the WordPress installation and potentially the underlying host.

Specific impacts include:

• Confidentiality: Theft of database credentials, user PII, customer data, and any sensitive information stored on the server.
• Integrity: Modification or deletion of site content, injection of malicious JavaScript (e.g., credit card skimmers, SEO poisoning), installation of backdoors, web shells, and malicious plugins.
• Availability: Defacement, ransomware, or complete takedown of the site.
• Lateral movement: Use of the compromised server as a pivot point to attack other systems in the hosting environment or internal network.

For businesses, the downstream consequences include regulatory penalties (e.g., GDPR, CCPA) if personal data is exfiltrated, reputational damage, loss of customer trust, and supply-chain risk if the site is used to distribute malware.

Mitigation and patching guidance

Immediate action: Upgrade The Events Calendar plugin to version 6.17.4 or later. This version contains the patch addressing the insufficient validation in Element_Classes::parse_array(). Verify the fixed version against the official vendor advisory and the WordPress plugin repository.

If immediate patching is not possible, consider the following interim mitigations:

• Disable comments on tribe_events post types. This can be done via WordPress settings or by adding remove_post_type_support('tribe_events', 'comments'); to your theme's functions.php.
• Enable strict comment moderation so that no comment is published without administrator approval. However, note that the vulnerability can be triggered by unapproved comments, so moderation alone is not sufficient — it only reduces the attack surface if combined with other measures.
• Deploy WAF rules to block comment submissions containing wp:legacy-widget blocks with suspicious classes maps. Wordfence and other WAF providers may offer virtual patching.
• Restrict access to wp-comments-post.php and single-event pages where operationally feasible.
• Disable the plugin entirely if it is not business-critical.

After patching, perform a full compromise assessment because the KEV listing implies active exploitation. Rotate all WordPress, database, and hosting credentials. Review logs for the entire exposure window (from the disclosure date backward, as the vulnerability may have been exploited before public disclosure).

Post-exploitation: what to do if you suspect compromise

If you find evidence of exploitation, treat it as a security incident:

1. Isolate the affected host from the network to prevent lateral movement.
2. Preserve evidence: Capture logs, disk images, and memory dumps before remediation.
3. Rotate all credentials: WordPress admin accounts, database users, hosting panel, FTP/SFTP, SSH keys, and API tokens.
4. Rebuild from a known-good backup: Do not attempt to clean a compromised WordPress installation; rebuild it from a backup taken before the compromise.
5. Re-scan for residual backdoors: After rebuilding, scan for web shells, malicious cron jobs, and unauthorized admin users.
6. Report the incident through your normal channels and monitor for follow-on activity.

Timeline of events

• 2026-09-12: Public disclosure of CVE-2026-78159; CISA adds it to the KEV catalog; Wordfence publishes technical analysis; public PoC appears on GitHub.
• 2026-09-12 (onward): Security media coverage (SecurityWeek, CyberSecurityNews) highlights risk to hundreds of thousands of WordPress sites.
• Ongoing: Community discussion on Mastodon, Infosec.Exchange, and Medium; hosting providers begin notifying customers.

Frequently asked questions

Q: Is CVE-2026-78159 in CISA KEV? A: Yes. CISA added CVE-2026-78159 to the Known Exploited Vulnerabilities catalog on 2026-09-12. This confirms active exploitation in the wild.

Q: Is there a public PoC? A: Yes. A public proof-of-concept is available on GitHub at abraxas/CVE-2026-78159. This lowers the barrier to exploitation.

Q: What versions are affected? A: All versions of The Events Calendar plugin up to and including 6.17.3 are vulnerable. Upgrade to 6.17.4 or later.

Q: Does the malicious comment need to be approved? A: No. The attack chain is triggered when do_blocks() processes the single-event HTML, including the comment area. An unapproved comment in the database is sufficient.

Q: What if I can't patch immediately? A: Disable comments on tribe_events posts, deploy WAF virtual patching, restrict access to comment submission endpoints, or disable the plugin until you can patch.

Q: How do I know if I've been compromised? A: Look for the indicators of compromise listed above: suspicious comments, outbound connections, new PHP files, modified core files, and unexpected admin users. If you find any, assume full compromise and initiate incident response.

Q: Is this vulnerability exploitable if comments are disabled? A: No. The attack chain requires comments to be enabled on tribe_events posts and at least one crafted comment to exist. Disabling comments breaks the chain.

Q: What is the EPSS score, and does it matter? A: The EPSS score is 0.00762 (53.8th percentile), which is relatively low. However, the KEV listing is a stronger signal of real-world risk. Prioritize based on KEV, not EPSS alone.

References

• GitHub Advisory GHSA-9c57-9fxg-8x9j
• Wordfence Threat Intelligence
• Wordfence Blog: Argus identifies two critical unauthenticated RCE chains
• SecurityWeek: Unauthenticated RCE flaws could expose 200,000 WordPress sites to takeover
• WP Plugin Changeset
• Dev.to Write-up
• ENISA EUVD
• CISA Known Exploited Vulnerabilities Catalog
• Public PoC repository (abraxas/CVE-2026-78159)
• The Events Calendar official site
• WordPress Plugin Security Guidance

---

Trusteed publishes emergent-threat intelligence for defenders. This post is for informational purposes only and does not constitute legal or compliance advice. Always validate against official vendor advisories.