SANS Institute · Transcript · · Updated
Emergency Livestream - PHP Vulnerabilities: What You Need to Know Today and Do Right Now – Transcript
Video by SANS Institute · Watch the original on YouTube
Summary
AI-generated from the transcript. Verify details against the source video.
- The PHP security team has released fixes and technical advisories for two critical vulnerabilities rated at 9.2 out of 10.
- PHP confirmed that these flaws can allow remote code execution where an affected server runs code controlled by an attacker.
- Any version of PHP from 5.4 and higher is vulnerable to this bug in some way without requiring authentication.
Use this video with Pro
Reading, copying and transcript downloads are free. Create saved AI results for this video with a signed-in Pro account ($9/month).
Transcript
Search ignores accents. All transcript text stays visible.
>> Hello to everyone joining us live and hello to those catching the recording later. I'm Rich Green and I definitely appreciate you all taking this time to join us for what I will say is an emergency SANS webcast on the PHP vulnerabilities. Some of you may have been following the news. Some of you may be hearing about this for the very first time.
Now, SANS doesn't do a lot of emergency webcasts. But when we do, it's because something deserves the community's immediate attention, right? Since this news broke yesterday, we've had folks digging through the advisories and technical information as it becomes available, working to really understand what's confirmed and what it means really for the people responsible for the systems.
And those systems, the ones that are tuning in right now. You all know SANS cares about the community and helping people protect organizations is at the heart of what we do. Training is one part of that mission. Getting practical information into your hands when something like this happens is another and that's why we're here today to help you really understand the issue and make informed decisions about what to do next.
We have roughly 29 minutes, maybe 30 minutes, right? So we'll focus on what this means for you, your systems, and your organizations. I'll have some questions for Moses and if we have time, we might even be able to convince him to do a little demo for us.
A little bit about Moses, if for some reason you have no idea who he is, which isn't cool. A red team operator at NuSec, SANS senior instructor, author of SEC588 cloud penetration testing. You'll also find him teaching all the various SANS courses focused on offensive AI.
So, Moses, I definitely appreciate you carving out the time to jump into this with me. >> Oh, yeah. This is a late breaking. I think um the official embargo for this vulnerability was actually lifted what, 2 hours ago? So, this is a very late breaking announcement and everybody has been trying to figure this out since yesterday.
Um yeah, so >> Yeah, for sure. Now, now, before we get into the details, and by we I really mean Moses, here's the update. The PHP security team has now released fixes for two critical vulnerabilities. Each of those were rated at 9.2 out of 10. The patches and technical advisories are available, so make sure to check those out like time now. For anyone who isn't familiar with PHP, it's a programming language that handles the server-side
processing behind websites and all sorts of applications. If you think about a website, HTML describes the page your browser displays, PHP can handle the work behind that page, like processing a login, retrieving information like from a database, generating the response sent back to the browser, and and so much more. Now, PHP has confirmed that these flaws can allow remote code execution, which is an attacker could make an affected server run code that they control. As you can
imagine, we are going to chalk that up as not good. So, Moses, now that we have the patches and technical details, what's actually going wrong inside of PHP, and what do people responsible for these systems need to understand first?
>> Yeah, so let's just get the elephant out of the room. These are two different bugs. What's going on here is architectural in one sense. So, one of the things that um we've known for a long time, if you've ever done any kind of PHP exploitation, is that the engine does not stop. It kind of just is very forgiving. Um it's kind of what's made the language very popular in the fact that an error will happen and it will just continue running.
Um so, what's what was theorized about 20 years ago was that some of these out-of-memory conditions could lead to some type of a use-after-free vulnerability or some other kind of memory bug that you may or may not be aware of. The the underlying code um of PHP um what has been happening here is it does seem like if you chain a few of these bugs together, you can do one of two
things. You can either execute code in the actual system or you can read memory artifacts. Now, I say this as some of the preliminary write-ups are still starting to be built. Um but, what we know right now is that any version of PHP from four or from five 5.4 and higher is vulnerable to this bug in some way.
>> Wow. >> Um and it does not require authentication. So, on a literal system with just a PHP framework running, you can get exploitation. >> That's That's crazy. That's It is It's mind-blowing to see. And me just listening to you say all of that, we all know that I am not a fan of clickbait or or fud tactics.
What's the most important thing people should avoid assuming from the headlines that are circulating from last night and probably here this morning and for the next few hours? >> Okay. So, if you want the actual details, there's two blog posts that I would recommend. There's a blog post from one of the founding one of the people who found this the the group called Calis, c a c a l i s.
Uh there was a few researchers. There's one in particular um that actually led the the work to find the initial bugs. And [snorts] also the Wiz team as well. Several folks there found additional things on the bug. Now My my advice is that if you're going to be looking at proof of concept code or the ability to test this in some way I would very much be hesitant as to what you're finding on the internet. I'm seeing a lot of
bogus or references to vulnerabilities that are just either older not real or have been known that are not this bug. Okay. So if you're going to be doing this work you should really wait for actual checks from your vulnerability scanner and what not. We can get into the details of like what that looks like. But what I want people to understand right now is that people have been taking advantage of the fact that this announcement came out
early and that lots of folks have been trying to capitalize or monetize on this. I actually saw one set of folks that were trying to like look at some meme coins around this. So just FYI for that.
>> So mentioning kind of that and then what you mentioned previously with the versioning of PHP. If we could let's help people work out what this means for their actual own environment. PHP in their most recent write up calls the risk highest for Apache with mod PHP but it's also warning covers PHP FPM and other web deployments. Can you explain those differences and what someone should check to determine really how exposed their own setup is?
>> Yeah. So let's start with what like what this is. Right? So it's 2026 and a lot of people are going to tell you that PHP is not really used that much. But it is. Okay. There is a ton of systems out there that are externally facing running PHP. So even if they're not even if you don't think about it in your enterprise they're there.
Um The way that you deploy PHP comes in two forms. Right? One is the older Apache module, right? So, this was an Apache only one-off. It was not an official implementation. It was just for Apache, and it's the way that most systems ran in the early 2000s, 2010s, etc.
>> Mhm. >> PHP officially came out with their own implementation called PHP-FPM. Um and that is the way that every other web server would integrate into PHP, okay? >> Okay.
>> Um the problem with the the actual root cause of this bug is an out-of-memory condition. So, what you're trying to do is exhaust memory in such a way that the system will fail, and it will leave dangling pointers, and then from there it will actually allow for execute well, write primitives and execution of code.
Basically, this thing is vulnerable just based on the implementation. And here's what you have to know. PHP, while it yes, it runs WordPress. We all We all have heard of WordPress. You might not be familiar with the fact that network management systems, so if you think of SolarWinds and how bad that was, think of Nagios and LibreNMS and a bunch of other network management systems like Zabbix are running PHP. Um
customer relationship management software is running PHP. Um NetScaler um and Palo Alto management interfaces for the firewalls are running PHP. Now, I'm not saying that they um aren't going to release patches or don't have vulnerabilities. What I am saying is that PHP is going to be in a lot of places, and I'm much more concerned, not just externally. Today, the concern is externally. The immediacy is external, but don't forget that we
are on pen tests all the time at Newvic, and we find internal PHP systems everywhere. So, if you do not know what's running PHP in your environment, start figuring that out now, right now. >> You heard him, right now. >> [clears throat] >> You really kind of answered the first part of my next question cuz I was going to put you on the spot and maybe there's people watching right now that are tuning in and we're going to say you're in charge of response for just a moment here. You've just been told your
organization has affected systems. Now that the fixes are available, what are the first three things you're doing? And it sounds like one of them is identification, the first one? >> Yeah. Well, the first I think the first one is like use a C temp or a tax service management tool on the outside.
Figure out what's running PHP. Because the attackers have already figured this out right now. Right now, as of yesterday, all the attackers or Bug Bunny Hunter, whoever you want, is going out there and scanning the entire internet to figure out who's got PHP and who am I going to target, right? So, your systems have already been scanned. Just be aware of that.
Um but I think about ransomware actors, you know, you have ransomware actors that are taking advantage of end days, right? So, you have shiny hunters and whatnot that are taking advantage of internal systems, VMware systems, etc. They you know that they're going to build scanners to try to take advantage of systems internally as well. So, you really need to think about patch if you can. Now, you can't you probably cannot patch the PHP version of your
appliances. The vendors would have to come out with a patch there. Um I hate to say this. People are still running PHP 5, okay? And this is this is a big problem, okay? PHP 5 is a big problem. If you are still running PHP 5, there is no simple way to just upgrade to 8 without breaking things. So, you're going to have to go through and figure out how to upgrade from 5 to a supported version.
They are not fixing 5. They are not fixing 7. They are fixing 8, the supported versions, 8.2 and higher. That's what the patches are for, right? So, if you're on an unsupported version, you you really need to figure something else out. Um there are mitigations. Um we can walk through those, but that is right now that's the immediate disease. Figure out PHP and patch it now.