Hardening Your cPanel Server: Beyond the Basics After CVE-2026-41940

Security is a moving target. With the recent discovery of CVE-2026-41940, it has become clear that just having a firewall isn’t enough anymore. If you’re running a shared hosting environment, you face a unique challenge: you need to keep your system open enough for customers worldwide to log in, but closed enough to keep hackers out.

While tools like Two-Factor Authentication (2FA) are great, they wouldn’t have prevented the specific entry methods used in recent exploits. Here is a guide on how to further protect your InterServer VPS or Dedicated Server.

1. Lockdown Your Management Ports

If you don’t have resellers and you access your server from a static IP address, there is no reason for the WHM management ports (2086 and 2087) to be open to the entire world. You can restrict these using the ConfigServer Security & Firewall (CSF).

• Edit your configuration file: /etc/csf/csf.conf
• Locate the TCP_IN list and remove 2086 and 2087.
• Restart the firewall with csf -r.

By doing this, only whitelisted IPs can even see the login page for your server management.

2. Managing Resellers with cPHulk

If you do have resellers, locking down ports to a single IP might not work. In this case, use cPHulk to block entire countries where you don’t expect any legitimate business. You can find these settings in the WHM Security Center. This narrows your “attack surface” significantly by stopping traffic from regions where you have no customers.

3. Use Real-Time Malicious IP Blocklists

Why wait for an attack to happen? You can tell your firewall to automatically block IPs known for malicious activity. We recommend adding these lists to /etc/csf/csf.blocklist:

• DSHIELD: DSHIELD|86400|0|https://www.dshield.org/block.txt
• INTERSERVER: INTERSERVER|3600|0|https://sigs.interserver.net/ip.txt

4. Disable the WHM Terminal Feature

Recent security audits have shown that the Terminal feature within the WHM UI can be a major point of entry. Even if you have locked down SSH, hackers have used this UI feature to install malware. We now recommend disabling it entirely by running this command:

touch /var/cpanel/disable_whm_terminal_ui

For more details, check out the cPanel support guide.

5. The Ultimate Safety Net: A Proper Backup Policy

Security isn’t just about stopping attacks; it’s about recovery. If a breach happens, your backup is your only way back. However, not all backups are safe. You must understand where your data is going:

• Local Disk Backups: These fail if your hard drive dies. Not recommended.
• Secondary Disk Backups: These survive a drive failure, but if a hacker compromises the server, they can delete these backups too.
• Remote Location Backups: This is the best choice. Storing data off-site ensures it survives hardware failure and server compromises.

For the best performance, we recommend JetBackup (commercial license required). We suggest JetBackup specifically for its very fast incremental speeds; it only backs up files that have changed, making it incredibly efficient for large servers. Pair this with InterServer Remote Storage to keep that data secure and off-site.

Depending on your setup, you can follow the official configuration guides here:

• cPanel Backup Configuration
• DirectAdmin Backup and Restore

6. The Gold Standard: CloudLinux and Imunify360

If you are serious about shared hosting security, the combination of CloudLinux OS and Imunify360 is unbeatable. Imunify360 includes KernelCare, which allows for “rebootless” kernel updates. This means when a major vulnerability is found in the Linux kernel, your server is patched instantly without you having to schedule downtime for a reboot.

7. Hardening SSH and Mail Protection

SSH is often the first place a bot will try to attack. To truly harden your server, you need to go beyond the default settings. We recommend the following changes to your SSH configuration:

• Change the Default Port: Move SSH away from the default port 22 to a random high-numbered port. This stops 99% of automated “script kiddie” attacks.
• Disable Root Login: Set PermitRootLogin no in your configuration. This forces you to log in as a standard user and then switch to root, adding a vital extra layer of security.
• Disable Password Authentication: Switch to SSH Keys and turn off password logins entirely. Key-based authentication is virtually impossible to brute-force compared to even a strong password.

Finally, protect your server’s reputation with MailBaby for outgoing email. By routing your mail through a smart relay, you ensure that even if one account on your server gets compromised and starts sending spam, your main server IP won’t get blacklisted. This keeps your legitimate emails landing in inboxes, not spam folders.

Take a moment today to review your security. Check our Backup Availability per Service guide to see what’s currently active on your account, and reach out to our support team if you need help hardening your system!