The Malware Scanner lights up, a customer's WordPress site is throwing redirects, and you need to clean the account without nuking files a developer will scream about. This is the runbook for that moment: what Imunify360's cleanup actually does, when to restore instead, and how to break the reinfection cycle so the same account isn't reinfected by Friday.
It's written for operators running Imunify360 on a shared cPanel or Plesk fleet, where infections are routine and you can't hand-inspect every flagged file.
Cleanup is the default now — Quarantine and Delete are gone
If you learned Imunify on the old Delete/Quarantine model, unlearn it. Cleanup is the default action on all new installs, and as of ImunifyAV(+) v6.2 the Quarantine and Delete actions were removed from both the UI and the CLI. Files quarantined under the old model can no longer be restored once that version lands, so don't build a workflow around quarantine.
The reason is simple: roughly half of all malicious entries on a real infected site are
injections — malicious code spliced into an otherwise legitimate .php or .js file.
Delete and quarantine treat the whole file as the threat, so they break the site to remove
the infection. Cleanup surgically trims the injected payload and leaves the legitimate code
in place. Before it touches anything, it backs up the contaminated file, so the action is
reversible.
The remediation decision tree
When the scanner flags files on an account, work down this list rather than mass-deleting:
-
Is it a real detection or a false positive? Custom or obscure plugin code sometimes trips the signatures. If you have any doubt, hold off and check how to submit and confirm false positives before you act. Cleaning a false positive corrupts a working file.
-
Run cleanup. For genuine detections, let Imunify clean. This handles the injection half safely and removes the pure-malware files. From the dashboard it's one button per file or per account; from the CLI see below.
-
Did cleanup break the site? If a page now errors, the injection was tangled with legitimate logic. Use Restore original to put the pre-cleanup file back, then clean manually or escalate. The original is available for 14 days.
-
Was the file legitimate but fully compromised? If cleanup left a stub or the file was replaced wholesale by the attacker, use Try to restore from backup to pull the pre-infection version — assuming you have a recent single-file restore available. This is the cleanest outcome when backups predate the breach.
-
Reinfected within hours? Cleanup treated the symptom, not the entry point. Jump to reinfection prevention below.
Doing it from the CLI
The dashboard is fine for a single account, but for a fleet or a scripted response the
imunify360-agent CLI is faster. Scan one account on
demand:
imunify360-agent malware on-demand start --path /home/baduser/public_html/
List what it found, with the file IDs you'll act on:
imunify360-agent malware malicious list --user baduser --limit 500
Clean specific files by ID, or clean everything flagged on the box:
imunify360-agent malware malicious cleanup --user baduser --items 12,17,42
imunify360-agent malware malicious cleanup-all
If cleanup went wrong, restore:
imunify360-agent malware malicious restore-original
imunify360-agent malware malicious restore-from-backup
And audit what happened afterwards:
imunify360-agent malware history list --user baduser --since 2026-06-20
Break the reinfection loop
Cleanup that isn't paired with closing the entry point just resets the clock. Imunify gives you the pieces to stop it:
- Force the credential reset. When Imunify detects that cPanel or WordPress credentials were used in the attack, it can automatically force a password reset — the single most effective way to break the loop, since most reinfections ride back in on stolen logins. Make sure this is enabled, not just the scanner.
- Turn on real-time and background scanning. On-demand scanning is reactive. The run-time scanner catches malicious uploads as they land, and a daily background scan (admin-configured) catches what slips through. An account that's only ever scanned on-demand is one you'll keep cleaning by hand.
- Enable Proactive Defense. The PHP-level Proactive Defense / PHP Shield blocks malicious scripts at execution time, so a backdoor that survives cleanup still can't run. This is what stops a missed shell from re-seeding the account.
- Patch the actual hole. Outdated WordPress, a vulnerable plugin, or world-writable permissions are the usual root cause. Cleaning files without patching the CMS guarantees a repeat.
If a particular account reinfects despite all of this, the entry point is something the scanner can't see — a cron job, a database-stored payload, or a compromised credential you haven't rotated. At that point a full backup restore to before the first detection, followed by a CMS and plugin update, beats another round of cleanup.