[00:00:00] 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, the security of WordPress. 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 WP Tavern dot com forward slash feed forward slash 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 very keen to hear from you and hopefully get you or your idea on the show. Head over to WP Tavern dot com forward slash contact forward slash jukebox, and use the contact form there.

So on the podcast today, we have Oliver Sild. Oliver has been working in the WordPress space for many years, and specifically with WordPress security, as one of the founders of Patchstack, formerly called WebARX. Patchstack is a product which is designed to help you identify plugin vulnerabilities in your WordPress sites.

Over the past couple of years, Patchstack has released an annual report about the state of WordPress security. The report for 2021 has just been released, and the podcast today is concerned with what they found out. We talk about why they produce this report. Who the intended audience is. What are the main takeaways in terms of the overall security of WordPress Core plugins and themes?

We then get into more specific details about what types of vulnerabilities and attacks seem to be prevalent in the WordPress space. Are there any trends which are useful to think about, and how WordPress security is managed by the community as a whole. Are budgets and time typically allocated for prevention and restoration of websites.

Towards the end we talk about how some people have pushed back on the usefulness of the report. They’ve questioned the motivations of security companies to write such reports and the use of language which they contain. Do they paint a more negative picture in order to drive sales of their commercial solutions?

If you’re interested in finding out more, you can find all the links and the show notes by heading over to. WP Tavern dot com forward slash podcast, where you’ll find all of the other episodes. And so without further delay, I bring you all Oliver Sild.

I am joined on the podcast today by Oliver Sild. Hello Oliver.

[00:03:16] Oliver Sild: Hello Nathan, how are you?

[00:03:17] Nathan Wrigley: I’m very well, thank you for joining us today. Oliver Sild will no doubt be able to introduce himself, but I’ll just do a very quick job. Oliver is, I believe, one of the founders, if not the founder of Patchstack, formerly WebARX, which is a security solution for WordPress websites amongst other things.

So my first question to you all about, just give us a little bit of background, certainly more than I just provided. Tell us about your history with WordPress and how you came to be involved with WordPress.

[00:03:47] Oliver Sild: Yeah. So in 20, 20 13, 20 14, around that time I was actually running a web development company we were mostly back then building websites in Joomla and then I remember just at one point, the demand on the market changed pretty much everyone wanted to WordPress site. So that kind of naturally moved us from Joomla to WordPress, and because our company was, we were calling our services like a secure web development. So what we wanted to do is that if we are building you something we’ll also make sure that the security side of that is covered as well. So we already had some level of internal tools built which were helping us to track what kind of software we were using on our different kind of customer’s websites. And that eventually, well, by now has turned into what Patchstack is.

Okay.

[00:04:40] Nathan Wrigley: Thank you very much, indeed. So security is your thing. And very recently there was a piece on the WP Tavern website, which I will link to a little bit later, which was highlighting the fact that you had released one of your annual reports.

I believe we’re on possibly the second iteration now. It’s called the state of WordPress security. And in this case it was 2021. So it’s a look back over the last year in WordPress security. And we’ll go into that. And that really is the point of the podcast today. We’re just going to appraise all of the different bits and pieces that you highlighted there because I’m imagining that most people listening to this podcast are deeply into WordPress. And this is obviously a seriously important side of any WordPress website, keeping it updated and secure.

And then towards the end of the podcast, we’ll go into a little bit of an exchange that happened over on a website where somebody called into question the language that you’re using over here, but, okay, so first thing I’m going to suggest then is that if you’re listening to this, you may like to go to Patchstack dot com forward slash white paper forward slash the state of WordPress security in 2021. All of those words are separated by hyphens. And you’re going to find the article that we’re talking about.

It’s broken up into lots of different sections. But first question is why are you making the efforts to write this report? And we know that you have a WordPress security company. That is your job. That’s what you do, but why go to the lengths of illustrating what’s going on in the WordPress space so that people like me, the general public can consume it? It must require quite a lot of resources and effort.

[00:06:14] Oliver Sild: Indeed yeah. I think we put that report together for three months. So it’s quite in depth by the way. If you want to quickly open up the white paper, you can just go to Patchstack dot com, we have with the banner on our front page that’s actually linking to that, but that’s a side note.

We actually did that first, last year. So we last year released one about the previous year and we started doing that on the point where as a company, we decided to switch into a very specific focus on security vulnerabilities found in the software that is built for and around the WordPress ecosystem, which is the WordPress Core, the plugins and themes and the wordpress.org repository.

But also the WordPress plugins and themes that are built as a premium ones that are not in the WordPress repository or the ones that are actually built or like being provided, some other marketplaces like Envato and so on. And by doing that, we switch the, like we have a SaaS product that is providing, we have a free version of a SaaS product where you can like, just connect like 99 websites, for example, and have a central overview if any of the plugins on any of your websites is becoming vulnerable. And at the same time, we started, looking into those different kinds of popular plugins and if they are vulnerable or not, then for years we’ve been providing code review and security auditing services for plugins.

By doing that over the time, what we’ve collected together is like a quite big database, so security issues around the WordPress ecosystem. So if you go to Patchstack dot com slash database, you actually see a full-blown list of all of the security vulnerabilities that are in the plugins, themes, WordPress Core, and so on.

