Many website owners believe that when a WordPress site is hacked, the fix is to find the bad plugin and delete it. For some infections that is enough. For a growing number, it is not, and a recently documented piece of malware shows why.

In September 2026, security company Sucuri published an analysis of a WordPress infection it calls "SC". Its defining feature is that it hides in many places at once, and each part can rebuild the others. Remove one piece, and the site can be reinfected within minutes. This article explains what was found, what it means for a small business, and what a proper clean-up looks like.

What Sucuri found

Sucuri described the malware in a post titled SC WordPress Malware: A Self-Healing Mesh of Loaders, Drop-Ins, and a Blockchain-Controlled Backdoor, published on 30 September 2026. The name comes from "SC_" markers in the code. Sucuri found it while cleaning up a compromised site, and it reports a single case, not a count of affected sites.

The important points, in plain language:

  • Eight places on the server. In the case Sucuri studied, the malware lived in a .user.ini file that makes a hidden file run before every page, several hidden or fake files in the wp-content folder, code injected into the active theme's functions.php, and a fake plugin installed twice, once as a must-use plugin and once as a normal plugin. File names vary from site to site.
  • They rebuild each other. Several of these components can recreate the others, so deleting one is not enough.
  • Hiding places outside the files. Sucuri also found copies in the database, in a block of shared server memory, and in scheduled tasks with random names. In related variants it also saw database triggers that recreate an administrator account.
  • Remote control through blockchain. The malware reads instructions from public Ethereum network gateways, about twenty of them according to Sucuri. There is no single server that can simply be shut down.

What it can do

According to Sucuri, the malware hides itself from the plugin list, collects site details and active administrator session tokens, and sends them out. It can receive new code to run, inject JavaScript into pages, and switch off and delete security plugins. It can also create or take over a hidden administrator account. Sucuri notes that injected JavaScript can be used to skim card details on online stores.

How the site was first compromised is not known. Sucuri did not identify the entry point, and its general advice is to keep software patched. Please treat any article that claims a specific cause with caution unless it cites evidence.

Why simple cleanup fails

Imagine weeding a garden by cutting the plants at ground level while the roots stay underground. That is what deleting the visible bad plugin does here.

  • If you remove the fake plugin but leave the .user.ini entry, the hidden loader runs on the next request and rebuilds it.
  • If you clean the files but leave the database entry, the payload is restored from there.
  • If you delete the hidden admin account but not the trigger or scheduled task that recreates it, it comes back.

Sucuri's own cleanup order for this case is a good illustration: first neutralise the loader instruction, because PHP can cache it for a few minutes, then clear the copies stored off disk, then remove the scheduled tasks and database triggers, delete the hidden administrator, and only then remove the files in one pass. That is work for a professional with server access, and not something to attempt by trial and error.

This is not only about one malware family

A sudden compromise can come from any direction. In October 2026, BleepingComputer reported that a Rank Math PRO build (version 3.0.123) downloaded from the vendor's site between 15 and 16 October contained a backdoor. The free version on WordPress.org was not affected, and 3.0.124 is clean. The vendor says sites that activated the bad version should be treated as compromised, and that updating or deactivating does not remove the threat.

The lesson is the same. Once an attacker has run code on your server, the safe assumption is that more than one thing was changed.

What a proper clean-up involves

The official WordPress.org guide, FAQ: My Site Was Hacked, covers the basics, and professional guidance follows the same logic. In short:

  1. Do not just delete the suspect plugin. Treat the whole site as compromised.
  2. Call your host or a security professional straight away. Ask them to check for hidden files, .user.ini, must-use plugins, the database and scheduled tasks.
  3. Keep a copy of the infected site. Label it clearly and store it offline in case you need to investigate later.
  4. Prefer restoring a backup made before the infection, ideally one stored away from the server. If you only have infected backups, ask a professional to clean the site step by step.
  5. Reinstall WordPress, themes and plugins from official sources. WordPress.org advises replacing wp-admin and wp-includes over SFTP, because the dashboard's reinstall button only overwrites existing files.
  6. Review administrators and scheduled tasks. Remove any account you do not recognise.
  7. Change every credential. That means WordPress, hosting, SFTP and database passwords, the secret keys in wp-config.php, and any API keys the site can read. Change them again once you are sure the site is clean.
  8. Scan again over the following days. If a file reappears, the clean-up is not finished.
  9. Prevent a repeat. Update promptly, remove unused plugins, switch on two-factor login, keep automatic backups away from the server, and consider a web application firewall as an extra layer. A firewall helps, but it is not a cure, so do not rely on one alone.

The cheapest protection: backups you have tested

The single most useful preparation is a recent backup stored somewhere an attacker on your server cannot reach, and a restore that has been tested at least once. WordPress's hardening documentation recommends regular backups, ideally stored on media that cannot be overwritten. With a clean backup, a bad day becomes a restore. Without one, it can become a rebuild.

Questions to ask your web person

  • Where are our backups stored, how often are they made, and when did we last test a restore?
  • Who is responsible for updating WordPress, themes and plugins, and how quickly?
  • Do we have plugins we no longer use, or ones that are no longer maintained?
  • If we were hacked tomorrow, who would we call and what would they do first?

Where I can help

If you are not sure about any of these answers, start with a calm look at what you have. The free Digital Business Audit reviews your website setup and highlights risks in plain language, with no pressure. If you are planning a new website, my website work includes 12-Month Post-Launch Support, so updates, backups and maintenance have a clear owner after launch.

Sources