--- title: What hosting teams get wrong about hacked sites description: Compromised customer sites are a platform problem, not a support problem. Here is how hosting teams should measure, prevent and price the cleanup work. date: 2026-09-21 updated: 2026-09-21 tags: [hosting, security, platform engineering] url: "https://joshdargie.com/blog/hacked-sites-hosting-platform" author: Josh Dargie --- Every hosting company I have worked inside has had a steady flow of compromised customer sites. Not an occasional spike, a baseline. It goes up in the weeks after a popular plugin gets a published vulnerability and then settles back to roughly where it was. What differs from company to company is whether that flow is treated as a support problem or a platform problem. Teams that treat it as a support problem hire more people to clean sites. Teams that treat it as a platform problem end up cleaning fewer sites. ## Cleanups close tickets, they do not fix anything The usual pattern is a tech removes the injected files, resets a password, closes the ticket, and the same account comes back six weeks later. That is because the site got cleaned and the way in did not get closed. An abandoned plugin nobody updates, a leaked FTP credential still sitting in an old desktop client, a second stale copy of the site in a public subdirectory, a shared password used across three accounts. If nobody records how the attacker got in, you are not running a security function, you are running a laundry service. The cheapest change here is a required field on the ticket: a suspected entry point, chosen from a short fixed list, even when it is a guess. After a month of that you can see the shape of the problem instead of arguing about it. In most shops I have reviewed, a handful of causes covers the large majority of cases, and at least one of them turns out to be something the platform is doing, not something the customer did. ## Measure reinfection, not resolution Support dashboards measure time to first response and tickets closed. Neither one tells you whether abuse is getting better or worse, because both improve when your team gets faster at cleaning, which is the activity you are trying to reduce. Two numbers are worth reporting monthly. First, compromised accounts per thousand accounts. Second, the share of those that come back within sixty days. The first tells you how exposed the platform is. The second tells you whether your cleanup process is actually remediation or just cosmetics. If the first number is flat and the second is high, every hour of cleanup labour you are paying for is being spent twice. I have written before about [reading your support queue as an early warning system](/blog/support-queue-signals). Abuse is the part of that queue most likely to be miscounted, because it rarely arrives labelled as abuse. It arrives as "my site is slow", "my email is bouncing", or "Google is showing a warning". ## Write the suspension policy before you need it At some point you will get an upstream complaint at two in the morning about a phishing page on a customer's account, and a level-one tech will have to decide whether to pull it offline. Whatever that person decides without a policy is what you will be apologising for later, to the customer or to your upstream. Decide in daylight. Which categories get suspended immediately with no notice (phishing, malware distribution, outbound spam past a threshold). Which get a notice period and how long. Who is allowed to override a suspension, and where that override gets recorded. What the customer sees on the suspended page, and who contacts them. Then put the customer-facing half of it in your terms of service, in language a small business owner can follow. A suspension that was described in advance is a bad day. A suspension that comes as a surprise is a chargeback and a review. ## Most of the reduction comes from boring defaults The single biggest drop in compromise rates I have seen did not come from buying a better scanner. Scanners tell you the house was already robbed. It came from defaults. Automatic updates for CMS core turned on for new accounts rather than offered. A published end-of-life schedule for old PHP versions with real removal dates, communicated months ahead and then actually enforced. One site per account instead of twenty sites sharing one document root, so a single compromise does not become twelve. Multi-factor authentication on control panel logins, on by default. Per-account outbound mail rate limits, which do not prevent a compromise but cap what it costs you in reputation. None of this is interesting work, and all of it moves the number further than another layer of detection. Some of it is the same operational discipline I described in [running cPanel at scale](/blog/cpanel-at-scale): the defaults you ship to new accounts quietly determine your workload two years out. ## Decide where free ends Unlimited free cleanups teach customers that patching their site is your job, and you will get exactly what you have taught. Charging for every incident pushes compromised accounts into abandonment, and you still end up cleaning the server. The version that holds up is a middle one. One cleanup included as goodwill, with a written explanation of the cause. After that, either paid remediation or a managed plan where updates are genuinely your responsibility and priced that way. The important part is not where you draw the line, it is that the line exists in writing before somebody is upset. If your team is spending its week on this and the number never improves, the fix is almost always upstream of the support desk: in your provisioning defaults, your version policy and your account isolation. That is the kind of review I take on as a fixed-fee engagement or a retainer, and you can see how I work on [platform and hosting problems](/hire#hosting). It is also how I run my own hosting company, [DrivenHost](https://drivenhost.com), which is a useful discipline: you find out quickly which of your policies you actually believe.