And last year, what we did is that we figured, we understood already by doing surveys and so on that actually plugin vulnerabilities and theme vulnerabilities, and like anything that you are running on your website that becomes vulnerable, is pretty much the number one security threat to the website. And then we started a thing that we call it today Patchstack Alliance, where we just decided to start building a community of ethical hackers, who then submit vulnerabilities that they find in any WordPress plugins in the ecosystem to us. We make sure that we help the plugin developer to fix those issues. And then we actually pay to those ethical hackers for the contribution that they make to the WordPress security.

And that’s on the other hand, generates a lot of data for us. So a lot of data about new vulnerabilities. A lot of data about, what is actually happening in that ecosystem. And we just decided to pull all that information and data that we have collected over this time and make it into a kind of annual report or a white paper.

[00:09:09] Nathan Wrigley: Yeah. It’s really definitely worth having a look at, because it portrays, obviously now that you’re in the second iteration of this, you’re able to compare the way that things were last year. And in many ways, this is a comparison piece based upon last year. And so we often hear the phrases, such and such a thing is up such and such a thing as down, you’re looking for trends basically.

The main gist is three sections. As you described, we’re talking about WordPress Core, WordPress themes and finally WordPress plugins. There’s obviously a little bit of nuance in there. Do you want to illustrate for us what you’ve found to be the big highlight bullet items, if you’d like for those three areas.

So should we start with Core? Let’s discuss what it is that you found over the last year in terms of the security or otherwise of WordPress Core. To paraphrase, it seems pretty good.

[00:10:02] Oliver Sild: Yeah. Like WordPress has quite mature software development cycle. WordPress the core, also has the bug bounty program.

They have the bounty program on hacker one. And who doesn’t know what backcountry program is? It’s basically, like you say to hackers, come hack my software. If you find something report it directly to me so I can fix it, then they will pay to you. So this is the approach that is being, is becoming very popular.

That’s the same thing, what we do to plugins, but WordPress has its for it’s own core. So they do that, which is nice because that is actually getting much more security attention on the WordPress Core. And at the same time we see less major security vulnerabilities being discovered in the Core itself. And something that we also saw this year, which was a little bit different was the dependency confusion attacks, where there was like a high risk of being maybe like a custom plugin being updated from the wrong source. I think the Core had an interesting year, but what we see is in general that the Core has a matured development kind of processes and cycle in place. So it’s getting better each year.

[00:11:14] Nathan Wrigley: I think in the year 2017, I believe it was, the bug bounty program began with hacker one and it would appear, it seems to have worked because over the years after that, there’s been a fairly precipitous drop in the amount of concern with WordPress Core. In fact of the four security updates that were released in 2021. And again, we’re talking about Core it would appear that only one of them had a critical vulnerability, which wasn’t actually concerning something that was Core. It was an insecure component. It was PHP mailer library if I remember rightly.

So that points to the idea that anybody these days is saying that WordPress itself is an insecure platform, which I’m sure we’ve all encountered when we’ve been building client websites and so on, people have this fear that WordPress itself is pretty insecure and your document seems to imply exactly the opposite. It’s very robust and very secure.

[00:12:13] Oliver Sild: Yeah, and if you read our white paper, we actually say that, we are saying that WordPress has done a very good job at that. WordPress is getting more and more security attention, obviously, as it’s running, soon, almost like the half of web, basically.

It makes sense that it gets more attention. More attention means more stuff is being found, more stuff being found means more stuff is fixed. And this is a good thing. And in terms of like the whole mature way of how there’s regular security updates and regular updates for the core itself. It shows that the core is doing really well.

[00:12:51] Nathan Wrigley: Do you want to illustrate for those people who perhaps aren’t familiar, one of the headline paragraphs that you’ve got right near the top is, the dependency confusion attacks. Now this may be something that people are very familiar with. I suspect maybe not. Do you just want to outline what those are and why you’ve illustrated it in the report this year?

[00:13:09] Oliver Sild: Yeah, we call it the fear of dependency confusion attacks, because we didn’t really see any dependency confusion attacks specifically. Like I was mentioning before, there was a risk where if you have a custom plugin that is not on the wordpress.org repo. And if you are adding a new plugin to the repo with the same slug that this custom plugin was using, then you could pretty much overwrite the custom plugin on the websites that it was running at.

So this was like, a risk where if there is like a plugin made by someone, maybe installed on like very high profile websites. This plugin is not known to the WP dot org, or it is not on the WordPress dot org repo, but someone made a plugin for, with the same slug and it went past it. And then the auto-update mechanism in the WordPress Core would basically update this plugin, now, which was a core, which was a custom plugin into the plugin that is now in the WordPress repository.

So basically replacing someone else’s plugin with a plugin made by another author. The content can be checked by the wordpress.org, like what actually this new plugin would do. But at the same time, of course a bit of a fear, I think a lot of people were afraid that this is going to affect everyone, but it was more of a theoretical thing that was a risk, but we didn’t really see any of such effects happening.

[00:14:37] Nathan Wrigley: Yeah in software, in general, nothing to do with WordPress, this kind of supply chain attack is potentially a real problem, isn’t it? Because if you can somehow become the official canonical source of the software, even though you are not the official canonical source of the software, you could in theory, get to many, many places very, very quickly.

