This entire series exists because of one attack on my own site. The morning malware appeared on my site through a poisoned plugin update, documented in the full anatomy article, sent me down a rabbit hole. I came back up with a changed view of where website risk lives, and every article in this series has been working toward this one.
I used to think of attacks as things that come at your website: brute force on the login, exploits against vulnerabilities, bots probing forms. Those still exist, and defenses against them still matter.
But the attack that reached me didn’t come at my site. It came through it, riding a channel I’d built, trusted, and automated. The supply chain is the attack surface now, and most site owners have never once looked at theirs.
Why do attackers target the supply chain?
Your instincts were trained on strangers at the door, and this comes from family.
Understand the economics and the shift makes perfect sense. Breaking into one website earns an attacker one website. But every WordPress site sits at the end of a delivery network: theme updates, plugin updates, hosting infrastructure, the libraries those plugins themselves depend on. Compromise any point upstream and you don’t get a website. You get every website downstream of that point, delivered automatically, through a mechanism each of those sites trusts by design.
In my incident, a plugin vendor sold their catalog and the buyer poisoned the updates. Hundreds of thousands of sites received malware through the front door, signed and delivered by the normal update process. Nobody broke in anywhere. The attackers purchased a road and every site on it. (See also a supply chain crack under every WordPress site: PHP2Shell)
Nobody broke in: the attackers bought a trusted road and every site at the end of it.
How silently that can happen is the worst of it. A vendor can sell a catalog installed on hundreds of thousands of sites, and the people running those sites find out when the malware arrives. I think marketplaces that let ownership change hands without telling anyone are failing every site owner who trusts them.
Once you see the pattern you find it everywhere. Abandoned plugins claimed by new owners with different intentions. Developer accounts phished, then used to push one poisoned release. Popular free tools changing hands, the sale announced nowhere. In each case the malicious code arrives with the credibility of the legitimate channel it rode in on, so none of your instincts flag it. Your instincts were trained on strangers at the door, and this comes from family.
Does the supply chain stop at software?
The supply chain doesn’t stop at your plugins folder, and 33 years in technology have taught me that the physical layer is always worse than people assume.
Today you can buy a cable, an ordinary-looking charging cable, with a complete hostile computer hidden inside the connector.
Plug it into a laptop and the cable itself attacks the machine, no software download required. That product exists, commercially, at hobbyist prices. The same logic extends to USB drives from conferences, cheap peripherals from marketplaces flooded with counterfeit electronics, and refurbished gear with pre-installed passengers. Every physical object that touches your systems shipped through a chain of hands, and you trusted all of them by default.
I’m not raising this to make anyone paranoid about their mouse. I’m raising it because the mental model transfers exactly: risk arrives through trusted channels, and the trust is exactly what makes the channel useful to an attacker. Software update, browser extension, cable. Same attack, different packaging.
Why is a compromised site worse than an outage?
A distinction from the series opener belongs here, expanded, because it explains why supply chain compromise deserves more of your worry than downtime ever did.
Outages are weather. A major cloud provider stumbles and half the internet vanishes for an afternoon; your visitors shrug, because their bank and their favorite store vanished too. Nobody concludes that you’re untrustworthy. They conclude the internet had a bad day, and they come back.
A supply chain compromise is different in kind, because a compromised site doesn’t go dark.
It stays up, wearing your name, serving someone else’s payload: spam links under your brand, redirects to scams, malware handed to the exact people who came because they trusted you. Downtime interrupts your beacon. Compromise inverts it, converting your accumulated credibility into the attacker’s distribution network. People forgive downtime. They remember impersonation, and for a service business whose site is its credibility, the one they remember is the expensive one.
My take
Trusted channels are where attacks come from now, and they work because of that trust. Look at your supply chain the way an attacker does. Who owns each plugin today, and would you know if it changed hands? The same goes for the cable on your desk and the USB drive from the conference. Downtime gets forgiven. A site serving malware under your name doesn’t. That risk is worth losing sleep over.
How do you live with a supply chain you cannot eliminate?
You can’t opt out. A modern website is other people’s code all the way down, and the update channels that carry risk also carry the security patches you need. Freezing updates chooses the known vulnerabilities over the unknown ones, and anyone who tells you to switch updates off and sleep well is handing you advice that’ll get your site compromised. The job is managing the supply chain you’ve got, and the earlier articles in this series turn out to be the management program.
Shrink the surface. Every theme module, every plugin, every builder is a channel. The plugin diet is a security program as much as a performance one; every removal is one fewer road into your server. Know your upstreams. The maintainer check is supply chain due diligence wearing a friendlier name. Ownership changes, dying projects, and support forums going quiet are exactly the conditions that precede a channel changing hands.
Watch what lands. I caught my incident the instant the payload arrived because I had scanning in place before I needed it. Whatever tools you choose, the principle is non-negotiable: something automated must watch your files, because the attack that matters will arrive dressed as something that belongs.
Keep the escape hatch. Real, tested, off-site backups are the answer to the day everything else fails. Every other defense reduces probability. Backups reduce consequence.
And update anyway. It bears repeating, because the lesson some people take from supply chain attacks is exactly wrong. The poisoned update is rare. The unpatched vulnerability is constant. Take the updates, and watch what they deliver.
| Practice | What it means | Why it matters |
|---|---|---|
| Shrink the surface | Cut themes, plugins and builders you don’t need | Every removal is one fewer road into your server |
| Know your upstreams | Check maintainers, ownership changes and support forums | Those conditions precede a channel changing hands |
| Watch what lands | Run automated scanning on your files | The attack arrives dressed as something that belongs |
| Keep the escape hatch | Keep real, tested, off-site backups | Other defenses reduce probability; backups reduce consequence |
| Update anyway | Take the updates and watch what they deliver | The poisoned update is rare; the unpatched vulnerability is constant |
The people who pay for a compromised site are the visitors who trusted it, and I think every site owner owes them the basics: fewer plugins, maintainers you’ve checked, something watching your files, and backups you’ve restored. Skipping those because the site seems fine today is how your name ends up fronting somebody else’s scam, and your visitors won’t care that a plugin vendor did it.
The final article in this series pulls all of it together: security as a posture instead of a product, and why nothing you can install matters as much as how you think. If you’d rather have someone who has walked through the aftermath manage your site’s supply chain, that’s work I do.
Frequently Asked Questions
