WordPress malware removal that closes the way back in.
Most sites we're called about were already cleaned once. The payload came off, nobody read the access logs, and the backdoor was still in the uploads folder. We snapshot first, prove how they got in, then close that route and harden the rest.
WordPress malware removal is the work of returning a compromised site to a known-good state: injected code stripped from files and database, core and plugin integrity restored, attacker accounts and credentials revoked, and the vulnerability that let them in identified and closed — so the same infection does not return next month.
Hacked, triage, clean, harden, monitor — and the decision at each gate
Five stages, each with a gate that must pass before the next starts. The gates stop a clean-up finishing before the cause is found.
Scroll the diagram sideways to see all five stages.
The entry points we find are boring: an unpatched plugin, a nulled theme, a reused admin password, a neighbouring site, stolen SFTP credentials, end-of-life PHP, or an old agency account nobody removed — the most common of all, and the only one that costs nothing to fix.
Six pieces of work, priced as one job
A clean-up without forensics is cheaper because it's a smaller job, not a better one — and it sells you the second clean-up too.
Triage and containment
Stop the spread before diagnosing anything.
- Maintenance page if the site is serving malware to visitors
- All active sessions and Application Passwords terminated
- Forensic copy of files and database, taken off the server before anything is deleted
Removal and integrity restore
Modified files found by comparison, not by guessing.
- Core, theme and plugin files diffed with WP-CLI checksums
- Injected loaders and obfuscated
evalblocks out ofwp-config.php,.htaccessand theme files - Injected rows in the options and posts tables cleaned too
Entry-point forensics
The part that decides whether this happens again.
- Logs read against file modification times to find the first malicious request
- Plugin and theme versions checked against WPScan and Patchstack advisories
- Where logs have rotated away, we say the cause is unproven
Hardening the route back in
The proven entry point first, then the obvious gaps.
- Admin accounts audited; passwords, database credentials, salts and API keys rotated
- Two-factor authentication on every account that keeps access
- File permissions, PHP version,
DISALLOW_FILE_EDITand WP-Cron reviewed
Blacklist and Search Console recovery
Filed once, correctly, after the site is clean.
- Reconsideration request filed in Search Console once the clean state is confirmed
- Browser and vendor blacklists submitted separately — they clear on their own schedules
- Review timing belongs to Google, and we don't promise it
The written incident report
Yours to keep, forward and audit against.
- The entry point with the evidence that identifies it
- A log-based timeline, and every file, account and credential changed
- Usable with an insurer, a client, or a regulator if personal data was exposed
Hour by hour, and what usually goes wrong at each step
Timings assume one site we can reach by SSH or SFTP, with logs intact. Each step names what usually delays it.
Get in, hold the damage, snapshot everything
Access, the symptom, and a forensic copy before a single file changes. A site serving malware to visitors goes behind a holding page first — cheaper than a Safe Browsing listing.
Goes wrong here: only the agency who left has the hosting login. Finding the account owner is often the longest part of the job.
Work on the snapshot, not the patient
Integrity checks, database inspection and log reading happen on the copy, so the evidence survives. This is where we learn whether the entry point is provable at all.
Goes wrong here: logs already rotated, common on cheap shared hosting. We say so rather than name a plausible cause.
Remove, then prove the removal
Payload, loaders, backdoors, rogue accounts and injected rows come out; a second integrity pass confirms nothing was missed, across every site on the account.
Goes wrong here: a neighbouring site reinfects this one within hours. If we may touch only one site on a shared account, we put that risk in writing first.
Close the proven route, then the obvious ones
Credentials rotated, two-factor enabled, PHP and permissions corrected, WP-Cron reviewed, a WAF in front. Scoped to the compromise and what you approve — no redesigns, no plugin swaps.
Goes wrong here: a password still reused elsewhere. Rotation only helps if it covers every copy.
Hand over evidence, then keep watching
Incident report delivered, reconsideration filed if a warning was raised, integrity monitoring left running, and the 30-day reinfection watch begins.
Goes wrong here: updates stop and a new advisory lands months later — which is why we mention an ongoing AMC retainer.
Four things people are told after a hack that don't hold
These four are behind most second clean-ups we're called into. Worth knowing whoever you hire.
"We restored a backup, so it's fine."
The compromise usually predates the symptom by weeks, so the backup holds the backdoor and the unpatched plugin. A restore that reinstates the vulnerability is a countdown.
How we handle it: a restore is containment only. We clean and patch forward, and check the backup itself is clean.
"The scanner says the site is clean now."
Scanners match known signatures in files. A backdoor in a database row, a WP-Cron task or a legitimate-looking admin account isn't a file.
How we handle it: compare against official releases, inspect the users and cron tables, and read the logs. A scan is a starting point, not evidence.
"We changed all the passwords."
That helps only if credentials were the way in, and does nothing about a shell already in the uploads folder.
How we handle it: rotation happens after the foothold is gone, and covers what people forget — database credentials, the salts in wp-config.php, and every API key.
"Our host cleaned it and said it was a plugin."
Hosts solve their own problem — malware serving from their IP range. They rarely read your logs or check the other sites on your account, a common reinfection route.
How we handle it: we check every site on the account and ask the host which plugin and advisory. "It was a plugin" without a version number is a guess wearing a uniform.
Security plugin, your host, or an engineer
Three routes, and we lose work to the first two regularly — we'd rather say so than charge for what Wordfence would have fixed.
| Can it do this? | Security plugin | Your host | Engineer-led rescue |
|---|---|---|---|
| Remove known file-based malware | Yes — this is what it's for | Usually yes | Yes |
| Find a backdoor in a database row | No — it scans files | Rarely | Yes, the tables are inspected directly |
| Find persistence in WP-Cron | No | No | Yes |
| Prove how the attacker got in | No — no log analysis | Almost never | Yes, or it states the cause is unproven |
| Check other sites on the same account | No | Rarely | Yes, in the same pass |
| Produce a report for an insurer or client | A scan log, not a report | A support ticket | Written incident report |
| Cost | Cheapest by a distance | Often included in hosting | Meaningfully more than either |
Scroll the table sideways for all three routes.
Try the cheap route first — genuinely
A plain file-based infection caught early is often cleaned by Wordfence, Sucuri or your host for a fraction of our fee. If it stays clear, you never needed us.
Engineer-led work earns its cost when the infection came back, the site takes payments or holds personal data, Google flagged it, or someone has to be told what happened.
What "hardened" means when we say it
Hardening means specific changes with specific effects — not a security plugin on default settings.
- Two-factor authentication on every retained accountTOTP, not SMS. Credential stuffing against
wp-login.phpstops working. - A web application firewall in front of the siteCloudflare or ModSecurity rules block a newly disclosed plugin vulnerability at the edge until you can patch.
- File-integrity monitoring left runningAn alert when a PHP file changes outside a deployment, so the next incident is found the same day.
- Least-privilege hostingSeparate accounts and PHP-FPM pools per site, so one compromised site can't touch its neighbours.
- The
wp-adminfile editor disabledDISALLOW_FILE_EDITinwp-config.php, so one admin session isn't also a code editor on your server. - Supported PHP and a current MySQL or MariaDBEnd-of-life PHP gets no security patches. Your host controls this one, so we put it to them in writing.
- An update routine with an ownerWeekly updates on a staging copy first, with a rollback point. Hardening decays without it.
Cleanup & forensics
Hardening
Recovery & reporting
Everything here is a tool or standard we use on live work. Where a compromise reaches past WordPress — the server, mailboxes, the network — see what we do and don't hold on security and compliance.
What we don't take on
- A clean-up with no log access. Without server logs we can remove the infection but not prove the entry point — and we won't charge forensic rates for a guess.
- Sites we're asked not to contain or snapshot. If a site is serving malware and we may not take it offline, the engagement is theatre. The snapshot isn't negotiable either.
- Nulled themes and plugins staying in place. If pirated code is the way in, it comes out — we won't leave a backdoor to save a licence fee.
- "Just make the Google warning go away." We don't file a reconsideration request for a site that's still compromised — a failed review is worse than none.
- Incident response for anything that isn't WordPress. Compromised servers, mailboxes and networks need a specialist, and we'll say so rather than improvise.
Cost, timing, ownership and reinfection
How much does WordPress malware removal cost?
A fixed fee per site, quoted after a free look at the symptoms. It moves on how many sites share the hosting account — every neighbour is checked — whether the database was hit, and whether a Google warning must be lifted. If a scanner will fix it, we'll say so and charge nothing.
How fast can you start, and how long does a clean-up take?
A single-site infection on hosting we can reach is typically resolved within a day or two of access, with containment first. It runs longer when several sites share the account, backups are already overwritten, or the database was hit. A Google warning adds its own wait — nobody can promise Google's timing. We reply within one business day.
Who does the work, and will they change anything else on my site?
One named WordPress engineer from triage to report, working on the forensic copy. We change only the compromise and the hardening you approve, and record every file, account and credential changed so your developer can audit it.
Who owns the custom fixes and hardening code you write?
You do. Any code we write — a must-use plugin, WAF rules, a patched theme function — is assigned to you on payment and documented in the report, with no dependency on us. The same IP position applies across every engagement model we offer.
What happens after the clean — do we need a maintenance retainer?
Not necessarily from us, but someone named has to own updates. The report's update routine can go to your own developer, or to us as an AMC retainer under dedicated teams and support: staged weekly updates, monitored backups and integrity alerts. A site with no update owner is waiting for the next advisory.
What if the site gets reinfected after you clean it?
Reinfection means the entry point was missed or a neighbouring site wasn't cleaned — our problem either way. A 30-day reinfection watch runs after handover, and the same infection returning inside it is re-cleaned at no cost. It doesn't cover a fresh compromise through a plugin installed later, which is why the report ends with an update routine, not a certificate.
Do we get evidence of what happened, and who owns it?
A written incident report: the entry point and its evidence, a log-based timeline, everything removed or changed, and the hardening applied. It's yours — for an insurer, a client, or a regulator if personal data was exposed. We keep the forensic copy for an agreed period, then destroy it. If the entry point can't be proven, the report says so.
Could a security plugin or our host do this instead?
Often, yes, for a plain file-based infection — try that first. Automated tools don't read logs to prove the way in, find backdoors in database rows or WP-Cron, or check neighbouring sites. If a scanner ran twice and the infection came back, that gap is why.
Related services
Tell us what you're seeing on the site.
Bring the symptom — the redirect, the warning, the pages you never published — and your hosting details. You'll leave knowing whether this needs forensics or a scanner.
- Email — [email protected]
- Phone / WhatsApp — +91 817 979 7732