How to Keep Your cPanel Account and Sites Secure

To keep a cPanel account and its websites secure, reduce what an attacker can reach at every layer: the login, the computer you log in from, the access points you forgot you created, and the software that runs on every site. Turn on two-factor authentication, limit where logins can come from, keep the computer clean, then delete every email account, FTP login, WordPress install, plugin, theme, database and domain you do not use. Each one is a door, and most accounts that get compromised have several open doors they never needed.

This guide is in four parts: the login, the computer, the inventory and clean-up, and the leftovers you cannot see in the panel. The site-level steps inside WordPress are in how to secure WordPress on cPanel hosting. Screens follow cPanel’s current layout; if a label differs on your version, search for it from the box at the top of cPanel.

Part 1: Protect the login#

Turn on two-factor authentication properly#

Go to Security → Two-Factor Authentication and choose Configure Two-Factor Authentication. cPanel asks for your password, then shows a QR code. Scan it with an authenticator app. Good choices are Aegis (Android, open source), Microsoft Authenticator, Google Authenticator and 1Password or Bitwarden if you already use them. Enter the six-digit code the app shows to confirm.

cPanel then shows a set of backup codes. Each one works once, and they are the only way in if you lose your phone. Copy them into your password manager now, not later. Keep the authenticator on a device you use every day, and a second device with the same setup if your provider allows it, so one lost phone does not lock you out.

After it is on, log in once from a new private window to confirm the code prompt appears. If your browser has an old session open, end it from the panel’s session list if it offers one, so an old session cannot outlive the change.

Use a password nobody else has#

Under Security → Password & Security, change the account password to 20 characters or more, generated by a password manager. Never reuse it anywhere else, and never reuse an email password for cPanel. The panel password is the key to FTP accounts, databases and mailboxes that share it, so one reused password gives an attacker the whole account.

Limit where logins can come from#

Under Security → IP Access Control, add the addresses you log in from. Logins from anywhere else are refused before the password is even checked. The trade-off is real: if your home address changes, you are locked out. Add a second route first, such as an office address or a VPN exit, and test it before you remove the old one. Keep your hosting provider’s support contact somewhere you can reach it without the panel.

Watch for login attempts you did not make#

Check the login history if your version of cPanel shows it in the Security section. If you cannot find it, ask support for the account’s login log. Look for logins from countries you do not work in, or at times you are asleep. A failed-login spike followed by a success is the pattern of a password being guessed or reused.

Part 2: Keep the computer you log in from clean#

Most account takeovers do not start on the server. They start on a laptop: a file downloaded from a convincing source, a browser extension that reads every page, or a stolen saved password. Once an attacker has your cPanel password and your two-factor code, the server’s own defences see a normal login. Treat the computer as part of the account’s security.

Run a full antivirus scan#

On Windows, open Windows Security → Virus & threat protection → Scan options → Full scan and let it finish. A full scan takes an hour or more on a large disk, so run it overnight. Then run Microsoft Defender Offline scan from the same menu. It restarts the PC into a clean environment and scans before Windows loads, which catches malware that hides from normal scans. Save your work first: the PC restarts.

On macOS, use a reputable antivirus product or Apple’s built-in XProtect, and check System Settings → General → Login Items for anything you do not recognise. On Linux desktops, the same principle applies: check the autostart programs and the packages you installed yourself.

An antivirus scan is not a guarantee. If you find something, or if you installed anything from an unfamiliar source recently, assume the machine has been used against you and do the rest of this part before logging in to cPanel again.

Check what starts with Windows#

Open Task Manager (Ctrl+Shift+Esc), go to the Startup apps tab, and disable anything you do not recognise. Then check the programs list under Settings → Apps → Installed apps, sorting by install date. A program you cannot remember installing, installed around the same time as a strange download, is the one to investigate.

Audit your browser#

• Extensions: remove any you do not use or do not recognise. An extension with permission to “read and change all your data on all websites” can capture a password the moment you type it.
• Saved passwords: do not let the browser store the cPanel password. Store it in a password manager, and clear the browser’s saved entries for your hosting, registrar and email logins.
• Sessions: sign out of cPanel and the panels you use when you finish. Browsers keep the session cookie, which an attacker with access to the browser profile can reuse.

Do not run what you cannot verify#

Most stolen hosting accounts came from something a person chose to run: a cracked plugin or theme, a “free” premium tool, an installer script from a forum, or a file attached to a message that claimed to be an invoice. Download plugins and themes only from the official directory, and check any file you did not expect with a scanner before you open it. Never run software from a cracked source on the computer that holds your hosting passwords.

Protect the SSH key and its folder#

If you use SSH keys with the account, the private key on your computer is as valuable as the password. Give it a passphrase (the setup is in how to set up SSH keys on Windows), and keep its folder readable only by you. In PowerShell:

icacls "$env:USERPROFILE\.ssh" /inheritance:r /grant:r "$($env:USERNAME):(OI)(CI)F"

Then check that no other account on the computer is listed with access. Keep a separate Windows user account for everyday work, and use an administrator account only when a task needs it, so a downloaded program does not run with full rights.

Check whether your passwords have already leaked#

Look up your email address at a breach checker such as Have I Been Pwned. If a breach shows a password you still use, change it everywhere, starting with the cPanel account, the registrar and the email account that resets all your other passwords.

Part 3: Inventory and remove what you do not need#

An unused email account, a forgotten FTP login or a WordPress install from 2019 with an old plugin is a working door for anyone who finds it. The aim is the smallest possible set of accounts, sites and software: everything you keep, you know the purpose of.

Back up before you delete anything#

Deleting is the one step you cannot undo. Under Files → Backup, download a full backup first, and check that the file opens. For each site you intend to remove, also export its database from phpMyAdmin. Only then delete.

Make the inventory#

Work through the panel once, and write down what you find. A simple table is enough:

Remove unwanted email accounts#

Email is one of the most common entry points, because a mailbox’s password can reset accounts elsewhere. Go to Email → Email Accounts and, for each address, ask who uses it. If nobody does, delete it. Before you delete a mailbox, check its forwarders and filters, because mail sent to the address may be going somewhere you rely on.

For a mailbox people still use, reset its password to a long unique one and check the list of connected devices and the forwarders. Then check the mail itself: a forwarder that copies all incoming mail to an address you do not recognise is a quiet form of data theft.

• Forwarders: delete any forwarder to an address you do not recognise. Under Email → Forwarders.
• Autoresponders: remove any you did not create; they can be used to send messages from your address.
• Email filters: review the account-level filters, which can silently move or copy messages.
• Track Delivery: look for sudden spikes in outgoing mail, which indicate a compromised form or script sending spam.

Remove unwanted FTP accounts#

Go to Files → FTP Accounts. Each FTP login gives access to files, and some can reach more than their home folder if they were created with the wrong directory. Delete every account you cannot attribute to a person or a deployment. For the ones you keep, make sure the home folder is the narrowest one that works, and move each to SFTP. Plain FTP sends the password unencrypted. Use SFTP, which runs over SSH, for anything you still need, with the SSH key or a strong password.

If the account has shell access, the same list is available from the command line, which also shows the FTP accounts the panel might not display clearly:

uapi --user=YOURUSER Ftp list_ftp

Remove unwanted WordPress sites, plugins and themes#

This is where most hacked cPanel accounts were compromised: an old WordPress install that nobody updates, with a plugin that has a known flaw. Work through the installs in the installer your host provides. For each, decide whether it is live, and delete the ones that are not.

Deleting a WordPress install in an installer removes its files, but often not its database, and the database holds the login hashes for its admin users. So:

1. Export the database from phpMyAdmin, then check the export opens.
2. Remove the install from the installer or delete its folder in File Manager.
3. Delete the database in MySQL® Databases, then its database user, if no other site uses it.
4. Remove the folder if anything is left behind, including the site’s subfolders under other domains.

Within a live site, remove what it does not use. Inside the WordPress admin, under Plugins, deactivate and then delete each plugin you do not need. Under Appearance → Themes, delete every theme except the one the site uses, and keep one default theme as a fallback. Inactive plugins are not harmless: their files still run when requested directly, and they still get attacked when they are outdated.

If you have command-line access and WP-CLI is installed, list what is inactive, and then delete it deliberately:

wp plugin list --status=inactive --path=/home/YOURUSER/public_html
wp theme list --status=inactive --path=/home/YOURUSER/public_html

Remove databases, users and domains you no longer use#

Go to MySQL® Databases. Every database should belong to a site you keep, and every database user should be attached to exactly one database. A user attached to several databases is a common way one site’s leaked password reaches another. Remove databases that belong to deleted sites, and remove the users that were attached only to them.

Under Domains, remove addon domains, subdomains and parked domains that point to nothing. A parked domain that still resolves to your account can be used to host content on your name, and an old subdomain can point at a folder that still runs an old script.

Revoke tokens and keys you cannot name#

Under Manage API Tokens, delete any token whose purpose you cannot explain. Under SSH Access, delete keys whose owners have left, and check each key’s comment against a person or a system. Under Cron Jobs, read every line: a job that downloads a file from an unknown address, or runs a script from a folder you did not create, is the first sign of a compromise.

Part 4: Find the leftovers you cannot see in the panel#

Even after a clean-up, a backdoor can survive: a PHP file hidden in an upload folder, a modified file inside a plugin, a cron job the panel does not show. If your account has shell access, these checks find most of them. Run them as your cPanel user, and read the output before deleting anything.

PHP files inside upload folders. Uploads should hold images and documents. A PHP file there is almost always an intruder:

