[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’d 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.

If you have a topic that you’d like us to feature on the podcast, I’m 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.

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’s 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.

A chance discovery during a malware cleanup on a client’s site, propelled Austin into what would become a wider investigation of plugin vulnerabilities. What he uncovered is both alarming and timely. Bad actors aren’t 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.

We trace Austin’s 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’s possible in threat detection and forensics, enabling individuals, and hopefully someday, the larger hosting providers to identify patterns and root causes behind widespread infections.

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.

If you manage WordPress websites, create plugins, or just care about the future of open source security, this episode is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast, where you’ll find all the other episodes as well.

And so without further delay, I bring you Austin Ginder.

I am joined on the podcast by Austin Ginder. Hello, Austin.

[00:03:40] Austin Ginder: Hey, good to meet you.

[00:03:41] Nathan Wrigley: Very nice to meet you too. I was put in Austin’s way by I think Courtney Robertson.

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’s 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’s pretty important that person gets a chance to stamp their credentials into the podcast about themselves. Because it’s 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.

[00:04:16] Austin Ginder: Sure. So I’m a developer, first off. I’ve been running a WordPress hosting service since 2014, and I’ve been working in the WordPress space since 2010. A long timer. I love automation. WPCLI commands, bash scripts. I’m in the weeds on a technical basis.

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

[00:04:56] Nathan Wrigley: Yeah. Thank you for that. So as you’re about to hear, we’re not gonna be talking at from the perspective of Austin demonstrates how to fix a particular challenge in WordPress. It’s much more of a general thing, and an alert really. It’s 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.

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’ve discovered in the last few weeks, and the three or four incidents that you’ve uncovered and what they mean and how they’ve come about?

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

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’t realise you’re updating to something that’s harmful for your website.

So that’s 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’s 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’t happen.

[00:06:42] Nathan Wrigley: Except, it does. So let me just reiterate what’s going on there. So if you’ve been to the wordpress.org repository, or indeed you’ve 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.

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’re asleep, it gets updated to the latest version. This in a universe occupied only by honest people would be absolutely fine. We’d have no problem that.

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

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.

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’s not like suddenly the plugin just stops working, or it’s really obvious what’s going on. It may be that just a few lines of code have been adapted, modified, there’s 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’re at?

[00:08:35] Austin Ginder: Yeah, these are bad actors trying to hide themselves. They’re sneaky. They don’t do things that are obvious. Like they’re not just uploading malware to WordPress plugin repo. What they’ll 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.

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.

And then once it’s on the update channel, wordpress.org has zero visibility, and you’re just running a hijacked plugin and you don’t even know it. Unless you go in and you run a verify command, from the command line or, you’re scanning for things like this. And then after they get the plugin hijacked, that’s when they compromise your site.

They could do SEO spam attacks, or display ads, or poison the search results from Google’s perspective. Many different things that they do to try to recoup their money in the investment.

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

Now, typically that would’ve 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’s going on. As far as they’re aware nothing has happened.

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.

Now, I suppose the wordpress.org version, there’d be a telltale sign that this was happening because there would be new and modified code to indicate, oh, look, there’s 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’re at?

[00:11:07] Austin Ginder: 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.

So all of the data is there and available to anyone to go in and audit the data, but it’s, it’s 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’ve been impossible to correlate together if it wouldn’t 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.

[00:11:59] Nathan Wrigley: Okay, so essentially what you are saying, I think, is that the work of checking this, prior to AI, let’s 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.

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

I have to ask from a personal point of view, why are you doing this? And I don’t mean that the way it sounds, because obviously it’s philanthropic. I’m extremely grateful that you are doing this. But how did you end up taking this on as a, I don’t know, a hobby, a pet project, a sideline?

[00:12:59] Austin Ginder: 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.

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’s very easy to do a thorough, in depth, investigation.

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.

[00:14:13] Nathan Wrigley: 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.

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’d found four. I don’t know if four plugins is now up into some other figure or not, but certainly at the time I was reading you’d found four plugins with exactly the same strategy. I don’t know if they were from the same vendor or what have you. Just tell us where you’re at in the middle of May 2026.

[00:15:07] Austin Ginder: Yeah, so I’ve now published four more or less in depth research. Now, I wasn’t 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’t found. So the crazy thing is all four situations are completely different, and that’s the wild thing.

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’s 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?

So one of my customers saw the notice flagged me. I scanned it, saw it was compromised, and then that’s 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.

The other three situations, again it’s 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.

I’m 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’s 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.

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’s weird. I had no plans to building something like this. I just stumbled upon it and every situation was a different story.

The last one I’ll share is, I was messing around with this idea that, I wonder if I could use AI to hunt through my own customer’s 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’s a variant version Jetpack’s running. That’s the core idea, or the core concept.

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’m like, what’s going on here? So I dig into it and I had 12 sites running a version of the plugin that wasn’t 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.

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’t directly searching for this stuff, it just came up, and then I’m like, after you get three of them, it’s alright, now I just wanna see if I can find one.

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’s called Scroll To Top. It was wired in to 20,000 sites, but it wasn’t active. So a lot of these bad actors, they will take their time, get a plugin that’s compromised in a lot of people’s sites, and then when the moment’s right, pull a trigger. And then at that point they can start to flow in bad content or SEO and actually do the compromise.

The one that I actually found was a compromise scenario, from what I can tell, the bad actor hadn’t actually pulled the trigger yet. So it was a success story.

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

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

That’s really alarming, isn’t it? Because who knows how many websites are currently sitting there with as yet undiscovered, back doors, or problems that we simply don’t know about because they haven’t been triggered? Yeah, that one is really alarming.

Austin, I’m going to give you a little opportunity because you keep saying my clients, and I don’t 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’s true to say that you’ve got something in the order of 3000 websites that you manage. Now, if you were building those as client websites, that’s a lot of clients. Just tell us what it is that you do, and that might widen the debate a little bit.

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

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’s the WordPress maintenance part.

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’s 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’t know it.

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’s how you’re going to discover it, weed it out.

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

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.

Okay, so you’ve then taken an additional step. You’ve 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’ll link to wpbeacon.io. Just tell us a little bit about that and that, how that’s helping the community.

[00:22:52] Austin Ginder: 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’ve 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.

This is not bad code, this is bad actors. They’re 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.

[00:23:39] Nathan Wrigley: And so I suppose the idea being that people who are, I mean obviously if you’ve got one WordPress website, it’s fairly unlikely that you’ll come across WP Beacon, because you’re not in the business of being in the community or what have you. But if you are somebody that’s, I don’t know, managing multiple clients, half a dozen or what have you’re in the WordPress space, this is the kind of thing you might want to know about.

I suppose you are then hoping to be some sort of gatekeeper of knowledge around whether a supply chain attack has occurred. So let’s say for example, I’m 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’ve got a search on the homepage. There’s 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’ve 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’s going on there?

[00:24:45] Austin Ginder: 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’t have. I see it as that. It’s 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.

So I have a friend, his name’s Sal. He used to work at Kinsta. So when I was dealing with one of these cleanups, I was messaging him privately. I’m like, hey, Sal, look what I found. And he is oh, gimme a second. I’m going take their compromise server offline. I’m 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?

The research person wants to make people’s site safe. So if you’re out there and you’ve got a hijacked plugin installed and you don’t 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.

[00:25:51] Nathan Wrigley: Oh, that is interesting, yeah.

[00:25:53] Austin Ginder: 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’t going to be tolerated or a signal to the bad actors like, we’re coming for you. We’re going to find you, we’re going to weed you out.

[00:26:21] Nathan Wrigley: Yeah, so that’s interesting. So connections with hosting companies would certainly be beneficial, wouldn’t it? Because let’s say a bunch of hosting companies are pointing their staff at the WP Beacon data, then you could probably satisfy, I don’t know, 60, 70, 80% of WordPress instal by communicating with the bigger hosts. Because I imagine that’s 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.

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’s 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’t be installed anymore, that’s one thing. If you can switch off the supply chain server, that’s another thing. But there’s going to be loads of different scenarios. It might be that they don’t have a supply chain server. It might be that they’re just defacing your website. And how do we disable that that particular functionality and the plugin?

I believe that wordpress.org has in rare situations deployed the, we will overwrite your plugin. I don’t 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’re taking command here, and we’re going to rewrite your plugins. I don’t think that’s very common, but I think that is something that can be done.

[00:27:59] Austin Ginder: In these situations, that’s exactly what they did. They reverted a patch, closed down the repos, and their patch is what stands.

[00:28:08] Nathan Wrigley: Right.

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

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’s not even needed. But that’s 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.

One of the bigger findings I found this past week, in the last few days, is this bad operator he’s 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’ve got to make it a little bit harder for them.

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

[00:29:37] Austin Ginder: I do think it’s 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’s a good thing, right? If it’s harder to uncover these problems, that’s a positive indication that something’s happening.

So I think I’ve been extremely lucky by reverse engineering a problem. Like, how does the malware get here? Oh, okay. So then figuring out that there’s a bigger issue at hand. And I also think it’s one of those scenarios that we all think people are searching through the data, but they aren’t. I’ve got a $200 month Claude Code subscription, and I can search through the data with that. It’s 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.

Yeah, I would encourage people to think bigger. If you’re 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’t 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.

[00:30:55] Nathan Wrigley: That’s interesting advice. Maybe in the future, some of the pain that you’ve 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’ve seen that work and so on?

One thing which dawns on me, and I don’t 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’t necessarily have to have a certain type of credential, or be a certain type of business and so on.

However, if you look out there in the broader tech landscape, things like, I don’t know, the Mac App Store or the iOS App Store or Google’s 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’s purporting to make a minor change to a particular app on your phone, what is being done there?

And I’m guessing that in the WordPress space, the fact that it’s 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’s 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’t have an answer. I’m certainly no expert. But it would be curious to see if there’s any lessons to be learned from the broader tech community.

[00:32:30] Austin Ginder: Obviously the openness of WordPress is its power. App Store versus Android, right, kind of comparison? We’re more open source. You could just do what you want. There’s 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.

How do we get there as quick as possible? That’s 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’m auditing all of my plugins. And I do it in a way that’s 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.

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’s a lot, right? Like wordpress.org is very popular. There’s a lot of code, but I do think it’s in a realm of realistic. If you are able to shave out a lot of the noise, we don’t have to audit everything. We don’t have to see every CSS file you’re changing, or image you’re changing. But we do have to look over every PHP line, every JavaScript line, that there’s nothing harmful in there. And then eventually we’ll start to catch things.

And I don’t think it’s necessarily a one off thing. We don’t 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’s too impossible.

[00:34:18] Nathan Wrigley: It feels like a large cliff that you’re 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’ve described, perhaps AI can be co-opted to do a lot of this work for us?

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

And I know that there’s 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’s more or less got access to anything on your WordPress website.

That’s 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’t really have the answer to that. I just think that’s a curious thing to raise and see if you’ve got any thoughts.

[00:35:29] Austin Ginder: I guess my initial thought is I don’t necessarily want my WordPress site to feel like my laptop, where I’m constantly clicking things.

[00:35:35] Nathan Wrigley: Yeah. Grant permission for this.

[00:35:38] Austin Ginder: I don’t know what the solution is either. I think some of those ideas are great when you’re thinking about making something from scratch, but they are not as relevant when you’ve already have an existing ecosystem. Like you can’t, I would think it’d be very hard to bring some of those concepts into WordPress at this point. We’re already past that.

[00:35:59] Nathan Wrigley: That ship has definitely sailed.

[00:36:00] Austin Ginder: 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.

It’d be great if we could find some way to make things more secure from an architectural standpoint, but that’s an architecture problem probably best suited for a new project.

[00:36:22] Nathan Wrigley: 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.

And it’s such a shame because with the benefit of hindsight, this was so obvious, and yet it hasn’t been a news story. Maybe it has in the past, I’ve certainly not come across it. But this whole supply chain thing is fairly new to me, and fairly alarming in the simplicity of deployment.

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’s going to have to wrangle with.

Okay. I think we’ve hit the sweet spot in terms of time Austin. If it’s 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.

[00:37:55] Austin Ginder: You can find me just by searching for my name, Austin Ginder. There’s not many Ginders. I’m on X, that’s my main feed. And you can also read along on anchor.host. I do blog posts there pretty regularly.

[00:38:09] Nathan Wrigley: 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’ll find the episode and anything that has been mentioned, any links or what have you, we will link to there.

So thank you for chatting to me today about what I wish didn’t exist, but it does exist. Austin, thank you so much.

[00:38:34] Austin Ginder: Thank you. This was a pleasure.