🚨 SC MALWARE — SELF-HEALING PERSISTENCE ACROSS FILES, DATABASE & MEMORY

Security researchers have documented a WordPress malware family tracked as SC, named after SC_ markers found in injected code. The supplied research describes a “self-healing” architecture in which persistence is spread across multiple locations and mechanisms.

Observed components include .user.ini, PHP loader files, WordPress drop-ins such as db.php and advanced-cache.php, theme functions.php, a malicious MU-plugin, a duplicate conventional plugin, a database payload, shared-memory content and scheduled redeployment.

Sucuri described the architecture as a “self-healing mesh.”

Traditional WordPress cleanup often follows: Find malicious file → Delete → Scan → Restore service. SC breaks that model by creating cooperating persistence nodes.

The supplied analysis identifies .user.ini, PHP loaders, wp-content/db.php, wp-content/advanced-cache.php, modified theme code, MU-plugins, ordinary plugins, database payloads, System V shared memory and scheduled redeployment.

These components can act as recovery points. Removing one node does not necessarily break the chain.

A simplified model from the supplied research is:

The result is a circular persistence mechanism rather than a single master file.

The malware uses auto_prepend_file so PHP loads attacker-controlled code before normal PHP request processing within the affected directory tree.

The supplied research also notes that PHP can cache .user.ini directives. Careless removal of the referenced file can therefore cause PHP failures during cleanup.

SC abuses early WordPress drop-in locations such as wp-content/db.php and wp-content/advanced-cache.php.

The supplied analysis says db.php contains an encoded copy of the backdoor and can restore a missing malicious plugin. advanced-cache.php can search surviving copies in MU-plugins, normal plugins, shared memory, ZIP restore bundles and the database.

An encoded representation of the payload can be stored in the WordPress database. This means a filesystem-only investigation can miss a recovery source.

Restoring a compromised database without understanding the persistence mechanism can therefore restore the attacker-controlled component as well.

Where supported, SC can place PHP code into a System V shared-memory segment. The supplied research reports that this memory-resident copy can survive ordinary file deletion and database cleanup depending on the hosting environment and process lifecycle.

DFIR lesson: if the investigation examines only the filesystem, it may be examining only one layer of the compromise.

The active WordPress theme can contain injected code inside functions.php. The supplied research describes this as another recovery mechanism capable of recreating the malicious plugin when it disappears.

The backdoor was observed in both wp-content/mu-plugins/ and wp-content/plugins/. MU-plugins are particularly important because they are automatically loaded and are not managed like ordinary plugins through the normal activation workflow.

The supplied research reports capabilities including hiding itself from administrator views, creating or manipulating privileged access, fingerprinting the WordPress environment, executing PHP, injecting JavaScript, targeting security controls and maintaining remote control through blockchain-based infrastructure.

The supplied research reports use of public Ethereum RPC gateways to communicate with a smart contract and retrieve instructions.

This can make blocking a single conventional IP address or domain insufficient. It also illustrates how legitimate public infrastructure can be abused for malicious communications.

Important: the exact initial delivery mechanism for SC is not established in the supplied research. Vulnerable plugins/themes, weak credentials, supply-chain compromise and insecure uploads are possible routes, not confirmed SC delivery mechanisms.

Defenders should hunt beyond obvious malware filenames.

These are investigation leads from the supplied technical analysis, not a universal signature set.

Deleting the malicious plugin may appear successful until the next request triggers a surviving recovery node such as db.php, theme code, database content or memory-resident code.

The defender has not necessarily failed to delete the malware; one node of a persistence network remained capable of reconstruction.

The supplied SC disclosure also discusses CVE-2026-1581, described as an unauthenticated time-based SQL injection in wpForo affecting versions up to 2.4.14. The source says version 2.4.15 addressed the issue and cites a CVSS 7.5 score and fewer than 20 observed exploitation attempts since 3 July 2026 from five IP addresses.

This does not establish CVE-2026-1581 as the entry point for SC. That distinction is important when separating related threat context from confirmed causation.

The central lesson is not simply that WordPress malware can hide. It is that persistence can become a network of mutually dependent recovery mechanisms.

SC demonstrates why incident response must examine files, WordPress internals, databases, scheduled execution, memory, credentials and network communications together.

Delete the backdoor.
Break the persistence.
Find the entry point.
Rotate the credentials.
Then rebuild trust.

CyberRakshakLabs Think Before You Click. Stay Aware. Stay Secure.