Security researchers at Sucuri have documented a particularly resilient WordPress malware family they call SC, named after markers found in the injected code. What makes the infection unusual is not simply that it installs a backdoor, but that it distributes the same backdoor across multiple persistence layers so that surviving components can rebuild the ones defenders remove. Sucuri says the payload exists in at least eight places across files, the WordPress database and System V shared memory, creating a circular recovery mechanism with no obvious single file that can be deleted to end the infection.

The persistence design is the most important part of the campaign. A conventional WordPress compromise often leaves behind one malicious plugin, a modified theme file or a PHP web shell. In this case, the different components actively monitor and restore one another. If the malicious plugin disappears, a WordPress drop-in can recreate it. If the drop-in is removed, an injected theme can restore it. If every obvious malicious file on disk is deleted, the next request can recover the payload from the database or shared-memory segment and write the entire infection back to disk.

The basic recovery model can be summarized as: file copy removed → surviving drop-in or theme detects absence → payload recovered from another location → malicious plugin rewritten → remaining persistence components recreated. If defenders clean only the filesystem, the database or RAM copy may survive. If they clean only the database, the files can repopulate it. If they remove visible plugins from the WordPress dashboard, the must-use plugin and drop-ins can continue loading invisibly. The malware is therefore best understood as a persistence system rather than a malicious file.

One of the earliest execution mechanisms is a .user.ini file containing an auto_prepend_file directive. PHP processes this directive before executing normal application code, which means the malware can run even on requests that never fully reach WordPress. The directive points to a loader, which in turn includes a hidden dot-prefixed PHP file. This hidden loader can rebuild the malware in the mu-plugins directory from several alternative sources, including another plugin copy, an encoded cache stub or a ZIP restore bundle hidden elsewhere on the site.

This use of auto_prepend_file is particularly effective because it sits below the ordinary WordPress plugin lifecycle. An administrator can disable every visible plugin and still have malicious PHP executed before WordPress starts. It also creates a cleanup trap because PHP caches the configuration value. Sucuri warns that deleting the target file before neutralizing the prepend configuration can temporarily break every PHP request on the account until the cached configuration expires. That detail alone demonstrates why ordinary “delete the infected files” remediation can make matters worse when the infection spans multiple execution layers.

The malware also abuses two special WordPress files, wp-content/db.php and wp-content/advanced-cache.php. These are known as drop-ins and are loaded very early during the WordPress bootstrap process. The malicious db.php contains a compressed and Base64-encoded copy of the full backdoor and rewrites the plugin whenever it detects that the malicious copy is missing or unexpectedly small. The advanced-cache.php component is even more flexible: it can recover the backdoor from five different sources, including the must-use plugin, the normal plugin directory, System V shared memory, a ZIP bundle and the WordPress database.

The active theme provides another recovery route. Sucuri found malicious code appended to the theme’s functions.php, effectively creating a theme-resident twin of the db.php persistence logic. Since the active theme executes during ordinary page requests, the attacker gains yet another opportunity to notice when the main payload has disappeared and write it back. The infection therefore does not rely on one WordPress extension point; it abuses configuration, drop-ins, themes, must-use plugins and ordinary plugins simultaneously.

The actual backdoor is installed in two locations: once as a must-use plugin and again as a conventional plugin. The must-use copy is especially useful to attackers because WordPress automatically loads files in wp-content/mu-plugins without requiring normal plugin activation. These plugins are also less visible to casual administrators and cannot simply be disabled through the normal Plugins interface. Sucuri says the malware additionally filters WordPress administrative views and update checks to hide itself, making a dashboard-only review unreliable.

The backdoor has substantial remote-control capability. It can fingerprint the infected site, collect WordPress and plugin versions, enumerate active themes and must-use plugins, gather administrator session tokens, fetch additional PHP payloads, inject arbitrary JavaScript into visitor pages, disable or remove security plugins and create a hidden administrator account. On e-commerce sites, arbitrary JavaScript injection could be used to deploy payment-card skimmers or redirect visitors to malicious content.

The hidden administrator capability is particularly serious because the malware can manipulate the WordPress database directly rather than relying solely on normal WordPress APIs. It can create or adopt a privileged account, assign administrator capabilities and then hide that account from user listings and administrative counts. Sucuri says the malware can also forge valid authentication cookies for the hidden account, allowing the operator to regain administrative access without knowing a conventional password.