And and it’s nice to see that you’ve not really found too much evidence of that over the last year. So WordPress core itself, I think it’s fair to say, you feel is in very good shape. The problem is really for WordPress and I’m sure this is something that many people can relate to if they’ve been using the software for any length of time, we’re going to get into themes and plugins. This is where I guess the problems begin to arise. Let’s tackle them in turn. Let’s go for themes first. What were the broad sweeping outlines that you that you discovered in your exploration of themes this year?

[00:15:32] Oliver Sild: I think this has been happening over the time, but basically what we see is that the line between themes and plugins is getting blurrier and blurrier Themes now use a lot of PHP code for, site builders are also, people considered as themes in a way, but then at the same time they actually a plugin. Yeah, so the line is getting blurrier and more PHP code is being introduced into the functionality of the themes, which basically brings the same kind of threats to the themes that we have with plugins, where there can be a kind of vulnerable PHP code that can be a trick doing something that was not meant to.

And what you saw is that there are vulnerabilities within themes that are as critical as you could expect from the plugins. It isn’t from this report, but I think a good example is. It was just recently with Freemius library, which was used by a lot of themes. And this is like exactly the supply chain issue where, there’s thousands of websites that are using one theme, and if this one theme becomes vulnerable, then all these thousands of websites are vulnerable. But now we’re also seeing where there’s thousands of themes on these themes use a library, and if this library gets vulnerable, then all these thousands of themes become vulnerable. And all those, I don’t know, hundreds of thousands of websites that use these thousands of themes become vulnerable as well. So this, you can see how this is coming, like from top to the bottom and eventually affecting a lot of websites. So as an example, I think two or three weeks ago when the Freemius thing happened, I think we, I believe we added 1,800 different vulnerabilities or vulnerable components to the Patchstack database in a single day.

So next year is going to be definitely more, we have more data that’s definitely from this year about theme vulnerabilities than we have from the past year.

[00:17:35] Nathan Wrigley: There were a fair number of what you might describe as critical vulnerabilities. There’s a list that you’ve described, depending on how interested you are in security.

The names of these things may be of interest or otherwise, but things like unauthenticated, arbitrary file upload and option deletion, that would appear to have been found at least in your case, 10 times in 10 different themes. Unauthenticated upload vulnerability, leading to remote code execution, which you’ve found in one theme.

Arbitrary file upload vulnerability, 42 themes were affected. So it’s fairly widespread. And I guess if any of those themes are incredibly popular, that can quickly get out of hand.

[00:18:16] Oliver Sild: Absolutely. If a single plugin that has, especially those unauthenticated vulnerabilities are the scariest ones because they require no access to the website, like any permissions to your websites and someone could basically, the malicious hacker could potentially upload file to your site without gaining access to the website. So this kind of vulnerabilities are very scary as they can be abused automatically and on scale. So indeed, like if a single plugin would have a hundred thousand installations and it would have just one, this one vulnerability, especially for unauthenticated one, then what we are seeing is that hackers very quickly build custom tools to start finding all the websites on the internet that use that theme and then start exploiting them automatically to inject backdoors or redirect traffic from the website, change the search engine results for your website. So if you watch, if you look at the website everything seems to be okay. But if you Google your website, for example, then it would give completely different results and redirect your site to somewhere else.

[00:19:24] Nathan Wrigley: So, is the trend in terms of themes, is your experience that there was more concern over the last year than there was in the previous 12 months? Or is it essentially the same quantity of vulnerabilities?

[00:19:39] Oliver Sild: I guess the trend is the fact that the vulnerabilities are just becoming a little bit more critical. I wouldn’t say that there is a big trend in terms of that there is like a massive increase in the vulnerabilities in themes, but I think the fact that so much more functionality is being shipped with the themes in terms of the PHP code in general than they are just more and more prone to being introduced or introducing that kind of critical vulnerabilities into the code.

[00:20:07] Nathan Wrigley: Yeah. Okay. Thank you. Let’s move on to WordPress plugins and this, as one might expect, has possibly greater numbers attached to it. There’s more plugins out there, and I would imagine that most websites have got one, possibly two themes, whereas they might have 15, 18 20, whatever the average number now is plugins. So there’s probably a bit of a larger target painted on plugins back than there is on themes back. Give us the overarching findings in terms of WordPress plugins for 2021.

[00:20:40] Oliver Sild: Yeah. Plugins are the ones that we’ve been focusing the most on. And these are the ones that our Alliance members or like the community of the ethical hackers that are reporting new vulnerabilities to us. Majority of the vulnerabilities that are being reported to us are about the plugins. If we’re looking about the total number of new vulnerabilities that we’ve added to the database of vulnerabilities that effect the WordPress Core, plugins and themes, then there has been quite heavy increase in if we compare it to the last year.

But that means that is actually very good news because that means that these are vulnerabilities that the developer has been able to get fixed because these vulnerabilities didn’t appear this year. These vulnerabilities probably in many cases at least they were sitting in those plugins for quite some time already. What just happened, why there is an increase in new identified vulnerabilities is just the fact that there’s more people looking at those, and reporting them to the developers.

[00:21:49] Nathan Wrigley: There was a couple of plugins, and I guess this is the difference with plugins is that really the sky is the limit in terms of the numbers of installs. I don’t know what the largest install base of any particular theme is, but I’m guessing it is nowhere near the install base of the largest WordPress plugins. And so there was a couple that you mentioned in one case, one of the plugins that had a critical vulnerability this year was over 3 million website installs.

