Name: PHP2Shell: Technical Threat Briefing with Wiz Research
Uploaded: 2026-10-21T18:31:39.187Z
Duration: 29 min 32 s
Description: PHP2Shell: Technical Threat Briefing with Wiz Research

Transcript for "PHP2Shell: Technical Threat Briefing with Wiz Research": Okay. Hello, everybody. Thank you for, taking time from what I can only assume, is probably a busy day. So we'll jump right into it. We'll basically start from, Tomer. Tomer is one of the threat researchers that found the vulnerability. So Tomer will share a bit about the vulnerability itself, how it works, why it's critical. Then we'll turn over to Alon. Alon will share a bit about the sections, mitigations, how the WIS products helped, but also in general. We know that there's also people here who are not WIS users, and then I'll kind of wrap it up and and summarize. So, hopefully, the goal for us is, to do, like, a quick brief that's extremely helpful for everybody as they go about today, understanding and, patching and monitoring. So let's get started. Tomer. Alright. Thank you. So we'll go ahead and share the slides. But generally speaking, what we wanted to, to share is the story of, how we found, PHP two shell. We'll go into some technical details. We're sort of in the middle of the... Of an interesting situation. We'll we'll we'll tell a little bit about that story as well. But we're at the time where many customers that I'm talking to, many users that I'm talking to are still in the process of patching. They're still in the process of figuring out, where they're impacted. I was honestly on calls all day, but I heard things like, government web... Website being taken offline, just to protect against, potential attacks using these vulnerabilities. It has a serious impact, so I completely understand why. But because of, the nature of the of the vulnerabilities, we will not share the the full exploit or anything like that. We wanna give defenders enough time to, to actually remediate. We will go into, some more technical details than, we revealed before, and I'll touch on some of the things I've seen on social media as well. But, first, let's get to it. So, I think the the the most important thing and and and the reason that you, you probably joined this webinar is because it is a critical vulnerability, so I can go, into this, pretty quickly. But from a technical perspective, what we're looking at is a a a very large scale, of, websites, very large scale of, potential server workloads that are affected by this. We've seen a whole bunch of numbers. Like, about 70% of the Internet is still using, PHP based web web applications. We're seeing this, also in the WIS customer base as well. We're seeing a pretty significant impact, and we're helping customers remediate. But more importantly than that, it's not a specific version of PHP. This is not a specific configuration of PHP. Basically, every single version that was released in the last twelve years or so is impacted. This is impacting PHP 5.4 onwards in default configurations. So virtually every PHP, workload up to yesterday, was affected. Hopefully, many of these are now being, being fixed and patched and and upgraded. Now when we think about the impact, some vulnerabilities can cause a denial of service. But in in this particular case, we did have a lab environment proving pre authenticated, remote code execution as one potential, one one potential way to exploit these vulnerabilities. We have a different exploit, proving a memory disclosure. So if we have to, to think about other incidents that are similar to this, sort of a React for Shell plus Heartbleed combined within the same incident. Now I know that's... There's a lot of chatter online on what exactly is the impact. Is it that important as people may, may perceive? Maybe the exploitation is very complicated. Luckily, we've had about two months, time to actually explore all of these questions. We've worked, we've worked hand in hand with, multiple different parties starting from, the PHP maintainers themselves, who had done an incredible job of responding to this incident, as well as, OpenAI and Califf, who, actually found, similar variance, stemming from this, from the same problems, in parallel. So when we realized that we're, looking at something much bigger and we were trying to, we were trying to generalize what is common across all of the vulnerabilities that we found, and we ended up with two CVEs covering, a lot of different variants, some of them we've built proof of concept exploits for. Some of them we didn't. Honestly, the best remediation guidance I can give is to patch, partly because of the fact that we we can't be sure that we covered every single possible case. I know if you read the the PHP, advisory, there's a lot of different workarounds that we recommend to, to users to implement. They're not a replacement, to fixing because we we did found... We did find, certain bypasses or certain other variants that, can still exploit these vulnerabilities. So when we started this research, we we we actually had this, theory that, even though there were a couple different WordPress vulnerabilities, in the last couple of months, it would be interesting for us to test out whether AI can help us, find vulnerabilities across the stack. So not necessarily a a a WordPress specific vulnerability, not not necessarily a PHP specific vulnerability, but thinking about, if there are certain constructs in in WordPress or in Drupal or in Joomla or any of these applications, that actually triggers some interesting code in PHP, that isn't... It's not necessarily a vulnerability by itself either. But combining the two together, could be a potential avenue for exploitation. Now, obviously, this is a very, very complicated research. It's not something, that, we could have done easily, twelve or twenty four, months ago because it would require a lot of, a lot of time, a lot of effort from, probably a large team of researchers. Luckily, today with frontier models, we can scale this up very rapidly, and we can explore very, deep code paths that that actually cover multiple different code bases. So that that was the initial idea, and and that that concept actually led to, a couple of explodable vulnerabilities we're, pretty surprised to see. It took us some time to realize what's going on there. The the... I I believe the the original exploit that we've had was against, WordPress on PHP. And, when we started to, to create a report for the PHP maintainers, We tried to, strip down, to the minimal application possible, that, that that is exposing this when we're building. We reported it to PHP, and, originally, the response was like, hey. This is a very strange application. Why would anyone write something like this? It does a whole bunch of strange things. I won't go into the actual details, because, I believe we'll reveal this probably, later this week or next week. But it just looks very strange. It's like someone is building applications solely to, exploit a vulnerability in the PHP engine. It's not likely that anyone will build an application like this. So the initial response was like, this is not truly a remotely exploitable, vulnerability. In reality, we did send this over email. They... They're probably flooded with a lot of different, questions and a lot of work, and they probably didn't notice that we did right, that this is based on, an exploit that we originally tested again against WordPress, and we're just trying to give them the minimal steps to reproduce this. So once we we, one... Once we understood the the impact, they understood the impact, we started to, to look for other var... Variants, and we found a different variant within Drupal. And we looked again, and we realized that there's, there's an interesting pattern that is happening here, within the way that the PHP engine actually decides to clean up, some of the data between requests. In both cases, we, we built a a a proof of concept exploit that led to RCE. But then we decided to dig a little deeper and understand how, that that error handling is happening within the PHP engine. And we realized that we can also find some other, variants and other types of vulnerabilities, that are independent of what's running on top of them. This is how we found those those other variants that eventually led to, either memory disclosure or remote code execution. We understood that that we had something pretty significant, and we kept sending more and more variants to the PHP team, up to a point point that they said, okay. This is probably blowing up. This is something really, really big, that we gotta understand how to change the architecture for PHP, so we can eliminate this class of vulnerabilities, and and and really, solve all the variants of this, of this attack. We didn't know at the time that, that originally, some other, some other parties, were working on similar pieces of research, closer to, to those, two last variants and reported them to, to PHP. So going into some more technical details, just really trying to understand structurally what is going on, this is probably one of the simpler, cases, of these variants, where basically what what is happening is that the attacker would, would send a request, to one of the HTTP workers that triggers, PHP. PHP would start running and then get to, some kind of an error condition. So so most of the information that's available right now on Twitter is really centered, around the out of memory, problems that, that some people were hinting on. Getting to a to a case where the PHP engine decides that it's out of memory, it should stop processing this request, and it cleans up. If that cleanup fails, then it would leave some stale pointers, in memory before starting to, to process this... The the next request. Once that next request is starting to, to be processed, if the the memory is not fully cleaned up, then there could be a stale pointer that is being used, even though it it actually belongs to the previous request. We call these situations, basically a use after free. In in PHP's case, this led to either exposing, process memory, from that particular, that particular worker or being able to, to allocate something on top of it, which can lead to arbitrary process read or, or write and from there to a remote code execution. And we've demonstrate... Demonstrated everything in proof of concepts that, that we've shared with, with PHP. So when we were thinking about what can't variants can can appear and what could be the impact, it... It's pretty wide just because of the fact that there's many, many, many different paths to exploit this, even much more than what's depicted here in this... On the slide. But, eventually, because of the... These reasons, we also, do not recommend to customers to rely on, on on, specific traffic based rules alone, because these might cover specific variants that are tailored to parts of this attack or tailored to, to specific, specific code path that can trigger these conditions, where there could be others, and we have found quite a bit. So originally, when we we started this research, this was actually a pilot for, an internal project, that we have. We call this Project Atlas. This is our, AI based vulnerability, vulnerability scanning, harness. We decided to, to scan a lot of different open source, components, not only PHP. And once we realized that there's a, there's a lot of different vulnerabilities that we need to coordinate, Obviously, we, we reported everything to the PHP team. We were trying to be as available as possible to answer questions, to provide additional variance. But once we started to, to realize that there's a pattern here, we wanted to, to use AI to actually find other variants, to find other potential code paths, and to make sure that the patch that is now public is as comprehensive as possible. We're fortunate that the PHP team decided to connect us with, OpenAI and Califf, who found similar vulnerabilities independently. And we managed to actually join hands and work together. So we leveraged, the the the shared expertise from all companies, to be able to make sure that we're covering enough ground and we're helping the PHP team to actually remediate, as soon as possible. With a couple different iterations of patches, we did a lot of adversarial test... Testing to make sure that there are no additional vulnerabilities or additional ways to bypass. We tested a lot of different workarounds and a lot of the different mitigations. This is why, our current, our our current recommendation on on workarounds are aligned with the the the PHP advisory. And even though there's a lot of different ideas online, I would stick to, to the official guidance just based on our testing. After that, we started to coordinate disclosures. So, obviously, we wanted to, get the information out there to other security vendors to make sure that, the detection rules are out there once the, the new release is public. And, unfortunately, as a part of that, process, information about the existence of the vulnerability was disclosed online, which led us to decide to, to push out an emergency release ahead of our original disclosure timeline just to make sure that, we're pushing out patches as soon as possible and and making sure that the release, is in time, and is is available to end users to put... Protect them. And this is, where we are today. We started this morning, US time, within, a new set of releases for, official releases that were patched, by the, the PHP team along with a series of patches for all of the supported versions, including some other backhorts that they've done to even older versions, just acknowledging the fact that these are critical vulnerabilities and, end users will need to patch them. We worked with a lot of the a lot of the distros, a lot of the maintainers to make sure that they have access to these patches and have, and they... They've already released, their, their back ports and their downstream, fixed versions. And right now, we're in a situation where, my recommendation for everyone is to identify where they have PHP workloads, make sure these are, these are operated to the the latest recommended versions, and make sure that they remediate the the vulnerabilities, in their environments. Over to you, Alon. Thank you, Tomer. Can you please, yeah. Okay. I'll share screen. Okay. So we want... While I'm, sharing the screen, we would like to talk about, the... Okay. Yeah. What what what can you do? We we are going to start with, some some general, guidance and, also, we'll refer to how we can help and show some examples to, to to WIS... For WIS customers in the portal. So, again, as as as, as as Tomer mentioned, we, recommend... I think our first recommendation, like in every case, is to identify the PHP assets that you have in your environment. Part of the complexity of this vulnerability is that it's it's, stems in, you know, the older versions of PHP, and it's been actually around for over a decade. It might be something that is not easy to do, but again, please use all tools you have both in Cloud, on prem, other other services that might run PHP. And, of course, remember the downstream impact of, other services like, WordPress that, are also, impacted. When when when we talk... And and we'll talk more about the prioritization, but we believe that in this case, there are two other, remediations, or two other important, prevention techniques. One of them is runtime. As Tomer mentioned before, it's memory corruption vulnerability, or actually two vulnerabilities that are exploited together. In this case, there is also for if you have a runtime sensor, and this is something that the WIZ runtime sensor can help with, you can detect the exploitation live and WIZ already has this the exploitation live and WIZ already has this capability. We saw the questions in the chat. We haven't seen any real exploitation by threat actors or any wide mass exploitation, so far. Doesn't mean that it's it's not there. I think we believe that we... Also, we shared the, insights with other, partners in the community. We believe that it's the same situation with them. We do see some experiments with POCs, but we haven't seen any XProtect so far. Again, this information is true now and it might change later. But what we can do is, again, detect the exploitation and also block the exploitation. How do we do it? We can detect. We mentioned before that there is a specific fatal error in the PHP request that is part of the exploitation process, and it leaves the walker process with corrupted state. We can detect this state before the next step of the exploitation. We can kill it and then the exploit stops. That's one prevention technique. Again, it's already deployed for the WIZ sensor, and we believe that that's a great solution for, I mean, if you have any PHP assets that you can't patch, some of them are older, there's still no patch for older versions, that could be a good mitigation. As Tom mentioned before, there are also other, you know, other, solutions, walk around... Walk arounds. We don't, we we... I mean, we have to remember that patching is of... That... That's that's the only, ultimate solution. Everything else, With everything else, there is a risk that we won't be able to actually either, if there's another exploit, we might need to add additional detections to cover it with the other walkarounds, with, for example, the memory limit, the walkaround that was proposed by PHP. It's something good. It's a good measure, but it's not enough. Now we move on to the next part, prioritization. We recommend, of course, with PHP, you have to map all your assets. Again, when we talk about all assets for with customers, for us, it used to be Cloud. Now, we can actually do it with the attack surface, management capabilities. We can also do it, from, not only from within the Cloud, but from the outside. Scan all your assets, whether it's, on prem, third party, services that we use, we use PHP or WordPress. We can connect. You can connect them to Wiz, and we can scan them for you. The next step, of course, is to map which ones are the most critical ones and try to patch them, try to install the Wiz sensor on them. Again, that's always how we start these high profile vulnerability response programs. Then we can talk about the Internet facing workloads that we know additional, and I I guess for PHP, it's something that, you you will see quite often since we saw a way method that it's it's affecting 70% of of the, Internet. So anything that is, Internet facing is at risk, since it's a remote code execution, vulnerability. And, so if you have access to this, like, public resource, you can try and exploit it. And then other... After that, other critical and high findings in the Wiz, platform, we will, have, we have the issues that can help you with that. You will start seeing them, showing up soon after, the scan cycle is complete. But in the meantime, you can use all these, vulnerability findings. It's been... I can say... I can share maybe from from our side that, since information, leaked, earlier than than expected, We had to push everything. There was a great effort on our side, first, you know, to to give, this kind of first aid solution yesterday after details, have leaked. And, but without disclosing anything about the vulnerability, we believe that the the embargo was, critical in order to protect everyone out there, and it was a great effort for us. And now, after, the patch is available, after, the embargo was lifted, we can, share all the, like, you know, all the different detection capabilities that we have. And I want to go for a quick, demo. I'll share another screen. Just one second. Okay. So for, Wiz, that's, the Wiz platform. I think for us, it's always about the threat center. Starting from the threat center, this is where you have all the information. So if there are any threats, any active exploitation in your environment, you'll see it here with the sensor detection. You can also see all the vulnerabilities and the graph queries that help you with the prioritization. We have... All the information about the vulnerabilities is going to be located here. We keep, updating this, threat advisory. So when we see, for example, exploitation in the wild, you, will see... You have all the information here, the, and and, you know, with addition additional recommendations. For example, here we mentioned the, PHP memory limit, temporary walk around that can be used, and, of course, how to assess the risk in your environment with, WIZ. I think that the most important part, again, we mentioned before, seeing, for example, all the instances of the vulnerability is something that you can do by just clicking on this link. But I believe that maybe most important one is to turn on the blocking mechanism with a sensor. This is something that is not on by default, and we highly recommend everyone to turn it on for their environment. You have all the information here. Maybe the last part is that you can also use AI, the Mica AI, our AI assistant. You can easily click, here, find, you know, all the information. Mika can do... I mean, it actually reads this advisory and has more context, more information about your environment, and it, creates know, guide for you. You can chat with it, ask questions about your environment, and basically use it as your, kind of AI assistant to, to to investigate this issue. Everything from the WIS, it has access to almost everything in the WIS platform, and it can give you all the answers you need. With that, I'll now give the floor to us to finish the session. Raz, you're on mute. To be fair, we did that sleep for, like, two days. So, I'll summarize quickly. So first of all, we talked about, of course, first, understanding where you're vulnerable, prioritizing exposed machines, obviously, and also places where we know are more critical in terms of applications. We talked about the only real fix being, the actual patch. Right? So where we can, where we have a patch, of course, patching is the first priority. Where there's not a patch, there's some, there's some, like, vendor that have back ports. And if it's not possible to cut... To patch, then ideally, isolate the machine, or there's a list of mitigations. Right? One mitigation, Alon mentioned... So for example, in Wiz, we have... You can deploy a runtime sensor that will actually block, exploitation attempts. There's also, of course, all of the WAF providers that we in PHB have been collaborating with to ensure that they have detection rules. And, there's also some mitigations like reducing memory, pressure, disabling a couple of things. I'll show you exactly where you can find, this information just online in a second. And, also, it's very hard to have, like, a hermetic detection on this just from logs, but there are some IOCs, you can use to support, like, an investigation or to hunt, and I'll also show you in a second, where that is. So I'll summarize by saying a couple of things. First of all, we really see we really see this as, security as a community. It's like a cool community. Like, if we think about it, like, patching all of those things. I don't know any other industry that has this level of collaboration, like we've had with the BHP folks who worked extremely hard, on the patching. So we're, really happy to help in any way we can, whether you're a WIS customer but you did not buy the runtime sensor or if you're not a WIS customer. We're really happy to help in any way we can. No strings attached. We can also help with, like, temporary technology for scanning that you can remove afterwards. In any way we can help, we're happy to help. And, since I saw also in the chat that nobody wants to click links in this group, you can just go to php2shell.com in your website. And here, you have a lot of the details I mentioned about, first of all, like, a really good breakdown of the vulnerability, but also here you have, explanations on the mitigations. So, again, patching is the only solution, but you have here detailed, detailed mitigation options. And the the same is also true for, again, there's no complete IOCs, but there's a list here of a couple of things you can monitor for in hunting queries, etcetera. So I think the website is a really, really good, a really, really good resource for everybody. And with that, I'll I'll say, thank you everybody again for the time, and thank you to the PHP team who worked extremely hard on this. And, yeah, good luck to everybody. And, oh, also, in that same website, there's, like, a contact us button. You can click on it. And if you want, like, to jump on the sync and talk about challenges in your own environment, you can do that there too. Thank you so much. Everybody.