I write a lot about keeping other people’s stuff safe online. Fair’s only fair if I’m honest about the time it went wrong on my end too.
A few weeks back I found malware sitting on my hosting account. Not hypothetically — actual malicious files, quietly dropped onto the server, doing exactly what malware does. Here’s what happened, how I fixed it, and what’s changed because of it.
How it happened
My hosting account had six separate WordPress sites sitting on it, sharing the same underlying filesystem — a live client site, an old ex-client site I still had access to, and a handful of my own test builds and experiments I’d never got round to deleting.
Malware turned up on four of those six, all with identical timestamps down to the second. That’s the giveaway: it wasn’t four separate break-ins. It was one compromise, and because everything shared the same account, it spread sideways to every site sitting next to it — including the live one.
On top of that, I found several old, half-finished test copies of my own site still sitting there with working login pages, and — embarrassingly — a full backup of the entire site just sitting downloadable at the web root, no password needed. None of that caused the malware. But it’s exactly the kind of loose end that makes a compromise worse once one happens.
What I did about it
First job was working out how bad it actually was. I checked every core WordPress file against the official checksums, scanned tens of thousands of PHP files by hand for malicious code, and went through the database line by line. The live client site came back clean — genuinely clean, not “looked fine so I stopped checking.”
Then the cleanup: quarantined everything suspicious, deleted every test build and old install that had no business still existing, and shut down anything that wasn’t a real, current site. What was left afterwards was two clean installs, both fully updated, each with exactly one admin account.
I also went back and hardened things that had nothing to do with how this particular malware got in, but were still worth locking down anyway — blocking anonymous access to WordPress’s built-in username list, and switching off an old remote-access feature (XML-RPC) that most sites don’t need and few people remember exists.
The actual lesson
It wasn’t a flaw in the website software. It was hosting hygiene — old test sites I should have deleted months ago, sitting on the same account as work that mattered.
So that’s changed. Client work now lives on its own hosting account, on its own — never sharing space with test builds, old experiments, or anything of mine that doesn’t need to be there. A site is only as secure as the weakest thing sitting next to it, and I’d rather that never be true again.
Why I’m telling you this
Because if I write a post telling you to use a password manager and turn on two-factor, and then quietly sweep my own mistakes under the rug, that’s worth nothing. This is the boring, unglamorous side of running websites — but it’s the side that actually matters.
If you want to know how your own site is hosted, or whether it’s sharing space with something it shouldn’t be, ask me. I’ll tell you straight.