A Comment Could Take Over Your WordPress Site Before You Approved It
A comment waiting for approval should not be able to take over the website reviewing it. Two Events Calendar remote code execution chains challenge that assumption: a crafted comment can reach vulnerable processing through its pending preview, before a moderator has approved anything.
Wordfence’s 14 September technical analysis describes two independent, unauthenticated paths. They require comments to be enabled and visible on the affected event page, including the plugin’s own comment-display option. No account or moderator approval is required. These are configuration-dependent vulnerabilities, not proof that every site with the plugin has been compromised.
The first fix did not cover both paths
| Identifier and score | Impact and prerequisite | Affected releases | First fixed release |
|---|---|---|---|
| CVE-2026-78159, 9.8 | Callable abuse resets an administrator password, followed by malicious-plugin upload; affected comment-preview route required | Through 6.17.3 | 6.17.3.1 |
| CVE-2026-78006, 9.8 | Unsafe deserialisation directly reaches server-side execution; affected comment-preview route required | Through 6.17.4 | 6.17.4.1 |
The actual plugin release notes date 6.17.3.1 to 26 August and 6.17.4.1 to 10 September. Some chronology in the disclosure narrative differs; the explicit vulnerability tables and release notes are the appropriate references for the fix. A maintained release at least 6.17.4.1 covers both identified issues.
For both chains, the write-up includes reproduction material but does not establish malicious exploitation or a verified standalone exploit release. A separate vendor-endorsed workaround was not established in the reviewed sources. Published technical detail is not proof of an attack against a particular site.
Moderation and execution are different boundaries
The operational lesson is broader than this plugin. A moderation queue controls what readers are permitted to see. It is not automatically a promise that the submitted content will remain inert until approval. BlackTree recommends checking preview and notification routes when assessing any system that accepts untrusted submissions.
For website owners, that distinction changes the question given to an agency or hosting provider. “Do you moderate comments?” is not enough. Ask which plugin build is running, whether the relevant event-comment route is reachable and whether both fixes have been verified on the live deployment.
A response checklist for site owners and agencies
- Find every affected installation. Include client sites, staging copies and retired campaign pages that remain reachable. Assign a named owner to each.
- Check the running plugin version. Verify a maintained version containing both fixes. An old update ticket or dashboard notification is not a live-build check.
- Review comment exposure. Record WordPress’s event-comment settings and the plugin’s display option. Moderation alone is not a compensating control for the described path.
- Use temporary restrictions carefully. Disabling the relevant submission and rendering route can reduce this specific exposure, but it needs testing and must not become a claim of complete remediation.
- Investigate suspicious changes separately. Review unfamiliar administrators, plugin files and unexpected server activity where evidence warrants it. A successful update does not explain earlier anomalies.
- Validate after the change. Confirm that event pages still work and that backup, monitoring and recovery procedures remain available.
These are BlackTree’s practical checks, not a claim that every affected installation needs rebuilding. If compromise is suspected, preserve evidence and involve qualified responders before destructive cleanup. For related context, BlackTree’s Avada research coverage examines a different route from web features to execution; it is not evidence of a connection between the cases.
The website can reject a comment for publication and still process it dangerously. The fix belongs at the execution boundary, not in the moderator’s inbox.
Sources
- Wordfence, original two-chain disclosure and vulnerability tables, published 14 September 2026. No publication clock or separate update time was provided on the reviewed page.
- The Events Calendar, official WordPress repository release notes, listing 6.17.3.1 on 26 August and 6.17.4.1 on 10 September 2026. No release clocks were provided.
One of the most interesting aspects here is the gap between what is considered “approved” from a user or moderation perspective and what has already been processed technically.
That distinction matters far beyond WordPress comments. In security, a control can appear effective at the organizational level while the underlying system is already exposing data, executing logic, or creating an attack path.
For risk assessment, it is therefore worth separating visible approval from actual technical exposure. Security boundaries should be evaluated where processing really happens — not only where users believe the boundary exists.