Critical Events Calendar Flaws Put More Than 200,000 WordPress Sites at Risk

Two critical vulnerabilities in StellarWP’s The Events Calendar plugin could allow unauthenticated attackers to execute code and take control of affected WordPress installations.

The plugin has more than 600,000 active installations. Approximately 240,000 websites were running releases earlier than version 6.17, placing them within the affected ranges for both flaws. However, exploitation depends on comment-related configuration, making the precise number of exploitable sites uncertain.

Both vulnerabilities carry a CVSS score of 9.8. Administrators should upgrade The Events Calendar to version 6.17.4.1 or later, because the two issues were corrected in separate releases.

Two independent routes to remote code execution

The vulnerabilities affect different parts of the plugin and use separate exploitation paths:

• CVE-2026-78159 is a code-injection vulnerability in the parse_array function.
• CVE-2026-78006 is a PHP object-injection vulnerability involving is_safe_widget_instance.

Each flaw can be exploited remotely without authentication, privileges, or user interaction. They share the following CVSS 3.1 vector:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

That rating describes network-accessible vulnerabilities with low attack complexity and high potential impact on confidentiality, integrity, and availability. Successful exploitation can therefore move beyond changing page content: it can result in server-side code execution and complete compromise of the WordPress installation.

The weaknesses have different classifications. CVE-2026-78159 is tracked as CWE-94, covering improper control over generated code, while CVE-2026-78006 is classified as CWE-502, deserialization of untrusted data.

No confirmed exploitation activity, attacker infrastructure, public exploit indicators, or malware campaign has been identified in the available information. A CISA Known Exploited Vulnerabilities catalog status and remediation deadline are also not known.

CVE-2026-78159 bypasses checks with a plain array

CVE-2026-78159 results from insufficient validation of the widget classes map. The vulnerable code is found in Element_Classes::parse_array().

The plugin attempts to assess whether a widget instance is safe. However, an attacker can submit a payload structured as a plain array, bypassing the object-oriented check performed by is_safe_widget_instance(). The payload can then reach a callable-invocation sink inside parse_array, where attacker-controlled data may be treated as executable behavior.

Processing occurs while The Events Calendar renders single-event HTML, including the page’s comment area. Exploitation requires comments to be enabled on tribe_events posts, and at least one comment must satisfy an additional condition that has not been publicly detailed in the available technical description.

This dependency limits the vulnerable attack surface but does not require the malicious commenter to have a WordPress account. Under the necessary configuration, the attack remains unauthenticated.

The NVD lists versions up to and including 6.17.3 as vulnerable. StellarWP corrected the issue in version 6.17.3.1, released on August 25.

Installing that release alone is no longer sufficient. It fixes CVE-2026-78159 but leaves the second remote-code-execution path unresolved.

CVE-2026-78006 exploits PHP deserialization behavior

CVE-2026-78006 affects is_safe_widget_instance, the same protection that the first vulnerability can avoid by supplying a plain array. This time, the attacker directly subverts the protection through PHP object injection.

PHP can invoke magic methods while data is being prepared and interpreted, before the plugin’s intended validation sequence has completed. The vulnerable flow allows enable_rendering_widget_copied() to generate what appears to be a legitimate wp_hash integrity attribute before execution reaches unserialize().

That forged integrity value lets hostile serialized data pass a check designed to distinguish trusted widget content. Once the data reaches deserialization, an attacker can trigger an object-injection chain capable of executing code on the server.

Comments on event content must be enabled and visible for this path to be exploitable. Critically, the malicious data reaches the vulnerable function before WordPress comment moderation or approval can block it. Requiring approval for new comments therefore does not, by itself, prevent exploitation.

The NVD identifies all versions through 6.17.4 as affected. StellarWP fixed the vulnerability in version 6.17.4.1, released on September 10.

Version differences create an update trap

The two patch levels are easy to confuse because they differ only in their final revision component.

Vulnerability	Vulnerable versions	First fixed version
CVE-2026-78159	Up to and including 6.17.3	6.17.3.1
CVE-2026-78006	Up to and including 6.17.4	6.17.4.1

A site running 6.17.3.1 is protected from CVE-2026-78159 but remains exposed to CVE-2026-78006. Administrators should consequently treat 6.17.4.1 as the minimum safe version covering both vulnerabilities.

This matters for fleets where updates are staged or pinned rather than installed automatically. Merely confirming that the plugin received an August 25 security update does not establish that the installation is protected against the later object-injection flaw.

Organizations should inventory every WordPress instance, including development sites, event microsites, dormant installations, and copies hosted under secondary domains. Each installation needs its installed plugin version verified directly.

Exposure depends on versions and comment settings

SecurityWeek estimates that more than 200,000 WordPress websites could be exposed to takeover. Usage data also indicates that about 240,000 sites were running versions earlier than 6.17, which fall within both vulnerable ranges.

These numbers do not mean every outdated installation can immediately be compromised. Both attack paths depend on comments being enabled in the relevant The Events Calendar configuration. CVE-2026-78159 is specifically associated with comments on tribe_events posts.

The plugin was downloaded slightly more than 300,000 times between September 10 and 14. Compared with an active installation base exceeding 600,000 sites, that volume suggests approximately half of installations may not yet have received the update for CVE-2026-78006. Download figures cannot confirm whether an update was installed successfully or whether the necessary comment settings are active.

The result is a large but imprecise exposure window. Version telemetry measures outdated software, while actual exploitability also depends on site configuration and content state.

Administrators should patch and investigate exposed systems

The primary response is to upgrade The Events Calendar to version 6.17.4.1 or later. Administrators should then confirm the installed version from each WordPress environment rather than relying solely on centralized update notifications.

Until patching is complete, operators can review whether comments are enabled for event content. Disabling them may remove a known prerequisite, but it has not been presented as a formal vendor replacement for installing the fixed version.

Security teams should inspect WordPress, PHP, and web-server logs for unusual activity involving:

• Comments submitted to event posts.
• Malformed widget arrays or unexpected classes data.
• Serialized PHP objects in incoming requests.
• Requests attempting to reach event-rendering or widget-processing code.
• New administrator accounts or unexplained privilege changes.
• Modified plugins, themes, or core files.
• Unexpected scheduled tasks, server-side scripts, or outbound connections.

No specific exploit strings or reliable indicators of compromise are currently available. Detection therefore requires behavioral review rather than matching a published signature.

If suspicious activity appears on a site that ran an affected version with event comments enabled, administrators should treat the entire WordPress installation as potentially compromised. That assessment should extend to credentials, database contents, hosting accounts, server files, persistence mechanisms, and any secrets accessible to the PHP process.