The command-and-control mechanism adds another layer of resilience. Instead of relying on one fixed C2 domain, the malware can query public Ethereum RPC gateways and use blockchain smart-contract data to resolve instructions or infrastructure. Sucuri found roughly twenty public gateways configured as potential communication paths. Because these gateways are legitimate third-party services used by normal blockchain applications, blocking one hostname does little if the malware simply switches to another.

This is an increasingly useful attacker technique. Legitimate infrastructure provides both availability and reputation. The attacker no longer needs to keep one obviously malicious command server alive. Public blockchain infrastructure effectively becomes a distributed rendezvous mechanism. The maliciousness is not in Ethereum itself, obviously, because apparently even malware developers have discovered the joy of outsourced infrastructure. The problem is the way the malware uses legitimate RPC services to conceal and decentralize command delivery.

The shared-memory persistence is perhaps the most technically interesting part of the design. On systems supporting System V shared memory, the malware writes a PHP payload into a memory segment identified by a fixed numeric key. That copy resides in RAM rather than the filesystem or database. As a result, an administrator can completely clean the WordPress directory and database and still have the site reinfected if the shared-memory segment remains available to another persistence component.

Shared hosting makes the problem even more awkward. Sucuri notes that a shared-memory segment can potentially be owned by another account on the same server, meaning the compromised account may not even have permission to remove the persistence mechanism directly. In that situation, the hosting provider may need to intervene. Once the drop-ins capable of reading the segment are removed, the orphaned shared-memory payload becomes much less useful, but leaving it unnoticed during cleanup creates another path for reinfection.

The malware also uses scheduled execution. It registers WordPress cron hooks, including randomized task names alongside known fetch-related hooks, while system cron can trigger wp-cron.php even when there is no visitor traffic. That means taking the website temporarily out of public circulation may not be enough to stop reinfection. Scheduled execution can restore malware independently of normal user requests.

Sucuri additionally observed database-trigger techniques in related SC variants. A malicious database trigger can recreate an administrator account whenever certain database actions occur. This persistence survives a complete filesystem restore because the malicious logic is stored inside the database server itself. Administrators can therefore delete a rogue WordPress account repeatedly and watch it mysteriously reappear until the underlying trigger is found and removed.

The cleanup order is therefore critical. Sucuri recommends first neutralizing the PHP prepend mechanism without immediately deleting its target, then removing the off-disk payload copies from the database and shared memory, clearing scheduled tasks and malicious database triggers, removing hidden administrator access and only then cleaning the files in one coordinated pass. If defenders begin by deleting visible files, the surviving components may simply recreate them before the cleanup is complete.

A proper remediation sequence should conceptually look like: stop automatic execution → remove database payload → purge shared-memory segment → remove cron jobs and database triggers → remove hidden administrator → delete loaders and duplicate plugins → clean injected theme code and drop-ins → rescan → monitor for regeneration → close the original entry point → rotate credentials and secrets.

That last step is important because eliminating persistence does not explain how the site was compromised initially. Sucuri says the original infection vector in the analyzed case remains unknown. Typical WordPress intrusion paths include vulnerable plugins or themes, weak administrative credentials, supply-chain compromise and insecure upload mechanisms, but none of those has been established as the cause of this particular SC infection.

That uncertainty means cleanup is not complete until defenders identify and close the original entry path. Otherwise the site can be perfectly cleaned and then compromised again through the same vulnerability or stolen credential. A recurring infection does not necessarily prove the self-healing malware survived; it could also mean the attacker simply regained access. Incident responders therefore need to distinguish persistence-driven reinfection from fresh exploitation.

The malware also demonstrates why WordPress administrators should not rely only on ordinary file-integrity checks. Filesystem monitoring may detect malicious changes, but it will not necessarily reveal an encoded payload hidden in wp_options, PHP code stored in shared memory, a malicious database trigger or a concealed administrator whose account is filtered out of the dashboard. WordPress incident response increasingly requires visibility across the application, database, PHP runtime, operating system and hosting environment.

