TRANSKRIBEERI 🔗
2026 10 21 audio: Hello, my front-end friend, and welcome to General Musings. My name is Kevin, and here at this podcast, I like to talk about whatever is front of mind for me in any given week, usually in some way that's related to front-end development, and we're definitely on topic with that. But it's actually twice this week because this is a bonus episode, because something has happened that I really want to talk about. you may or may not have heard about it by now, but yeah, there's there's some stuff going on in the world of PHP with some major security issues that have come up with a couple of bugs that have led to some really big Vulnerabilities and I wanted to talk about those today because my dad came to see me a little bit earlier today to ask me if I've ever heard of PHP. And I was like, the the situation has reached the the masses or the the normies, or I don't know what we want to say, the non-tekies of of the world. if my dad is asking me about PHP. And if you if you haven't heard about this, you don't even know what I'm talking about. there are currently headlines going around saying 70% of the internet is affected by a dangerous PHP bug. And yeah, that probably sounds pretty bad, right? And then my dad's coming to talk to me about it because it's on the BBC where they're talking about it. And that's because like government agencies are taking their websites offline and there's other companies as well that are doing that. And while I'm a little bit skeptical of the 70% number, I actually don't think it's a bad thing to have headlines like that right now, because I think people really need to be aware of this problem because not only is this a real bug, it is a very serious problem. And so in this video, I'm going to be going through what's actually happened so far, why it's such a big deal, where that 70% number actually comes from, and where things might actually be, and what you should be doing about it as well. So, as far as what's actually happened, there's two bugs that are in PHP itself. these aren't things that are in WordPress, it's not a plugin, anything like that. It's in PHP the language. So the language that WordPress and Drupal and Joomla and Magento and other things are built on top of. And they all make up a huge chunk of the internet in general, not to mention just like the custom PHP sites people have and everything else. and this actually turned up it was some researchers at Wiz, which is a cloud security company, along with a company called Caliph and OpenAI's Codex Security Team. And they all reported this issue to the PHP team back in August. And you might be going, August, that was a long time ago. Why is this becoming a thing now? And yeah, you're totally right. It has been a while. But what happened next normally is all done very quietly. And in this case, that's what happened. It got reported in around mid to late August. Then by September, the team had started working on fixing this issue. And all of this is going behind the scenes. Their PHP team builds a fix, they provide that to hosts and Linux distributions to get it out ahead of time. Then the team is going to announce the bug and say, hey, look, we have a fix for this issue that exists right now. But the thing that made it worse was that. The fix was supposed to come out on Thursday, October 22nd. I'm currently recording this on Wednesday, October 21st, and the fix is already out because yesterday, which would have been Tuesday the 20th, the details of all of this leaked on a post on Hacker News. So the PHP team had to push the release date up by a day, and the fixes came out on the 21st instead. So there was a timeframe of probably less than a day from the time the post went out to when PHP did it, but there was a time where This information was leaked out and there was no fix in place. And this is first of all a really big deal because there was a major issue. And when I say major issue, this was very severe. there is a severity scale for bugs and and vulnerabilities like this. And in this case, PHP wrote rated both of them because there's two different vulnerabilities. They both got rated a 9.2 on the 10 scale, which means critical, which is You know, 9.2. It's just it's really bad. there were rumors or some headlines going around that it was a Taunoto 10, but that wasn't PHP's rating. It was probably some rounding up because it looks good for a headline. But there's actually three things that make this really bad beyond it just being, it's it's severe, right? So the first one is that it lets people run their own code on your server. It's basically a full takeover. They could read your database, your user's data, grab API keys, they can inject spam or malware into the pages on your site. Or they could even go and like leave a back door so everything looks fine, but they could come back later and do whatever they wanted then. And that's pretty bad to begin with. Second of all, though, is they also didn't need to log in. A lot of serious bugs that we see require you to either have an account so you're in the system, or they need the admin to click on something where this one doesn't, which means the attackers can automate everything and just scan the internet looking for targets. And the third thing that raises this up. To be even worse is with some of the setups, the attack happens before any of the site's code even runs. So this means that it really doesn't matter how well your site is built, right? This isn't a bad plugin or a sloppy code problem. If the PHP underneath isn't patched, a perfectly well-written site or bit of code is it's still exposed. And for all this, it doesn't matter how the server is running PHP, because there's a few different ways that a web server can hand a page over to PHP. And this affects pretty much all of them. So there's PHP FPM, which runs PHP as its own separate service. It's actually quite common and paired with Nginx. Another one is modph, which
Load full transcript
builds the PHP into the Apache web server. It's a bit of an older setup at this point, but it's used all over the place, including the official Docker images for WordPress, Drupal, and Joomla, which are what the researchers, from what I understood, were actually using to show. Or d to prove this vulnerability. And this is the the higher risk part that I was talking about. The PHP has said this is the highest risk setup. and that's the one I referenced earlier, saying that it allows their code to be run before your site's own code. Then there's even older than that, there's PHP CGI, which is one of the oldest ways of running PHP, more modern ways with like FrankenPHP, which is a newer server with PHP built right into it, or Lightspeed, which is a web server that's really popular with shared hosts. And if you don't know what any of those are. Don't worry about it. The point is basically any normal way of hosting PHP is affected by this or by the two vulnerabilities. Now, does that mean 70% of the internet is affected? Not sure about that. The numbers come from Wiz's own write-up. Their headline says that it affects 70% of the internet. but that's because in their article they say that PHP powers 70% of all websites, which I'm not 100% sold on. W3 Techs, which tracks what technologies website use. They say that PHP is used by 69.3 of all websites whose server-side programming language they know. So, you know, static sites don't count there. And there's other ones that have server-side, but they just don't know what language is actually running. And even if it was 70%, maybe not all of those are vulnerable. The patch has been out now. So you get the idea. But it's still, like, regardless of that, it's still a massive amount of word websites, right? So like I don't want to pick on that number. because I mean, if you just look at WordPress. That's around 40% of all websites, at least according to W3Text. And again, this isn't only targeting WordPress, but even if it was just WordPress, that would still be this massive problem. But it's not just WordPress, it's everything that's using PHP. And while this is really bad, things get messier from here, because they have Put out some fixes. But the fixes only came out for PHP 8.2 and newer. Now that means if you're on PHP 8.1 or older, PHP isn't releasing a new version for you, and that's actually a lot of sites. Of the ones that are running PHP, about 27% are still on PHP 7, almost 14% are on either PHP 8 or 8.1, and almost 8% are still on PHP 5. That means that around 48% of PHP sites are on versions that PHP won't ship a fix for, which is insane, right? So it's like, it's fine, we have a fix. Lots of you don't have one. And that's because, like most things that ship new versions, PHP doesn't support the old versions for Infinity. In the case of PHP, they offer support for four years, which I think is actually pretty good. but even if you look at 8.2, which is getting fixed now, the support for 8.2 is ending at the end of this year, because we're getting up to that four-year window. So that means there's no like easy way to fix things if you're running an older version of PHP, though not everything is lost here. Because PHP actually decided to do something a little bit unusual, which is PHP published the fix as raw code. Now, dealing with raw code is not the same thing as just Upgrading to the newer version that you might if you were on one of the up-to-date ones already, because you'd have to build PHP yourself for this. And most people aren't doing that. But the fact they did it at all shows you, first of all, how important it is to try and at least have a solution to this, and also that PHP realizes how much old PHP is out there. Now, some Linux distributions like Ubuntu, they add fixes to versions as they ship. So, depending on your setup, you may get one of those fixes through a normal update. But if you're on something like PHP 5 or an early version of PHP 7, nothing is going to be coming from PHP at all. Which leads to a really big thing because first of all, that means there's people that are sort of stuck a little bit. But also the biggest issue, maybe of all, which is that most site owners don't control their version of PHP. The host does. Right? Like going if you have WordPress and you log in, you Updating WordPress doesn't do anything. Updating your plugins doesn't do anything. You need to update PHP, and that's why so many sites get stuck on old versions to begin with. It could be that you're running an old theme and upgrading the PHP would break the theme or the plugin. And of course, then there's sites that just aren't actively being maintained anymore, but they're still online and still being used. And now they're open for all these vulnerabilities as well. So how worried should you be? And I guess it depends a little bit. When I was talking to my dad, I was like It won't really affect you unless the site, well, first of all, I guess your data could leak. That's definitely, I guess, a possibility. but it the main thing I was like, well, if you go to visit a website and it's down, then you know that it's down, right? and there's definitely like attacks that are going on right now. Cloudflare's already said it's been seeing early attacks, and a security firm Watchtower says it's been seeing attempts to exploit both bugs. On the other hand, there's other security companies like Huntress that monitor their Customer systems and they say they haven't seen anyone exploiting anything, at least as of this morning. but I have a feeling there's lots that are at least attempted exploits that are going on now. Patch Stack's another WordPress security company that said they've seen multiple active exploitation incidents confirmed. So maybe some mixed messaging depending on where you're looking, but I think we can. know that things are in place. But as far as I can tell, no one's publicly confirmed a successful break-in yet, at least when I
was doing my research for all of this. And attempts aren't the same thing as break-ins, but again, right now if somebody's dealing with an actual successful attack, they're probably very busy at the moment and maybe haven't publicly announced it yet. But there is some breat breathing room depending on how you're hosting things. Cloudflare, again to talk about them, they have put firewall rules in place to block these attacks before they reach sites. And this is for all of their customers. So even if you're on a free plan, that's there. It's not a fix, but at least it's a stopgap to try and help things while fixes are being put in place. And as I mentioned, there's a lot of organizations that while they're trying to fix things have just taken their sites offline. The Netherlands is one of them that where they took off their government and education websites. And there's been a number of other sites that I've been hearing about coming offline as well. So they can fix things while the site's off. Once they know everything is fine, then they'll put the site back up. And I guess that leads us to what you should do. So I guess the first thing would be it depends if you have a site that's running PHP or not. but if you do have one, find out what version of PHP is currently running. your host's dashboard should tell you in there somewhere. Depends on the host you're using. So it might be easy to find, it might be a little bit harder to find. If you are using WordPress, you can find it under tools, site health. info and then go into the server. If you're not using WordPress and you're having trouble finding it, if you're on shared or managed hosting, you should be able to ask your host if they've patched it. I'll put some version numbers down in the description just that you can look for the ones that you want to see to know if it's there. But yeah, contacting your host that you might just get a chat bot that might be a little bit frustrating to actually get through and the host might be getting slammed right now a little bit as they're trying to push these fixes into place. But yeah, there's a lot being done but I would say definitely Take a look at what version your host is on if you can. If you own your own server, it's a little bit different. I would just say go and update now. you might be going, but I'm on five and it's me a bunch of breaking changes. That sucks. But I think that means it's time to bite the bullet and figure out how to actually get that update in place because it's obviously important to do. PHP's advisory does have some settings that you can use to reduce your exposure, but they've also been really clear that this doesn't make you safe. So you could. Go and check out that advisory again. That'll be linked in the description as well. just to sort of reduce your exposure while you then go and look into the different upgrading paths that you might have. And I mean, this is for the easy upgrades and the hard ones, I guess. But if you are on like PHP seven or five, this is, as I said, time to bite the bullet and deal with that. It could even mean taking the site down for a while before you're able to get it up to one of the new versions of PHP and getting things back online. Yeah, these vulnerabilities really are. serious, about as serious as they can come and a huge amount of the web is being affected by this. And the crazy thing is a huge portion of that will also not get an official fix because they're running on such old versions of PHP. So yeah the severity of it is real and I'm curious. If you work with WordPress or other things that are running PHP, are you in panic mode now? Are you not worrying about it? Leave a comment down below to let me know. And if you're not dealing with all of this, because maybe you're like me and you have some static site generators that you're using instead and you're taking it nice and easy. Well, that means until next time you have the time to make your corner of the internet just a little bit more awesome.