14 min read

A Free, Open-Source WordPress Malware Cleanup Tool for Every Site and Server Owner

Varun Dubey

Founder, Wbcom Designs · Published Sep 13, 2026 · Updated Sep 13, 2026

If your WordPress site has been hacked, cleaned, and then hacked again within days, this is for you. It is not your imagination and it is not you doing it wrong. Modern WordPress infections are built to come back, and most cleanups only remove the part you can see.

We see this constantly: a site owner cleans an infection, breathes out, and watches it return a day later while every scanner they run swears the site is fine. So we built a free tool that actually fixes it, and open-sourced it for everyone. This is not a product pitch. It is a free, GPL-licensed tool anyone can download and use, and this post explains what it does, why the usual cleanups fail, and how to end the loop.

A cleanup only works if it finds and removes every layer, and then proves nothing came back. Find the whole chain, or you find none of it.

The problem: cleanups that do not stick

Most malware scanners check files against a list of known signatures and report clean. Real infections do not work that way. They reinfect. They leave a hidden re-installer, a rogue admin account, a scheduled task, a poisoned server config, or an SSH key, somewhere the file scanner never looks. Delete the part you can see, and the rest quietly rebuilds it.

For a site owner, that is genuinely frightening. Your site is compromised, the cleaner says it is fine, and you have no way to tell who is right. You might see strange redirects that only happen on mobile, or a warning in Google Search Console, or a note from your host, while every plugin you try reports a clean bill of health. The gap between what you are experiencing and what the tools tell you is exactly the gap this kind of malware is designed to live in.

Why even a paid server scanner is not enough

This is the part most people find surprising. It happens even with a paid, server-level scanner running the whole time. We recently cleaned a server that had one active from start to finish, and it still could not stop the reinfection, because the malware’s persistence lived in the database, the scheduled-task table, and an SSH key, not in the files it scanned.

That is not a failing of one product. It is the limit of the whole file-based model. Any scan that only reads files, free or paid, gives you a half-cooked result on this kind of infection: it clears what it recognizes and leaves the parts that grow it back. And the malware keeps advancing. The families we see now actively self-create new backdoors of every shape, rotate their file names, and plant decoys to waste an investigator’s time, so yesterday’s cleanup does not cover today’s variant. A tool that answers only the question “is this file known-bad?” is always one step behind something whose entire purpose is to regrow from parts it never looks at.

What the whole reinfection chain actually looks like

When we say a tool has to find the whole chain, here is what that means in plain terms. A serious WordPress infection usually spreads itself across several independent hiding places, so that removing any one of them is not enough:

A hidden re-installer that runs automatically on every page load and puts the malware back.
Poisoned system files that WordPress loads before anything else, so the bad code runs first.
Chunks of malware stored in the database, which a file scanner never opens.
Scheduled tasks that rebuild the infection on a timer.
Extra administrator accounts the attacker created, sometimes with an email quietly changed on a real account so they can reset its password later.
Redirect rules in the server config that send your visitors somewhere else while showing you a normal site.
Empty decoy files placed only to look normal and waste a cleaner’s time.
An SSH key that lets the attacker log back into the server directly, after every file and database cleanup.

Those layers protect each other on purpose. Clean the files and the scheduled task rebuilds them. Clean the files and the task and the person with the SSH key logs back in and re-seeds everything. A cleanup only works if it finds and removes all of it, and confirms nothing came back.

Where a file scanner looks	Where reinfecting malware also hides
PHP files with known-bad code	Chunks of malware stored in the database
Uploaded shells in the site folder	Scheduled tasks that rebuild the infection
Modified WordPress core files	Extra admin accounts and changed emails
A list of known signatures	An SSH key that reopens the whole server

A file-only scan checks the left column. Reinfecting malware lives in the right one.

What we built

We contributed an open-source malware-cleanup tool, technically a Model Context Protocol (MCP) server, that you drive in plain language through an AI assistant. It connects to your site over SSH and WP-CLI, with nothing to install on the infected site, and it does three things a normal scanner does not:

Finds the whole reinfection chain, not just the visible shell: hidden re-installers, database payloads, scheduled-task hooks, rogue admins, SSH-key backdoors, and cloaked server rules that signature scanners cannot see.
Removes it safely. Scans are read-only. Every destructive action shows you a preview first and waits for your confirmation, quarantines instead of deleting so mistakes are recoverable, and refuses to touch anything irreversible without a recent backup.
Works at any scale, from one personal blog to a hosting company’s entire fleet, on cPanel, Plesk, or plain SSH.

How it works, without the jargon

