WordPress Plugin Supply Chain Attacks: Hunting for Backdoors with AI with Austin Ginder

Robert: Hello and thanks everyone for joining. Today it’s a pre-recorded session. By the time this airs, we’ll be in Krakow at WordCamp Europe, so follow our social media channels for updates from us about the event.

We’re also running our yearly security survey. You can help us by participating, so we can get a better understanding of what people are doing to secure their websites. We’ll publish the results in September, like we do every year, so everyone can learn from each other about what works and what doesn’t when it comes to keeping websites secure. 

Please don’t forget to like and subscribe so you’re notified whenever there are new episodes.

Today, we’ll be talking mostly about supply chain attacks, and there’s a lot that falls under that topic, including how people actually discover these things in the wild. There have been quite a few cases lately in the WordPress ecosystem. Supply chain attacks aren’t exclusive to WordPress, but they are on the increase. I have someone who’s been looking deeply into this. He’s Austin, the developer and owner at Anchor Hosting. How are you, Austin?

Austin: I’m doing good. Great to be here and share what I’ve been finding. Happy to chat about all things WordPress.

Robert: I’ve seen a few interviews of yours on Kinsta, and I’ve been reading your blog. You’ve done quite a lot of research, and I really like how you write. You describe the full case, the timeline, everything that happened, and what you did. Before we dive in, a quick introduction to what you do.

Austin: I run Anchor Hosting. It’s a WordPress hosting management service, kind of a hybrid model where I resell web hosting and handle all the maintenance, which includes security. It’s mostly a solo-run business. I have a few folks who help out from time to time, but I’m currently managing around 3,000 WordPress sites. That gives me maybe a unique perspective and a useful sample size, especially with how AI is changing everything right now.

Robert: 3,000 websites, I’m sure they keep you busy.

Austin: I’m very efficient. If you go back years and watch some of my WordPress.TV talks from WordCamps, I’m all about efficiency. Being a developer, my main thing is the command line: how can I write a script, how can I automate things? That’s the DNA of my business.

Robert: You mentioned you take care of security and AI. From our email exchanges and other interviews, you’re not a security person; you’re a developer. But thanks to what you’ve been encountering, you’ve been moving more into security and diving deep into supply chain attacks. Let’s start from the beginning. At what point did your job shift from hosting and maintenance to cleanup and security?

Austin: In the past, I’ve always handled malware incidents for my customers. But one thing I do differently is I require all of my sites to be fully up to date. So historically, the amount of incidents I deal with has been pretty low when you move a site over, get everything current, and keep after it, the chances of a hack or malware infection go down.

I say “historically” because that changed recently. The first wave, I think, happened in November and December of last year, 2024, when I saw an uptick of previously clean sites getting backdoors planted. Then, around February, it seemed like all those backdoors were activated at once. It was like a land rush. I saw a huge increase in sites that were already in a good place, starting to get compromised.

There are different categories of hacks: credential-based attacks, where someone just signs in; plugin vulnerabilities that let an attacker get into the site; and lower-level attacks, where they get partial access and can tweak certain settings. February was when I started using AI to combat this, because the hackers were using AI to discover zero-day vulnerabilities, which was giving them access to sites that were previously well-maintained.

Robert: So you started using Claude Code more aggressively?

Austin: Yes. When I first did a security audit on a hacked site with Claude Code, my mind was blown. You can give it SSH access, tell it to do a full scan, figure out how the attacker got in, check the security logs for hacker IP addresses, and look at all the logged-in users inside WordPress. You can endlessly ask questions and get a level of detail that was previously impossible to stitch together. Obviously, anything’s possible manually, but it’s completely unrealistic to expect a developer to sift through every server log and every file change to build the full picture.

So that was the start of it. In February, I started cleaning up sites using AI. And some of these security reports got so in-depth that I started uncovering larger issues I had completely stumbled upon.

Robert: Do you have a specific process for cleaning up websites, especially since, as you said, these were already well-maintained sites?

Austin: A lot of it is trial and error. You’d be amazed at how far you can get just starting a conversation with “my site’s infected, please help” in Claude Code. What’s happened since is that I’ve reset security on many fronts. I have a lot of new processes in place now.

One example: I inject a must-use plugin for all my customers. It’s lightweight and handles a few things for my hosting platform, magic login links, and user enumeration protection to prevent usernames from leaking out to the internet. I kept adding to it because I needed a baseline of protection for all these customers.

Producing better security reports means feeding AI more data. A few things I have that are a bit unique to my setup:

I do long-term backups. If you’ve been an Anchor Hosting customer for years, I’ve got nightly backups going back to 2020. Having a long time frame of backups gives you much greater visibility. A lot of these malware attacks aren’t “I got in one day and broke stuff,” it’s “I got in and did nothing for a year, then acted.” So if you can point AI at years of backups, it can fill in the gaps.

