WordPress Backdoor Uses Self-Healing Persistence to Survive Malware Cleanup

Cybersecurity researchers have uncovered a sophisticated WordPress compromise in which attackers deployed multiple persistence mechanisms to ensure that a backdoor could restore itself even after security teams removed infected files.

The malware, tracked as SC, was identified by Sucuri and described as a self-healing mesh controlled through blockchain infrastructure.

The backdoor is distributed across multiple locations, including WordPress files, the database and shared memory. Each surviving component can recreate the others, making simple file deletion ineffective.

SC Malware Uses Multiple Persistence Layers

According to Sucuri, the malware can exist in at least eight locations simultaneously.

The components include:

  • .user.ini
  • wp-content/c1b12371.php
  • wp-content/.c1b12371.php
  • wp-content/db.php
  • wp-content/advanced-cache.php
  • wp-content/themes/khorshidi/functions.php
  • wp-content/mu-plugins/hyper-engine-kit.php
  • wp-content/plugins/hyper-engine-kit/hyper-engine-kit.php

The file names can vary between infections.

The different components are designed to restore missing copies of the malware. Removing one component can therefore cause another surviving component to recreate it during a subsequent request.

Obfuscated PHP Code Hides the Malware

Sucuri found that the malicious PHP files do not contain easily readable function names.

Instead, the malware uses a decoder and substitution cipher to resolve obfuscated strings and function names at runtime.

This makes the injected code more difficult to identify through simple manual inspection.

.user.ini Starts the Infection

The .user.ini file uses PHP's auto_prepend_file directive to execute a loader before PHP processes requests within the affected directory.

The loader points to another PHP file, which then searches for the hidden malware components.

Because auto_prepend_file operates at the PHP level, the malicious code can execute before a request reaches normal WordPress processing.

Multiple Files Rebuild the Backdoor

The hidden loader can reconstruct the malicious plugin from several sources.

These include:

  • An existing copy inside the plugins directory
  • An encoded cache stub
  • A ZIP restoration bundle
  • The WordPress database
  • System V shared memory

The db.php drop-in contains a compressed and Base64-encoded copy of the backdoor and can restore the malicious plugin if it is deleted.

The advanced-cache.php drop-in provides another restoration mechanism and can search multiple locations for a surviving copy.

A malicious block injected into the active theme's functions.php provides another route for restoring the backdoor.

Fake Plugin Provides Additional Persistence

The actual payload is installed as both a must-use plugin and a normal WordPress plugin.

The malware was found under:

wp-content/mu-plugins/hyper-engine-kit.php

and:

wp-content/plugins/hyper-engine-kit/hyper-engine-kit.php

The two copies provide redundancy.

The must-use plugin is automatically loaded by WordPress, while the normal plugin provides another copy that can be restored if one of the components is removed.

Blockchain Used for Command and Control

The backdoor uses the Ethereum blockchain infrastructure for command-and-control communication.

Rather than depending on a single hardcoded C2 server, the malware can communicate through public Ethereum RPC gateways and retrieve instructions through blockchain-based infrastructure.

This makes traditional IP-based blocking more difficult because legitimate third-party blockchain services are being used as part of the communication mechanism.

Backdoor Can Create Hidden Administrator Accounts

Once active, the malware can fingerprint the compromised WordPress installation and communicate information to its operators.

Its capabilities include:

  • Creating hidden administrator accounts
  • Executing PHP code
  • Fetching additional payloads
  • Injecting JavaScript into websites
  • Targeting visitors with skimmers
  • Deactivating security plugins
  • Deleting selected plugins
  • Retrieving information about the infected WordPress installation
  • Rebuilding deleted malware components

The malware can also hide itself from the WordPress administrator plugin interface and update checks.

Persistence Beyond the File System

One of the more significant characteristics of SC is its ability to store copies of the payload outside ordinary WordPress files.

Database

A compressed and encoded copy of the backdoor can be stored inside the WordPress database.

A surviving loader can retrieve this copy and rebuild the malware files.

System V Shared Memory

On servers supporting System V shared memory, the malware can place a copy of its PHP payload inside a shared-memory segment.

Because this data exists in memory rather than as a normal file, deleting WordPress files or cleaning the database does not necessarily remove it.

Scheduled Tasks

The infection also registers WordPress cron hooks, including randomized names.

System cron can execute WordPress's cron process and trigger the malware's redeployment process without relying on normal visitor traffic.

Malware Can Target Website Visitors

After establishing control over a compromised WordPress installation, the backdoor can retrieve JavaScript from its operators and inject it into the website.

This capability can potentially be used to deploy:

  • Payment skimmers
  • Credential-stealing scripts
  • Additional malware
  • Malicious redirects
  • Other browser-side attacks

The backdoor can also execute PHP code on the compromised server.

Initial Infection Method Remains Unknown

Sucuri said it is currently unclear how the attackers initially compromise websites using SC.

Potential initial access methods include:

  • Vulnerabilities in WordPress core
  • Vulnerable WordPress plugins
  • Vulnerable themes
  • Weak administrator credentials
  • Supply-chain compromises
  • Insecure file-upload functionality
  • Existing PHP web shells

The researchers did not identify a specific initial access vector responsible for the analyzed infection.

How to Remove the Malware

Because the malware can regenerate itself, deleting the visible infected plugin is not sufficient.

A complete investigation should examine:

  • .user.ini
  • PHP configuration files
  • .htaccess
  • WordPress drop-ins
  • Themes
  • Must-use plugins
  • Normal plugins
  • WordPress database
  • Cron jobs
  • Shared-memory segments
  • Administrator accounts
  • Database triggers
  • Outbound blockchain-related connections

Security teams should also identify and close the original entry point before restoring the website.

wpForo WordPress Plugin Also Under Attack

The disclosure comes as attackers are actively exploiting a separate vulnerability in the wpForo Forum WordPress plugin.

The flaw, tracked as CVE-2026-1581, is an unauthenticated SQL injection vulnerability with a CVSS score of 7.5.

The vulnerability affects wpForo versions up to and including 2.4.14.

According to telemetry from Previdian, fewer than 20 exploitation attempts have been observed since July 3, 2026.

The activity originated from five unique IP addresses associated with infrastructure in:

  • Bulgaria
  • Switzerland
  • France
  • United States
  • Yemen

The activity demonstrates the continuing risk posed by vulnerable WordPress plugins, particularly when attackers can obtain unauthorized access to websites and establish persistent backdoors.

Key Takeaway

The SC malware demonstrates how a WordPress compromise can become a self-restoring infection rather than a single malicious file.

By distributing copies across WordPress files, plugins, themes, the database and shared memory, the malware can restore itself after partial cleanup.

Security teams investigating compromised WordPress sites should therefore examine all persistence layers, not just suspicious PHP files, and should identify the original entry point before considering the system clean.