And then there was another one with over a million. The seriousness of that is pretty obvious I’m sure. The quantity of people that are affected. You seem to be saying that in terms of the conscientiousness of the developers, you seem to be fairly happy with that, in that a lot of vulnerabilities got patched fairly quickly and disclosed in the appropriate way.

However, we’ve still got this legacy of older plugins. In fact, you mentioned nine that have been removed from the repository, completely gone from the repository and yet have vulnerabilities, which essentially are going to stick around for ever.

[00:22:56] Oliver Sild: Yeah, these are the most scariest ones. Like in, in most cases what we see is that developers, once a security report is being delivered to them, they look into it and they release a patch. So they fix it in most cases, the vulnerability doesn’t become publicly disclosed before that happens. Like, we also have our own disclosure policy where we just don’t like, we let the developer know about the vulnerability that was reported to us about, his, or her plugin, but at the same time, we keep it.

We don’t publish that before we make sure that the developer had enough time to fix that. And also after that, that they have time to let their own users know that there is a security update and they should basically, update the sites as fast as possible. Just to make sure that we don’t cause any unwanted damage where this information might get in front of the wrong person.

And we, what we wanted to do this year is we counted all the critical vulnerabilities and by critical, we mean the ones that are actually being, are actually the vulnerabilities that have the characteristics that hackers would want to automate exploitation attempts. So that means that it’s usually unauthenticated vulnerability, that basically you can either inject something to the website, add a back door or something, and you can fully automate that. And there was, yeah, like I think we counted, I think it was 35 different plugins that had that kind of vulnerabilities in last year. The scary part was that many of them didn’t really receive a fix at all.

So these are plugins where the developer was either, had abandoned the plugin, was not active anymore. So in that sense, if you were running this plugin for example, if you were part of those plugins that didn’t ever receive a patch for this critical vulnerability. In your WordPress website, you would just see that everything is up to date.

You would never see that there is an issue with this plugin unless you are being notified by like some security product or something that would say that, Hey, there is a vulnerability in this plugin. So this is a bit scary.

[00:25:09] Nathan Wrigley: Yeah. This, I think we should dwell on this actually, because it seems like this is a real failing, or at least an area of possible improvement in the future. So let’s just reiterate what we’ve just said. So we’ve got a plugin, which has discontinued support. There are no ongoing updates for whatever reason, this plugin, which is in the repository is stalled. Nobody’s going to update it in the future.

Now, at some point in the future, a vulnerability is discovered in it. It could be severe, it could be minor. It doesn’t really matter, but the point being that any WordPress user would never be alerted to the fact that something here is awry and something needs updating, because the only mechanism we’ve got in the WordPress admin area is to see when things need updating.

And so we update them. And if there’s no update, the assumption would be everything must be fine. How on earth do we overcome this problem in the future? Do you have any thoughts on a process that we could adopt or some direction of travel that we might move in to make this go away?

[00:26:15] Oliver Sild: Oh yeah, it requires a lot of awareness building around the ecosystem in general. We need to talk even more about the security in the WordPress ecosystem. We need to make sure that developers are also the ones that are not afraid to talk about security, because over the years, what we’ve seen is a lot of developers, like the plugin developers, specifically have been worried about like even dealing with security issues because they don’t want to be highlighted as, oh, this plugin had the vulnerability.

So they see this as a negative kind of attention. In fact, for me, for example, completely from the opposite side see it as a very good sign that this developer actually takes attention on security. But that’s obviously because, from my end, I just see that there are so many vulnerabilities in different plugins.

And the fact that there’s just increasing numbers of them now being reported from the last year, in our white paper, for example, that just the fact that more of them are being identified and being reacted on. It’s not the fact that there’s now, more of them, but they are at the same time what they see constantly is that the developers don’t need to be afraid of the security issues in a sense where they try to avoid those issues. And I think there should be even more and more open discussion about, hey, let’s together make the security in the plugins and in the software better.

And I guess in terms of the core, I guess at one point core would need to have some level of security incorporated to basically give an insight on the plugins that are being used on the websites. For that specific reason, for example, because there’s been so much people saying, even from people that worked in the wordpress.org, we’ve seen people saying that, yeah, basically you just need to enable auto updates and you would be fine.

But it’s not true. It’s just not true because in many cases like that, you can have auto updates enabled, but this there’s no update, if there is no update for the plugin, basically you don’t even know about issue. So I guess, yeah, this is definitely something that needs attention over the years. We are doing our best, like our product is actually literally covering that area of letting the users know if there’s a vulnerability, even if this plugin is being removed from the repo, or even if this plugin didn’t even receive a patch. So we are letting our customer know about that. Then we are also providing a patch to protect against the attacks against these plugins. But at the same time, yeah, I think this is clearly a issue that needs more and more attention.

[00:28:58] Nathan Wrigley: Yeah, it would be nice to come up with some kind of system which didn’t break things, which enabled, I don’t know, perhaps these particular plugins to be disabled. In some way removed, but then that of course has all sorts of implications in terms of the ownership of the site and whether you actually want people to have the capacity to be able to remove things from your website. People flock to WordPress because you get to own everything. It’s yours, and you can modify it as you like. And the idea that some plugin could be removed, disabled without your say so, is one that I’m sure the community would definitely want to have a long and deep conversation about. But interesting. You found nine that had these problems this year and there seemingly is no way of automating that problem to go away, as yet.

