How WordPress Sites Get Broken Into, Ranked by Frequency

Symptoms first, names second

Threat references are usually organised by attack name, which is the wrong way round for whoever is using one. Nobody arrives knowing they have a pharma hack. They arrive because Google is showing pages they never wrote, or the site redirects on mobile only, or a customer reported a warning.

The index above is filtered by symptom for that reason. Start from what is visible and it returns the patterns that produce it – frequently more than one, which is itself worth knowing before committing to a fix.

Three routes account for nearly all of it

Across five hundred recovered sites the entry point is almost always one of three things, and none of them is a flaw in WordPress.

Credentials. A reused administrator password from an unrelated breach, or one weak enough to guess. No vulnerability is involved and no patch prevents it.

An outdated or abandoned plugin. Code with a public advisory and no available fix, or a fix nobody applied. Abandonment is the harder case, because there is no update to install.

Executable uploads. Hosting that allows PHP to run inside wp-content/uploads turns a minor file-upload flaw into a persistent backdoor.

Why cleaned sites get reinfected

The most common thing we are called about is a site cleaned two weeks earlier and infected again.

It is nearly always the same story: the payload was removed and the way in was left open. Malware on WordPress persists in more places than the file system – injected rows in the database, administrator accounts nobody created, scheduled tasks, must-use plugins – and a cleanup that only replaces files misses most of them.

Every page in this section names the entry route alongside the removal, because removal without it buys a fortnight.

Reading this before anything happens

This section is written for an incident and is considerably cheaper to read outside one.

Each pattern names the configuration that permits it. Unique passwords and two-factor close the credential route. A quarterly plugin audit closes the abandoned-code route. Denying PHP execution in the uploads directory closes the third, and it does so against vulnerabilities that have not been discovered yet.

Three changes, none of them expensive, covering the routes behind most of the recoveries this index is built from.

What this index is counted from

The patterns here are the ones that turn up repeatedly in real recoveries, not a taxonomy copied from a vendor’s threat feed. A feed lists every technique that exists; a recovery log records which ones actually arrive at a small WordPress site, and the two are not the same shape.

What arrives is dull and repetitive. A credential reused from a breach on an unrelated service. A plugin the owner stopped updating because it still worked. A file written into an uploads directory that executes PHP because nothing told it not to. Sophisticated attacks against WordPress exist, and they are not what takes a plumbing company’s booking site offline.

That shapes the defence, which is unglamorous for the same reason. No product closes these. Each is a configuration decision, made once, that stops being a decision afterwards – exactly the kind of work that gets deferred forever on a site nobody owns the upkeep of.

Every entry names the route in, the evidence that identifies it, and the change that closes it. Where an incident is happening now rather than being read about, start from the symptom rather than the name.