Organizations should also look specifically for abnormal outbound connections from PHP or web-server processes to public Ethereum RPC endpoints. Those services may be perfectly legitimate elsewhere in the organization, but a WordPress site with no blockchain functionality repeatedly querying Ethereum RPC gateways deserves investigation. The same contextual logic applies to System V shared-memory use. PHP applications rarely need to store executable PHP payloads in shared-memory segments, so such behavior can be a strong indicator even when the exact malware signature changes.

Indicators described by Sucuri include unexpected code in wp-content/db.php or wp-content/advanced-cache.php, suspicious blocks appended to an active theme’s functions.php, auto_prepend_file directives in .user.ini, php.ini or .htaccess, duplicate plugin copies under both mu-plugins and plugins, randomly named ZIP bundles, large compressed Base64 blobs in WordPress options, unexpected shared-memory segments containing PHP, hidden privileged users and outbound Ethereum RPC traffic. File names may differ between infections, so defenders should prioritize behavior and structure over literal filenames.

One especially useful signal is the presence of the same unfamiliar plugin code in both the normal plugin directory and the must-use plugin directory. Ordinary plugins rarely need to maintain cloned copies in both locations, and a component that continually rewrites one copy from the other should immediately raise suspicion. Likewise, an unexplained auto_prepend_file pointing into wp-content is difficult to justify in most standard WordPress deployments.

The incident also highlights the value of immutable backups, but only if restoration includes more than website files. Restoring wp-content from a clean backup while preserving the compromised database can immediately recreate the malware. Restoring the database while leaving contaminated shared memory can produce the same result. Even replacing the entire WordPress directory may fail if malicious PHP configuration outside the web root continues prepending the loader.

A true clean restore may therefore require recreating the runtime environment itself, especially when incident responders cannot confidently enumerate every persistence mechanism. In high-risk cases, rebuilding the site or hosting account from a known-good baseline may be safer than attempting endless surgical cleanup against a malware family designed specifically to survive partial remediation.

Credentials should also be rotated after cleanup. The backdoor can collect administrator session information and create hidden privileged access, so WordPress administrator passwords, hosting credentials, database credentials, API keys and security salts should be treated as potentially exposed. Rotating only the WordPress password while retaining compromised session material or database credentials is inadequate.

For e-commerce operators, visitor impact should also be considered. Because the malware can inject arbitrary JavaScript into front-end pages, an infected store could potentially serve payment skimmers or credential-stealing scripts even while the WordPress backend appears functional. Incident response should therefore include reviewing customer-facing JavaScript, checkout behavior and external resources loaded during the compromise window.

The broader lesson from SC is that modern website malware increasingly behaves like an ecosystem. Attackers are no longer satisfied with planting one PHP file and hoping administrators miss it. They build recovery paths, hide copies in different layers, use trusted external infrastructure for command delivery and deliberately anticipate how defenders will attempt cleanup.

This changes the defender’s mental model. The question should not be:

“Where is the malicious file?”

It should be:

“What mechanisms can recreate the malicious file?”

That shift matters because SC is specifically engineered to make conventional cleanup appear successful for only a few seconds. A defender deletes the malware, refreshes the page and watches it return. The obvious assumption is that the deletion failed. In reality, the deletion may have worked perfectly; another persistence component simply did exactly what it was designed to do.

The infection chain can therefore be summarized as: initial WordPress compromise → SC backdoor deployed → copies distributed across plugins, drop-ins, theme, configuration, database and shared memory → cron and database mechanisms reinforce persistence → Ethereum infrastructure provides resilient command resolution → operator gains hidden administrative control → arbitrary PHP or JavaScript can be deployed → any surviving component reconstructs the rest after cleanup.

The most important operational lesson is simple: do not treat reinfection as a file-removal problem. Treat it as a persistence-architecture problem.

If one part of the architecture survives, the malware has not been cleaned.

It has merely been inconvenienced.

Cybersecurity researchers have shed light on a WordPress compromise in which threat actors deployed multiple persistence mechanisms to ensure that the final payload kept returning without having to infect the site again. The backdoor has been codenamed SC after the "SC_" markers present in the injected content. Sucuri has described the malware as a "self-healing mesh" that's

Source: WordPress Backdoor Rebuilds Itself After Cleanup Using Files, Database, and Shared Memory via The Hacker News — published 01 Oct 2026.