WHMCS holds your clients' names, addresses, invoices and, through the server module, the keys to their hosting accounts. It is the one application on your server worth attacking on purpose. None of the steps below take more than a few minutes, and together they close the routes that real WHMCS compromises use.
1. Delete the installer
If install/ still exists, anyone can open it. Remove it the moment the install finishes:
rm -rf install/WHMCS shows a red warning in the admin area until you do.
2. Lock configuration.php
The file contains the database password and the encryption hash for stored card data. Make it read-only:
chmod 400 configuration.phpIf a future update needs to write to it, WHMCS tells you; loosen it for that minute and tighten it again.
3. Rename the admin directory
Every WHMCS on the internet has /admin/, so every bot tries it. Rename the directory to something not guessable and tell WHMCS in configuration.php:
$customadminpath = "office-x7k2";Update any bookmarks. The client area is unaffected.
4. Restrict the admin area by IP
If you and your team work from fixed addresses, add an .htaccess inside the renamed admin directory:
Require ip 203.0.113.0/24
Require ip 198.51.100.7On nginx-served Plesk sites, use Apache & nginx Settings → Additional directives for the location instead. If your IP changes often, skip this step and rely on the next two.
5. Turn on two-factor authentication
Configuration → System Settings → Two-Factor Authentication. Enable a time-based (TOTP) option and make it mandatory for administrators. A leaked password then gets an attacker nothing.
6. Move the writable directories
attachments, downloads and templates_c must be writable by PHP, which makes them the natural place for an attacker to drop a script. Move them above the document root and point WHMCS at the new paths:
$attachments_dir = "/var/www/vhosts/yourbrand.com/whmcs-data/attachments/";
$downloads_dir = "/var/www/vhosts/yourbrand.com/whmcs-data/downloads/";
$templates_compiledir = "/var/www/vhosts/yourbrand.com/whmcs-data/templates_c/";Create the directories first and give them the site user's ownership. Do the same for crons/ with $crons_dir, then update your cron job path.
7. Force HTTPS and set the URL
Under General Settings, set the WHMCS URL with https:// and, in Plesk, enable the permanent redirect from HTTP. Cookies carrying an admin session should never cross the network in plain text.
8. Remove unused modules
Every gateway and registrar module you are not using is code that could have a vulnerability. Deactivate them, and delete the folders under modules/gateways/ and modules/registrars/ that you will never use. Fewer moving parts.
9. Use a dedicated database user
The database user in configuration.php should have rights on the WHMCS database only. If you created it as a Plesk database user attached to that one database, you already have this.
10. Keep WHMCS updated
Security releases are announced in the admin dashboard. Apply them within days, not months; the changelog for each one tells attackers what to look for in unpatched installs. The WHMCS 9 upgrade guide covers doing it without downtime.
11. Back up the database daily
Plesk's scheduled backups cover files. Add a nightly database dump too, stored off the server:
mysqldump --single-transaction whmcs_db | gzip > /backup/whmcs-$(date +%F).sql.gzA restore is only useful if you have tested it once.
12. Read the logs occasionally
Configuration → System Logs → Admin Log shows every admin login with its IP. Activity Log shows changes to clients and settings. A glance once a week catches a compromised admin account before your clients do.
What this does not cover
Application-level rules such as CAPTCHA on the client login, rate limiting and disabling client registration for closed businesses live under General Settings → Security and are worth a look. And none of this replaces server hardening: firewall, Fail2ban and automatic updates on the box itself, which on a managed VPS or a VPSPioneer reseller account is already done for you.