Okay, so we’ve dealt with core, we’ve dealt with themes and plugins and what I’ve just described as orphaned plugins. Let’s just talk about the broad bits and pieces that your report highlighted this year. Some of it is good. Some of it is less good, but the first sort of headline pieces that you’ve definitely found that there was a rise in vulnerabilities found compared to 2022. On the face of it that sounds like a bad thing, but you’re saying that there were many more in the previous year than in the year prior to that.

[00:30:24] Oliver Sild: Yeah, it’s the best news of the white paper, to be honest, because that means that there was 150% more vulnerabilities being identified. Imagine if there was zero vulnerabilities being identified and only, and all those vulnerabilities would be sitting there, still doing that, and just nobody would know about those, until someone who with malicious intention could just take advantage of them.

I wouldn’t be surprised if this year we are going to see even a bigger increase because there’s just so much more attention being put into identifying those vulnerabilities and helping the plugin developers to make their code even more secure.

We are for sure investing a lot into it with Patchstack Alliance. Like last year we paid out like 13 K in the bounties for like individual ethical hackers who just let us know about vulnerabilities that they found in any plugins in the WordPress ecosystem, and we just paid them for that effort. So we’re definitely going to double down this year on that as well. So we’ll see how that will affect this year.

[00:31:31] Nathan Wrigley: Yeah, it’s interesting because on the face of it, if the number of vulnerabilities is larger, the immediate instinct around that is to assume that things have got worse. And of course the statistics could be for all sorts of reasons. As you’ve just described, there’s perhaps more eyeballs looking to discover these things. There’s initiatives like your own and the bug bounty, which have enabled people to actually feel that they’re getting remunerated for that. And so they’re more serious in the endeavor to search for them. But also, maybe it’s a product of the fact that WordPress itself is just growing, and as it grows, there’s going to be more eyeballs looking for these things, but also possibly it becomes a bigger target. And so there are more of these things out there. There’s more plugins, there’s more themes, there’s more code and it’s just a sort of byproduct.

But anyway, interesting take on it. Definitely worth looking at. That was the rise in vulnerabilities now onto more sort of specific details about what these types of vulnerabilities are. A significant proportion of the things that you concerned yourself this year with were XSS vulnerabilities, which is cross site scripting. For those people who are not really familiar with that, would you just paint a picture of what cross site scripting vulnerabilities are, and any thoughts on why it represents almost 50% of everything that you’re seeing?

[00:32:54] Oliver Sild: I think cross site scripting is just one of the easiest things to find the web. See, cross-site scripting, for example, you take like a website search bar, if you go to a WordPress site and there’s like a search bar. And if you, for example, write inside of this search bar, like HTML code, for example, and then what happens is that this, the functionality that is searching this information from the site for example, is going to show you the results, and this HTML code that you put there would then basically be meshed together with the kind of code of the website and it would just basically load it.

I think actually even a better example would be with comments. Wherever you have, like WordPress don’t have that issue, but for example, or earlier days, there was a lot of websites with commenting sections. And then if there was an issue where if you basically post any HTML code with some, maybe Java script, something that was maybe popping up like an alert for you and you post that comment there, then what would happen is that the site would then basically render that into as part of the code of the website.

So when it was even saved in that case, then the siet would basically load the code that was posted there as actual comment. So this is like a sanitation thing as well. So you want to make sure that you make a difference between actual code and what the content is that is being submitted to the website or the input in that sense.

[00:34:26] Nathan Wrigley: So it represents almost the majority, 49.8 something percent of everything that you find. But I guess that is as you describe, it’s because it’s relatively straightforward to pull off. Possibly at least from my perspective, the vulnerabilities then shrink in terms of percentage and towards the very bottom, I guess the worst really that you could have is remote code execution. And that number is not 0.94% of everything that you were looking at. So I guess there’s some positive message to come out with that. Less than 1% of all the things were truly very serious indeed.

[00:35:02] Oliver Sild: Yeah, indeed. As always easiest stuff comes out the first. So these are the ones that are usually reported the most, that are mostly visible and accessible in terms of, for even a simple thing can just submit something into a comment form, and see if it’s going to load something in a weird way. So this kind of vulnerability is going to be found very easily.

[00:35:27] Nathan Wrigley: Yeah. Now moving on to plugins. Curious thing that you’ve discovered again from the data that you’ve managed to gather is that there are actually fewer plugins in use, which, you would imagine, would reduce the attack surface. And so you would equally think that the number of things that you were having to clean up regularly or that you were discovering had been broken, would go down. But it seems that there’s a sting in the tail. So there’s fewer plugins, but more of them are being left without being updated.

[00:35:56] Oliver Sild: Indeed. Yeah. This was an interesting find. I expect that, I do still expect that the number of plugins, we’re going to see this number dropping more and more, even in the upcoming years, as people are getting more and more aware around the security implications when you’re just, using a lot of plugins on the website.

But I think it’s also about the kind of hygiene thing where users are also not so prone anymore to leave like deactivated plugins standing there on the website. So they’re starting to delete those things. And I think people are seeing more and more that plugins, like each of the plugin that you install to your website can be like a link, can be like an entry point for a hacker if there is a vulnerability found in that specific plugin.

