1. Executive summary
Two critical-severity, unauthenticated code-injection vulnerabilities in The Events Calendar WordPress plugin — a component with more than 600,000 active installations — allow remote code execution and complete takeover of the affected WordPress installation. CVE-2026-78159 was fixed in plugin version 6.17.3.1 (released 25 August 2026) and CVE-2026-78006 in version 6.17.4.1 (released 10 September 2026); both are rated CVSS 9.8 by the reporting research, a score we reproduce as source-reported and have not independently verified — no CISA KEV status is available to us for either CVE. Approximately 240,000 sites are reported to run versions prior to 6.17, and download telemetry between 10 and 14 September suggests roughly half of installations may still be exposed to the second flaw. Both exploitation chains require comments to be enabled and visible on events, which materially narrows the exposed population. For EMEA financial services the exposure is concentrated in marketing, investor-relations and event microsites and any WordPress estate sitting outside central IT change control — full site takeover there is a credible route to brand abuse, credential harvesting and a pivot toward corporate infrastructure.
2. Regulatory framing
No specific DORA/NIS2 article is directly engaged by this item.
This is a vendor vulnerability disclosure with no client-specific incident, no confirmed exploitation and no named ICT third-party provider relationship in scope. If exploitation is subsequently confirmed on a client estate, DORA Art. 17 (ICT-related incident management process), DORA Art. 18 (classification of ICT-related incidents and cyber threats) and DORA Art. 19 (reporting of major ICT-related incidents to competent authorities) become engaged by that incident, and NIS2 Art. 23 (incident reporting obligations) applies to in-scope entities — but those triggers are the incident, not this advisory.
3. Technical analysis & attack chain
Affected component: The Events Calendar WordPress plugin, all versions before 6.17.3.1 per the source's blanket statement; see the version discrepancy note below. The plugin is developed by StellarWP.
Confirmed exploitation preconditions: the target runs an affected plugin version and comments on events are enabled and visible. The source states that exploitation of both defects requires comments to be enabled in the plugin.
Attack chain (as described by the source)
- Reconnaissance / target selection — attacker identifies a WordPress site running The Events Calendar with event comments enabled and visible. No authentication is required at any stage of either chain.
- CVE-2026-78159 — unauthenticated code injection (CVSS 9.8, source-reported). Insufficient input validation allows an attacker to inject a plain-array payload that bypasses the plugin's checks. The payload executes during processing of single-event HTML, including the comment area. No authentication and no comment approval are required.
- CVE-2026-78006 — unauthenticated PHP object injection (CVSS 9.8, source-reported). Insufficient protections in a plugin function can be bypassed by a commenter without authentication or approval. The injected code is delivered to the vulnerable function before moderation occurs, so the moderation queue is not a control.
- Execution — both chains are independent of one another but both terminate in remote code execution and, per Defiant, the complete compromise of the WordPress installation.
Post-exploitation: the source provides no detail on payloads, web shells, persistence mechanisms, privilege escalation, command-and-control, lateral movement or data access following successful RCE. We do not speculate on these. Assume full control of the web application context (and therefore of any database credentials, WordPress salts and filesystem content reachable by the web user) is available to a successful attacker, and scope compromise assessment accordingly.
Population discrepancy. The headline figure is "200,000+ WordPress sites"; the body cites approximately 240,000 sites on versions prior to 6.17. The 240,000 figure is the more specific of the two and is the one to plan against.
Confidence caveat. All technical detail above rests on a single source — Defiant's research as reported by SecurityWeek. The CVSS 9.8 scores are the source's, not verified against NVD or any authoritative reference data in our possession. No exploitation in the wild is reported in the source material, and no CISA KEV listing is available to us. Verify version and severity claims against the vendor's own advisory before making enforcement decisions.
4. Mitigation & containment
P1 — within 24 hours
- Inventory every WordPress installation in the estate and determine the installed version of The Events Calendar. Prioritise internet-facing sites, marketing/IR/event microsites, and any WordPress instance outside central patch management.
- Update The Events Calendar to 6.17.4.1 or later. This is the only action that closes both CVE-2026-78159 and CVE-2026-78006. Updating only to 6.17.3.1 leaves CVE-2026-78006 open.
- Where patching cannot be completed inside 24 hours, apply one of the following compensating controls, in order of preference:
- Disable the plugin on sites that do not need it live.
- Disable comments on events (and remove comment visibility on event pages). The source states both exploitation chains require comments to be enabled, so this breaks the attack path for both.
- Deploy a WAF rule blocking unauthenticated HTTP POST requests to event comment submission endpoints on affected hosts, and alert on such requests rather than silently dropping them — they are a useful detection signal.
P2 — within 72 hours
- Compromise assessment on any site that ran an affected version with event comments enabled: review for unexpected administrator accounts, modified or newly created PHP files in the WordPress installation, unexpected scheduled tasks, and anomalous outbound connections from the web host.
- Review web server, WAF and reverse-proxy logs for unauthenticated POSTs to event comment endpoints, particularly any followed by requests to unusual PHP paths.
- If compromise is suspected or confirmed, rotate WordPress administrative credentials and the authentication salts/keys in
wp-config.php, and treat any secrets reachable by the web application (database credentials, API keys in plugin configuration) as disclosed. - Confirm that WordPress automatic background updates are actually functioning on the affected estate — the download telemetry cited in the source suggests a large share of installations did not pick up the fix.
P3 — within 7 days
- Add The Events Calendar to the third-party component inventory with an owner and a patch SLA, and extend the same treatment to other WordPress plugins in production use.
- Restrict plugin installation and update privileges to a small administrative group; remove filesystem write access for the web user where the platform allows it.
- Test the update on staging before broad rollout if the plugin is customised, and monitor the vendor's release channel for follow-on fixes to the same component.
5. Indicators of compromise
No indicators of compromise available in the source material. The source provides no hashes, domains, IP addresses, file paths, registry keys or command lines.
The source does describe the exploitation preconditions rather than observed activity, so the following behavioural indicators are derived from the described attack path and are low confidence — they are hunting hypotheses, not confirmed telemetry. They are single-sourced to the same Defiant/SecurityWeek reporting.
Behavioural indicators
| behaviour | where to observe | confidence |
|---|---|---|
| Unauthenticated HTTP POST to event comment submission endpoints on hosts running The Events Calendar < 6.17.4.1 | web server access logs, WAF logs, reverse-proxy logs | low — derived from the described exploitation precondition, not from observed telemetry |
| Comment payloads reaching plugin processing logic before moderation, i.e. execution activity associated with comment submission rather than comment approval | PHP error logs, application performance monitoring, plugin-level logging | low — derived from the described attack path |
| Unexpected administrator accounts or file modifications on WordPress installations running affected versions | WordPress audit logging, filesystem integrity monitoring | low — generic post-RCE hypothesis, not sourced |
6. Detection
Insufficient indicators to author detection rules.
7. Sources
- SecurityWeek — "Unauthenticated RCE Flaws Could Expose 200,000+ WordPress Sites to Takeover" — https://www.securityweek.com/unauthenticated-rce-flaws-could-expose-200000-wordpress-sites-to-takeover/ — published 2026-09-16. (Primary and only substantive source; reports research by Defiant. No URL for the underlying Defiant research was supplied with this item.)
8. Adverse Trace position
We assess this as a high-severity, narrowly-conditioned exposure rather than a broad emergency. The CVSS 9.8 ratings are the reporting researcher's and are unverified against our reference data; no CISA KEV status is available to us and the source reports no exploitation in the wild. The compensating factor is real: both chains require event comments to be enabled and visible, so estates that have comments disabled are not exposed regardless of plugin version. The aggravating factor is equally real — a large share of the 600,000+ installations appear not to have taken the fix, and WordPress estates in financial services frequently sit outside central patch governance on marketing and event microsites, which is exactly where this plugin is deployed. Client impact is therefore concentrated, not universal: full site takeover of a public-facing microsite, with the attendant brand, phishing and credential-reuse risk. All technical detail here is single-sourced to Defiant via SecurityWeek — verify plugin versions and severity against the vendor advisory before enforcement. We will monitor for a vendor advisory, for any CISA KEV listing, and for exploitation reporting; if either CVE is listed or exploitation is observed, we will reissue at a higher priority with revised guidance.
Published via PulseTrace — Adverse Trace threat intelligence.