Your site works fine. That proves nothing.

A client called because a few subdomains were down. The main site was fine. It looked like the smallest problem of the week.

It was exactly the wrong way round.

What we thought it was

Seven subdomains returned an empty HTTP 500. DNS was fine, certificates were fine, Apache answered on all of them. The error log said the same thing thousands of times:

PHP Parse error: syntax error, unexpected token "{" in .../index.php on line 2

Line 2 was not our code. It was a webshell — a backdoor, dropped into a file beside the real page.

And here is the interesting part. That backdoor was written using $variable{38}, a syntax deprecated in PHP 7.4 and removed entirely in PHP 8.0. The host had upgraded PHP. The malware could no longer run — and it took the whole page down with it.

The subdomains were not broken. The malware in them was.

The site that did work

While we were looking at seven broken sites, the main site sat happily on 200. Nobody was worried about it.

It had a different variant: one PHP 8 still understands. No error, no blank page, nothing. It simply worked — which meant it was still running.

The only site that worked was the only site whose backdoor was still alive.

That is the whole lesson of the week. A working website proves nothing. Our first instinct was to investigate what was broken and trust what was not. That instinct nearly cost us the one live backdoor.

Why it came back

We cleaned it. Eight hours later the file was back.

The answer was two lines appended to a WordPress core file, six seconds before everything else:

include "/home/.../backup/app/security/assets/css/16869";
include "/home/.../modules/cache/live-traffic/138527";

Files with no extension, in a directory dressed up as a security plugin's cache. Search for *.php and you will never find them. Only a diff against the original WordPress release exposes it — two lines in a 26 kilobyte file.

There was more. Over eleven thousand attacker-planted .htaccess files allowlisting the attacker's own shells. The host's scanner meanwhile reported "no malware detected" while six were live — and one backdoor carried that same scanner's name and copyright line in its header. Anyone reading a file listing sees the name of their own security software and moves on.

What to take from it

A 200 is not a clean bill of health. Your site can look perfect for months while somebody else is reading it. Most malware is written specifically not to be noticed — being noticed is how it gets removed.

Do not repair an error you do not understand. Had someone tidied up that "syntax error", seven working backdoors would have come back. The crash was the only thing keeping them harmless.

A green dashboard is not evidence. It is a vendor telling you they found nothing. That is not the same as there being nothing.

Put your site in version control. Not one site on that account was in Git, so there was no known-good state to compare against and every file had to be judged on its contents alone. That, more than the malware, is what made it expensive.

---

Want to know what is on your own site? Our Website Health Scan looks at speed, technical SEO, security and cookie compliance over three working days, and hands back one written list: what is broken, what it is costing you, and what to fix in what order. Fixed price, no subscription.