So basically the less buttons you have, you reduce the risk significantly. So it was interesting yes, to see that even though the number of plugins installed per website is actually dropping. But at the same time, the amount of plugins out of those that were outdated was actually higher. I’m not a hundred percent sure that what is like the actual cause of that, or if it’s just like something that we see this year, but I think next year we’re going to have more data to see more into why that could be.

[00:37:21] Nathan Wrigley: Yeah, it’s curious on the 50,000 websites that you were analyzing in order to generate this report down from 23 plugins and themes, now residing at about 18. 18 different plugins and themes installed. Yeah, that’s interesting. We’ll revisit that next year and see where we’re at. I guess this is a fairly obvious thing to say, but it was worth pointing out, the seventh point on your list of things was that the easy to exploit vulnerabilities remain the main targets, like I said, that’s fairly straightforward.

[00:37:52] Oliver Sild: Anything that is unauthenticated and basically that can be automated.

[00:37:57] Nathan Wrigley: So it’s old tried and tested things that the hackers know can be achieved. They’re going to go after the low hanging fruit. And sadly, the eight point that you make is that old vulnerabilities remain as great big targets. So things which could have been fixed from last year, still are hanging out there and being exploited.

[00:38:19] Oliver Sild: Yeah, indeed. I think a big reason for that, there are all these automated hacking tools. I mean that people don’t load from Github or from hacking forums and places like that, where guys who, you know, sometimes kids who get into, like looking into hacking, trying to maybe yeah getting into that field. They are basically downloading software that is prebuilt by someone and there’s someone made it at the point where there was specific vulnerabilities just introduced. So they have hard-coded the exploitations into those tools and these tools are still available, and people who are getting into the kind of dark side, I’d say, are then starting to play with those tools.

So this is one of the reasons why we see that happening. We’ve seen a few of those tools as well. This kind of proves the point. But then in terms of that, like there isn’t a lot of hits that these tools are probably getting, because most of those websites that running those plugins have already been either patched or either hacked already and then patched.

[00:39:29] Nathan Wrigley: Yeah. An interesting thing that comes up later is really around the personnel who are responsible for updating things. And you’ve got a couple of points on this, but we’ll try to tackle them in one go. Whilst there’s an increase in awareness of security on WordPress websites, no doubt because of publications such as your own, it would appear that there’s not a lot of time, space, money provided. So who is responsible for updating things could be really crucial. And it says on your report that 53% of respondents stated that they updated their components weekly. Some, perhaps as many as 20% did things daily. 18% possibly monthly updates happening. So that’s quite an important blend in the picture. That the frequency of updates, crucial I suppose. If you’re leaving things for an entire month and a not keeping yourself up to date with the news, I’m sure that there’s many websites where monthly is just off the charts. It would probably be more like every six months or possibly not at all.

But then also, the difficulty in actually finding a budget to do these things. And you make the point that many, many websites be they run by an agency or an individual, or just a solopreneur. They have no budget for this kind of thing. They’re just crossing their fingers and hoping for the best. So do you want to talk around that? The people involved, the time that they’ve got, the frequency of updates and the budget that they’ve got?

[00:40:59] Oliver Sild: Yeah. The frequency is an interesting take because in terms of how fast we are often seeing attacks happen against websites when a new vulnerability, or let’s say a critical vulnerability is being found in a plugin that the website is using. These like when we are not even talking about zero days in this case. Zero days are the ones that nobody knows the vulnerability before it’s already being attacked.

But for example, sometimes the vulnerability is being discovered, disclosed. And after that, hackers learn about that and then they are going to basically exploit that. So there’s like a cat and mouse game. Who patches first? Is it the hacker or, sorry, who uses the vulnerability first? Is it like the website owner who was going to update this and patches it, or is it the hacker who manages to exploit this before to website owner managers to update it?

And this time period is actually somewhere around one hour.

[00:41:54] Nathan Wrigley: Wow.

[00:41:54] Oliver Sild: Yeah. So this is something that has to be kept in mind that, daily updates sounds good as well. And from there on, the longer time to take for updating, the more risk there is for the website.

But the interesting thing is like the auto updates. Have you put like WordPress autoupdate into Google search and look that into what kind of articles are popping up?

[00:42:21] Nathan Wrigley: No, but I can imagine you’ve got some interesting insights there.

[00:42:25] Oliver Sild: Basically the majority of the articles are about how to turn off WordPress auto updates.

[00:42:32] Nathan Wrigley: Yeah.

[00:42:33] Oliver Sild: I remember when WordPress auto updates came for the plugins, and basically like most of the kinds of articles or like how-to’s use we’re about to come to turn it off. Because people are still scared the websites are going to break down if there’s some feature breaking update coming for a plugin. So this is something interesting about the updating side of things that we’ve been seeing over the year.

[00:43:00] Nathan Wrigley: Yeah. That’s a really interesting, difficult seesaw to think about. The idea of being, if you switch off auto updates, which of course is available for multitude of things in WordPress, including plugins, you can just have click a button next to the plugin and it will just automatically update it.

A lot of people concerned that the update might break the site. So in terms of them having to do some additional work to un-break it, or re-install from a backup or whatever it is that they need to do. That concern in many cases overrides the possibility that there could be some vulnerable software there, a plugin, which is vulnerable.

