Expert orientation, as of June 2026.
The call nobody wants
Recently, on an ordinary afternoon, an email from a host landed with a business owner. The gist: your website is locked. The malware scanner found malicious code, and until that is sorted out, nobody sees your site any more, only a password prompt.
The owner forwarded the notice to me. Less than an hour later I was on the case and secured the whole webspace first, exactly as it was: over ten thousand files, a good hundred megabytes. Somewhere in there sat three directories that had no business being there.
Three plugins nobody ever installed
The first was harmlessly named after security, roughly the way a burglar puts on a high-vis vest. The second was the actual weapon: a backdoor that takes the attacker’s commands and runs them on the server. The third left only a tiny marker, so the attacker can find infected servers again later.
The camouflage was telling. At first glance the file names read like perfectly normal WordPress components. Only on a second look did the swapped letter show up, an “l” instead of an “i”, in a spot nobody checks in a directory listing. Small, inconspicuous, effective.
That is the moment the real decision is made. Not “how do I clean this up?”, but: can I trust this installation at all any more?
“What could possibly happen to such a small site?”
That is the question I hear most often, and it is the most dangerous one. Because the attacker could not care less whether your site has three subpages or three hundred. Your content does not interest him. What interests him is what sits behind the site: a server, a domain, a name people trust. That is exactly what he turns into money.
What happens next almost always runs quietly:
- Your domain sends spam. Within hours, thousands of phishing emails go out in your name. The result: your domain lands on blacklists, and suddenly your real emails, quotes, invoices, replies to customers, no longer arrive. This drags on for weeks.
- Foreign pages appear under your address. Hundreds of hidden subpages for gambling, fake medication or counterfeit goods, slipped into your domain. Google finds them and demotes your site, or shows visitors a red warning: this site may harm your device. Your visibility is gone.
- Your site becomes a trap for others. A deceptively real bank login form suddenly sits on your domain. The scam email that goes with it carries your domain name as the bait. Strangers enter their passwords there, and your good name was the hook.
- The server works for criminals. It attacks other sites, mines cryptocurrency at your expense, or hands further malicious code to your visitors.
And if the site ran a contact form or held data anywhere, the hack can quickly turn into a reportable data protection incident, with a deadline and an awkward letter to those affected.
The insidious part: you often notice nothing for months. No loud “Hacked by” banner, that was the old days. Today the infection is quiet, because quiet pays better. You find out when the first customer calls and says: “Hey, a strange email just came from you.” Or when the host locks the site, as happened in this case.
Repairing means guessing
Back to the decision. The honest answer to the trust question is usually no. Once you have had a backdoor in the system, you never know for certain that it was the only one. A second, neatly hidden way in is enough, and a few days later the same attacker is standing in the house again. You clean, he comes back, you clean again. Work where the burden always stays with you.
On top of that comes the real problem: the hole the attackers came through is often still there after the clean-up. And that hole almost never sits in the core of WordPress itself. It sits in the extensions.
The numbers for 2025 are unambiguous. The security firm Patchstack counted over 11,000 new vulnerabilities in the WordPress ecosystem, which works out to more than thirty every single day. 91 percent of them sat in plugins; in the core of WordPress itself there were six. And for almost half of them there was no fix at all by the time they were made public. So the vulnerability is publicly known before the matching update even exists.
It gets exploited in record time. For the most heavily attacked vulnerabilities, the median was just five hours from disclosure to the first attack. About half of the serious cases were hit within a day.
Read that slowly. A vulnerability becomes known, and before you have had lunch, automated attacks are already knocking at thousands of sites at once. “Just update regularly” is no plan against that pace; it is a race you lose structurally the moment enough foreign code runs on your site.
The second option: leave it out
The affected site was a calling card on the web. A handful of pages, a few texts, a legal notice. No shop, no login, no customer area, nothing that changes from day to day.
Yet WordPress brought along the full machinery: a database, a login form, a dozen extensions, an entire piece of software that runs code on every page view. Plenty of moving parts for content that stays the same for months. Those moving parts are precisely the attack surface.
So we took them away. The hacked installation became a plain, static site. Pure HTML, delivered like a document. No database for anyone to break into. No login to brute-force. No writable directories for malicious code to nest in. On top of that the proper security headers and forced encryption.
The same day the site was reachable again. This time without the door the attacker had strolled in through, because that door simply no longer exists.
When a CMS is the right choice anyway
Now the fair counter-argument, because it is not always that simple.
There are good reasons for a content management system. A shop with orders. A members’ area. A blog that grows daily. Bookings, forms, everything that genuinely lives and changes constantly. Where that is needed, a CMS earns its place, and then it has to be hardened properly: two-factor login, as few extensions as possible, real backups, automatic updates.
The mistake is a different one. It is the five-page company site that changes twice a year and still carries the full risk of a full-blown piece of software. Out of pure habit. Because that is how it is done.
I have nothing against WordPress. Well hardened and reduced to the essentials, it runs reliably. It also tops the hack statistics simply because it is the most widespread system on the web, and therefore the most rewarding target. But after a break-in, “repair” is often not a security gain, only the feeling of one. And feeling is a poor defence against the next automated attack.
The real lesson is simple: every piece of code you do not need can be used against you.
When your site is suddenly locked
An infection lives on speed, and on the wrong thing being done in the first panic. If your site goes offline without warning or the host reports malicious code, that is a case for damage control. Together we look at what actually happened, and then decide whether cleaning up is enough or the clean cut is the wiser move. Let’s talk.
Frequently asked questions
My WordPress site was hacked. Can’t I just have it cleaned up?
Sometimes yes, but with a caveat. After a break-in it is almost never possible to prove that every backdoor was found. A single overlooked way in is enough for the next infection. Above all, the original vulnerability often stays open after the cleaning. Whether repair makes sense or a rebuild depends on what the site actually needs to do.
How do I tell that my site is affected?
Often the host gets in touch first, because its scanner triggers and locks the site. Other signs: unexplained new files or users, redirects to foreign sites, warnings in Google Search Console, or your domain suddenly sending spam. When in doubt: better to have someone look once too early than too late.
Isn’t a static site a step backwards?
On the contrary. For a site whose content rarely changes, static is faster, cheaper to run and considerably harder to attack, because there is almost nothing to attack. Appearance and function for the visitor stay the same. What falls away is the technology in the background that you never saw but always paid for, in risk.
What happens to my content and my findability when I switch?
Texts, images and structure are carried over, and the addresses of your pages stay the same. For Google, nothing about your visibility changes for the worse; the higher speed actually helps. The only thing that matters is that the move is done cleanly, so that no address leads nowhere.
How quickly can a replacement site be online?
For a manageable company site, often the same day, as in the case behind this article. What matters is not speed alone, but that the vulnerability which led to the break-in is closed afterwards, and not merely covered over.
This article describes a real incident in anonymised form. It is expert orientation, not security advice for an individual case.