find ~ -path '*/uploads/*' -name '*.php' 2>/dev/null

Files changed in the last week. Compare the list with the updates you made yourself:

find ~ -type f -mtime -7 -not -path '*/cache/*' -not -path '*/.cache/*' 2>/dev/null | head -100

Core WordPress files that should not change. WP-CLI can compare every core file with the official copy:

wp core verify-checksums --path=/home/YOURUSER/public_html

Plugin files that differ from the directory. Run this for each plugin you keep:

wp plugin verify-checksums --all --path=/home/YOURUSER/public_html

Scheduled jobs and keys, from the command line:

crontab -l
cat ~/.ssh/authorized_keys 2>/dev/null

A checksum mismatch in core files is strong evidence of a compromise. Restore those files from a clean copy of the same WordPress version, do not edit them by hand, and change every password on the account. Then ask your host to review the account, because a file can be replaced in ways the checks above will not show.

Part 5: Keep the isolation and the malware tools working#

If your host runs CloudLinux, its CageFS layer keeps each account’s files out of reach of other accounts, and resource limits stop one runaway site from using the whole server. If Imunify360 is installed, it scans uploads for known malware and blocks repeated attacks at the firewall. Check its dashboard weekly for quarantined files and blocked addresses. When a clean site starts showing errors, look at its log first, because the firewall may be blocking a legitimate request.

Give each site its own PHP version where you can, and keep versions on the ones that still receive security fixes. An old PHP version left in place for one old site is a reason to retire that site, not to keep the version.

Part 6: Back up, and know what to do if it happens#

Download a full backup every week, and store a copy outside the account. A backup inside the same account is deleted in the same attack that damages the site. Test a restore of one site at least once a quarter.

Know the signs of a compromise: logins you do not recognise, cron jobs, FTP accounts, API tokens or SSH keys you did not create, files with recent dates in folders you never edit, outgoing spam, and visitors redirected to unrelated pages from search results. If you see any of them:

1. Change the cPanel password from a clean computer, and revoke every API token and every SSH key.
2. Disable the affected FTP accounts and email accounts until you have checked them.
3. Take a backup of the current state, so the evidence is kept.
4. Restore compromised WordPress files from clean copies, and change every site admin and database password.
5. Ask your host for a review of the account. Changing passwords alone does not remove a backdoor.

A checklist to review each month#

1. Two-factor is on, and the backup codes are stored in the password manager.
2. IP access control lists only addresses you use.
3. Every email account, forwarder and FTP login has a named user.
4. Every WordPress install is live, updated, and has no inactive plugins or unused themes.
5. Every database and database user belongs to a site you keep.
6. Every cron job, API token and SSH key is explained.
7. Imunify360 has no unexplained quarantines.
8. The most recent full backup is downloaded and stored off the account.
9. The computer you log in from has a recent full antivirus scan and no unknown startup programs.

Common mistakes to avoid#

• Relying on two-factor and nothing else. It guards the panel login, not the mailboxes, FTP and databases.
• Deleting a WordPress install and keeping its database. The database still holds admin login hashes.
• Switching plugins off instead of deleting them. Inactive code can still run and still gets attacked.
• Keeping FTP accounts for “just in case”. Each one is a password that can be guessed or reused.
• Sharing one database user across sites. One leaked wp-config.php then exposes every database it touches.
• Trusting a cracked plugin or theme. It is the most common way a hosting account is compromised in the first place.
• Storing the cPanel password in the browser on a shared computer. Anyone who uses that browser can use the account.
• Restricting IP access without a second route in. One changed address and you are locked out.

Frequently asked questions#

Is two-factor enough on its own?#

No. It makes the panel login much harder to take over, but the account is also reached through email, FTP, databases, WordPress admin logins and API tokens. Each needs the clean-up in part 3.

How often should I run the clean-up?#

Do the full inventory once now, then the monthly checklist. A new site, plugin or email account should be added to the inventory on the day it is created, so it does not become the forgotten one.

Can antivirus on my computer protect the hosting account?#

It protects the computer, which is one of the most common routes in. It does not protect the server, which is why the account-side steps still matter. The two together cover both ends.

What if an old site is still used by a client?#

Move it into its own account, or onto a plan that can support it properly, before you remove it from this one. Keeping it here means its risks stay with every other site on the account.

Do I need shell access to do this?#

No. Every part except the checks in part 4 can be done from the cPanel interface. The checks in part 4 are faster on the command line, but the same questions can be asked by reading each list in the panel.

Can I delete everything and start again?#

You can, and sometimes it is the cleanest option for an account that has been compromised. Take a complete backup first, check it, and restore only the content you have verified as clean.

The short version: protect the panel login with two-factor and a unique password, make sure the computer you log in from is clean, then delete every email account, FTP login, WordPress install, plugin, theme, database, domain and key you cannot name. Check what remains for leftovers, and keep a backup outside the account.