Threat Overview
Two flaws in The Events Calendar — each rated 9.8 — let a visitor with no account and no approved comment either reset the site administrator’s password or run operating system commands on the server. Both trace to one decision: rendering an event page buffers the whole page, comment area included, then hands that HTML to the block parser. WordPress parses blocks from post content, never from text submitted by strangers — and comment sanitization preserves the delimiters that block markup depends on.
| Threat Metric | Technical Details |
|---|---|
| Severity Rating | CRITICAL (CVSS 9.8 / 10.0) |
| Vulnerability Class | Unauthenticated PHP Object Injection & Arbitrary Callable Invocation (CWE-502 / CWE-436) |
| Vulnerable Components | The Events Calendar up to and including 6.17.4 (CVE-2026-78006) and 6.17.3 (CVE-2026-78159) |
| Attack Vector | Anonymous comment submission on a public event page |
| Preconditions | Comments enabled on event pages, with “Show comments on event pages” active |
| Disclosure & Fix | Reported by Wordfence Argus, acknowledged August 24; patched in 6.17.4.1 (September 10) |
The Breakdown: How the Exploit Works
An attacker submits a comment containing a crafted wp:legacy-widget block on any public event page. No login, no registration, no moderator approval — WordPress gives commenters a moderation-hash link that previews their own pending comment, and opening it runs the block through the widget-rendering pipeline first.
CVE-2026-78006 uses PHP object injection: a malformed serialized payload slips past the is_safe_widget_instance() check, because PHP parses serialized input before that check inspects the result. The gadget chain reaches an array_map() callable that runs system commands as the web server user. CVE-2026-78159 needs no serialization — a plain array passes the check and reaches CSS class handling, where is_callable() accepts globally available function names. Researchers invoked wp_update_user() to reset administrator ID 1’s password, with no capability check in the path.
The Operational Risk: What an Attacker Gains
Signed in as an administrator, the attacker installs a malicious plugin and owns the site — plus whatever shares its hosting account: customer records, injected spam pages, a foothold that outlives routine patching. Roughly 240,000 sites still run versions predating 6.17, and the plugin saw more than 300,000 downloads between September 10 and 14.
Our Take in Plain English
“You did nothing wrong. You published an event page and left comments on, which is what the plugin is for. But on a dynamic platform, every public input field is a door into the same process that serves your pages. The fix is not better moderation — the attacker never needed approval. It is making a comment structurally incapable of reaching your execution layer, which only comes from separating the page you serve from the machinery behind it.”
The Modern Architectural Remedy
- Legacy Dynamic Platform: Builds every page on demand inside the process holding database credentials, plugin code, and filesystem write access. One parsing mistake reaches all of it.
- Modern Pre-Rendered Architecture: Serves pre-compiled pages from the edge. Commentary stays data — handled by an isolated service, never passed to an engine with execution authority.
Immediate Action Items for WordPress Operators
- Update immediately: The Events Calendar 6.17.4.1 or later.
- If you cannot update today: Disable comments on event pages and turn off “Show comments on event pages.” That removes the precondition for both chains.
- Patch, then assume: Review administrator accounts and password-change timestamps, recently installed plugins, and logs for comment-preview requests. Treat any site that ran an affected version while publicly reachable as potentially compromised.