Security Brief: Two Critical The Events Calendar Flaws Enable Unauthenticated WordPress RCE
https://vulnify.app/blog/security-brief-the-events-calendar-cve-2026-78006-cve-2026-78159-rce

Two critical vulnerability chains in The Events Calendar WordPress plugin can lead to unauthenticated remote code execution when comments are enabled on event pages. CVE-2026-78006 and CVE-2026-78159 both carry CVSS scores of 9.8 and affect vulnerable releases used across hundreds of thousands of sites.

What happened Wordfence disclosed two independent critical vulnerability chains in The Events Calendar, a widely used WordPress plugin active on more than 600,000 websites. Both chains begin in the plugin's event-page widget rendering pipeline and can ultimately lead to remote code execution without authentication. The first issue, CVE-2026-78006, affects The Events Calendar through version 6.17.4 and is rated CVSS 9.8. It combines unsafe handling of serialized widget data with a validation weakness, allowing PHP object injection to reach a dangerous deserialization path and execute operating-system commands under the web server account. The second issue, CVE-2026-78159, affects versions through 6.17.3 and is also rated CVSS 9.8. It takes a different route through the same broader widget-processing surface. Attacker-controlled array values can reach a callable invocation path that was intended for dynamic styling logic. Wordfence demonstrated that the primitive can be used to alter an administrator account and progress to remote code execution. Both chains require comments to be enabled on event posts and The Events Calendar's own option to show comments on event pages to be active. They do not require a WordPress account or moderator approval. The plugin's processing of pending comment content allows an attacker to trigger the vulnerable rendering path through the normal pending-comment preview flow. Wordfence recommends updating to The Events Calendar 6.17.4.1, which was the latest fully patched version at the time of its September 14 disclosure. Why comments enter the widget pipeline The root of both chains is unusual because ordinary WordPress comment text is not normally treated as Gutenberg block content. The Events Calendar's V2 single-event template buffers a large portion of the rendered event page, including the comment area, and then passes the resulting HTML through WordPress block processing. That design widens the block parser's input surface. HTML comment delimiters used by Gutenberg block markup can survive normal comment sanitization, so attacker-controlled comment content may reach the block-processing logic even though it was submitted as a comment rather than trusted post content. WordPress also gives a commenter a moderation-hash preview URL that lets them view their own pending comment before a moderator approves it. That matters because it creates a way for an unauthenticated attacker to cause the crafted comment to be rendered immediately. The shared high-level path is: Anonymous comment submitted to event | v Pending-comment preview becomes available | v Event page buffers comment content | v Buffered page passes through block processing | v Attacker-controlled legacy widget data is processed | v One of two vulnerable execution paths is reached The two CVEs diverge after that shared entry point. CVE-2026-78006: PHP object injection to RCE CVE-2026-78006 affects versions up to and including 6.17.4. The vulnerable code attempts to inspect serialized widget data before WordPress later deserializes it. The check was intended to reject unsafe objects, but Wordfence found that PHP object behavior could be triggered during parsing in a way the validation logic did not safely account for. The result is that attacker-controlled serialized data can pass the plugin's safety decision and later reach an object chain capable of invoking dangerous application behavior. Wordfence's validated chain reaches arbitrary operating-system command execution. For defenders, the key point is not the exact serialized structure used in a proof of concept. The important condition is that an untrusted comment can enter a widget-deserialization path that was designed for trusted rendering state. The fix therefore needs to come from the plugin update rather than attempts to block one particular serialized pattern. CVE-2026-78006 is patched in version 6.17.4.1. CVE-2026-78159: callable invocation to RCE CVE-2026-78159 is independent of the object-injection flaw. It affects versions through 6.17.3 and abuses an array-processing path in the widget classes map. The code accepts values that PHP considers callable, even though the original purpose is related to building CSS class information. Because attacker-controlled widget data can reach this path, a string corresponding to an available PHP or WordPress function can be invoked with attacker-influenced arguments. Wordfence demonstrated that this can be used to change an administrator password, after which the attacker can authenticate as the administrator and install malicious code through WordPress. The practical result is again complete site compromise, but the mechanism is different from CVE-2026-78006. This distinction matters because patching only the object-injection guard would not address the second path. StellarWP released fixes for both issues, with version 6.17.4.1 representing the fully patched release cited by Wordfence at publication. Why it matters for website owners The Events Calendar is used by organizations that publish conferences, community events, training schedules, venues, ticketing information, and other public event data. These websites often allow public interaction, and comment functionality may have been enabled years earlier without being considered a security-sensitive feature. The vulnerabilities are particularly serious because no account registration is required. A site can therefore be attacked by an anonymous internet user if the required event-comment configuration is present. Moderator approval is also not a reliable barrier because the pending-comment preview is sufficient to trigger the vulnerable page rendering. Remote code execution can move the incident beyond WordPress itself. The PHP process may have access to database credentials, API keys, mail configuration, media files, customer records, and other secrets stored by the application. A successful attacker may also create secondary backdoors or administrator accounts that remain after the original plugin is updated. Administrators should therefore distinguish between patching and incident response. Updating closes the known vulnerability path. It does not prove that a site exposed before the update was never compromised. What to check on your site Confirm The Events Calendar version. Update to 6.17.4.1 or a newer vendor-supported release. Check event comment settings. Determine whether comments are enabled for tribe_events posts and whether the plugin's event-page comment display option is active. Review historical exposure. If comments were enabled while a vulnerable release was running, treat the site as having met the main configuration prerequisite. Review pending and spam comments. Investigate unusual comments containing unexpected block-like markup or content that does not resemble legitimate discussion. Check administrator accounts. Look for unknown users, unexplained password changes, privilege changes, or new administrator sessions. Inspect plugins and themes. Search for unfamiliar plugins, recently modified PHP files, and code introduced outside the normal deployment process. Review access logs. Correlate unusual event-page requests, comment submissions, moderation preview URLs, and subsequent administrative activity. Preserve evidence if compromise is suspected. Retain web, WordPress, hosting, and authentication logs before making extensive cleanup changes. Recommended response Update The Events Calendar to a fully patched release immediately. If updating cannot be completed promptly and the plugin is not essential, temporarily disabling it reduces exposure. Sites that do not need comments on events can also disable that functionality as an additional risk-reduction measure, but configuration changes should not replace the security update. Because both chains can lead to full site compromise, any indication of exploitation warrants a broader WordPress investigation. Compare core, plugin, and theme files against known-good copies, review administrative users, inspect must-use plugins and scheduled tasks, and rotate credentials that may have been accessible to the PHP process if code execution is confirmed. High-value sites should also consider whether a compromised WordPress host had access to external systems such as SMTP services, CRM platforms, payment services, storage buckets, or APIs. An attacker who reaches server-side code may be able to reuse those credentials outside the original website. Using Vulnify for WordPress review Vulnify's WordPress Stack Checker can help website owners review publicly detectable WordPress technology and identify properties that need closer plugin inventory. This is particularly useful for organizations with multiple production, staging, or legacy WordPress sites. Public-surface checks cannot determine whether a malicious pending comment previously reached an internal widget deserialization path or whether a web shell was placed on the server. Direct WordPress and filesystem review is still required when assessing CVE-2026-78006 and CVE-2026-78159. For a broader operational workflow, Vulnify's WordPress Security Workflows documentation can help structure external checks alongside the administrative verification that must happen inside WordPress. Lessons for WordPress plugin design The disclosure highlights a recurring risk in large WordPress extensions: trusted rendering pipelines can accidentally be widened to include untrusted content. A function that is safe when processing administrator-created page content may become dangerous if the same path begins processing anonymous comments. Developers should minimize use of PHP deserialization on attacker-influenced data, avoid dynamic invocation of arbitrary callables, and treat integrity hashes as meaningful only when they protect data that was validated before signing. Security checks should fail closed and should not silently transform untrusted data into trusted state. Plugins that render user content should also keep clear boundaries between comments, post content, block markup, and widget configuration. Reusing a powerful rendering pipeline across those boundaries can expose code paths that were never designed to accept anonymous input. Related reading WordPress Stack Checker WordPress Security Workflows Conclusion CVE-2026-78006 and CVE-2026-78159 are two separate critical vulnerability chains in The Events Calendar, but both originate from the same broader design problem: anonymous comment content can enter a powerful widget-rendering pipeline and reach unsafe downstream behavior. Both vulnerabilities carry CVSS scores of 9.8. The first can reach remote code execution through PHP object injection, while the second abuses a callable invocation path that can be used to take over an administrator account and then execute code through WordPress. Sites should update to 6.17.4.1 or later, review whether event comments were enabled while vulnerable versions were exposed, and investigate account or filesystem anomalies where compromise is possible. The absence of moderator approval does not protect an affected site because the pending-comment preview flow is sufficient to trigger the vulnerable processing. Sources Wordfence: Two Critical Unauthenticated Vulnerability Chains in The Events Calendar Wordfence Intelligence: The Events Calendar Vulnerabilities