I also do what I call “quick saves,” a lightweight Git repo that stores just my customers’ themes and plugins, updated every day. The whole purpose is to see what changed, when, and where. If a customer reports something broken, I look at the quick save and can see “this plugin updated and this other one got deactivated.” I can click in and see the file diff. It also lets me revert a paid plugin, such as Gravity Forms Pro, to a previous version.

Feeding long-term backups and quick saves to an AI audit is like a superpower. The AI can crawl through the history and say, “I see that this file also changed two years ago in a very similar way,” then cross-reference the database backup from that time, spin up a local copy, and sift through WP-CLI commands. It produces a very rich picture and lets you uncover things that were previously hidden.

Robert: At what point did you realize this wasn’t just an individual website issue but a much bigger problem?

Austin: That’s a good question. I have to go back to my first discovery. As part of reprocessing my security approach, I started building better ways to catch malware. One of my new alerts was checking for changes in JavaScript code every day. It scans the site, pulls out all the JavaScript tags, and if anything changes, it emails me. It’s a simple diffing system. I might get ten of these emails a day, but instead of reading them manually, I have my AI pull all the JavaScript changes, download every single one, and look for anything harmful.

This all came about because one of my customers got hit with a credit card skimmer on a fully up-to-date site, a zero-day exploit. Every keystroke on the checkout page was being sent to the hackers. Every card was being stolen.

After I cleaned that up, the first thing my new system actually caught was a plugin called Widget Logic. The AI flagged it, “I see something that looks strange here. It’s showing a football widget, which isn’t related to this plugin.” And when I dug deeper, I realized: this code isn’t on WordPress.org at all. What happened is that at some point in the past, the original authors moved on, the domain for the update server expired, and a hacker registered it, got SVN access, and started preparing a supply chain attack. The AI figured out there was a five-year gap in authorship, which pointed directly to what had happened.

I reported it, WordPress.org was very responsive, and they closed it down right away. It was a completely accidental discovery; the real research came from just asking the right questions of Claude Code.

Robert: For the listeners who aren’t familiar, what exactly is a supply chain attack?

Austin: Supply chain attacks are attacks that come through the normal update channel. You install a plugin from WordPress.org, and the plugin could have a malicious author, or someone may have stolen the developer’s credentials and pushed out a bad update. WordPress sites are hardwired to check for updates, so when you update, you’re getting that update through the official WordPress.org channel. If you get hacked by doing an update, that’s a supply chain attack. The official update mechanism is the one doing the harm.

Robert: So someone injects themselves into the update process and controls things from there. And there are different methods, such as changing the update server, manipulating version numbers, buying a legitimate plugin, and pushing malicious code later?

Austin: Yes, exactly. Let me describe the three main types I’ve encountered.

The first is an expired domain. The original author moves on; their domain expires. A hacker registers it, and because the plugin is still pointing to that domain for updates, the hacker now controls what gets pushed. That was the Widget Logic case.

The second involves version manipulation. Some attackers push bad code, then immediately “fix” it, but they lie about the version numbers, stuffing zeros into them so nobody actually gets the update. Their goal is to keep as many sites as possible on the bad version for as long as possible.

The third is a direct purchase attack. Someone buys an established plugin portfolio in one case, someone spent over $100,000 to buy a company with 30-plus plugins, then waits, and pushes malicious code. The Essential Plugins situation was actually a public case study on Flippa praising the sale. Then the buyer used it to plant backdoors across hundreds of thousands of sites. WordPress.org caught it and patched everything quickly, but the intent was clear.

Robert: Across your fleet of 3,000 sites, how many were affected by the Essential Plugins case?

Austin: It was installed on maybe 20 to 30 of my sites. Only one actually got compromised. That’s huge praise to the WordPress.org team for identifying and stopping it. They were working through all 30 plugins within the day before they got shut down.

Robert: And the Quick Page Post Redirection plugin that was a different kind of discovery?

Austin: Yes, and I could only find that one because I manage a large number of sites. I built a tool to hash all of my plugins and look for variant hashes. If you’ve got the same version of a plugin installed across multiple sites, you expect the same codebase. If they show up with different hashes, something is wrong.

The tool found 12 sites using a variant version of the Quick Page Post Redirection plugin, a very popular plugin. When I dug in, that variant went back five years. At some point in the past, someone hijacked the plugin’s update mechanism. Anyone who updated at that moment got a compromised version. And the hacker maintained and released his own variant updates for years after. The only trace in WordPress.org’s codebase was a single commit reference from five years ago.

