I’ve spent decades in cybersecurity, so I know how this sounds: my website got malware. Both my sites run WordPress on SiteGround, and one morning I got an email from their scanner. Malware detected, quarantined, fix this within three days or bad things happen. That’s nearly a direct quote. My heart fluttered. This site is my business.
The prescribed fix was easy. The quarantined file was sitting right there; delete it and the alert clears. I deleted it immediately. And then I didn’t stop, because deleting the payload without understanding the entry isn’t remediation, it’s housekeeping. If you don’t know how it got in, it’s coming back.
Two days of forensics
I spent the next two days investigating, working with an AI assistant as a research partner, a workflow I recommend to anyone doing solo incident response. The question was simple: what put that file there?
The answer turned out to be bigger than my site. A WordPress plugin vendor had sold their entire plugin catalog to a new owner, and the new owner poisoned it. Updates pushed through the legitimate update channel carried malware to every site running those plugins. Hundreds of thousands of installations received the infection through the front door, signed and delivered by the normal update mechanism. The episode is publicly documented, and reading the reports was an education: this wasn’t a break-in. The attackers bought the supply chain.
My plugins didn’t appear on the published list of the sold catalog. That proved nothing, and I treated it as proving nothing. Lists compiled during an active incident are incomplete by nature.
Why are supply chain attacks the scariest?
Understand the economics and you understand why this attack class is growing. Breaking into one website earns an attacker one website. Poisoning a plugin vendor earns the attacker every site running that vendor’s code, delivered automatically, through a channel every site trusts by design. In this incident, one acquisition converted into a foothold on hundreds of thousands of sites at the same time. No exploit development, no scanning for vulnerabilities, no defenses to defeat, because the update mechanism isn’t a defense, it’s a welcome mat.
The purchase angle deserves more fear than it gets. We train ourselves to imagine attackers as intruders, but nothing requires intrusion when ownership is for sale. Small software vendors sell their products constantly, for retirement, for consolidation, for a payday, and the transaction transfers something no one prices correctly: the standing, trusted access to every installation. The buyer of a plugin catalog buys the update keys to every site running it. Due diligence flows one direction in those sales, toward the buyer.
The users, whose sites are the actual asset changing hands, are never consulted and rarely notified.
Nobody broke in. The attackers bought the plugin vendor and pushed malware through the update channel every site trusts by design.Share on X
What clue revealed the WordPress supply chain attack?
What cracked it was timestamps. One of my plugins had updated within the same thirty seconds as the infection landing on my server. Update completes, malware appears, thirty seconds apart. That’s not coincidence, that’s causation with a receipt. I proceeded on the basis that the plugin was poisoned, removed it, and moved to hardening.
How do you harden WordPress after a supply chain attack?
Because I’m a security guy, cleanup wasn’t the end. I went through the whole site the way I used to go through enterprise systems after an incident. I removed every plugin that wasn’t earning its place, on the reasoning that every plugin is a vendor relationship and every vendor relationship is supply-chain exposure. I hardened configurations across both sites.
Then I upgraded my host’s scanning to the premium tier, and the reason is worth understanding. The base scanner detects and notifies: you get the three-days-or-else email and you do the work. The premium tier quarantines automatically, no email, no three-day clock, plus a weekly scan report. I pay for the privilege of never getting that heart-flutter email again. Anything that drops malware into the site gets locked in a box before I ever hear about it. For a business that lives on its website, that’s some of the cheapest insurance available.
How do you audit your own supply chain?
After the incident I formalized what I now do routinely, and what I recommend to anyone whose business depends on a website. Inventory your plugins and ask of each one: who owns this today, and is that who owned it when I installed it? Ownership changes are usually announced quietly, in changelog entries and transferred support addresses, and they’re the single highest-value signal available. A plugin that changes hands isn’t necessarily compromised, but it’s just re-rolled the dice on the only question that matters. That’s whose code executes inside your site.
Then shrink the surface. Every plugin I removed during the hardening pass was a vendor relationship I no longer had to monitor. The plugin count on a typical WordPress site reflects accumulation, not need, and each entry on the list is a party you’ve granted code execution. Treat the list the way an enterprise treats vendor access, because that’s precisely what it is.
Finally, assume the front door will fail anyway and position something behind it: server-side malware scanning with automatic quarantine, file-change monitoring, and backups that predate any compromise. My quarantine email was the system working. The premium upgrade was me deciding the system should work without needing me in the loop.
The lesson that transfers
Every breach, every near-breach, every breach I merely read about, I treat the same way: as a lesson, followed by whatever work it takes to make that class of incident impossible for me. That habit came from enterprise incident response and it applies at every scale. The supply-chain angle is the part most site owners never consider. You audit your own security and forget that every plugin author, every theme shop, every vendor in your stack can be bought, and their access to your site transfers with the sale.
Trust is transitive, and attackers know it.
For more from this series, see The Cybersecurity Hub: breaches, audits, and hard-won security lessons from four decades in the trenches.
