Cleaning Up a Hacked WordPress Site: Imunify360, Manual Steps, and When to Split cPanel Accounts

If Google Safe Browsing, search console warnings, or visitors report malware on WordPress on your Middlehost cPanel account, you need two tracks at once: automated containment (so traffic stops executing bad code) and manual verification (so hidden backdoors do not return next week). Follow the steps below in order. Later sections explain how Malware Cleanup Policy site limits apply: included manual cleanup on Business plans is only available when your cPanel account is within those limits. If you have more sites on one cPanel account than your plan covers for manual work, split or restructure first before expecting staff to take over the infection. For how density affects blast radius and cleanup noise, read multiple websites on one cPanel account risks.

Step-by-step: clean a hacked WordPress site on Middlehost

Work through these steps on one WordPress site at a time. If you have many sites on the same cPanel account, finish one site end-to-end before you assume the neighbor directories are clean.

Step 1: Gather facts before you change files

• Write down symptoms: redirects, new admin users, unknown plugins, Japanese SEO spam, etc.
• In cPanel → Imunify360, note what is already flagged for this account (you will revisit it in Step 3). Screenshot or export the view if you want a record before you change files.
• Count how many other websites live on this Middlehost cPanel account. If the number is large, plan for splitting accounts later (see Step 14, our Malware Cleanup Policy, and multiple websites on one cPanel account risks) so included manual cleanup on Business plans matches your layout.

Step 2: Open Imunify360 and capture the baseline

1. Log into cPanel.
2. Open Imunify360 (it often appears under Security).
3. Review the Malware tab, History, and any Proactive Defense messages for this account.
4. If there is a Scan or Scan all action, run it and wait for it to finish.

This is your baseline: what the server already quarantined or cleaned before you touch WordPress.

On Middlehost, Imunify360 is where you get the file-level list. Open the malware history and the infected / cleaned file views in the same panel. Most of what Imunify360 reports there is handled automatically (cleaned, quarantined, or hardened) without you editing each path by hand. Keep that list open while you work through the WordPress steps below, because you still need to review other areas of the site depending on how deep the infection was (themes, uploads, database redirects, cron, and passwords are common follow-ups even when Imunify360 looks quiet).

Step 3: Read Imunify360 on Middlehost and plan deeper checks

• In cPanel → Imunify360, open the latest infected and cleaned file list for this cPanel account. That panel is the authoritative file-level view on Middlehost for what the scanner already touched.
• If you run a second scan later (for example after Step 12), compare it to the baseline from Step 2 so new hits stand out from old history.
• Most entries Imunify360 flags are cleaned automatically once the scanner has seen them. You still manually review other layers on the same site as needed: custom code outside standard signatures, wp-content uploads, premium themes, wp-config.php, .htaccess, and the database often need human eyes even when the Imunify list is short or empty.
• If Imunify360 looks clean for files but the public site is still wrong, continue with Steps 5 through 13. That usually means manual intervention is still required (database redirect, cron reinfection, stolen password, or custom code).

When Imunify360 lists hundreds of files: note them, then prefer a clean backup restore

Hand-editing or deleting every flagged path in File Manager is slow and easy to miss when the list is long. After you capture what Imunify360 reported (screenshots or exports from Step 2–3), a faster recovery path is often to restore the site or account from a backup you trust is clean, for example a JetBackup or cPanel restore point from before you believe the compromise started.

Picking a restore date (heuristic, not proof): In Imunify360, open malware history and sort infected file events by date. The earliest detection that clearly belongs to this incident is often a reasonable anchor when you scroll JetBackup or cPanel restore lists: prefer a snapshot from before that time if your retention still holds one. That does not prove the site was clean the day before (malware can sit undetected, live only in the database, or predate Imunify360’s first hit), but it is still a better starting guess than choosing a random backup with no timeline.

Raw Access logs: Restoring from backup rewinds files on disk, which typically replaces or removes the latestRaw Access log files for the account (not only PHP under public_html). If you still need recent request history to trace entry or reinfection, download logs from Metrics → Raw Access (Step 13) before you restore, and keep copies offline.

