The Morning I Found a Plugin I Never Installed

One morning I found malware on my website, delivered through a channel I trusted.

I told that story in full in My Own Site Got Hit: Anatomy of a WordPress Supply-Chain Attack, including the two days of forensics and the trail that ended at a plugin vendor’s catalog sold to an attacker. The short version: my host’s scanner caught the payload the instant it landed, deleting it took a minute, and understanding how it arrived took two days. Total damage: zero. By the standards of website compromises, that is the best possible outcome, which is exactly why I can tell the story calmly.

This article is not about the incident. It is about what the incident started.

The part that actually scared me

The malware itself was not the frightening part. Malware is weather. If you run anything on the public internet, attacks arrive constantly, automatically, indifferently. My logs show thousands of probes a day, and yours do too, whether you look or not.

The frightening part came later, staring at that folder, when I asked the obvious question: how many ways could something like this get in?

I have spent 33 years in technology, a good chunk of it responsible for keeping large systems running, so I made a list. It was a long list. The theme I was running, built by people I had never met, updated on their schedule, not mine. Dozens of plugins, each one a channel that pushes code onto my server whenever its author publishes an update. The page builder with its own ecosystem of addons. Every one of these is a trusted delivery pipeline into my website, and I did not choose most of the people I was trusting.

That is what the security industry calls the supply chain, and once you see it, you cannot unsee it. I had locked my front door carefully. Meanwhile, forty vendors held keys to the back.

Run the same inventory on your own site and the list gets uncomfortable fast. Your theme updates when its author says so. Every plugin updates when its author says so. Your page builder, your forms tool, your SEO plugin, your gallery, each one is a standing arrangement in which code you have never read arrives on your server and runs with full permissions. Any one of those authors getting compromised, or selling their plugin to someone with worse intentions, or simply abandoning it to whoever claims the name later, converts a trusted channel into a delivery vehicle. None of that requires anyone to attack you specifically. You are just downstream.

Why this matters more than traffic

Here is the frame that made this personal rather than academic. I am a service provider. My website is not a store shovelling widgets, where traffic volume is everything. It is my beacon on the internet. It is where I live professionally. The people who matter do not arrive by the thousands; they arrive a few at a time, having heard my name somewhere, and they are deciding whether to trust me with a significant project.

For a business like that, the website has one job: be excellent for the person standing in front of it. Fast, credible, professional, and above all trustworthy. I have written elsewhere about why the website matters more in the AI era, not less, and about what building on WordPress actually involves once the brochure promises wear off. Now imagine that person arrives the week my site is serving spam pharmacy links from a hidden injection, or redirecting to a scam, or simply gone while I rebuild it.

Everyone understands ordinary downtime. A major cloud provider hiccups and half the internet disappears for an afternoon; visitors shrug and come back tomorrow. Outages are weather too, and people forgive weather. A compromise is different in kind, because a compromised site does not just go dark. It impersonates you. It uses your name and your reputation to serve someone else’s garbage to the exact people you most needed to impress. Downtime is forgiven. Impersonation is remembered.

How do you audit WordPress plugins after a scare?

So I went down the rabbit hole, and I went down it properly. Over the following weeks I opened up everything running on my sites and asked each piece the same questions. What do you actually do? Who maintains you? What happens on my server when your author publishes an update? What would it cost me to remove you?

The answers were educational, and some of them were ugly.

I found a commercial theme that turned out to be an assembly of mismatched parts, shipping code to every visitor for features no page on my site ever used. I found a page builder whose assumptions had quietly wrapped themselves around dozens of my pages, so deeply that leaving it meant rebuilding every page that touched it. I found plugins that did the one thing I wanted plus fifteen things I did not, all of it loading on every request. I found excellent software maintained by exactly one person, and thought hard about what happens to my business the day that one person stops.

The process itself was mundane, which is why anyone can do a version of it. For each piece of software I asked who publishes it, when it was last updated, how its support threads read, and what its changelog says about momentum. Ten minutes per plugin, no code reading required. The pattern that emerged surprised me: the risk was not concentrated in obscure plugins from unknown authors. Some of the heaviest, most tangled, most difficult-to-remove software on my sites came from the biggest names in the WordPress ecosystem, installed years ago because everyone else used them too. Popularity had stood in for evaluation, and popularity measures marketing, not engineering.

None of those discoveries were the breach. That is the point. The breach was an event, handled in an afternoon. The audit revealed conditions, and conditions are what determine whether the next event is an afternoon or a catastrophe.

What this series covers

That audit became this series of articles. Each one takes a piece of what I found and turns it into something you can act on without being a developer:

Why so many commercial themes are Frankenstein monsters of repackaged parts, and how to evaluate a theme by what it does rather than what it includes. Why page builders are the hardest relationship to leave, and what it actually took to get out of two of them. How to put your plugin stack on a diet without losing capability. Why the number of people maintaining your software matters as much as the software itself. How the supply chain delivers attacks through the very update mechanisms you depend on, and not just in software, since these days even a cable can carry a hostile computer inside it. And finally, why security is a posture you hold, not a product you install.

The takeaway before the series

If you take one thing from this article, take this: your website’s biggest risks arrive through channels you invited. Not through the front door an attacker forces, but through the updates, themes, plugins, and tools you trusted enough to install. That does not mean stop trusting; a modern website is built entirely of other people’s work, mine included. It means trust deliberately. Know what is running, know who maintains it, know what it would cost to remove, and keep something watching for the day one of those trusted channels betrays you. And keep real backups, because every other defense can fail and that one still saves you. If you would rather have someone who has been through this handle it, that is work I do.

I got the easy version of the lesson. The folder appeared, the scanners caught it, and the worst consequence was a series of articles. The next site owner may not get the easy version. The rest of this series is about making sure that when your turn comes, and on a long enough timeline it comes for everyone, your story is as boring as mine.