Your site is redirecting to a pharmacy ad, or Chrome is showing a red "Deceptive site ahead" warning, or a customer emailed you a screenshot of Japanese spam text where your homepage used to be. However you found out, the next hour matters more than the last six months of "I'll get to security eventually." Here's how to actually clean a hacked cpanel" class="auto-link">WordPress site, in order, without making it worse.
Symptom: How You Usually Find Out
Hacks rarely announce themselves politely. The common tells we see on support tickets:
- Google Search Console or Chrome flags the site as "This site may harm your computer" or "Deceptive site ahead."
- The site redirects visitors to a completely different domain, but only on mobile, or only from Google search results (this is a classic conditional-redirect infection).
- Your hosting account's outbound mail suddenly gets suspended for sending thousands of spam emails you never wrote.
- New admin users appear in Users that nobody on your team created.
- File Manager or FTP shows PHP files in
wp-content/uploads/— a folder that should only ever hold images and media, not executable code. - Your host emails you directly saying malware was found during a routine scan and the account may be suspended.
If your site is already flagged by Google or a browser warning is showing, don't panic and don't just restore an old backup yet — read the next section first, because you need to know how they got in before you can stop it happening again.
Cause: How Attackers Usually Get In
In our experience cleaning up compromised accounts, it's almost never a targeted attack. It's automated bots scanning for known weaknesses:
| Entry Point | How It Happens |
|---|---|
| Outdated plugin/theme | A known vulnerability gets exploited by a bot within days of disclosure, on every site still running the old version |
| Nulled/pirated plugins | "Free" premium plugins downloaded from non-official sites, often with a backdoor built in from day one |
| Weak admin password | Brute-forced against wp-login.php, especially if the username is still "admin" |
| Leaked FTP/cPanel credentials | Reused password exposed in an unrelated data breach |
| Stale, abandoned install | A subdomain or old WordPress copy nobody's touched in years, still publicly reachable |
You often can't prove which one it was after the fact — and honestly, for cleanup purposes, it doesn't matter which door they used. You're going to lock all of them anyway.
Fix: Cleaning Up a Compromised Site
1. Take the Site Offline (Briefly) and Change Every Password
Before touching files, change these immediately, from a device you trust:
- Your cPanel password
- Every WordPress admin account password
- Database password (in phpMyAdmin, then update
wp-config.phpto match) - FTP/SFTP passwords
If the attacker still has valid credentials cached somewhere, they'll keep re-infecting the site as fast as you clean it. This step isn't optional and it isn't step three — it's step one.
2. Take a Full Backup of the Infected Site — Yes, Even Now
It sounds backwards, but grab a full cPanel backup (Files + Database) before deleting anything. If cleanup goes sideways, you want a fallback point, and you may need infected files later to confirm what was removed. Store it somewhere separate, don't restore it as-is.
3. Compare Against a Clean Core
Download a fresh copy of WordPress core matching your version from wordpress.org, and diff it against your live wp-admin/ and wp-includes/ folders. Any file that doesn't match stock WordPress in those two directories is suspicious — core files should never be modified. In cPanel File Manager, sort by Last Modified and look for anything touched recently that you didn't change yourself:
# Via SSH, if you have it — find PHP files modified in the last 30 days
find /home/username/public_html -name "*.php" -mtime -30 -type fPay close attention to wp-content/uploads/, any folder starting with a dot, and file names that look almost right — wp-cofig.php, class.wp.php, or a second index.php tucked inside a plugin folder. These are the classic disguises for a backdoor.
4. Remove Malicious Users, Plugins, and Scheduled Tasks
Check three places attackers love to hide persistence:
- Users – delete any administrator account you don't recognize. Check the "Registered" date; a fresh admin account from last week is a red flag.
- Plugins – delete (not just deactivate) anything you didn't install, and anything nulled/pirated even if it looks legitimate.
- Cron jobs – both WP-Cron entries (visible via a plugin like WP Crontrol) and real cPanel cron jobs. A malicious cron re-downloading a backdoor every hour is a common re-infection trick.
5. Run a Malware Scan and Reinstall Core Clean
Use a scanner — Wordfence, Sucuri SiteCheck, or MalCare all work — to catch anything the manual pass missed. Then reinstall WordPress core fresh: in wp-admin, go to Updates and click Re-install Now even if you're already on the latest version. This silently overwrites every core file with a known-clean copy, which clears out anything hiding in wp-admin/ or wp-includes/ that a manual review missed.
6. Check the Database Too
Malware isn't always a file — sometimes it's injected into the database, commonly in the wp_options table (look for suspicious entries under siteurl, home, or widget/theme option blobs) or appended directly into post content. In phpMyAdmin, search the database for eval(, base64_decode, or <script> tags that shouldn't be there.
7. Ask Your Host to Re-check and Lift Any Suspension
If SkyServer flagged or suspended the account, once you've cleaned it up, open a support ticket asking for a re-scan. We keep a record of what was found originally, so we can confirm the specific infection is gone before lifting any restriction — much faster than a blind "please unsuspend me" request.
Prevention: Making Sure It Doesn't Come Back
Cleanup without prevention just buys you a few weeks before the next infection. The short version, once you're clean:
- Turn on auto-updates for plugins and core minor releases.
- Delete plugins and themes you're not actively using — don't just deactivate them.
- Never use nulled/pirated premium plugins. If you can't afford the license, use a free alternative instead.
- Enable two-factor authentication on all admin accounts.
- Keep automated off-site backups running (SkyServer's JetBackup retains daily snapshots) so a future incident is a five-minute restore instead of a five-hour cleanup.
If you want the full preventive checklist — file permissions, firewall rules, login hardening — that's a longer job worth doing once you're confident the current infection is fully gone.
Frequently Asked Questions
Can I just restore an old backup instead of cleaning up manually?
You can, but only if you're confident the backup predates the infection — and many infections sit dormant for weeks before doing anything visible. Restoring a backup that already contains the backdoor just delays the same problem. If you do restore, still change every password and run a scan afterward.
Will Google remove the "Deceptive site ahead" warning automatically once I clean up?
No. After cleanup, request a review through Google Search Console (Security Issues section). It typically takes anywhere from a few hours to a few days for Google to re-crawl and lift the warning once the site is verified clean.
How do I know if the hack is actually gone and not just hidden better?
Run at least two different malware scanners (they catch different signatures), reinstall WordPress core, and manually review any file modified in the last 60 days. If mail suspensions or redirects reoccur within a week, there's still a backdoor somewhere — usually in an unchecked plugin or a database injection.
My whole hosting account got suspended, not just one site — why?
On shared hosting, one compromised site can affect the whole account if file permissions are loose enough for the infection to spread across directories, or if it's sending spam mail that trips abuse filters account-wide. This is one good reason to keep each site in its own cPanel account rather than stacking multiple sites under one.
Should I switch hosts after getting hacked?
Usually not — the vulnerability is almost always in the WordPress install itself (a plugin, a weak password), not the hosting infrastructure. Switching hosts without fixing the underlying cause just moves the same vulnerable site somewhere new. Focus on the cleanup and hardening steps above first.