Before you click restore, write down which domains or installs still need manual cleanup or a developer review after the rollback. Typical reasons: the only backups you have might already include malware, the attack lived mostly in the database (files look fine but redirects remain), or you are not sure which snapshot is safe. Flag those sites so they are not “forgotten” once files roll back; they may still need Steps 5 through 13 or scoped help under our Malware Cleanup Policy where it applies.

After a successful restore, treat security as account-wide: rotate passwords, update or remove vulnerable plugins, run Imunify360 again, and walk the hardening ideas in Steps 9 through 12 for each WordPress site on that cPanel account, not only the one that screamed loudest. If you still pack many installs on one cPanel account, plan a split so the next incident is easier to isolate (multiple websites on one cPanel account risks).

What we store, how long, and what you should keep yourself are spelled out in our Backup Policy. If no clean restore exists, continue with the manual path from Step 4 onward instead of guessing.

Step 4: Take a safety copy before destructive edits

Use cPanel → Backup or JetBackup (if your plan shows it) and download a partial or full account backup before you delete large trees or before you restore over live data (see the prior section and our Backup Policy). If you only have SFTP, at minimum zip wp-content, wp-config.php, .htaccess, and anything else in the web root you might need for reference. You want a rollback if a theme delete was too aggressive or if Step 5 removes a file you later realize was custom.

Step 5: Strip the web root, then lay down clean WordPress core

Malware often hides in the document root as fake index.php files, random .php droppers, or extra files beside WordPress. The safest baseline is to remove everything in the site’s public web root except three things, then upload a clean WordPress package.

Do this only after Step 4 (backup). In File Manager or SFTP, inside the folder that serves your site (often public_html or the domain’s document root):

1. Keep these exactly as-is for now:
2. wp-config.php (your database settings and salts)
3. wp-content/ (themes, plugins, uploads: you will clean those in Steps 6 through 8)
4. .htaccess (keep the file so custom permalink rules or SSL rules are not lost, but you must audit it in Step 11; if it is full of redirects you did not add, replace it with a clean WordPress default from the official docs after core is restored)
5. Delete everything else in that directory: the old wp-admin and wp-includes folders, index.php, every other wp-*.php at the root, and any stray PHP, HTML, or shell scripts you do not recognize. Attackers routinely drop webshells next to WordPress where people forget to look.

Then rebuild core from a known good source:

1. Download a fresh WordPress zip from wordpress.org for the same major version you intend to run (or plan a controlled upgrade separately).
2. Unpack it and upload wp-admin/, wp-includes/, and all root-level PHP files from the zip (index.php, wp-*.php, xmlrpc.php, license.txt, etc.) into the now-empty root without overwriting wp-config.php.

Never “patch” malware inside core line by line. Clear the root except the three keeps above, then replace core wholesale.

Step 6: Reinstall plugins from a known good source

1. In wp-content/plugins, remove plugins you do not recognize or no longer need.
2. For each plugin you keep: delete its folder, then reinstall from WordPress.org or the vendor zip you purchased.
3. Activate one plugin at a time if you are hunting a reinfection source.

Step 7: Reinstall themes the same way

1. Remove unused themes. Keep one default theme (Twenty *) as a fallback.
2. Delete the active theme folder only if you have a clean zip from the author to put back.
3. Inspect functions.php in custom or child themes for injected code before you re-enable.

Step 8: Clean wp-content/uploads

1. Sort by file type or search for *.php under uploads. Delete PHP files there unless your project truly needs them (rare).
2. Look for double extensions (image.jpg.php) and huge single files with random names.
3. Clear any cache folders your security plugin created only after you trust the plugin binary again.

Step 9: Harden wp-config.php and users

1. In phpMyAdmin or WordPress admin → Users, remove rogue administrators.
2. Change all remaining admin passwords to new random values.
3. In wp-config.php, set new Authentication Unique Keys and Salts from the WordPress.org secret-key service, and change the database password to match a new strong value (update the database user in cPanel → MySQL Databases first, then wp-config.php).
4. Optionally set DISALLOW_FILE_EDIT to true to block theme and plugin editing from wp-admin for teams that do not need it.

