WordPress Backdoor Uses Eight Recovery Points to Rebuild After Cleanup

A recently documented WordPress backdoor can reconstruct itself after defenders delete its visible files, drawing on redundant copies distributed across the filesystem, database and, on supported servers, shared memory.

The malware was codenamed SC after SC_ markers found in injected content. Sucuri describes it as a blockchain-controlled, “self-healing” mesh. Researcher Gabriel Barbosa reported that its payload occupies at least eight locations, with surviving components able to restore deleted parts of the infection.

The reporting on SC appeared alongside details of exploitation targeting a separate vulnerability in the wpForo Forum plugin. The available evidence does not connect that flaw to SC’s delivery or operation. They should be treated as distinct security issues.

Eight components form a circular persistence system

SC’s resilience comes from multiple recovery paths rather than a single concealed file. Removing the apparent plugin may accomplish little if a loader, database copy, restore archive or shared-memory segment remains available.

Sucuri identified eight principal components:

1. .user.ini sets PHP’s auto_prepend_file directive, causing a loader to execute before PHP requests within the affected directory tree.

2. wp-content/c1b12371.php loads a hidden, dot-prefixed file when that file exists in the same location.

3. wp-content/.c1b12371.php acts as the first-stage loader. It searches for the fake plugin and can rebuild it under mu-plugins from three sources: a normal plugin copy, an encoded stub in the cache directory, or a ZIP restoration bundle with a random hexadecimal filename.

4. wp-content/db.php uses WordPress’s automatically loaded database drop-in mechanism. It contains the backdoor payload in compressed, Base64-encoded form and redeploys the plugin if the expected file is missing or smaller than a defined threshold.

5. wp-content/advanced-cache.php runs before ordinary plugins when caching is enabled. It can reconstruct the malware from five locations: the must-use plugin, a conventional plugin copy, PHP held in System V shared memory, a ZIP bundle, or the database. It then hooks plugins_loaded and includes the restored plugin.

6. wp-content/themes/khorshidi/functions.php provides theme-level persistence. Sucuri says it carries the same backdoor and rewrites the plugin whenever the plugin is absent.

7. wp-content/mu-plugins/hyper-engine-kit.php is the malware installed as a must-use plugin, a category that WordPress loads automatically.

8. wp-content/plugins/hyper-engine-kit/hyper-engine-kit.php supplies another copy of the same payload in the standard plugins directory.

The backdoor obscures its function names and uses a substitution-cipher decoder to make its code harder to interpret. It also conceals itself from the WordPress administrator’s plugin screen and from update checks.

This architecture makes component-by-component deletion unreliable. A file that appears secondary may be the copy used to rebuild everything else during the next execution cycle.

Shared memory extends persistence beyond files and SQL records

On servers supporting System V shared memory, SC writes PHP code into a segment addressed through a fixed numeric key. The reporting does not provide the value of that key.

Because the segment resides in RAM, it can remain available after website files and database records have been cleaned. The malicious advanced-cache.php drop-in can recover the PHP from that segment and use it to recreate the plugin.

Shared hosting may complicate inspection and removal. According to Sucuri, the memory segment can be owned by a different account, potentially placing it outside the compromised site owner’s normal administrative reach.

The infection also registers WordPress cron hooks, including randomized names and a known fetch hook. The supplied material does not identify those hook names. A system cron job runs the WordPress cron file, allowing scheduled redeployment without depending on visitor traffic.

Files, database content, restore archives, scheduled tasks and shared memory consequently operate as parts of one recovery mechanism. Cleaning only the WordPress plugins directory leaves several potential reconstruction sources untouched.

Ethereum-based control enables further compromise

Sucuri characterizes SC as a blockchain-controlled backdoor that communicates with command-and-control infrastructure through the Ethereum blockchain. The available reporting does not include Ethereum wallet identifiers, command-and-control addresses or comparable infrastructure indicators.

Once running, the malware can fingerprint the infected website, retrieve additional payloads and create a hidden WordPress administrator account. Its reported operator capabilities include:

• Fetching arbitrary JavaScript for injection into website pages.
• Delivering skimmers or other malware through injected scripts.
• Executing PHP code on the compromised server.
• Deactivating or deleting selected plugins.
• Repeating the reinfection process when components are removed.

These capabilities expose both the website and its visitors. Server-side PHP execution gives an operator extensive control over the WordPress installation, while arbitrary JavaScript injection can place malicious code in pages served to users.

The cited reporting does not identify the actor operating SC. It also says the initial delivery method is unknown. Vulnerable WordPress components, weak credentials, compromised plugin supply chains and insecure upload functions are listed only as common possibilities, not as confirmed entry points for this malware.

Exploited wpForo SQL injection is a separate issue

The concurrently disclosed plugin flaw is CVE-2026-1581, an unauthenticated, time-based SQL injection affecting wpForo Forum versions 0 through 2.4.14, inclusive.

The vulnerability is exposed through the wpfob parameter. Insufficient escaping of user-controlled data, combined with inadequate preparation of an existing SQL query, allows an unauthenticated attacker to append SQL queries and extract sensitive information from the database.

The Wordfence-issued CVE Program record identifies tomdever as the vendor and credits Youssef Elouaer with discovering the flaw. The record was published on February 19, 2026, and updated on April 8, 2026.

CVE-2026-1581 is rated HIGH, with a CVSS 3.1 score of 7.5 and the following vector:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

The vector describes a remotely exploitable vulnerability with low attack complexity, no privilege requirement and no need for user interaction. Its assessed impact is high for confidentiality, with no listed integrity or availability impact. The flaw is classified as CWE-89, improper neutralization of elements used in an SQL command.

Previdian telemetry recorded fewer than 20 exploitation attempts since July 3, 2026. The activity came from five unique attacker IP addresses geolocated to Bulgaria, Switzerland, France, the United States and Yemen. The individual addresses were not provided.

The reporting does not identify the attackers behind those attempts. Nor does it establish any relationship between CVE-2026-1581 and the SC backdoor.

Incident response must cover every restoration source

For a suspected SC compromise, deleting hyper-engine-kit.php or one of the loaders is not sufficient evidence that the infection has been eradicated. Responders need to investigate all eight reported component paths and the additional recovery sources they reference.

That review should account for:

• Both ordinary and must-use plugin directories.
• The db.php and advanced-cache.php drop-ins.
• The affected theme’s functions.php.
• .user.ini and its auto_prepend_file setting.
• Cache content and randomly named ZIP restoration bundles.
• Malicious data stored in the WordPress database.
• WordPress and system cron activity.
• System V shared-memory segments on servers that support them.

The available reporting does not provide a validated SC removal sequence, the numeric shared-memory key, complete cron-hook names or specific command-and-control indicators. Administrators should therefore avoid declaring a site clean merely because the visible plugin no longer appears.

For CVE-2026-1581, operators should determine whether any WordPress installation runs wpForo Forum 2.4.14 or earlier. The supplied vulnerability records do not identify a fixed version or workaround, so they do not support naming a particular release as the remedy. Administrators should consult current vendor guidance and review relevant web and database activity for suspicious requests involving wpfob.

The two incidents require different investigations. SC calls for broad persistence hunting across several storage and execution layers, while CVE-2026-1581 requires plugin exposure assessment and investigation of possible database extraction. Conflating them could send defenders toward the wrong entry point or cleanup strategy.