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 is 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: 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 gets an attacker one website. Poisoning a plugin vendor gets 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 works like 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. I think that’s indefensible. If a vendor sells the right to push code onto my server, I should hear about it from the seller before the new owner’s first update lands. I heard about it from a malware scanner.
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?
The buyer of a plugin catalog buys the update keys to every site running it.
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 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 didn’t justify 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 I had a reason.
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.
I also moved everything behind Cloudflare. It was a pain in the fucking ass to set up, even for a technical guy, but my site had been getting hammered by about 50,000 bot requests a day, a lot of it from Russian addresses, and that traffic now dies at the edge before it ever reaches WordPress.
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 buried 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 exactly what it is. I took that further than most people would. My site runs over 100 plugins now, and all but about four of them are ones I built myself, each doing one small job I needed.
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.
My take
Check who owns every plugin today. A vendor sold its whole catalog, the buyer poisoned it, and my site was one of hundreds of thousands that took the malware. Ownership changes hide in changelogs and transferred support addresses, and they’re the best warning you’ll get. Cut every plugin you can live without. Then put automatic quarantine and clean backups behind the front door, because the front door will fail eventually.
The lesson that transfers
Every breach and near-breach, including the ones 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. Most site owners never consider the supply chain. You audit your own security and forget that the plugin authors, theme shops and other vendors in your stack can be bought, and their access to your site transfers with the sale.
The injustice is that the people with the most at stake had no say. Site owners who kept their plugins updated, the thing every security guide tells them to do, got malware for their diligence, and the seller walked away with the money. Until plugin marketplaces tell users when a plugin changes hands, every site owner has to watch for it alone, and most of them don’t know they should.
For more from this series, see The Cybersecurity Hub: breaches, audits, and hard-won security lessons from four decades in the trenches.
