{"id":2911,"date":"2026-09-14T02:38:28","date_gmt":"2026-09-14T09:38:28","guid":{"rendered":"https:\/\/www.cycognito.com\/blog\/?p=2911"},"modified":"2026-09-14T02:38:30","modified_gmt":"2026-09-14T09:38:30","slug":"emerging-threat-cve-2026-78006-the-events-calendar-remote-code-execution-via-php-object-injection","status":"publish","type":"post","link":"https:\/\/www.cycognito.com\/blog\/emerging-threat-cve-2026-78006-the-events-calendar-remote-code-execution-via-php-object-injection\/","title":{"rendered":"Emerging Threat: (CVE-2026-78006) The Events Calendar Remote Code Execution via PHP Object Injection"},"content":{"rendered":"\n
\"\"
Sample of assets impacted by The Events Calendar RCE vulnerability, identified by the CyCognito Platform<\/em><\/figcaption><\/figure>\n\n\n\n

What is CVE-2026-78006?<\/h2>\n\n\n\n

CVE-2026-78006 is a deserialization of untrusted data vulnerability (CWE-502) in The Events Calendar, a WordPress plugin published by StellarWP, that allows an attacker to achieve remote code execution on the underlying host. The flaw sits in the is_safe_widget_instance<\/code> function, whose guard against unsafe object data can be bypassed. An attacker who supplies a forged wp_hash<\/code> integrity attribute passes validation, and PHP magic methods are then reached during pre-parsing before unserialize()<\/code> is called on the attacker-controlled payload.<\/p>\n\n\n\n

The vulnerability carries a CVSS v3.1 base score of 9.8 (Critical).<\/p>\n\n\n\n

Exploitation is pre-authentication. The delivery path runs through the comment system rather than any administrative interface. The plugin’s V2 single-event template processes buffered comment HTML through do_blocks()<\/code>, so an unauthenticated visitor can submit malicious block markup as a comment on an event page. WordPress issues the commenter a moderation-hash URL that renders their own pending comment immediately, which means the payload executes before a moderator ever reviews it. No account, no credential, and no administrator interaction are required.<\/p>\n\n\n\n

One condition narrows the exploitable population. Comments must be enabled and visible on event pages for the delivery path to work. Sites that disable commenting on the events post type, or that restrict comment submission to logged-in users, remove the unauthenticated route even while running an affected version. Publicly available exploitation data showed a low observed exploitation rate at the time of writing, with an EPSS score under 1 percent, though proof-of-concept code for the vulnerability is publicly available.<\/p>\n\n\n\n

What assets are affected by CVE-2026-78006?<\/h2>\n\n\n\n

All versions of The Events Calendar up to and including 6.17.4 are affected. The plugin is one of the more widely deployed event and calendar extensions in the WordPress ecosystem, and the affected range covers the full 6.x line as well as older 5.x releases still in service. Version fingerprints observed across the assets in this analysis span the 5.10.x, 6.15.x, and 6.17.x lines, all of which fall inside the vulnerable range.<\/p>\n\n\n\n

In practice, an affected asset is an internet-facing WordPress site that publishes an events, conferences, training, or community calendar section. These are frequently not the organization’s flagship domain. They are campaign microsites, regional or divisional sites, careers and recruitment portals, conference and training registration sites, staging and pre-production hostnames left publicly reachable, and sites inherited through acquisition or run by an agency on the organization’s behalf.<\/p>\n\n\n\n

That deployment pattern is what makes this vulnerability relevant to external exposure rather than only to WordPress administrators. Event and calendar sites are built to be public and indexed, so they are reachable by design. They are also commonly maintained outside the central IT patching cycle, which means plugin updates depend on whoever owns the site rather than on a scheduled process. Comment functionality is frequently left at the WordPress default on these sites, since nobody has a reason to turn it off, and that default is precisely the precondition this vulnerability requires.<\/p>\n\n\n\n

What does our data show about exposure patterns?<\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Exposure in this set is led by Health Care at 25.9% of observed assets, with Consumer Discretionary contributing 16.7%. Assets here were predominantly identified by service fingerprint rather than by confirmed vulnerable-version detection, so the set describes hosts observed running The Events Calendar and potentially exposed, not confirmed exploitable targets. <\/p>\n\n\n\n

Health Care’s position is consistent with how the sector publishes online. National and regional health systems operate large estates of small, topic-specific public sites: service directories, clinical network pages, staff recruitment portals, patient information microsites, and regional board sites. <\/p>\n\n\n\n

Each one is inexpensive to stand up on WordPress, each one has a legitimate reason to publish a calendar of clinics, training, or community sessions, and each one tends to be owned by a communications or service team rather than by central IT. Consumer Discretionary shows a similar structure for different reasons, with hospitality, travel, and property brands running per-property and per-campaign sites where an events calendar is a core commercial feature.<\/p>\n\n\n\n

The pattern across the full set points less at a patching failure than at an ownership failure. The affected software is not embedded in core infrastructure. It is a plugin on a secondary web property, and the organizations carrying exposure are generally those with the most fragmented web estates rather than the weakest security programs. Assets in this set include staging and pre-production hostnames that remain publicly resolvable, and sites whose naming shows no relationship to the parent brand. Both are signs that the exposure is created at discovery time, not at patch time. An organization cannot patch a plugin on a site it does not know it owns.<\/p>\n\n\n\n

Are fixes available?<\/h2>\n\n\n\n

Yes. StellarWP released The Events Calendar 6.17.4.1 on September 10, 2026, which corrects the object injection path. The vulnerability was reported by Wordfence and published on September 12, 2026. Organizations running any version at or below 6.17.4 should treat themselves as affected and update.<\/p>\n\n\n\n

The version numbering deserves attention. The fix arrived as a fourth-level point release on the 6.17.4 line rather than as a new minor version, which makes it easy to overlook in an inventory that tracks only major and minor versions. An asset reporting 6.17.4 is vulnerable. An asset reporting 6.17.4.1 is not. Any check that truncates the version string will not distinguish between the two.<\/p>\n\n\n\n

Because the plugin is distributed through the WordPress plugin repository, sites with automatic plugin updates enabled may already have taken the fix without operator action, while sites with automatic updates disabled will not. Defenders should verify the installed version directly on each site rather than assuming a fix has propagated, and should confirm current guidance with the vendor.<\/p>\n\n\n\n

Are there any other recommended actions to take?<\/h2>\n\n\n\n

Until patching is confirmed, defenders should:<\/p>\n\n\n\n