You do not write code or run commands. You install the tool once, then talk to it in plain English. You tell it how to reach your site, then you ask for what you need: scan this site, tell me what is infected, clean it up, remove any accounts that should not be there. It does the technical work over your existing server access and reports back in readable language.

The loop is always the same four steps: you ask, it shows you a preview of exactly what it proposes to do, you confirm, and it re-scans afterward to prove the change held. Nothing destructive happens without that preview and your go-ahead, and anything it cannot undo will not run until there is a recent backup in place. That is what makes it safe to hand to someone who is not a security engineer.

Who it helps

Site owners. If you run a single WordPress site, whether it is a small business, a blog, a store, or an educational website, you can finally get a straight answer about whether your site is actually clean, and remove what is there without gambling the whole site on a risky delete. You do not need to understand the internals. You ask, you review what it proposes, you confirm.

Server and hosting owners. If you run a server full of WordPress installs, you can scan the whole thing, find which accounts are actually compromised rather than guessing, and clean them with the same safety rails on every site. We proved this on a real server with 22 accounts and more than 60 WordPress installs, all infected with a self-reinfecting backdoor, cleaned from end to end. For a host, the difference between reimaging a customer’s account and surgically cleaning it is the difference between a support nightmare and a quiet afternoon.

Agencies and freelancers. If you look after client sites, whether they are membership communities, online stores, or training and course websites, you get a repeatable, auditable cleanup you can run the same way every time, with a record of exactly what was removed. That consistency is what lets you offer cleanup as a service you can stand behind.

Safe by design, not by hope

The scariest part of cleaning a hacked site is the fear of making it worse. A single wrong delete can take a live site down with no way back. We designed the tool so that cannot happen by accident.

Every scan is read-only, so looking never changes anything. Every removal is a quarantine first, which means files and database rows are archived before they are deleted and can be restored if something was flagged by mistake. Every destructive action shows a full preview of what it will touch and waits for an explicit confirmation. And anything that genuinely cannot be undone refuses to run until there is a recent backup. Those are not optional settings you have to remember to turn on. They are how the tool works by default.

Why we made it free and GPL

WordPress itself is licensed under the GPL, and its ecosystem is strong because people give back to it. A malware-cleanup tool that only paying customers can use does not make the web safer, it just makes one company’s customers safer. We did not want that. This tool is licensed under the GPL, the same license as WordPress core, which means anyone can use it, study how it works, share it, and improve it.

That choice is deliberate. This class of infection is spreading, it is getting more automated, and it is hitting site owners who have done nothing wrong beyond running a slightly out-of-date plugin. Everyone who owns a WordPress site, and everyone who hosts one, should be able to find and remove it, whether or not they are ever a Wbcom customer. Contributing the tool openly, and continuing to harden it every time a real cleanup teaches us something new, is how we think a company that lives inside WordPress should behave.

Frequently asked questions

My security plugin says my site is clean. Should I trust it? If your site has never been reinfected, probably. If it was cleaned and came back, no. A clean result from a file scanner only means there are no known-bad files at that moment. It says nothing about the database, the scheduled tasks, or an SSH key, which is where reinfecting malware actually lives.

Do I need technical skills to use it? You need to be able to give it your site’s server details, the same information you would give any host or developer. After that, you ask for what you want in plain language and confirm each step. You do not write code.

Will it work with my host? It works over standard SSH and WP-CLI, which most serious WordPress hosts provide, on cPanel, Plesk, and plain servers alike. It works for a single site as easily as for a whole server.

Is it really free? Yes. It is open source under the GPL. There is no paid tier hiding the important features. The whole point was to make this class of cleanup available to everyone.

What if I am not sure my site is infected? Run a scan. Scans are read-only and change nothing. If the site is clean, you get peace of mind. If it is not, you get a clear picture of what is there before you decide what to do.

What a reinfecting site actually feels like

If you have not lived through this, it is worth describing, because the experience is part of why it is so hard to deal with. You get a signal that something is wrong: a customer says the site redirected them to a spam page, or Google flags your site as deceptive, or your host emails to say they found malware. You panic a little, run your security plugin, and it says everything is fine. So you move on.

A day or two later it happens again. Maybe a strange administrator appears in your user list. Maybe your homepage is fine on your laptop but sends visitors on phones to a betting site. Maybe your email starts landing in spam because your server is quietly sending junk. Every time you clean it, it comes back, and every scanner you try tells you there is nothing there. That mismatch is exhausting, and it is exactly the outcome the malware is engineered to produce. It is not that your tools are broken. It is that they are looking in one place while the infection lives in five others.