Step 10: Check the database for obvious redirects

In phpMyAdmin, select the site database:

• Table wp_options: search option_value for http, <script, base64, or your domain plus spam strings in home and siteurl.
• Table wp_users: confirm no unexpected user_login rows with administrator capability.

If you are not comfortable with SQL, use a trusted security plugin with a database scan feature, work with your developer, or export tables and search offline. Do not assume Middlehost will run database surgery for you on request: included manual cleanup under our Malware Cleanup Policy only applies when your cPanel account is within the per-plan site limits for your tier. We do not take on included manual cleanup for an infected cPanel account that still holds more sites than those limits allow. Split extra sites into separate cPanel accounts (or upgrade to a tier that matches your footprint) first, then open a ticket if you still need help within policy.

Step 11: Inspect .htaccess and root includes

You kept .htaccess in Step 5 on purpose, but it is still a favorite hideout for redirect malware. Open it in File Manager or SFTP. Remove blocks you did not add: odd RewriteRule chains to foreign domains, php_value auto_prepend_file, or includes of random PHP in /tmp. If the file is long and unfamiliar, replace it with the default WordPress .htaccess block from the official WordPress documentation for your permalink structure, then save permalinks once from wp-admin after the site loads. Check wp-config.php for require lines you did not place.

Step 12: Rescan with Imunify360 and clear caches

1. Return to cPanel → Imunify360 and run another scan.
2. Confirm the infected and cleaned files list looks sensible.
3. If you use LiteSpeed caching plugins or server cache, purge all caches so visitors stop seeing an old infected HTML layer.

Step 13: Download and read Raw Access logs

If you are about to restore from backup (see the section above), pull Raw Access downloads first: a restore often wipes or replaces the newest on-server logs, so waiting until after rollback loses that timeline.

1. In cPanel, open Metrics → Raw Access (on some themes it is listed as Raw Access only).
2. Download the latest domain log for the affected site.
3. Search for repeated POST traffic to xmlrpc.php, odd wp-login.php bursts, wp-admin/admin-ajax.php spikes, or requests to PHP files that no longer exist under uploads.

Logs tell you how entry happened, not only what file was bad.

Step 14: Decide on manual help or account splits

• If the site is clean in Imunify360 and behaves normally in a private browser window, monitor for 48 to 72 hours.
• If it reinfects, read Step 13 again, then consider splitting many sites across two or more cPanel accounts (for example, ten sites per account) so the next Imunify360 alarm points at a smaller group. That also aligns with included manual site limits on Business plans described in the Malware Cleanup Policy.
• If automation is clean but symptoms remain, first confirm the cPanel account is within the manual cleanup site count for your Business plan in the Malware Cleanup Policy. If you are over that count on an infected account, split sites across additional cPanel accounts (or adjust plans) before asking for included manual work: we do not take that on until the account matches the policy limits. Once you are in scope, open a support ticket, mention you completed this checklist, and describe what still fails. Cheap plans remain automation-first with optional paid manual cleanup per the policy.

How Middlehost malware cleanup fits together

Our Malware Cleanup Policy is the contract-level source of truth. In short:

• Imunify360 runs on our servers and includes unlimited automated malware cleanups for common threats.
• Business Hosting adds manual cleanup by security staff where automation is not enough, with ongoing manual coverage tied to per-plan site limits (for example Mantis covers one site, HummingBirdtwo, Marlin and Dragonfive each, as listed in the policy).
• Cheap Hosting (Starter, Firefly, Crane) leans on automation first; sites often migrate as-is and Imunify360 cleans what it can on arrival. Manual investigation or cleanup on those plans is a flat fee per site as described in the policy.
• Included manual cleanup on Business plans is offered only when the infected cPanel account is within the site count your plan allows for manual work in the policy. We do not take on included manual cleanup while that account still exceeds those limits. Split or restructure first, then request help.

