Wordfence’s Mu-Plugin Discovery Turns a Blockchain Into a Takedown-Resistant Command Post

The Wordfence Threat Intelligence Team found a WordPress backdoor in mid-June 2026 that treats getting removed as a temporary setback rather than a failure state. The malware, uncovered during a routine site cleanup and detailed in a post published this month, installs itself as a must-use plugin disguised as an automated health-check tool, rewrites itself from a database backup if its file is deleted, and reaches its command servers through an Ethereum smart contract instead of a domain name that a registrar or hosting provider could seize. None of those three tricks is new by itself. Seeing all three built into the same sample is what makes it worth a closer look: it suggests attackers targeting WordPress at scale are combining previously separate evasion techniques into a single package that is meaningfully harder to fully clean out.

A Health-Check Tool That Was Never Real

Must-use plugins, or mu-plugins, are a lesser-known corner of WordPress. Files dropped into wp-content/mu-plugins load automatically on every page request and, according to WordPress’s own documentation, cannot be disabled except by removing the file itself. They do not show up in the main Plugins list (WordPress tucks them into a separate Must-Use section instead), they generate no update notifications, and their activation hooks never fire, which is exactly the kind of quiet corner an attacker wants for a plugin nobody expects to click on.

Wordfence’s sample leaned into that obscurity by posing as a legitimate one: an automated health-check and reporting tool, complete with a fabricated author name and a link to a code repository. Across the team’s detections, the malware turned up under more than 4,000 distinct filenames, most often appearing as familiar WordPress artifacts like the advanced-cache.php and db.php drop-ins, or a theme’s own functions.php. The plugin metadata (name, author, repository link) varied between samples too, which Wordfence notes makes both the metadata and file hashes unreliable indicators on their own.

The code itself skips the obvious tells. Rather than the familiar eval(base64_decode()) pattern most static scanners flag on sight, the malware hides its WordPress API arguments (hook names, option keys, file paths, even fragments of SQL) behind a custom substitution cipher and decodes each value only at the moment it is used.

Abuse of the mu-plugins directory itself is not new either. Security researchers at Sucuri documented a similar case in July 2025, noting they had already seen “a similar trend with hidden malware in this very directory” back in March of that year. What is new in the Wordfence sample is not the hiding place. It is everything built on top of it.

Losing One Piece Doesn’t Lose the Infection

“The malware layers several persistence mechanisms, so removing one component does not necessarily remove the infection,” Wordfence writes, and the sample backs that up structurally.

Access starts with a fabricated administrator account, created through WordPress’s own wp_insert_user() function and immediately hidden from the people who would otherwise notice it. The malware hooks three separate WordPress filters (pre_user_query, rest_user_query, and views_users) to strip that account out of the admin user list, the REST API’s user endpoint, and even the per-role counts displayed above the Users table, decrementing them by one so the totals still add up. A separate hook on WordPress’s own authenticate filter, which runs during the login process, harvests the plaintext username and password of any administrator who successfully signs in, whether or not that account is the one the malware created itself.

Removal is where the layering shows most clearly. If the plugin file is deleted, a self-healing routine restores it: the malware keeps a copy of its own source in a WordPress database option, writes that copy back to disk, chmods the file to read-only, and backdates the modification timestamp so a routine file-integrity scan sees nothing unusual. For copies that land in the ordinary wp-content/plugins directory rather than mu-plugins, a fallback the malware uses when it cannot write to the mu-plugins folder, it goes further: it writes its own entry directly into WordPress’s active_plugins database option, reading the site’s database name and table prefix straight out of wp-config.php to do it, switching itself back on without ever touching WordPress’s normal activation screen. On hosts running more than one WordPress install on the same filesystem, the malware also checks a hardcoded list of server paths, at most once every three days, and copies itself into any site it can reach.

A Smart Contract as the Backdoor’s Phone Book