I guess it’s a difficult one to decide which way to go. But it’s curious that a lot of people have decided to not implement automatic updates because presumably of the fear of things going astray in the way it looks or a plugin breaking. And of course that is a legitimate concern.

Just seen over the last week that a couple of major plugins had problems where they broke significant parts of the websites, and they had to roll back those updates and then ultimately figure out a patch and then release that as the new update, which then got automatically updated. So I can see where people’s concerns come from there. I guess your advice would be switch on automatic updates because having a hacked website is probably better than having a modestly broken website.

[00:44:23] Oliver Sild: Yeah. And actually the other way around. I heard you were saying that the hacked website is better than broken website. So I was saying the other way around, so it’s better to have a broken website than a hacked website.

[00:44:37] Nathan Wrigley: That’s what I intended to say if I got that wrong. I apologize. Yeah.

[00:44:40] Oliver Sild: But yeah, basically, yeah, it’s better to have a broken website because you can at least put the maintenance mode on and do something about that and fix it. And usually like how WordPress is behaving right now is that it also lets you know if something was breaking down and it doesn’t like, the site doesn’t throw you a bunch of errors.

It isn’t like that anymore. So it isn’t that much of a risk at that point anymore to be completely afraid of plugin auto updates.

[00:45:09] Nathan Wrigley: Yes. Then that’s a good point. And you will also hopefully receive an email with some kind of information about the problem that may have brought your site down.

Okay. Turning then to the budget. This is really interesting, the data that you’ve gathered, as much as 28% of people who responded said that they basically had zero budget to protect their websites. In other words, 28% of those people were just hoping for the best and crossing their fingers. And a further 27% said that they had a monthly budget of between $1 and $3.

The numbers vary. There are people who had significantly more and people who were somewhere in between, but quite an interesting spread there from zero to quite a lot. And the majority of these numbers are tending towards a very small budget I guess that you would argue that, it ultimately, it would be better to have something than nothing.

[00:46:01] Oliver Sild: For sure. Yeah. I guess the zero budget also means free plugins right? In a way of using like free security plugins and then it doesn’t mean a hundred percent that don’t use anything or they don’t have any measures in place. But at the same time, what we are also seeing is that security is still a hard sell.

Especially when we talk to agencies where the customers are like, aren’t you supposed to take care of it? Not understanding that the security is a thing that needs to be taken care of separately. That is a part of ongoing process and that you should basically prevent them rather than just deal with the consequences later on.

There was another good point where we also asked from the same people about how much they have paid for malware cleanups within the past year. And that was like, there was one, I think the highest responder was like, who said he spent 4.8 K dollars on cleanups last year. That’s a lot of websites that you can secure or protect.

And basically we even get some sort of service on top of it, or like incident response assistance that like we offer where, specialists are jumping in and fixing everything if something should happen, even though we had security in place.

[00:47:21] Nathan Wrigley: Now, obviously you’re here representing Patchstack, and Patchstack is a commercial company. You’re in the business of securing websites, but you’re also in the business of paying your employees. So you need to pay to use the service. There was an interesting piece which got written over on the Master WP website, and I will make sure to link to it in the show notes. And there’s a further piece which we’ll get to in a minute.

It was written by Rob Howard on March the 14th and it was called, is WordPress security getting better or worse. In this piece, he takes your report to task and largely it’s around the kind of language that you use. There’s definitely merit in going and reading it, but you then, one of your team members issued a non rebuttal rebuttal of that piece.

But just for a couple of minutes, let’s just delve into that. I think his concern is that the way that you portray the report is, let’s use the word sensational. His argument would be that it’s in your interest as a provider of security solutions to paint a picture, which is, let’s say somewhat alarming, there’s all of these problems, and look at the enormous array of different vulnerabilities that there are out there.

And therefore you bring the statistics to bear that best represent the fact that there are problems. So just wanted to give you a chance to talk about that. And I will also mention. The rebuttal piece, again on the same website, interestingly, Master WP it’s by Robert Rowley, they’re both Robs, so you’ll probably have to read them one at a time.

And this is called, rebuttal, how Patchstack is improving WordPress security. So I’m just giving you a platform here to reply to Rob Howard’s piece, where he takes you to task for using sensational language and massaging the figures so that they, he accuses you of using sloppy statistics.

[00:49:08] Oliver Sild: Yeah, to be honest, I’m not a hundred percent sure like what is really sensational about that? But in a way, when we put together the whole white paper, we just basically looked at the numbers. We look at the numbers and we are presenting what it is. I understood that one of the things that may be what he thinks about is sensational is the, that there is 150% increase in vulnerabilities being discovered.

It is something that we can just say, and it’s a fact. The question how do you interpret that, whether negative or positive? That needs more context. And the context we do give. The context is that just means that there is more vulnerabilities being identified, which is a good thing because to WordPress is getting more secure because of that.

So when this post was published by Rob, we actually went over it, then we were like, oh, actually there’s like a lot of good points because obviously we are also a little bit tunnel visioned when we are dealing with that much of data and hooking into the problem that we are trying to solve. And then we’re obviously talking about that, how we’re talking in house, in a way.

So we should, I get his in terms of like a criticism that we probably should also be more specific in terms of how we are, or like what our intentions behind that are, like whether we see in a negative way or in a positive way. But yeah, like I, we were really happy about the piece that he wrote. We even shared his piece, which wrote criticism about Patchstack on the Patchstack Facebook page, on the Patchstack Twitter. We were like, hey, see what he wrote. There were really good points. And then later on we obviously responded to that with our take on what we actually meant by that and where we thought he may be, in some cases, wrong and where he was right as well.