If you pack many WordPress installs on one cPanel account, one infection often spreads across directories. That makes automated noise higher and manual hours burn faster than the same sites split across multiple cPanel accounts. To stay inside the included manual site counts on Business plans, we recommend splitting heavy portfolios across separate cPanel accounts so each account stays within the policy tiers you actually pay for. See also multiple websites on one cPanel account risks.

What Imunify360 does (and what it cannot promise alone)

Imunify360 is always active on our stack. It monitors files, blocks many exploit patterns, and removes a large share of known malware signatures automatically. On Middlehost you read the same evidence in cPanel: Imunify360 shows you which files were infected and what it already cleaned, and most flagged payloads are handled without hand-editing every line.

No scanner is omniscient. Some infections hide in custom code, obfuscated uploads, or database-driven redirects that do not look like a static signature. Others reinfect because a password or plugin hole is still open. When automation has done its job and the site still shows symptoms, treat that as a signal for manual intervention and the deeper WordPress steps in this guide.

Where to see detections in cPanel

Open cPanel → Imunify360. Use the malware list, infected and cleaned files, and history screens as your checklist on Middlehost. Revisit them after Step 12 and again after any big theme or plugin change, not only once at the start.

If infections keep coming back

When cleanup repeats weekly, you usually still have a reinfection channel: weak passwords, a missed upload, a vulnerable plugin, or too many unrelated sites on one cPanel account sharing the same Linux user.

Split the footprint. If you run something like twenty sites on one cPanel account, move half to a second cPanel account. Watch which account triggers Imunify360 first after the split. That isolates which site is the root cause faster than chasing twenty directories at once.

Keep using Raw Access from Step 13 after each incident so you can see new patterns early.

If you are outgrowing shared layout discipline, compare business web hosting for higher manual cleanup entitlements and clearer resource headroom, or cheap web hosting when budgets are tight but you still want Imunify360 automation on every account.

After the site is stable, you can tune speed with identify and fix performance issues on a WordPress site.

Frequently asked questions

Does Imunify360 mean I never need manual cleanup?

No. It removes a lot automatically, but complex or persistent cases still need human triage, especially when malware lives in the database, in custom code, or when reinfection is continuous.

Will Middlehost manually clean every domain on my one cPanel account for free?

Business plans include manual cleanup up to the site count for your tier, per the Malware Cleanup Policy. We do not perform included manual cleanup on an infected cPanel account that still contains more sites than that limit. Split sites across additional cPanel accounts (or choose a plan tier that matches your real footprint) before requesting included manual work; see multiple websites on one cPanel account risks for why packing many domains on one cPanel account inflates both risk and support scope. Outside those limits you may still use automation (Imunify360) and paid manual options where the policy lists fees.

Where do I see infected and cleaned files on Middlehost?

Everything is in cPanel → Imunify360: malware history, infected and cleaned file views, and proactive defense events for your account. Use that screen after Step 12 and after any large theme or plugin change.

Is free malware cleanup only for migrations?

Eligibility and scope are spelled out on free malware cleanup and tied to our migration policy. Read both before you schedule DNS.

Should I delete all plugins to fix malware?

Deleting everything is rarely the fastest recovery. Follow Step 6: remove unknown plugins first, reinstall trusted ones from official sources, and replace premium plugins only from the vendor zip you paid for.

Imunify360 flagged more files than I can fix by hand. What now?

Note the detections, then see When Imunify360 lists hundreds of files above: a clean backup restore is often faster than one-by-one deletes. To narrow which backup to try first, sort Imunify360 malware history by date and note the earliest detection tied to this incident, then pick a restore from before that moment if retention allows (still not a guarantee the site was clean). Before you restore, download Raw Access logs if you still need them (restores often remove the latest on-server logs), and list any domains that will still need manual work or developer review afterward. After restoring, secure every site on the account and reread our Backup Policy so your expectations on retention match your plan.

If you want help planning a split of cPanel accounts so your footprint matches the Malware Cleanup Policy, or a migration with cleanup while you are within manual site limits, contact our team with your domain list and what Imunify360 still shows after your own passes.