I reported it to WordPress.org. They shut down the plugin. But here’s the hard part: you can’t force all the people running the variant version to switch back to the official one unless they individually reinstall it. In some of these cases, I reached out to security researcher friends who could look at the variant, identify the callback server, and work to get it taken offline through the ISP and domain providers. Even years later, that’s still meaningful work.

Robert: That tells us there’s probably still more out there that we haven’t found yet.

Austin: Absolutely. This has been going on all along, there just hasn’t been a way to surface it. As a community, we have to accept that there are probably supply chain attacks from the past that we haven’t uncovered yet, and that still have consequences today.

Robert: What can be done at the WordPress.org level to help mitigate these issues?

Austin: It comes down to code auditing, both on the upload side and after the fact. All of my discoveries have been reactive: something bad happened, I reverse-engineered what went wrong, and learned from it. From a proactive standpoint, you can scan code through AI and try to catch some of these things before they go live. But whatever mechanism you put in place, bad actors will try to work around it. You need both: better proactive scanning and reactive scanning for vulnerabilities and malware after the fact.

My goal is a 100% code audit for all my customers’ sites. I’m working toward that by building a hash database. For every plugin and theme, if you reduce them to a unique hash, you only have to audit them once. Once you’ve audited a hash with the latest AI model and identified what’s wrong with it, including exploits and malware flags, you can build a database. That’s what I’ve been working on with WP Registry.

Robert: Can you explain WP Registry and WP Beacon?

Austin: WP Registry at wp-registry.io is the beginning of a hash database. You can see everything I’ve hashed. There’s also a plugin you can download and run as a WP-CLI command to check your own sites against my database. My guess is that most sites will show 20% coverage because my customer pool only represents so many installs, but even at 20%, you have a guarantee that those plugins are verified and identified.

WP Beacon is the scanner I built to proactively find supply chain attacks. I fed it the fingerprints from my three previous discoveries, specific infrastructure patterns, hardwired server connections, and had it scan the top 2,000 WordPress.org plugins via SVN. It ran for 17 hours. While I was on a call with a friend, it flagged a critical finding, a scroll to top plugin with the exact same infrastructure as the ones I’d found before. Same fingerprints, probably the same hacker or the same off-the-shelf tooling. I reported it to WordPress.org, and they took it offline.

Robert: It’s interesting because we built File Monitor at Melapress around a similar principle, hashing all the files on a site and alerting if anything changes, including comparing WordPress core files against the official hashes from WordPress.org. We’re adding plugin support soon. The fact that not enough people use it surprises me, honestly.

Austin: Hashing is a brilliant mechanism not just for verifying plugin state, but for understanding plugin intent. WordPress actually has a built-in verify checksum command you can run on your codebase and on anything from WordPress.org. We should be running AI-powered code audits on every hash and making those findings publicly available, with vulnerabilities embargoed until patched, of course. This doesn’t have to be an official project. The community can do this. The technology is there. Claude Code 4.8 does a fantastic job finding problems, and you can layer multiple AI models plus human researchers on top of each hash. That’s a future I think we can actually build.

Robert: It’s a great example of AI being used for good because some of these past supply chain attacks took months or years to surface. You uncovered one in an hour.

Austin: Exactly. And what’s interesting right now is that even inexperienced hackers have access to AI, so they’re finding and exploiting zero days they wouldn’t have found before. But they’re also burning those zero days quickly because they’re fumbling through them. Once a zero day is found and patched, that door is closed. From an ecosystem standpoint, I think everything is getting better. There are more findings right now because AI makes scanning easy, but everything being found is also getting fixed.

Robert: Any thoughts on the EU Cyber Resilience Act and the software bill of materials, the idea that every plugin should list its third-party dependencies?

Austin: Honestly, I’m not deeply familiar with it, so I don’t have a strong opinion. General guidelines on what to do when something goes wrong would be helpful for individuals. What I will say is: it’s weird that I, someone who doesn’t consider himself a security researcher, can find anything at all. It comes back to the fact that most code has never had real eyeballs on it. With AI, you can get eyeballs everywhere. So it’s finding things. And at the end of the day, that’s all good.

Robert: Austin, before we wrap up, where can people find you and learn more?

Austin: You can find me at anchor.host where I blog regularly. Also on X at Austin Ginder.

Robert: Thank you very much, Austin. Thanks for your time and for sharing all of this knowledge. We’ll link to WP Registry, WP Beacon, and your supply chain write-ups in the show notes. They’re very well written and genuinely worth reading, even if you’re not a security person.

Don’t forget we’re running our yearly security survey, you can contribute at melapress.com/survey. And please like and subscribe. Thanks, everyone.

Austin: Thank you.