{"id":5343,"date":"2026-06-03T14:00:00","date_gmt":"2026-06-03T14:00:00","guid":{"rendered":"https:\/\/frontlinenewsng.org\/?p=5343"},"modified":"2026-06-03T14:00:00","modified_gmt":"2026-06-03T14:00:00","slug":"wptavern-219-austin-ginder-on-how-ai-is-exposing-hidden-threats-in-wordpress-plugin-updates","status":"publish","type":"post","link":"https:\/\/frontlinenewsng.org\/?p=5343","title":{"rendered":"WPTavern: #219 \u2013 Austin Ginder on How AI Is Exposing Hidden Threats in WordPress Plugin Updates"},"content":{"rendered":"
Transcript\n
\n

[00:00:19] Nathan Wrigley:<\/strong> Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley.<\/p>\n

Jukebox is a podcast which is dedicated to all things WordPress, the people, the events, the plugins, the blocks, the themes, and in this case, how AI is exposing hidden threats is WordPress plugin updates.<\/p>\n

If you\u2019d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com\/feed\/podcast, and you can copy that URL into most podcast players.<\/p>\n

If you have a topic that you\u2019d like us to feature on the podcast, I\u2019m keen to hear from you and hopefully get you, or your idea, featured on the show. Head to wptavern.com\/contact forward slash jukebox and use the form there.<\/p>\n

So on the podcast today we have Austin Ginder. Austin has been involved in the WordPress ecosystem since 2010, and since 2014 has run Anchor Hosting, a business that manages thousands of WordPress websites. While he\u2019s a developer and automation enthusiast at heart, in recent months Austin has found himself at the forefront of a burgeoning crisis in WordPress, security supply chain attacks targeting plugins.<\/p>\n

A chance discovery during a malware cleanup on a client\u2019s site, propelled Austin into what would become a wider investigation of plugin vulnerabilities. What he uncovered is both alarming and timely. Bad actors aren\u2019t just hacking sites directly, but are instead infiltrating the supply chain, either by purchasing plugin companies and weaponising them, or by hijacking plugins and pushing out malicious updates. These attacks are subtle, often shifting plugin update servers away from wordpress.org to rogue channels where malware can be distributed, leaving end users in the dark, and their sites at risk.<\/p>\n

We trace Austin\u2019s journey from accidental security investigator to creator of the WP Beacon Project, a resource aimed at tracking, documenting, and alerting the WordPress community to known supply chain attacks.<\/p>\n

He shares how AI tools have radically changed what\u2019s possible in threat detection and forensics, enabling individuals, and hopefully someday, the larger hosting providers to identify patterns and root causes behind widespread infections.<\/p>\n

We get into case studies of specific plugins compromised in recent months, the challenges of auditing over 60,000 plugins in the wordpress.org repo, and the complexities of stopping these attacks once malicious code is in the wild. Austin also discusses his hopes for greater collaboration with hosts and security researchers aiming for better automated monitoring and response.<\/p>\n

If you manage WordPress websites, create plugins, or just care about the future of open source security, this episode is for you.<\/p>\n

If you\u2019re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com\/podcast, where you\u2019ll find all the other episodes as well.<\/p>\n

And so without further delay, I bring you Austin Ginder.<\/p>\n

I am joined on the podcast by Austin Ginder. Hello, Austin.<\/p>\n

[00:03:40] Austin Ginder:<\/strong> Hey, good to meet you.<\/p>\n

[00:03:41] Nathan Wrigley:<\/strong> Very nice to meet you too. I was put in Austin\u2019s way by I think Courtney Robertson.<\/p>\n

Thank you Courtney for that because, on a different podcast, which I do, we were talking about an item, which is very much in the news at the moment. It\u2019s all to do with plugins and security. And whenever I say security, any of the people that I have on the podcast, I feel it\u2019s pretty important that person gets a chance to stamp their credentials into the podcast about themselves. Because it\u2019s one of those areas where a little bit of knowledge can go a long way. Tell us about your background, WordPress hosting, security, those kind of things.<\/p>\n

[00:04:16] Austin Ginder:<\/strong> Sure. So I\u2019m a developer, first off. I\u2019ve been running a WordPress hosting service since 2014, and I\u2019ve been working in the WordPress space since 2010. A long timer. I love automation. WPCLI commands, bash scripts. I\u2019m in the weeds on a technical basis.<\/p>\n

But in terms of security, I wouldn\u2019t call myself a security expert, which is ironic for this conversation because of some of the things I\u2019ve been finding over the last month or so. And it\u2019s all thanks to AI. AI has been my friend. It\u2019s just right place, right time, getting lucky and also just a mix of everything is changing right now in the world.<\/p>\n

[00:04:56] Nathan Wrigley:<\/strong> Yeah. Thank you for that. So as you\u2019re about to hear, we\u2019re not gonna be talking at from the perspective of Austin demonstrates how to fix a particular challenge in WordPress. It\u2019s much more of a general thing, and an alert really. It\u2019s a bit of a call to action about a problem which has been systemic in the WordPress ecosystem, well, forever really, since I guess, plugins came along.<\/p>\n

And this is all about really change of ownership of plugins, and I could do a job of trying to describe the scenario here, but do you want to just run through what you\u2019ve discovered in the last few weeks, and the three or four incidents that you\u2019ve uncovered and what they mean and how they\u2019ve come about?<\/p>\n

[00:05:37] Austin Ginder:<\/strong> Yeah. So in particular, we\u2019re talking about supply chain attacks, and a supply chain attack is a different kind of attack. It\u2019s not a direct, my site got infected with malware or something like that. It runs a little bit more deeper. It\u2019s a scenario where either it can happen a couple different ways.<\/p>\n

A hacker might get control over the plugin repo itself, maybe a credential breach, where they sign in and they are acting as the author, and they push out bad code. As a user, you just update your plugin and you don\u2019t realise you\u2019re updating to something that\u2019s harmful for your website.<\/p>\n

So that\u2019s one scenario. The other scenario which is crazy to me, but like hackers literally buying companies and then weaponizing the plugins themselves and distributing them through the official channels. So that\u2019s the big story that I was covering this last month. That is just what possesses someone to spend six figures to buy a suite of plugins and then weaponize them and try to get away with it? No, that can\u2019t happen.<\/p>\n

[00:06:42] Nathan Wrigley:<\/strong> Except, it does. So let me just reiterate what\u2019s going on there. So if you\u2019ve been to the wordpress.org repository, or indeed you\u2019ve downloaded plugins from third party vendors, maybe a pro version of a plugin or what have you. Usually there is some aspect of the WordPress admin UI, which enables that plugin to be updated by clicking a link or perhaps automated, the update will happen.<\/p>\n

Increasingly, I think people are being, have been encouraged to click enable automatic updates. So it just ticks over in the background. Perhaps while you\u2019re asleep, it gets updated to the latest version. This in a universe occupied only by honest people would be absolutely fine. We\u2019d have no problem that.<\/p>\n

However, the scenario that you are describing is that kind of invisibly it\u2019s entirely possible for somebody to sell their plugin or indeed maybe even have their plugin repo hijacked in some way. But let\u2019s go with the sell their plugin scenario, because that\u2019s the easiest one to get a hold of. Sell it to somebody.<\/p>\n

Obviously, I would imagine in most cases, assuming that person is a good actor, is just going to carry on doing the nice things that the plugin does, updating the code, and doing security updates and what have you. However, there is zero guardrail to stop them putting whatever they want into the plugin.<\/p>\n

And so overnight, a plugin which has been working for a decade or more, doing its job, now suddenly is masquerading. And it may be that the functionality of the plugin is also still there. It\u2019s not like suddenly the plugin just stops working, or it\u2019s really obvious what\u2019s going on. It may be that just a few lines of code have been adapted, modified, there\u2019s some backdoor smuggled in to the plugin. An end user would never know that this was going on. Have I summed that up? Is that about where we\u2019re at?<\/p>\n

[00:08:35] Austin Ginder:<\/strong> Yeah, these are bad actors trying to hide themselves. They\u2019re sneaky. They don\u2019t do things that are obvious. Like they\u2019re not just uploading malware to WordPress plugin repo. What they\u2019ll do instead is they might slip a third party updater, which is against the guidelines, clearly. But they can do it a little bit more sneaky.<\/p>\n

So if they can get a third party uploader put into their plugin, then they can actually hijack the plugin. Meaning you download a plugin from wordpress.org, and you run auto updates, and it updates not from the wordpress.org version to the newest wordpress.org version. It offloads to their own compromised update channel.<\/p>\n

And then once it\u2019s on the update channel, wordpress.org has zero visibility, and you\u2019re just running a hijacked plugin and you don\u2019t even know it. Unless you go in and you run a verify command, from the command line or, you\u2019re scanning for things like this. And then after they get the plugin hijacked, that\u2019s when they compromise your site.<\/p>\n

They could do SEO spam attacks, or display ads, or poison the search results from Google\u2019s perspective. Many different things that they do to try to recoup their money in the investment.<\/p>\n

[00:09:50] Nathan Wrigley:<\/strong> So let me just run that by you again. So just to make sure I\u2019ve understood. So in this scenario, the plugin, it is like a one time thing in a way, but we\u2019ll explore that as well in a moment. The plugin is acquired by somebody else and potentially some of the behaviour that you\u2019ve seen is that the only part of the plugin that they modify is the location of the update server.<\/p>\n

Now, typically that would\u2019ve been over at wordpress.org, and every time you click the update button, you are receiving the repo version of it. However, this updated version will then offload to a third party server somewhere. And at that moment, wordpress.org loses all visibility of what\u2019s going on. As far as they\u2019re aware nothing has happened.<\/p>\n

You are now just getting updates from elsewhere. You would never see anything. But obviously whatever payload they wish to put into that plugin is completely invisible to wordpress.org.<\/p>\n

Now, I suppose the wordpress.org version, there\u2019d be a telltale sign that this was happening because there would be new and modified code to indicate, oh, look, there\u2019s a third party server in play here. But WordPress org has no visibility into what the malicious code being updated onto your website is. Again, is that about where we\u2019re at?<\/p>\n

[00:11:07] Austin Ginder:<\/strong> Yeah. Everything on wordpress.org is open source. Even the platform itself is open source, so you can see the full code, how everything operates there. And in addition to that, all of the plugin activity happens on SVN, which is like the raw pipeline.<\/p>\n

So all of the data is there and available to anyone to go in and audit the data, but it\u2019s, it\u2019s an after the fact situation. Like after a situation happens, you can go back to the raw data and run a full audit to try to piece together all these missing pieces. And all these missing pieces would\u2019ve been impossible to correlate together if it wouldn\u2019t be for AI. Like now we have a superpower where we could just run AI through it all. If we feed it the right points, we can start to make the correlation after the fact as to what happened.<\/p>\n

[00:11:59] Nathan Wrigley:<\/strong> Okay, so essentially what you are saying, I think, is that the work of checking this, prior to AI, let\u2019s go with that, it was just too humanly intensive. There were 60 plus thousand plugins on the wordpress.org repo, going back and having a human inspect every single update, every single file, every line of code is, as you can imagine, a completely unrealistic process.<\/p>\n

However, now AI really its superpower is its capacity to take a giant corpus of data, and then do things with that data. It\u2019s almost like it can capture the entirety of the internet in one hit. And so that\u2019s what\u2019s enabled you to weed out this sort of stuff.<\/p>\n

I have to ask from a personal point of view, why are you doing this? And I don\u2019t mean that the way it sounds, because obviously it\u2019s philanthropic. I\u2019m extremely grateful that you are doing this. But how did you end up taking this on as a, I don\u2019t know, a hobby, a pet project, a sideline?<\/p>\n

[00:12:59] Austin Ginder:<\/strong> This is completely accidental, right? The backstory is in February, I saw a huge shift at my own customers websites, where sites that have been secure for years and years, all of a sudden was getting malware. The short version of it is while I was doing some malware cleanup for a customer, I uncovered one of these big back doors, and it was just like going through the process.<\/p>\n

So malware cleanup before AI was always a little bit of a dicey thing. You can check all the boxes, make sure everything looks good, but you never had the certainty that it was all a hundred percent clean. Did I miss something? But with AI it\u2019s very easy to do a thorough, in depth, investigation.<\/p>\n

How did this happen? Where did it come from? Is my site actually clean now? It just crawls over all the files with Claude Code and other tools, and it gives you a nice report. When I had some recent, my own customers that got malware, and I ran through the forensics level style that AI can give, it uncovered some things that made me question, maybe I should look upstream, maybe I should look at wordpress.org. And I started to feed that into the AI and sure enough, there was something there and it was story worthy.<\/p>\n

[00:14:13] Nathan Wrigley:<\/strong> So presumably that was then bound to a particular plugin. So your customer, something went wrong, you pointed the AI at it, it gave you a report, pointed you to the wordpress.org repo. And that in theory could have been the end of that. You clean up your client website and move on.<\/p>\n

But it sounds like this became much more than that, because over the intervening days and weeks, you found that this was alarmingly, not just a one-off. This was a pattern. And I think the last time I was reading about this, I think you\u2019d found four. I don\u2019t know if four plugins is now up into some other figure or not, but certainly at the time I was reading you\u2019d found four plugins with exactly the same strategy. I don\u2019t know if they were from the same vendor or what have you. Just tell us where you\u2019re at in the middle of May 2026.<\/p>\n

[00:15:07] Austin Ginder:<\/strong> Yeah, so I\u2019ve now published four more or less in depth research. Now, I wasn\u2019t the sole finder of all these, but I was the one who actually pointed the AI at it, and got to the root of it. And it uncovered some other things that previous folks hadn\u2019t found. So the crazy thing is all four situations are completely different, and that\u2019s the wild thing.<\/p>\n

So the one was, the source was the WordPress Plugin Team. So they saw there was some bad activity happening, with a set of the Essential Plugins package. So that\u2019s like a 30 plus plugins. So they closed down all the plugins. They issued an alert, Hey, your site might be compromised. And they actually put code in the patch of the plugins that would check the wp-config file, was it tampered with by the plugin authors themselves?<\/p>\n

So one of my customers saw the notice flagged me. I scanned it, saw it was compromised, and then that\u2019s when I uncovered how big of a deal it was, the Essential Plugins. It was actually a purchase of a company. That was just one of them.<\/p>\n

The other three situations, again it\u2019s all kind of part, it stems back to me overhauling my security system for my clients. The other one was flagged by a new security feature I was implementing where I check all of my customers JavaScript embeds.<\/p>\n

I\u2019m basically scanning changes over time, hoping to catch like a credit card skimmer, or something else like that for my own customers. Well one of them came back. Something\u2019s weird. It was a widget logic plugin that was embedding some weird sports JavaScript code for one of my sites. And I kept digging and digging into it, and sure enough, it was another supply chain attack on that particular plugin.<\/p>\n

So, in all these instances, the WordPress Plugin Team has been fantastic. Very responsive and closing down the plugin, and applying patches, and getting the out there. Yeah, it\u2019s weird. I had no plans to building something like this. I just stumbled upon it and every situation was a different story.<\/p>\n

The last one I\u2019ll share is, I was messing around with this idea that, I wonder if I could use AI to hunt through my own customer\u2019s plugins to detect plugins that are running different versions of the code base. You might have Jetpack installed with the latest version, but maybe there\u2019s a variant version Jetpack\u2019s running. That\u2019s the core idea, or the core concept.<\/p>\n

So I built this tool with AI to scan my own customers, and it found a variant version of the Quick Redirection Plugin installed. I\u2019m like, what\u2019s going on here? So I dig into it and I had 12 sites running a version of the plugin that wasn\u2019t on wordpress.org. So then I threw it through AI. It told me the difference. And sure enough, like you had to keep digging to get actually get to the answer what happened.<\/p>\n

But that was a situation where many, the plugin author themselves offloaded most of their customers to a hijacked version. And my own customers years later were running a hijacked version. So I wasn\u2019t directly searching for this stuff, it just came up, and then I\u2019m like, after you get three of them, it\u2019s alright, now I just wanna see if I can find one.<\/p>\n

So I built the scanner and while I was scanning the top 2000 WordPress sites, I found one, and it was active. It was active, meaning the plugin, it\u2019s called Scroll To Top. It was wired in to 20,000 sites, but it wasn\u2019t active. So a lot of these bad actors, they will take their time, get a plugin that\u2019s compromised in a lot of people\u2019s sites, and then when the moment\u2019s right, pull a trigger. And then at that point they can start to flow in bad content or SEO and actually do the compromise.<\/p>\n

The one that I actually found was a compromise scenario, from what I can tell, the bad actor hadn\u2019t actually pulled the trigger yet. So it was a success story.<\/p>\n

[00:19:13] Nathan Wrigley:<\/strong> Yeah, that is really, kind of makes it more alarming in a sense, doesn\u2019t it? Because once I suppose there\u2019s an active exploit, and people are beginning to report what\u2019s going on here? There\u2019s some strange behaviour on a website, I presume at that point eyeballs will fall on what\u2019s going on and work will be done.<\/p>\n

However, as you\u2019ve just described maybe months, weeks, possibly years, a plugin can have incredible functionality. It might gain widespread adoption, because it\u2019s doing this one thing particularly well. Just with this dormant code sitting there waiting for the moment that\u2019s opportune. Maybe there\u2019s some scenario in the real world in which it will become a timely thing to be able to deploy that.<\/p>\n

That\u2019s really alarming, isn\u2019t it? Because who knows how many websites are currently sitting there with as yet undiscovered, back doors, or problems that we simply don\u2019t know about because they haven\u2019t been triggered? Yeah, that one is really alarming.<\/p>\n

Austin, I\u2019m going to give you a little opportunity because you keep saying my clients, and I don\u2019t think we painted the context of that. Just tell us a little bit about what you do and how that aligns you to have, have an eyeball on so many websites. I think currently, when you say my clients, I think it\u2019s true to say that you\u2019ve got something in the order of 3000 websites that you manage. Now, if you were building those as client websites, that\u2019s a lot of clients. Just tell us what it is that you do, and that might widen the debate a little bit.<\/p>\n

[00:20:39] Austin Ginder:<\/strong> No, I don\u2019t do consulting work anymore. So back in 2014, I transitioned into web hosting full-time. I run Anchor Hosting, and my business is, it\u2019s a pretty simple business model. I resell other managed WordPress hosting services, and provide all of the support and maintenance on top of it.<\/p>\n

So I primarily use web hosts like Kinsta and Rocket.net. They are larger companies. They have a lot more eyeballs on it. I like to layer as many layers between me and the web host infrastructure as I can, so that I can actually solve what I want to solve. And that\u2019s the WordPress maintenance part.<\/p>\n

So I have a little bit more visibility than some. So that is more unique position than most. And I actually would say if there\u2019s any takeaway from this conversation, the takeaway is any hosting company out there that has more data than me, they are sitting on a gold mine and they don\u2019t know it.<\/p>\n

Because any site that gets malware, that is the gold. If you can point AI at every malware situation or attack, you can sometimes back channel it to figure out where it actually happened, and start to paint a bigger picture. I would love to get my hands on like a web host that has millions of sites and run some scans, because that\u2019s how you\u2019re going to discover it, weed it out.<\/p>\n

[00:21:59] Nathan Wrigley:<\/strong> And there\u2019s maybe patterns going on. I don\u2019t suppose every hacker of WordPress plugins is some kind of evil genius. They might just be, I think what\u2019s often called script kiddies. The idea being that they are taking templates and copying and pasting these ideas far and wide.<\/p>\n

And therefore I suppose patterns would emerge and maybe as you said, some of these larger hosts would be able to spot that pattern, and get out in front of these different problems which have, as yet, been undetected.<\/p>\n

Okay, so you\u2019ve then taken an additional step. You\u2019ve got yourself a URL, wpbeacon.io. Dear listener, as is always the case, anything that we mention today, so the links to the articles which Austin has written, I will put those in the show notes, but also I\u2019ll link to wpbeacon.io. Just tell us a little bit about that and that, how that\u2019s helping the community.<\/p>\n

[00:22:52] Austin Ginder:<\/strong> So WP Beacon was again, an idea I threw together last month. Not a whole lot of planning. But it was just like, okay, I\u2019ve got three of these now. These are basically in depth investigations. Where do you put it? Because this is different than a typical vulnerability database. Like a vulnerability database is really good about endeavour to find bad code.<\/p>\n

This is not bad code, this is bad actors. They\u2019re two completely different problems. So I built WP Beacon as like my place to put all these findings. And the idea is actually have it be a legitimate feed for other folks, like another metric or another vulnerability database, but for supply chain attacks in particular.<\/p>\n

[00:23:39] Nathan Wrigley:<\/strong> And so I suppose the idea being that people who are, I mean obviously if you\u2019ve got one WordPress website, it\u2019s fairly unlikely that you\u2019ll come across WP Beacon, because you\u2019re not in the business of being in the community or what have you. But if you are somebody that\u2019s, I don\u2019t know, managing multiple clients, half a dozen or what have you\u2019re in the WordPress space, this is the kind of thing you might want to know about.<\/p>\n

I suppose you are then hoping to be some sort of gatekeeper of knowledge around whether a supply chain attack has occurred. So let\u2019s say for example, I\u2019m considering putting a new plugin in. I find something on the wordpress.org repo, and it looks fine. Everything about it is screaming, yes, install me. I would go over to WP Beacon. I see that you\u2019ve got a search on the homepage. There\u2019s a list of the number of installations that have been covered, authors, tracked plugins that are being watched and what have you. I would be able to, in some way, interact with that website and gain an understanding of, yep, we\u2019ve got nothing on them. Everything looks fine, or no, hold on, have a second thought. This thing happened last month. Is that again? Is that kind of what\u2019s going on there?<\/p>\n

[00:24:45] Austin Ginder:<\/strong> I think end users might find value in it, but I think the better target audience is, this is missing security research that security people don\u2019t have. I see it as that. It\u2019s like when I do a report and I put it up on WP Beacon, those identifiers of these bad actors can then be, action can be taken on that by real legitimate security people.<\/p>\n

So I have a friend, his name\u2019s Sal. He used to work at Kinsta. So when I was dealing with one of these cleanups, I was messaging him privately. I\u2019m like, hey, Sal, look what I found. And he is oh, gimme a second. I\u2019m going take their compromise server offline. I\u2019m like, what do you mean? So he whips it out and he gets their domain suspended, website taken offline. And this is like the crucial gap, right?<\/p>\n

The research person wants to make people\u2019s site safe. So if you\u2019re out there and you\u2019ve got a hijacked plugin installed and you don\u2019t know about it, you need a research person, and a security person, to take care of the issue for you. And that is like taking down their infrastructure, taking down the bad actors infrastructure.<\/p>\n

[00:25:51] Nathan Wrigley:<\/strong> Oh, that is interesting, yeah.<\/p>\n

[00:25:53] Austin Ginder:<\/strong> My goal of WP Beacon is just like, this stuff needs to be more visible. We need to be drafting and documenting this is how the supply chain attack happened in this case. And here is all of the identifiers for the security firms to go for, and take down their infrastructure. To give some sort of incentive that like this kind of behaviour isn\u2019t going to be tolerated or a signal to the bad actors like, we\u2019re coming for you. We\u2019re going to find you, we\u2019re going to weed you out.<\/p>\n

[00:26:21] Nathan Wrigley:<\/strong> Yeah, so that\u2019s interesting. So connections with hosting companies would certainly be beneficial, wouldn\u2019t it? Because let\u2019s say a bunch of hosting companies are pointing their staff at the WP Beacon data, then you could probably satisfy, I don\u2019t know, 60, 70, 80% of WordPress instal by communicating with the bigger hosts. Because I imagine that\u2019s where the majority of WordPress websites occur. I presume another angle would be the .org repo itself. The team over there, the Plugin Review Team and the Security Team and what have you.<\/p>\n

One ray of light, I suppose is that if you fix this, then you have fixed it. Whereas a lot of security problems keep coming back. Well, no, that\u2019s not entirely true, is it? Having said all of that, I was fairly confidently thinking if you can, if you can get the plugin turned off so that it can\u2019t be installed anymore, that\u2019s one thing. If you can switch off the supply chain server, that\u2019s another thing. But there\u2019s going to be loads of different scenarios. It might be that they don\u2019t have a supply chain server. It might be that they\u2019re just defacing your website. And how do we disable that that particular functionality and the plugin?<\/p>\n

I believe that wordpress.org has in rare situations deployed the, we will overwrite your plugin. I don\u2019t know how to describe that, but I have a memory that in the past, something so catastrophic had happened inside of a wordpress.org repo, that there is the capacity for WordPress to say, okay, we\u2019re taking command here, and we\u2019re going to rewrite your plugins. I don\u2019t think that\u2019s very common, but I think that is something that can be done.<\/p>\n

[00:27:59] Austin Ginder:<\/strong> In these situations, that\u2019s exactly what they did. They reverted a patch, closed down the repos, and their patch is what stands.<\/p>\n

[00:28:08] Nathan Wrigley:<\/strong> Right.<\/p>\n

[00:28:09] Austin Ginder:<\/strong> So I think a lot of what my, what I\u2019m trying to do is complimentary to what everyone else is doing. And I think it\u2019s a little bit more, it\u2019s an unexplored area, what WP Beacon is exploring. We have all this data, let\u2019s see what we can get out of it.<\/p>\n

But I do share your optimism, and also I would love this to just be a solved problem, and six months later we shut down WP Beacon, like it\u2019s not even needed. But that\u2019s just not how the world works, right? What I do hope will come from this is the bad actors that have been operating for years, 10 plus years, we make it harder for them to operate. I think that would be a more realistic success story of this project.<\/p>\n

One of the bigger findings I found this past week, in the last few days, is this bad operator he\u2019s been operating for the last 13 years. And what happens is his accounts get shut down, his plugins get shut down, and he just tries again. He opens up new accounts, new plugins, and he just keeps trying. We\u2019ve got to make it a little bit harder for them.<\/p>\n

[00:29:09] Nathan Wrigley:<\/strong> And also what\u2019s really interesting there is that this is not, for you at least anyway, this doesn\u2019t feel like a finished story. This kind of feels like, for you, now that you\u2019ve put yourself in this seat, if you like, it feels each week possibly something new will be coming along, something that you\u2019ve explored? Is that the case? I would like for you to say no at this point, no, there\u2019s nothing new happening, but I the feeling that there\u2019s quite a lot that you are uncovering on a daily, weekly, monthly basis.<\/p>\n

[00:29:37] Austin Ginder:<\/strong> I do think it\u2019s going to be harder and harder to find interesting things based on the raw data, using my technique of just going through and auditing things? That\u2019s a good thing, right? If it\u2019s harder to uncover these problems, that\u2019s a positive indication that something\u2019s happening.<\/p>\n

So I think I\u2019ve been extremely lucky by reverse engineering a problem. Like, how does the malware get here? Oh, okay. So then figuring out that there\u2019s a bigger issue at hand. And I also think it\u2019s one of those scenarios that we all think people are searching through the data, but they aren\u2019t. I\u2019ve got a $200 month Claude Code subscription, and I can search through the data with that. It\u2019s actually feasible for individuals to start auditing the data and to get more eyeballs on this in a way that would never been possible before.<\/p>\n

Yeah, I would encourage people to think bigger. If you\u2019re an individual, you can take your site, download a backup and run it through Claude Code and do a file by file audit. It might take a few, Claude doesn\u2019t like to do this, but it might take a few wranglings. No, look every line of code and tell me what you see. Do you see vulnerabilities? Do you see malware? Do you see any harmful things there? And an individual can do this, and they can get a very high level detailed report unique for their site.<\/p>\n

[00:30:55] Nathan Wrigley:<\/strong> That\u2019s interesting advice. Maybe in the future, some of the pain that you\u2019ve been through with Claude trying to get it to behave in the way that you expect, maybe that be interesting data to put out? What are the prompts which you\u2019ve seen that work and so on?<\/p>\n

One thing which dawns on me, and I don\u2019t really have the answer to this, because the wordpress.org repo, for good reason, has been wide open. What I mean by that is, lots of people can submit code. You don\u2019t necessarily have to have a certain type of credential, or be a certain type of business and so on.<\/p>\n

However, if you look out there in the broader tech landscape, things like, I don\u2019t know, the Mac App Store or the iOS App Store or Google\u2019s Play Store. I wonder what their approach is to firstly the onboarding of new plugin developers. But then what the inspection is for updates. When code comes through and it\u2019s purporting to make a minor change to a particular app on your phone, what is being done there?<\/p>\n

And I\u2019m guessing that in the WordPress space, the fact that it\u2019s run often by volunteers means that those kind of things are just going to be different. And perhaps those things need to be looked at. There needs to be potentially some more friction that\u2019s added, or some more steps. And I know that a lot of work has been done by the Plugin Review Team to automate as much of that as possible, and to put some steps in place to make it so that those submissions get inspected in a more timely way. But I don\u2019t have an answer. I\u2019m certainly no expert. But it would be curious to see if there\u2019s any lessons to be learned from the broader tech community.<\/p>\n

[00:32:30] Austin Ginder:<\/strong> Obviously the openness of WordPress is its power. App Store versus Android, right, kind of comparison? We\u2019re more open source. You could just do what you want. There\u2019s pros and cons, right? So how do we make what we have more safe? And I think the answer to that is everything needs a hundred percent code audited.<\/p>\n

How do we get there as quick as possible? That\u2019s a token question. Like, how many tokens can we spend to audit everything? I have fairly good coverage now for my own customer base. What I do is whatever leftover usage I have, I\u2019m auditing all of my plugins. And I do it in a way that\u2019s efficient, meaning I only audit this one plugin version once. That gets assigned to a hash, a unique hash. Then I know, oh, okay, so all of my sites using that same variant are covered.<\/p>\n

So a hundred percent code coverage is what we need to do now. And then long term, also in concurrently, we need to start auditing any changes that come over the wire. It\u2019s a lot, right? Like wordpress.org is very popular. There\u2019s a lot of code, but I do think it\u2019s in a realm of realistic. If you are able to shave out a lot of the noise, we don\u2019t have to audit everything. We don\u2019t have to see every CSS file you\u2019re changing, or image you\u2019re changing. But we do have to look over every PHP line, every JavaScript line, that there\u2019s nothing harmful in there. And then eventually we\u2019ll start to catch things.<\/p>\n

And I don\u2019t think it\u2019s necessarily a one off thing. We don\u2019t have to wait around for Automattic to come up with a solution. The data is out there. Anyone with a laptop and a subscription could just create a mirror and see, what changed over the last, day, and then start auditing that. I think people think it\u2019s too impossible.<\/p>\n

[00:34:18] Nathan Wrigley:<\/strong> It feels like a large cliff that you\u2019re staring at, at the beginning of this. And certainly in the past before AI, that cliff was, I imagine, more or less impenetrable But now the way that you\u2019ve described, perhaps AI can be co-opted to do a lot of this work for us?<\/p>\n

I wonder what you\u2019ve got, if you\u2019ve got any thoughts on the sort of permissions system. So I know that other, let\u2019s say CMSs and certainly devices like Android devices and iOS devices, they come with permissions based systems. So for example, this code, it\u2019s allowed access to the root file structure. Or it\u2019s allowed access to the camera, or whatever it may be.<\/p>\n

And I know that there\u2019s been debate in the WordPress ecosystem recently about whether something like that would be a good idea. At the moment, plugins, all bets are off. If you put a plugin in, it\u2019s more or less got access to anything on your WordPress website.<\/p>\n

That\u2019s an absolute strength of WordPress because it enables anybody to do anything. But I suppose given that it can enable any anybody to do anything, it also prevents a very large threat surface as well. I don\u2019t really have the answer to that. I just think that\u2019s a curious thing to raise and see if you\u2019ve got any thoughts.<\/p>\n

[00:35:29] Austin Ginder:<\/strong> I guess my initial thought is I don\u2019t necessarily want my WordPress site to feel like my laptop, where I\u2019m constantly clicking things.<\/p>\n

[00:35:35] Nathan Wrigley:<\/strong> Yeah. Grant permission for this.<\/p>\n

[00:35:38] Austin Ginder:<\/strong> I don\u2019t know what the solution is either. I think some of those ideas are great when you\u2019re thinking about making something from scratch, but they are not as relevant when you\u2019ve already have an existing ecosystem. Like you can\u2019t, I would think it\u2019d be very hard to bring some of those concepts into WordPress at this point. We\u2019re already past that.<\/p>\n

[00:35:59] Nathan Wrigley:<\/strong> That ship has definitely sailed.<\/p>\n

[00:36:00] Austin Ginder:<\/strong> I want to be in the Wild West. I want to be able to code and do what I want to do. And especially with AI. If I got an idea, I just want AI to go to town, write me up the plugin to my spec, and not have to deal with some of those extra safeguards.<\/p>\n

It\u2019d be great if we could find some way to make things more secure from an architectural standpoint, but that\u2019s an architecture problem probably best suited for a new project.<\/p>\n

[00:36:22] Nathan Wrigley:<\/strong> The truth is that this will never, ever be solved. I mean security problems online. There will be a no point in the future at which everything is always safe, because humans are ingenious, and there are really credible, credible is the wrong word. There are ways to make money, or to make it worthwhile for the bad actors to be doing the bad things. And so long as those incentives exist, there will be people trying to hijack websites, undermine the security of your computer or phone or whatever it may be. But this is certainly an interesting one.<\/p>\n

And it\u2019s such a shame because with the benefit of hindsight, this was so obvious, and yet it hasn\u2019t been a news story. Maybe it has in the past, I\u2019ve certainly not come across it. But this whole supply chain thing is fairly new to me, and fairly alarming in the simplicity of deployment.<\/p>\n

You literally purchase, or somehow get hold of, a popular plugin, not necessarily even a popular plugin, a plugin. And then instantaneously every one of those websites is up for grabs in whichever way you would like to grab it. Definitely something that the WordPress community\u2019s going to have to wrangle with.<\/p>\n

Okay. I think we\u2019ve hit the sweet spot in terms of time Austin. If it\u2019s all right with you, we will wrap it up there. However, before we go, do you just want to drop a few little bits about where people could contact you? I am more or less certain that somebody listening to this podcast will have thoughts for you about getting in touch, helping out, or what have you. So tell us where you can be found.<\/p>\n

[00:37:55] Austin Ginder:<\/strong> You can find me just by searching for my name, Austin Ginder. There\u2019s not many Ginders. I\u2019m on X, that\u2019s my main feed. And you can also read along on anchor.host. I do blog posts there pretty regularly.<\/p>\n

[00:38:09] Nathan Wrigley:<\/strong> Okay. In which case I will just point everybody to the wptavern.com website. If you go and use the search feature, search for Austin Ginder. Austin, spelled in the usual way. Ginder, G-I-N-D-E-R. You\u2019ll find the episode and anything that has been mentioned, any links or what have you, we will link to there.<\/p>\n

So thank you for chatting to me today about what I wish didn\u2019t exist, but it does exist. Austin, thank you so much.<\/p>\n

[00:38:34] Austin Ginder:<\/strong> Thank you. This was a pleasure.<\/p>\n<\/div>\n<\/details>\n

On the podcast today we have Austin Ginder<\/a>.<\/p>\n

Austin has been involved in the WordPress ecosystem since 2010, and since 2014 has run Anchor Hosting, a business that manages thousands of WordPress websites. While he\u2019s a developer and automation enthusiast at heart, in recent months Austin has found himself at the forefront of a burgeoning crisis in WordPress security, supply chain attacks targeting plugins.<\/p>\n

A chance discovery during a malware cleanup on a client\u2019s site propelled Austin into what would become a wider investigation of plugin vulnerabilities. What he uncovered is both alarming and timely, bad actors aren\u2019t just hacking sites directly, but are instead infiltrating the supply chain, either by purchasing plugin companies and weaponising them, or by hijacking plugins and pushing out malicious updates. These attacks are subtle, often shifting plugin update servers away from WordPress.org to rogue channels where malware can be quietly distributed, leaving end users in the dark and their sites at risk.<\/p>\n

We trace Austin\u2019s journey from accidental security investigator to creator of the WP Beacon project, a resource aimed at tracking, documenting, and alerting the WordPress community to known supply chain attacks. He shares how AI tools have radically changed what\u2019s possible in threat detection and forensics, enabling individuals, and hopefully, someday, the larger hosting providers, to identify patterns and root causes behind widespread infections.<\/p>\n

We get into case studies of specific plugins compromised in recent months, the challenges of auditing over 60,000 plugins on the WordPress.org repo, and the complexities of stopping these attacks once malicious code is in the wild. Austin also discusses his hopes for greater collaboration with hosts and security researchers, aiming for better automated monitoring and response.<\/p>\n

If you manage WordPress websites, create plugins, or just care about the future of open source security, this episode is for you.<\/p>\n

Useful links<\/h2>\n

\u200awordpress.org plugin repository<\/a><\/p>\n

Claude Code<\/a><\/p>\n

WordPress Plugin Review Team Handbook<\/a><\/p>\n

Anchor Hosting<\/a><\/p>\n

WP Beacon website<\/a><\/p>\n

Austin on X<\/a><\/p>","protected":false},"excerpt":{"rendered":"

Transcript [00:00:19] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley. Jukebox is a podcast which is dedicated to all things WordPress, the people, the events, the plugins, the blocks, the themes, and in this case, how AI is exposing hidden threats is WordPress plugin updates. If you\u2019d like […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"advanced_seo_description":"","jetpack_seo_html_title":"","jetpack_seo_noindex":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[1],"tags":[],"class_list":["post-5343","post","type-post","status-publish","format-standard","hentry","category-latest-news"],"jetpack_featured_media_url":"","jetpack_likes_enabled":true,"jetpack-related-posts":[],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/frontlinenewsng.org\/index.php?rest_route=\/wp\/v2\/posts\/5343","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/frontlinenewsng.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/frontlinenewsng.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/frontlinenewsng.org\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/frontlinenewsng.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=5343"}],"version-history":[{"count":0,"href":"https:\/\/frontlinenewsng.org\/index.php?rest_route=\/wp\/v2\/posts\/5343\/revisions"}],"wp:attachment":[{"href":"https:\/\/frontlinenewsng.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=5343"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/frontlinenewsng.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=5343"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/frontlinenewsng.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=5343"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}