The Events Calendar, a WordPress plugin running on more than 600,000 websites, carries two critical, unauthenticated vulnerability chains that let an attacker execute code on the server or hijack an administrator account, Wordfence disclosed on September 14, 2026. Site owners should update to version 6.17.4.1 immediately.
What to Know?
- Wordfence Argus found two independent exploit chains in The Events Calendar plugin, both rated 9.8 on the CVSS scale.
- Neither chain requires a login, account registration, or admin approval. Both trigger through an unapproved comment’s own moderation-preview link.
- The first chain (CVE-2026-78006) uses PHP object injection to run arbitrary operating system commands on the server.
- The second chain (CVE-2026-78159) abuses an arbitrary-callable function to reset the administrator’s password, opening the door to a malicious plugin upload and full site takeover.
- StellarWP, the plugin’s developer, shipped a complete fix in version 6.17.4.1, released September 10, 2026.
How It Happened?
Both chains start in the same place: the plugin’s single-event page buffers its entire rendered output, comment section included, and runs it through WordPress’s do_blocks() function. WordPress core normally reserves that function for post content, not comments, but The Events Calendar’s get_v1_single_event_html() method widens the block parser’s reach to cover anything a visitor types into the comment box.
Wordfence Argus Identifies Two Critical Unauthenticated Vulnerability Chains Leading to Remote Code Execution in The Events Calendar Plugin
— Wordfence (@wordfence) September 14, 2026
Update The Events Calendar to version 6.17.4.1 as soon as possible.https://t.co/Xrf0wSw7tr
WordPress’s comment sanitizer keeps HTML comment delimiters intact, and Gutenberg uses those same delimiters as block markup. A malicious wp:legacy-widget block hidden inside a comment survives sanitization and reaches the block parser. WordPress also generates a moderation-hash preview link the moment someone submits a comment, so the commenter can see their own pending, unapproved post immediately, no moderator required.
From there, a shared flaw does the rest of the work. The plugin’s enable_rendering_widget_copied() function checks a submitted widget instance with a routine called is_safe_widget_instance(), and if that check passes, the plugin generates a valid wp_hash() integrity signature for the attacker’s own data. That signature is the exact check WordPress core relies on before deserializing a widget, so forging it defeats core’s only safeguard.
The first chain slips a fully formed PHP object past that check by appending an invalid data type after it, so the preliminary parse returns false and reports no object found. When WordPress later performs the real deserialization, PHP still executes the object’s magic methods first, including one that reaches Lazy_Post_Collection::custom_unserialize(). That method hands attacker-supplied callback and ids values straight to array_map(), letting the attacker run any system command as the web server user, according to Wordfence’s technical write-up.
The second chain skips serialized objects entirely. A plain array clears is_safe_widget_instance() because it contains no object to flag, so the guard offers no protection. Wordfence found that the array’s contents flow into Element_Classes::parse_array(), a function meant to build CSS class lists that also accepts any PHP callable, not just closures. By naming wp_update_user as a callable inside the array, along with an admin user ID and a new password value, an attacker can force a live call to wp_update_user() with no capability check, changing the administrator’s password outright.
Disclosure and Patch Timeline
Wordfence sent the first vulnerability to StellarWP through its Vulnerability Management Portal on August 21, 2026. StellarWP acknowledged the report on August 24, 2026 and released an initial patch the next day, later formalized as version 6.17.3.1. Wordfence disclosed the second chain on August 23, 2026, and StellarWP acknowledged it the following day.
Wordfence Premium, Care, and Response customers received a firewall rule covering known exploits for both chains on August 22, 2026. Sites running the free version of Wordfence will get the same rule on September 21, 2026, 30 days after the premium release under Wordfence’s standard disclosure policy.
StellarWP’s full fix landed in version 6.17.4.1 on September 10, 2026, which the vendor’s own changelog describes as having strengthened validation of copied widget instances. Both exploit chains require that comments be enabled and visible on event pages, since The Events Calendar’s own Show comments on event pages setting controls whether the vulnerable rendering path runs at all.
What’s Next?
The real weakness here sits at the seam between two systems that trusted each other’s judgment. WordPress core assumes a widget instance is safe once it carries a valid integrity hash, and The Events Calendar generated that hash for data it never should have trusted, including plain arrays and malformed serialized objects. Once that single check fails, an anonymous website visitor holds the same access a logged-in administrator would.
Site owners running The Events Calendar should update to version 6.17.4.1 without delay, since both chains work without any login and can be triggered the moment a comment is submitted, before a moderator ever sees it. Anyone who left comments enabled on event pages before September 10, 2026 should also check recent admin account activity and password-reset logs for signs the second chain was already used, and rotate the administrator password as a precaution. Updating the plugin closes both chains outright. Disabling comments on event pages removes the trigger but leaves the underlying code path in place until the update is applied.
