Hacked WHMCS: Client Data, Billing and Server Access
By Glenn Lyvers · Updated · 4 min read
Of the applications that get compromised, a client billing system is close to the worst case. It holds your customers' personal and payment details, it stores credentials for the servers and control panels it provisions, and it has an API with reach into your infrastructure. A compromise here is rarely contained to the application itself, and it should be treated as an emergency.
Why this is worse than a website hack
Think about what the system actually holds. Client records with names, addresses and contact details. Payment information, whether stored or tokenised. Support ticket history, which frequently contains credentials customers pasted in. And integration credentials for the servers, control panels, registrars and payment gateways it manages.
That last category is the one that turns a compromise into a cascade. Someone with your billing system's stored credentials may be able to reach every server it provisions, which means your clients' sites are exposed through your systems rather than their own. That is a materially different conversation to have with them than an ordinary outage.
How they get in
An outdated installation is the leading cause, and this is software where updating promptly genuinely matters because vulnerabilities in it are valuable and get attention. After that: a compromised administrator account, often through a reused password or stealer malware on a staff machine; a vulnerable third-party module or addon; and exposed configuration or installation directories left reachable after setup.
Also worth checking: whether the admin directory is at its default path, whether the installation directory was removed after setup, and whether configuration files are readable over the web. Those are basic deployment steps that are skipped surprisingly often.
What to do first
Preserve evidence before you change anything, as covered in preserving evidence, because you will need the activity log and the timeline for what follows. Then take the system offline or restrict it to known addresses while you work — an active intruder in a billing system is doing damage continuously.
Then assume compromise of everything it holds and start the rotation immediately, in parallel with the investigation. The credentials for servers, registrars and gateways matter more urgently than the application itself, because those reach outside your control.
The rotation list
The encryption key the application uses for stored credentials, plus the database password. Every administrator password, and every API credential the system issues or holds. Server and control panel credentials for everything it provisions. Registrar API credentials. Payment gateway API keys. Email and SMTP credentials. Licence and integration keys for addons.
Force a password reset for client accounts as well, since their records were in the database. My guide on rotating credentials after a hack covers the general order, and here the principle is to start with the credentials that reach other systems rather than the ones that only affect this one.
Working out what happened
The activity log is your most useful artefact — it records administrative actions with timestamps and is usually detailed enough to reconstruct what was done. Check for administrator accounts you did not create, API credentials you did not issue, and changes to payment or email configuration.
Then the file side: compare against a clean copy of your version, look for uploaded files in writable directories, check templates for injected code, and check for scheduled tasks. Read your web server logs for the entry point, using the log technique, and use file timestamps to date the earliest change.
The part you cannot avoid
Your clients' data was in that database and, depending on what the system stored, so were credentials to their servers. They need to be told, and they need to be told promptly enough to act — this is not a situation where waiting for complete information serves anybody.
That means a breach notification assessment, which my guide on breach notification obligations covers, and probably a payment card conversation covered in PCI compliance after a skimmer. My guide on telling customers after a hack covers how to write it. Handle the technical cleanup in parallel rather than sequentially — that is work I take on, and the platforms I clean covers what that looks like.
Common questions
Why is a WHMCS compromise more serious than a website hack?
Because of what it holds: client personal and payment data, support history that often contains pasted credentials, and integration credentials for the servers, registrars and gateways it manages. A compromise can therefore reach your clients' infrastructure through your systems rather than theirs.
What should I rotate first?
The credentials that reach outside the application — server and control panel logins it provisions, registrar API credentials and payment gateway keys — before the ones that only affect the billing system itself. Then the encryption key, database password, all admin passwords and every issued API credential.
How did they get in?
Most often an outdated installation, since vulnerabilities in billing software are valuable and attract attention. Otherwise a compromised admin account through a reused password or stealer malware, a vulnerable addon, or configuration and installation directories left reachable after setup.
Do I have to tell my clients?
Yes, and promptly. Their personal and payment data was in that database, and depending on what was stored, credentials to their own servers may have been too. They need enough time to act. There is also very likely a formal breach notification obligation depending on your jurisdiction.
Can I just restore from a backup?
Not on its own. A restore returns the application to an earlier state but does nothing about credentials already taken, and if the backup predates your knowledge of the compromise it may well contain the same vulnerability or backdoor. Rotate credentials regardless of whether you restore.
More than malware
Most people meet me in an emergency. It isn’t all I do.
I’ve been building and repairing systems since 1995. Whatever brought you here, there’s a good chance I can help with the rest of it too — and you’ll be dealing with the same person either way.
Hacked, but not WordPress?
Joomla, Drupal, Magento, Shopify, PrestaShop, Laravel, Node, IIS and plain HTML — cleaned the same way, priced the same way.
Take a look →Custom builds & AI systems
Plugins, custom applications, website chatbots and automation — built to do exactly what you need, maintained by the person who wrote them.
Take a look →Servers, speed, SEO & accessibility
Migrations, faster load times, technical SEO and accessibility fixes. Measured improvements, with the numbers to show you.
Take a look →Better web hosting
Fast, secure hosting with SSL and backups included at no extra charge. Clear pricing, no long-term contracts, no surprises.
Take a look →Classes & free tools
Rather learn to handle it yourself? I teach this, and I give away the tools I built for my own cleanups.
Take a look →Something else broken?
Half my work is untangling what someone else started, gave up on, or broke. Describe it in plain words and I’ll tell you honestly.
Take a look →Tell me what’s wrong. I’ll tell you what it takes.
No queue, no call centre, no sales pitch — one person who answers, quotes honestly, and does the work.