[00:51:11] Nathan Wrigley: Yeah. It’s interesting. Obviously statistics can be in every walk of life, statistics can be looked at in a variety of different ways. And you only have to look at virtually any parliamentary system on earth to realize that the opposition can present the same statistics in an entirely different fashion and it’s completely plausible and the numbers are correct.

Yeah, I think some of the things that he was saying was it would just be nice to have some sort of background, some insight into, so for example, does the increase, this 150% figure that was mentioned, is that because there are more plugins that are out there? How serious are these vulnerabilities that we’re talking about? If there’s an increase, but 99% of those were benign and did virtually nothing, could they be lumped in as 150% increase? Has the total number of plugins in the entire market changed? And what are your reporting methodologies in terms of what is it that you’re actually trying to do from the report? Are you just trying to be a purveyor of information? Or is there a hope from the Patchstack piece that some customers will come your way as well? So just those pieces really?

[00:52:18] Oliver Sild: Yeah. I guess if the statistics didn’t come from like some internal data that we are not showing anyone, it’s the public CVE’s that we are one of the authorities to generate the publicly or like the internationally kind of standard vulnerability identification IDs. There’s three companies in the space which can do that in the WordPress ecosystem. And we’re one of them. So like this vulnerability information, it’s all public to the, to everyone, we are just showing that’s how much there was in 2020. That’s how much there is in 2021.

There is no kind of translation whether if it was actually not that much of an increase or not. The question isn’t about about like increase, I guess in general, I think the question is about why it was increasing. And the increase isn’t because, at this point the increase isn’t because the WordPress is getting more plugins to the wordpress.org.

We actually, even, I think in the rebuttal piece have shown how much percentage the wordpress.org repo has grown over the year compared to the same period. The thing literally is, there’s just more eyes. There’s more people looking for the vulnerabilities in the plugins and they’re identifying more vulnerabilities.

These vulnerabilities may or may not be in there already for years. It’s the number of vulnerabilities that the 150% of increasing vulnerabilities found in WordPress ecosystem means that there was just 150% more vulnerabilities found in WordPress ecosystem. Basically, it means just that.

Now, if you want to give that positive or negative meaning, it is definitely up to you. Of course we could have tried probably present that in a better way and maybe, I’m not sure if we actually wrote in our white paper that we find this a good thing. I need to double check it really quickly, but we usually like anywhere we talk, we always say that it’s a good thing. It is what it is.

[00:54:31] Nathan Wrigley: Yeah. It’s interesting because the language that Rob would like is definitely more on the sort of optimistic side, isn’t it? So instead of bringing out the things that are going wrong, he would like to emphasize the things that are going right, so for example, he rewrites something where the illustration is that there’s problems, and he says that a possible alternative headline would be not 0.65% of WordPress sites get an important update. So I guess it’s stressing the negative.

[00:54:59] Oliver Sild: Would you read that?

[00:55:00] Nathan Wrigley: Yeah. And that’s an interesting thing about human nature, isn’t it? Because you only have to look at newspapers for example, or headlines in articles on the web to realize that well, people are, they’re drawn to controversy to some extent aren’t they? They like the sort of sensational aspect. And so yes, interesting point. Yeah, really interesting point.

[00:55:19] Oliver Sild: And in our case, if, when we released the white paper as well, we even saw in some cases where journalists were, we didn’t tell them what, we didn’t actually even send it out in that way that all you need to use, like some sort of headlines, but we did see the journalists just take out some piece of data and they would just make their own kind of headline based on that.

In a way, I think people need to also think. I understand that, okay, let’s then talk about this issue in a so positive way that like nobody would even understand that there is like a problem at all. But is that our goal? If we want to make WordPress ecosystem more secure, we need to talk about those issues.

There are issues and these issues are being solved, and we are showing that there is like increased effort in solving those. Let’s talk about those things. We shouldn’t just let’s try to somehow sugar coat it in a way or

[00:56:17] Nathan Wrigley: Thank you. I will definitely mention both of those articles in the show notes. We’re going to have to round it up because we’re approaching the amount of time that we’ve got. Before we go though, obviously we know that you’re at Patchstack, which is at patchstack.com. But should anybody wish to reach out to you personally, are there any good ways for people to do that?

[00:56:38] Oliver Sild: Yeah, anyone can reach out to me on Twitter. I think that’s the easiest way to reach out either DM or just tag me. It’s @oliversild. And then yeah, if you want to look at what we are doing. If you’re a plugin developer, you can always get like security testing for you’re plugin through Patchstack. If you’re an agency and you want to have security overview and a vulnerability overview, every single website that you have across your portfolio, then you can use Patchstack for that.

And for hosting companies, we also have so they would always know if new vulnerabilities are being reported to us by the ethical hackers community. Or if we are adding new items to the database from any other sources. So Patchstack database, Patchstack audits. We’re basically doing anything around WordPress plugins and trying to make the whole ecosystem more secure.

[00:57:31] Nathan Wrigley: Oliver Sild, thank you very much for joining me on the podcast.

[00:57:35] Oliver Sild: Thanks Nathan.