The most distinctive piece is how the malware finds out where to send stolen data. Instead of a hardcoded domain or IP address that a hosting provider or registrar could take down, the backdoor queries an Ethereum smart contract: it picks one of three hardcoded contract addresses and one of twenty-one public RPC gateways at random, then sends a standard read-only eth_call, the same kind of request any legitimate blockchain application makes to read a contract’s stored data. The decrypted response hands back the current list of command-and-control server addresses along with the encryption key used to talk to them. “The blockchain’s role is only to point the malware to its current servers,” Wordfence explains. “This is what makes the channel resilient. The servers can be taken down and replaced, and the attacker simply updates the contract, so the next time the malware runs, it receives the new list.”

This general technique, commonly called EtherHiding, is not new, but this particular use of it is a meaningful variant on what has previously been documented. Google’s Threat Intelligence Group traces EtherHiding to September 2023, when the financially motivated group UNC5142 built it into a campaign, called CLEARFAKE, that compromises WordPress sites specifically. As of June 2025, GTIG had identified roughly 14,000 web pages carrying UNC5142’s injected code, which fetches an infostealer payload from a smart contract on the BNB Smart Chain, not Ethereum, to serve fake browser-update overlays to site visitors; GTIG has not observed that campaign active since late July 2025. Separately, GTIG reported in October 2025 that North Korea’s UNC5342 had folded EtherHiding into an unrelated social-engineering campaign starting in February 2025, the first time the firm had observed a nation-state actor adopt the technique.

The Wordfence sample does not match either of those campaigns. It runs on Ethereum’s main chain rather than BNB Smart Chain, and it uses the contract to route the backdoor’s own outbound traffic rather than to deliver a payload into a site visitor’s browser. What it shares with both prior cases is the underlying premise GTIG laid out when describing UNC5142’s infrastructure: “Network based protection mechanisms are more difficult to implement for Web3 traffic compared to traditional web traffic given the lack of use of traditional URLs. Seizure and takedown operations are also hindered given the immutability of the blockchain.” A technique that needed a criminal group’s dedicated infrastructure in 2023, and that a nation-state adopted for a targeted campaign in 2025, is now showing up adapted inside commodity WordPress malware that Wordfence found during ordinary incident-response work.

What the Access Is Actually For

Once a command server responds, the backdoor’s next move is decided by four keys in the reply, and the attacker can change any of them at any time without touching the compromised site directly. One key delivers a base64-encoded PHP payload, validated only by checking that it starts with <?php and is at least 500 bytes long, which the malware writes over its own file to update itself. A second key deactivates and deletes other plugins outright. A third supplies regex rules that the malware applies across the files of every currently active plugin, stripping out matching text with preg_replace(). A fourth delivers raw JavaScript, hooked to wp_footer at priority 999, that gets echoed straight into every visitor’s browser.

Wordfence is careful to frame this as a capability list rather than a confirmed set of actions on any given site: “The code shows what the malware is capable of, not what it has been instructed to do.” What the malware’s own data-exfiltration report is built to carry back is more concrete: Wordfence’s write-up names site payment credentials, customer order data, and full administrator access as the kind of haul a single encrypted upload can contain.

Detection and Response

Wordfence built a detection signature for this sample and released it, after the company’s internal review process, on June 23, 2026. Wordfence Premium, Care, and Response customers received it immediately; users of the free version received the same signature after the standard 30-day delay built into that tier. The company says its plugin scanner now catches more than 99 percent of samples and indicators of compromise in its threat-intelligence database when running the premium signature set, a database that has grown past 4.4 million unique malicious samples.

For site owners checking their own installs, Wordfence’s indicators of compromise center on four things: a must-use plugin file whose author name, plugin name, or linked repository does not correspond to anything real; an administrator account nobody recalls creating; unfamiliar options sitting in the WordPress database; and custom cron schedules that were not set up intentionally. Because file hashes and plugin metadata both vary between samples, none of those checks work well in isolation, which is itself the clearest signature of what this malware family was built to do: defeat the fast, superficial version of a security review.