What to do right now if you think your site is hacked

If you are reading this in the middle of an incident, here is a calm order of operations that will not make things worse:

Do not delete things at random. Panic-deleting files can take your site down without removing the infection. Look before you remove anything.
Take a backup now, even of the infected site. You want a restore point before you start changing things, and it preserves evidence of how the attack happened.
Change your passwords, but do not stop there. Reset your WordPress admin passwords and your hosting and database passwords. This kills stolen credentials, but on its own it will not remove a reinstaller or an SSH key.
Check who your administrators are. Look at every admin account and its email address. An account you do not recognize, or a real account whose email was quietly changed, is a red flag.
Get a full picture before you clean. Scan everything, including the database and server access, so you know the full shape of the problem before you start removing pieces. A read-only scan cannot make anything worse.

How to choose a cleanup you can trust

Whether you use our tool, hire someone, or lean on your host, the questions you ask up front tell you almost everything about whether the cleanup will actually hold:

Do you check the database and the user accounts, or only files? Files-only cleanups do not survive a reinfecting infection.
Do you look at server-level access like SSH keys and scheduled tasks, not just WordPress? The way back in is often outside WordPress entirely.
Do you re-check the site hours later to confirm it did not come back, or do you close the ticket on the first clean result?
Do you find out how the attacker got in, or only remove what they left behind? An open door means it happens again.
Can you undo a mistake? Quarantine-first cleanups are recoverable. Permanent deletes are not.

A cleanup that treats your site as a whole system, files, database, accounts, and server access together, is the kind that ends the problem. A cleanup that greps a folder of files and calls it done is the kind that resets the timer.

Staying clean is as important as getting clean

Removing an infection is only half the work. If the door the attacker used stays open, the next one walks in. Most WordPress compromises start with an out-of-date plugin that has a publicly known vulnerability, often an unauthenticated file-upload or code-execution flaw that gets exploited within hours of being disclosed.

So the cleanup does not really end until the entry point is closed. That means updating or removing any plugin with a known vulnerability, and being ruthless about plugins whose entire job is a security risk. File-manager plugins are the clearest example: they exist to browse, edit, and upload files on your server, which is a remote-code-execution surface by design, and they give a normal visitor nothing. Removing them, keeping everything else current, and using strong unique passwords with two-factor authentication on admin accounts is most of what it takes to keep a cleaned site clean.

How often should I scan after a cleanup? For the first week, check daily, because reinfecting families often reveal themselves on a delay. After that, a weekly scan is a reasonable habit for most sites, and a daily automated scan makes sense if you run many sites or a store.

Does this replace good hosting and backups? No, it complements them. Reliable backups and a decent host are your safety net. This tool is what you reach for when something gets through anyway, which, given enough time and enough plugins, eventually happens to almost everyone.

Why this is everyone’s problem, not just the victim’s

It is tempting to think a hacked WordPress site is a private problem for whoever owns it. It is not. An infected site is rarely just defaced. More often it is quietly conscripted: it sends spam that damages the reputation of every server it shares an address with, it hosts phishing pages that trick other people, it attacks other sites, and it pushes malware to its own visitors. One compromised site on a shared server can drag down the deliverability and reputation of every neighbor on that machine.

That is the real reason we made this free. The web gets safer when the barrier to properly cleaning an infection is low enough that people actually do it, instead of hiding a reinfected site behind a green checkmark and hoping. Every site that gets genuinely cleaned is one less launchpad for the next attack. A tool that only a handful of paying customers can use does not move that needle. A free, open one that any owner or host can pick up does.

We also keep learning in the open. Every real cleanup teaches us something, a new hiding place, a new trick, a new entry point, and those lessons go straight back into the tool and into our public threat research so the whole community benefits. That is the loop we want to be part of: find something new in the wild, harden the tool against it, write up what we learned, repeat.

A few more common questions

Can I use this on a site I manage for a client? Yes. Many of the people using tools like this look after sites for other people. You get a consistent, repeatable process and a clear record of what was removed, which is exactly what you want when you are accountable to a client.

What if my host says the site is clean but I still see problems? Trust what you are seeing. Hosts usually run the same file-based scanners, so a host saying clean often means the files look fine while the database, cron, or an SSH key is still compromised. A full scan that includes those layers will tell you which it is.

Is an AI-driven tool safe to point at my live site? The safety does not come from the AI, it comes from the guardrails around it: read-only scans, previews before any change, quarantine instead of deletion, and a backup requirement for anything irreversible. You stay in control and approve each step. The assistant is how you drive it in plain language, not a black box making silent changes.