01 · The Real Story
Like handing every website visitor a server console disguised as a comment form
CVE-2026-78159 is a code-injection flaw in The Events Calendar WordPress plugin (all versions through 6.17.3, fixed in 6.17.3.1). The bug lives in Element_Classes::parse_array(), which processes widget CSS class maps. The function's safety check, is_safe_widget_instance(), only rejects PHP *objects* — it happily accepts plain arrays. An attacker submits a crafted comment containing a wp:legacy-widget block with array entries whose values are PHP callables. When WordPress renders the event page — including via the unapproved-comment moderation-preview URL the commenter gets back immediately — do_blocks() hands the malicious block to the plugin's widget pipeline. parse_array() walks the array, hits the callable values, and invokes them via call_user_func. The documented end-state is a wp_update_user() call that resets the admin password, giving the attacker full site control. Over 600,000 WordPress sites run this plugin.
StellarWP and Wordfence rate this CRITICAL 9.8, and the CVSS vector (AV:N/AC:L/PR:N/UI:N) is technically accurate — the chain is unauthenticated and requires no user interaction since the attacker triggers their own moderation-preview URL. However, the vendor score assumes every install is reachable. In practice, The Events Calendar's *Show comments on event pages* setting must be explicitly enabled for the vulnerable rendering path to execute. This is not the plugin's default behavior. That single configuration gate meaningfully narrows the exploitable population, though it does not eliminate risk — event-centric sites frequently enable comments. The existence of multiple public PoCs (including a mass-exploit scanner) and the 600K+ install base push this firmly into HIGH territory, but the configuration prerequisite makes a blanket 9.8 CRITICAL misleading for prioritization.
"Public PoC turns any event comment box into unauthenticated RCE, but the comments-on-events gate pulls this to HIGH."
02 · The Attack Path
5 steps from start to impact.
STEP 01
Fingerprint target and locate event posts
The attacker scans for WordPress sites running The Events Calendar, identifiable via
/wp-content/plugins/the-events-calendar/ assets, tribe_events REST API endpoints, or the tribe-events CSS class. The mass-exploit tool tec.py from the antid00t repo automates discovery using async scanning with up to 50 threads. The attacker enumerates published events via /wp-json/tribe/events/v1/events and checks whether comments are open on any event post.Conditions required:
- Target runs WordPress with The Events Calendar <= 6.17.3
- At least one published event exists on the site
Where this breaks in practice:
- Plugin fingerprinting can be blocked by removing version strings and restricting REST API access
Detection/coverage: WAF rules detecting tribe_events REST enumeration; WPScan or Wordfence vulnerability scanner flags outdated plugin version.
STEP 02
Confirm comments are enabled on event pages
The attacker checks whether the target has the Show comments on event pages setting enabled by visiting an event page and looking for the comment form. If the comment form is absent, this attack chain is dead. This is the primary friction gate — The Events Calendar does not enable event comments by default, so many installations are not exploitable.
Conditions required:
- Show comments on event pages is enabled in plugin settings
Where this breaks in practice:
- Default configuration has comments on events disabled — site admin must have opted in
- Some sites use third-party comment systems (Disqus, etc.) that bypass wp-comments-post.php entirely
STEP 03
Submit malicious comment with wp:legacy-widget payload
The attacker POSTs to
/wp-comments-post.php with a comment body containing a Gutenberg wp:legacy-widget block. The block's instance attribute carries a plain PHP array (not an object) with the idBase set to tribe-widget-events-list. Array values are set to PHP callable references — the documented payload targets wp_update_user to reset the admin password. The abraxas/CVE-2026-78159 PoC and the antid00t mass exploit tool both automate this step. The comment enters the moderation queue and WordPress returns the moderation-hash preview URL to the attacker.Conditions required:
- Comment form accessible and accepts POST
- WordPress returns moderation-hash preview URL in response
Where this breaks in practice:
- Anti-spam plugins (Akismet, CleanTalk) may reject or quarantine the comment before it reaches moderation
- Some WAFs detect wp:legacy-widget patterns in comment bodies
Detection/coverage: Wordfence firewall rule (premium since Aug 22, free since Sep 21); WAF signatures matching wp:legacy-widget in POST body to wp-comments-post.php.
STEP 04
Trigger moderation-preview rendering to fire the callable chain
The attacker visits the moderation-preview URL returned in step 3. WordPress renders the event page with the pending comment included. The plugin's V2 single-event template buffers the page HTML and passes it through
do_blocks(), which processes the malicious wp:legacy-widget block. The plugin's widget pipeline calls Element_Classes::parse_array(), which iterates the array entries, identifies callable values, and executes them via call_user_func. This fires the wp_update_user() call with attacker-controlled parameters, resetting the admin account password.Conditions required:
- Moderation-preview URL renders the pending comment through do_blocks()
- Element_Classes::parse_array() reached via widget pipeline
Where this breaks in practice:
- If the site uses a Full Site Editing block theme instead of a classic theme, the rendering pipeline may differ
Detection/coverage: Server-side log analysis: GET requests to moderation-preview URLs immediately following POST to wp-comments-post.php from the same IP; PHP error logs may show unexpected call_user_func invocations.
STEP 05
Admin login and full site takeover
With the admin password reset, the attacker logs in to wp-admin and achieves full site control. From here the typical WordPress post-exploitation playbook applies: upload a malicious plugin or theme containing a web shell, modify existing PHP files, exfiltrate the database including user credentials and PII, or pivot to other services on the same host. The antid00t tool offers optional destructive modes including PHP file upload and credential harvesting.
Conditions required:
- Admin password successfully reset in step 4
Where this breaks in practice:
- Two-factor authentication on admin accounts blocks login even with a reset password
- WordPress admin panel IP allowlisting prevents attacker access
Detection/coverage: WordPress login audit logs (Wordfence, Sucuri, WP Activity Log) flag password resets and new admin logins; file integrity monitoring detects new or modified PHP files.
03 · Compensating Control
1
HIGH 8.1→IGNORE 0.0
SEVERITY REDUCEDDisable comments on event pages immediately — Navigate to Events > Settings > General and uncheck *Show comments on event pages*, or run
wp option update tribe_events_show_comments 0 via WP-CLI. This eliminates the prerequisite for the entire attack chain — no comment rendering means no do_blocks() processing of malicious widget blocks. This is a zero-risk change that can be deployed today. Per the noisgate mitigation SLA for HIGH severity, deploy within 30 days — but given public PoC availability, same-day deployment is strongly recommended.2
HIGH 8.1→IGNORE 0.0
SEVERITY REDUCEDUpdate to The Events Calendar 6.17.4.1 — This is the definitive fix that closes both CVE-2026-78159 and the companion CVE-2026-78006. Test in staging and deploy to production. Per the noisgate remediation SLA for HIGH severity, complete within 180 days. Given the weaponized PoC landscape, push this into your next maintenance window rather than waiting the full SLA.
3
HIGH 8.1→LOW 2.5
SEVERITY REDUCEDDeploy WAF rule blocking wp:legacy-widget in comment bodies — Add a WAF rule (ModSecurity, Cloudflare, Sucuri, or equivalent) that blocks POST requests to
/wp-comments-post.php containing wp:legacy-widget in the comment field. Wordfence premium users already have this rule since Aug 22; free users since Sep 21. For non-Wordfence setups, create a custom rule. This breaks step 3 of the attack chain by preventing the malicious payload from entering the moderation queue. Deploy within the 30-day mitigation SLA.4
HIGH 8.1→MEDIUM 6.0
SEVERITY REDUCEDEnable two-factor authentication on all WordPress admin accounts — Even if the attacker resets the admin password via the callable chain, 2FA prevents login to wp-admin. This blocks the documented post-exploitation path but does NOT prevent the
call_user_func execution itself — if the attacker pivots the callable to a different sink (e.g., direct system() instead of wp_update_user()), 2FA is irrelevant. Treat as defense-in-depth, not a standalone mitigation. Deploy within 30 days.What doesn't work
- IP-based rate limiting on wp-comments-post.php — the exploit requires only a single POST and a single GET request. Rate limiting at typical thresholds will not prevent a one-shot exploit.
- WordPress comment moderation approval workflow — the vulnerability fires on the *moderation-preview* URL, which renders the pending comment before any moderator approves it. Requiring manual approval does NOT prevent exploitation.
- Disabling Gutenberg/Block Editor for posts —
do_blocks()runs on all rendered content regardless of whether the Block Editor is the active editor. The malicious block in the comment is processed by the rendering engine, not the editing interface. - CAPTCHA on the comment form — while it reduces spam, the exploit can be scripted to solve common CAPTCHAs or use CAPTCHA-solving services. It adds friction but is not a reliable control against a targeted attacker.
04 · Intelligence Metadata
The supporting signals.
| In-the-Wild Status | No confirmed active exploitation as of 2026-10-08. Not listed on CISA KEV. No GreyNoise or Shadowserver tags observed. However, the public availability of a mass-exploit scanner (antid00t/tec.py) with async 50-thread scanning significantly lowers the bar — opportunistic exploitation is a near-term expectation. |
|---|---|
| Proof-of-Concept | Two public repositories: abraxas/CVE-2026-78159 by @abraxas_null (single-target Python PoC with Docker lab environment, 5 commits) and antid00t/CVE-2026-78006-CVE-2026-78159 (mass-exploit scanner covering both CVEs, asyncio/aiohttp engine, WAF bypass via Unicode escapes, 21 commits). Also indexed on Sploitus. No Metasploit module or nuclei template confirmed. |
| EPSS | 0.01394 (1.39%) — moderate exploitation probability. Given the publication of weaponized mass-exploit tooling, EPSS is likely lagging real-world risk. Expect upward movement in coming weeks. |
| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — network-accessible, low complexity, no privileges, no user interaction. Technically accurate for the happy path but does not encode the comments-on-events configuration prerequisite that gates real-world exploitability. |
| Affected Versions | All versions from 0.x through 6.17.3 — the entire release history of The Events Calendar prior to the fix. |
| Fixed Versions | 6.17.3.1 fixes CVE-2026-78159 specifically. 6.17.4.1 fixes both CVE-2026-78159 and companion CVE-2026-78006 (PHP object injection). Target upgrade: 6.17.4.1. |
| Install Base | WordPress.org reports 600,000+ active installations (some sources cite 800,000+). The most popular event-management plugin in the WordPress ecosystem. All installs are internet-facing by definition. |
| Disclosure Timeline | Aug 21: Wordfence reports to StellarWP. Aug 22: Premium firewall rule deployed. Aug 24: StellarWP acknowledges. Sep 10: Patch 6.17.4.1 released. Sep 12-14: Public disclosure. Sep 21: Free Wordfence firewall rule. |
| Discoverer | Wordfence Argus AI — an automated vulnerability research agent. Both CVE-2026-78159 and companion CVE-2026-78006 were found by the same automated analysis of The Events Calendar's comment-rendering pipeline. |
| Companion Vulnerability | CVE-2026-78006 (CVSS 9.8) — PHP object injection variant using the same comment-to-do_blocks pipeline but via unserialize() triggering Lazy_Post_Collection::__unserialize() then array_map('system', $cmds). Same prerequisites, same fix version. Treat both together. |
Sources.
05 · The Call
Final Verdict
↓ DOWNGRADED to HIGH (8.1/10)
Why this verdict
- Configuration gate narrows exploitable population. The Events Calendar does not enable comments on event pages by default. The *Show comments on event pages* setting must be explicitly turned on by the site administrator. This is a hard prerequisite — without it, the entire attack chain is inert. While event-centric sites commonly enable this, estimated 30-50% of installs have event comments active, narrowing the exploitable base from 600K+ to roughly 180K-300K sites. This is a meaningful reduction that the CVSS 9.8 does not reflect.
- Fully unauthenticated with public weaponization keeps severity in HIGH, not MEDIUM. When the configuration gate is met, the chain is two HTTP requests with zero authentication. Multiple public PoC repos exist, including a mass-exploit scanner with WAF bypass capabilities. This is not theoretical — it is script-kiddie-ready. The 1.39% EPSS is likely to climb as scanning tools proliferate.
- Role multiplier: WordPress web application tier (no high-value-role floor). The Events Calendar is a WordPress plugin deployed on public-facing websites. It is NOT a high-value-role component — not identity infrastructure, not a hypervisor, not PKI, PAM, CI/CD, backup, kernel-mode agent, or network edge. Blast radius is capped at individual WordPress site takeover: one database, one web root, potentially the underlying host if the web server runs privileged. For enterprises running WordPress as a marketing CMS, this is a (b) line-of-business or (a) low-value tier. No floor override applies.
- No active exploitation or KEV listing. As of October 2026, no confirmed in-the-wild exploitation, no CISA KEV entry, and no GreyNoise mass-scanning tags. The mass-exploit tooling makes this a ticking clock, but absent confirmed campaigns today, the evidence supports HIGH rather than CRITICAL.
- Anti-spam and WAF controls provide pre-exploit friction. Akismet (active on roughly 30% of WordPress sites), Wordfence firewall rules (deployed Aug 22 for premium, Sep 21 for free), and generic WAFs can intercept the malicious comment before it enters the rendering pipeline. These are widely deployed baseline controls in the WordPress ecosystem, compounding friction beyond the configuration gate alone.
Why not higher?
CRITICAL would require either a high-value-role floor override (this plugin is a web CMS addon, not infrastructure) or a frictionless chain across the full install base. The comments-on-events configuration prerequisite is a real gate that excludes a meaningful fraction of installations. The blast radius is capped at individual site takeover — not domain, fleet, or supply-chain compromise. No active exploitation is confirmed, and widely-deployed WordPress security tooling (Wordfence, Akismet) provides layered pre-exploit friction.
Why not lower?
MEDIUM would dangerously understate the risk for sites that DO have event comments enabled. On those installations, this is a zero-click, unauthenticated, two-request RCE with public mass-exploit tooling and WAF bypass capabilities. The 600K+ install base means even a conservative 30% exploitable fraction represents approximately 180,000 internet-facing targets with near-zero barrier to entry. The weaponization is complete and the PoC quality is high.
06 · Verification
Crowdsourced verification payload.
Run this script on each WordPress host as any user with read access to the wp-content directory. Invoke with: bash cve-2026-78159-check.sh /var/www/html (pass your WordPress root as the first argument; defaults to /var/www/html). No root privileges required. Outputs VULNERABLE, PATCHED, or UNKNOWN with exit codes 1, 0, 2 respectively. If wp-cli is available, it also checks whether event comments are enabled.
#!/bin/bash
# CVE-2026-78159 - The Events Calendar < 6.17.3.1 RCE check
# Usage: bash cve-2026-78159-check.sh [/path/to/wordpress]
# Exit: 0=PATCHED 1=VULNERABLE 2=UNKNOWN
WP="${1:-/var/www/html}"
F="$WP/wp-content/plugins/the-events-calendar/the-events-calendar.php"
if [ ! -f "$F" ]; then
echo "UNKNOWN - The Events Calendar plugin not found at $F"
exit 2
fi
# Extract version from plugin file header
V=$(sed -n 's/^[[:space:]]*[*]*[[:space:]]*Version:[[:space:]]*//Ip' "$F" | head -1 | tr -cd '0-9.')
if [ -z "$V" ]; then
echo "UNKNOWN - could not parse plugin version from $F"
exit 2
fi
FIX="6.17.3.1"
# Version comparison using sort -V (coreutils 7+)
LOW=$(printf '%s\n%s' "$V" "$FIX" | sort -V | head -1)
if [ "$LOW" = "$V" ] && [ "$V" != "$FIX" ]; then
echo "VULNERABLE - The Events Calendar v${V} (fixed in ${FIX}+)"
# Best-effort check for comments-on-events setting via wp-cli
if command -v wp > /dev/null 2>&1; then
CS=$(wp option get tribe_events_show_comments --path="$WP" --quiet 2>/dev/null || true)
if [ "$CS" = "1" ] || [ "$CS" = "yes" ]; then
echo " EXPOSURE: Event comments ENABLED - exploit path is OPEN"
elif [ -n "$CS" ]; then
echo " EXPOSURE: Event comments appear DISABLED - exploit path likely blocked"
fi
else
echo " NOTE: wp-cli not found - manually verify Show comments on event pages setting"
fi
exit 1
else
echo "PATCHED - The Events Calendar v${V}"
exit 0
fi