cPanel Server Security Checklist: 15 Essential Steps for 2026
A secure cPanel server needs more than a strong root password. Hosting companies and agencies must protect administrator access, hosted applications, email and backups together. This cPanel server security checklist outlines 15 practical steps for reviewing a Linux hosting environment in 2026.
Before you change your WHM security settings
This guide is for server administrators with root or appropriate WHM access. Resellers and website owners should ask their hosting provider to handle server-wide changes. Available features vary by version, operating system and installed software.
Confirm backups and provider console access before changing SSH, firewall or authentication settings. Record the current configuration, apply changes in a controlled maintenance window and verify that websites, email and administrator access still work.
Quick cPanel security checklist
- Keep cPanel, the operating system and PHP supported
- Run WHM Security Advisor
- Enable two-factor authentication
- Use strong, unique credentials
- Secure SSH without locking yourself out
- Restrict exposed ports with a firewall
- Configure cPHulk brute-force protection
- Enable and tune ModSecurity rules
- Scan for malware and investigate the entry point
- Keep WordPress and other applications updated
- Limit account privileges and isolate workloads
- Audit file permissions and scheduled jobs
- Protect outbound email from abuse
- Store off-server backups and test recovery
- Monitor security events and maintain a response plan
1. Keep cPanel, the operating system and PHP supported
An unpatched hosting stack can expose every account on a server. Inventory your operating system, cPanel release tier, PHP versions, database and web server. Replace end-of-life components and apply supported security updates through a documented maintenance process.
Review WHM Update Preferences and update logs. Check that scheduled updates actually finish, plan required reboots and test critical websites after changes. Avoid changing release tiers or upgrading production databases without compatibility checks and a recovery plan.
2. Run WHM Security Advisor
Start with WHM → Security Center → Security Advisor. It provides a useful baseline for configuration weaknesses and missing protections, but it is not a complete penetration test.
Record the findings, assess their impact on your environment and assign an owner to each remediation. Run it again after major changes. A clean report does not prove that hosted applications or third-party plugins are secure.
3. Enable two-factor authentication
A stolen password should not be enough to administer your hosting environment. Enable the server's two-factor authentication policy in WHM, then configure it for your administrator and reseller accounts. Encourage cPanel users to enroll too.
Enabling the policy makes enrollment available; it does not automatically enroll every user. Maintain a verified recovery process, protect authenticator secrets and check integrations separately. API tokens need their own access controls.
4. Use strong, unique credentials
Use a password manager to generate different passwords for WHM, cPanel, email, databases and application administrators. Review the minimum password strength policy and remove shared administrator credentials where practical.
Rotate credentials after suspected exposure and when staff access ends. Do not place passwords in public repositories, support screenshots or website files. Review stored deployment credentials and database configuration permissions.
5. Secure SSH without locking yourself out
Use passphrase-protected SSH keys for administration. Restrict SSH access to approved administrators and consider a VPN or IP allowlist where your team's connectivity permits it.
Before disabling password authentication, prove that key-based access works in a second session and confirm your provider's console or rescue access. Changing the SSH port can reduce background noise, but it does not replace authentication or patching.
6. Restrict exposed ports with a firewall
Allow only services your server actually needs. Separate public website and mail traffic from administrative access, and review both the provider firewall and the server firewall.
Follow cPanel's port requirements for your active services. Account for DNS, mail, FTP passive ports, monitoring and backup destinations. Choose a maintained firewall compatible with your operating system; blindly copying rules can interrupt legitimate traffic.
7. Configure cPHulk brute-force protection
Enable and review cPHulk in WHM → Security Center. Set thresholds suitable for your users, monitor repeated authentication failures and enable useful notifications.
Add carefully selected trusted management IPs before tightening restrictions and retain console access. Large allowlists weaken protection. cPHulk helps with authentication attacks; it does not remove malware or patch vulnerable websites.
8. Enable and tune ModSecurity rules
A web application firewall can help identify and block suspicious HTTP requests. Enable ModSecurity with a supported, maintained rule set and verify compatibility with your Apache or LiteSpeed configuration.
Inspect audit logs before adjusting rules. If a legitimate request is blocked, narrow the exception to the affected rule and application where possible. Disabling the WAF across the entire server leaves unrelated sites exposed.
9. Scan for malware and investigate the entry point
Use a maintained malware scanner appropriate to your hosting stack. Schedule scans, route alerts to someone who can act and establish a quarantine and recovery process.
A detected file is a starting point. Preserve useful evidence, investigate access logs, cron jobs and unexpected accounts, and identify vulnerable software or exposed credentials. Replacing infected files alone may leave the attacker able to return.
10. Keep WordPress and other applications updated
Server-level patches do not fix an abandoned WordPress plugin or an outdated CMS. Inventory hosted applications, update their core software and extensions, and remove unused themes and plugins.
Use supported software from trusted sources and avoid nulled extensions. Test important updates with a backup available. If a website is already compromised, pair cleanup with credential rotation and a review of how the attacker gained access.
11. Limit account privileges and isolate workloads
Review reseller privileges, shell access, sudo permissions, FTP accounts and API tokens. Give each identity only the access its work requires and remove permissions when that work ends.
Disable unnecessary shell access or use an appropriate jailed environment. Where supported and licensed, evaluate CloudLinux CageFS for filesystem isolation and LVE for resource control. Resource limits help contain workloads; they are not a malware prevention guarantee.
12. Audit file permissions and scheduled jobs
Check unexpected FTP users, SSH authorized keys, writable application directories and cron entries. Keep secrets outside public document roots where applications permit it and use ownership appropriate to the account.
Avoid blanket chmod 777 fixes or recursive ownership changes without understanding the application. Compare suspicious changes against deployment history. Restrict compiler access where appropriate while accounting for legitimate build requirements.
13. Protect outbound email from abuse
A compromised mailbox or application can send spam and damage a server IP's reputation. Review mail queues, sending rates, authentication failures and unusual outbound traffic. Apply sensible account limits and investigate sudden spikes.
Maintain SPF and DKIM and introduce DMARC according to the domain's legitimate sending sources. Authentication does not stop every compromised account or guarantee inbox placement. Also review PTR records and the server's mail identity with your infrastructure provider.
14. Store off-server backups and test recovery
Backups should survive loss of the hosting server. Keep protected copies outside the server, with retention matched to business needs and credentials that do not give a compromised web account control over every copy.
Monitor completed jobs and test a representative account restoration in an isolated environment. Confirm that files, databases and required configuration are recoverable. A successful backup job is useful evidence, but a working restore is the stronger check.
15. Monitor security events and maintain a response plan
Track service health, disk capacity, login anomalies, malware findings, backup failures and mail abuse. Send important alerts through a channel that will still work if the hosted mail server is unavailable.
Document who responds, how to preserve logs and how to contact the provider. Review access monthly and test recovery periodically. If root compromise is suspected, isolate and investigate the server and consider a rebuild from trusted media rather than assuming an account-level cleanup is sufficient.
Turn the checklist into a maintenance routine
Prioritize unsupported software, exposed administrator access, missing backups and evidence of active compromise first. Then schedule the remaining improvements and keep a record of changes. Security controls work best when someone checks their results and responds to failures.
For a broader operational routine, read why regular server maintenance matters. HostGree provides managed cPanel/WHM server administration, security audits and hardening, WordPress malware cleanup and email deliverability troubleshooting.
Frequently asked questions
Is cPanel secure by default?
cPanel provides security controls, but administrators still need to configure access, maintain supported software, monitor events and protect hosted applications. Default settings are not a substitute for ongoing server management.
Do I need both cPHulk and ModSecurity?
They address different risks. cPHulk helps detect authentication abuse, while ModSecurity inspects web application requests. Neither replaces a network firewall, software updates or malware investigation.
How often should I review server security?
Monitor important alerts daily, review updates and backup results routinely, and perform a broader access and configuration review monthly or after major changes. Adjust the schedule to the importance and activity of your services.
Can a firewall stop WordPress malware?
A firewall can reduce exposure, but it cannot guarantee that a vulnerable plugin or stolen application credential will not be exploited. Combine it with application maintenance, least privilege, scanning and a recovery plan.
Official documentation and further reading
Reviewed against cPanel documentation on October 6, 2026. Check the documentation for your installed version before applying configuration changes.