Name: PHP2Shell: The Next Log4J? Learn How to Find Your Exposure and Act Fast
Uploaded: 2026-10-23T16:30:43.423Z
Duration: 56 min 40 s
Description: PHP2Shell: The Next Log4J? Learn How to Find Your Exposure and Act Fast

Transcript for "PHP2Shell: The Next Log4J? Learn How to Find Your Exposure and Act Fast": Hello, everyone, and welcome to today's webinar, PHP two Shell, is your exposure Log four j scale. And thank you so much for taking the time today to join with us. My name is Nulofa Nigar, and I am the global campaign manager here at BitSight. I'll be your host for today's session. And before we get started, just a couple of housekeeping notes. Today's session is being recorded, so we will share the recording with you afterward. You'll also see a doc section on your right where we have some additional links and resources available for you to read and download. As well as we have the q and a tab where you have any questions during the presentations, Please submit them as we go and rather than waiting till the end. We will do our best to get through as many as possible. You'll also notice, talk to a bit side expert button right at the top of the screen, the orange one. So if you... Anything that you wanna discuss today and you wanna connect with our website experts, that's the button that you click to, and you will be connected to your account owners or any website expert, and we'll get all your queries answered. So moving on to why we are here today. With the recent disclosure of two critical PHP vulnerabilities, there's a growing concern about potential scale of exposure and what this could mean for organizations and their supply chain. So today, we'll hear from our experts about what we know so far, what BitSight latest research says, and most importantly, what organizations can do to understand their exposure and take action. And with that, let me now introduce our speakers for today's session. So Stephen Boyer is the cofounder and chief innovation officer at BitSight. He's a cybersecurity entrepreneur and industry leader, as you all know. He has spent more than a decade helping organizations understand and manage cyber risk with a focus on advancing security intelligence, innovation, and cyber resilience. Moving on to the next speaker, Will Riccardi is the director of customer success at BitSight, bringing over years of experience in cybersecurity, third party risk management, and cyber insurance. He's a certified third party risk professional, and he helps organizations leverage cyber risk intelligence to strengthen their security posture and build cyber resilience. Last but not the least, Joao Wedinu is a principal research scientist at BitSight with over ten years of experience in cybersecurity. His expertise spans malware analysis, threat intelligence, and security research with a particular focus on tracking threat actors, investigating vulnerabilities, and uncovering emerging cyber threats. Before we jump in, here's a quick look at what we'll be covering today. We'll start by setting the context around these newly disclosed PHP vulnerabilities, what makes them significant, how they compare to Log four j, and why organizations need to pay attention. From there, we will then look at what latest bit side research and data revealed about the state of exposure, including the potential impact across organizations and their third party ecosystems. And finally, we'll move into a live demonstration of how BitSight can help you identify vulnerable assets, prioritize the risks that matter most, and monitor exposure across your supply chain. We'll then wrap up with a q and a session, so please keep those questions coming throughout the presentation. And with that, Stephen, I'll hand it over to you to get us started. Hey. Thank you. And thank you everyone for participating. You can imagine this has been a pretty wild last couple of days for us and for pretty much everybody. And so we put this together very quickly so I can... Hopefully, you can appreciate, you know, the speed that we're gonna operate with. Maybe not as polished as normal, but I think we wanna be able to really get to, hey. What do... What's happening? What are we seeing and what you can do? And then we'll talk about some things that we're gonna be providing to everybody. The reason why I I wanted to put in the title, you know, this log for j, reference is back in December 2021, a CrowdStrike executive told the AP press the Internet was on fire. Right? It was because of Log four j. And so... And then just this week, a dark web forum had a post that says, hey, that the Internet will be on fire. Right? So same sentence, five years apart. Right? And then, like, there's this one line thesis, Log four j taught us this pattern, and PHP to shell or this vulnerability to PHP is really kind of that same same test at, at web scale. So kinda why does this matter? It's just a massive flaw on a large part of the Internet. And if you go to the next next slide or... And we all advance it, this is a big deal. Right? This is just such a big deal. We'll see if it's even bigger than Log four j, but, you know, there were some predictions that Log four j would still be around for decades. And and just recently, you know, there were some studies that, you know, there's still some of these vulnerable libraries being found in code now, you know, five years, later. And so, you know, I pulled, you know, this quote from a recent article in the Wall Street Journal. We're saying, hey. This may be the most severe bug that AI has ever found. And if you're not familiar, this was found using OpenAI's, capability here. It was a vulnerability that has been known for probably twenty plus years, but not deemed to be exploitable. And sure enough, you know, these new advances in AI have enabled us, to be able to now find the ability to exploit it. So I'd say this is, at least of today, maybe the most consequential vulnerability, found and exploit... You know, found, in code. I think they... I'd read that it was, like, 600 files that needed to be changed, tens of thousand lines of code, to be updated here to be able to provide the patch. I just wanted to give you guys that sense that this is a big deal, in the industry. I'm gonna just quickly advance the slide. Now this is under this backdrop of something that we've never seen, in vulnerabilities. So this is something I just, put together, looking at vulnerabilities going back ten years. And if you look back, you know, going back and then look forward, you start to see, hey. In this year, right now, where we are, we're at 85,000 vulnerabilities. We're almost certainly gonna go over a 100,000, you know, which is gonna be at, like, a 13, you know, what we... What we've never seen before. So I... That's the backdrop that we're all... That AI has really kind of enabled. I think this is where something that, you know, we all need that we're all facing this. We'll probably have others, but right now, this one is truly, without precedent. The volume is without precedent, and it's coming at us just this massive velocity. Alright. So, hey, what are the parallels here, between, Log four j, and PHP to show? First, it's site. This is one component all over the place. Right? So Log four j was a logging library embedded in applications. PHP is a runtime, really part of, you know, all sort of the content management systems, etcetera. It's a server side language. Right? So that's the... You think about kinda layer of pervasiveness. Both of these have unauthenticated... Unauthenticated remote code execution. Right? So that's what makes them, pretty dangerous. They're certainly hidden, in your vendor ecosystem, across applications pretty much broad and wide, and I think that's what makes this one, also particularly dangerous. What's also interesting here is that the exploit came out before fix. So this already started to be exploit. Yeah. I think in Log four j, it was nine days before public disclosure. In this case, it looks like it was four days before disclosure. You know, it's, you know, it's certainly being, you know, weaponized. There's really no fix at the application level. Right? For Log four j, it's at the library level. For PHP, you know, that's gonna be at the run time, and it's not like you just update. You know, this could be, you know, something, you know, much more, severe. And so I think we've learned a lot of lessons there, between these two, and I just think the pervasiveness here is is going to be something akin to what we saw, for Log4j. If we go to the next slide, wanted to just show a little bit of the timeline. I've referred to, you know, some of that already here, but you start to see, like, hey. You know, this was supposed to be announced yesterday. It got it got moved out. But, you know, certainly, people found, the the exploit, and the code is being, you know, updated. Certainly, no exploitation is out there. And because the news broke, they had to accelerate, you know, sort of the release. And now you start to see this information getting out much more rapidly. I'd say because that vulnerability has been sitting there for a while, you know, it just got the recent attention, but I think why we're doing this webinar now is that and we know exploitation's out there and this is so pervasive, we're going to get to more of what that is in a second, but when I saw that announcement, I'm here in Europe, and that came out like 5AM, where we were in Europe, we knew this was going to be a pretty big deal. So if you go to the next slide, just wanted to say, like, you know, this is not just... You can't just fix this. That's why it's very similar, to Log four j in that, right, this is a, you know, run time. Right? This is not just a update the patch, and, you know, update some sort of application. Right? So this is just not a bug in the application. It's it's the runtime. As far as we know and everything that I've looked at, every PHP version is impacted. Now there are patches for a small selected, Joelle. We'll get into that one, but there's not, like, a complete workaround here, which is, you know, kind of one of those, concerns. And so, like, that... And there are many end of life versions from what we understand. Some of them... Some of the versions are getting sort of light, fixes, and this stuff is all over the place. So that's, you know, that's the concern. Let's go to the next slide, and take a quick take a quick look. This is where... And some of you may or may not be familiar with our DVE or Dynamic Vulnerability Exploit Scoring, but this is our measure of exploitation. We all know that, you know, there are 85,000 vulnerabilities already this year, but really about 3% actually get exploited or less. That exploitation is growing, but what we wanted to be able to show you in tracking is that we know this is getting active exploited. If you're going to prioritize anything, you got to prioritize, you know, something, in this range, because we know that there's likely what we saw with, you know, Log four j, eventually, nation state level actors, you know, start exploiting this stuff. It's just going to be... Although it's not as easy as Log4j, that was a CDSS 10. This is, like, a nine point, I wanna say, two. So there is a little bit more than the attack complexity, so those things are, different. But finding PHP is almost trivial. Right? So that's not as hard. Certainly, finding the specific version is not always, there and available in some places. But the fact that there's PHP there, we know that there's a vulnerability. Now, we know vulnerability doesn't necessarily mean exploitation or exploitability, but we... Just like that vulnerability was found using AI, my guess is that there'll be AI tools and AI automation here that's going to make this, you know, actually really kind of exploitations, at scale. Alright. Let's go to the next slide. I'm going to hand this over to, Juwao after having set that up, and I'll come back and talk talk a little bit. Thanks, Jerome. Thanks, Steven. So, quite the October cyber awareness, month. Right? Very interesting things coming out. So basically, it is quite a mess. Let's put it this way. We know that we've seen, like, nearly 70% of all websites are affected in some way by by by this because they run PHP at some level. You may may see it, may not see it. We... We've noticed that at least in the nine... In the last ninety days, around 50,000,000 hosts, we have confirmed that they are running some sort of PHP version. And from those, like, from the version, we can actually identify over 4,400,000 of them, run some sort of, PHP version that is affected and cannot be patched. And some of them, are even not even supported, so... Or even have like minimal backports that allow you to some... In some way, bypass the issue, but not completely. So it makes it very complicated to actually, address this, correctly and easily, like Steven was saying. Next slide, please. So to put it, in terms of of of a plot, so we've... We shared this in in a blog post already, and this shows you in orange the versions where a patch has been, published, where you can update to that patch and, ideally fix the vulnerability. Everything you see in blue are versions that do not have a patch, or if they have, they have, like, a minimal back port that takes... It's a lot more complicated than running the actual patch, that is provided in the version from 8.2 to to 8.5. And and what's make... What makes this even worse is that you can see, like, version 7.4 is the one that we see that has the highest volume, in terms of exposure. And it's one that's in... It's at end of life. So, there are minimal backports. Next slide, please. And and makes it even harder to try and find where all of these end of life versions are, especially when so many of them, do not have, like, a a patch for it. So if if we count all of those versions, we have, like, over two thirds of them, that are not covered by any kind of patch. So they are not... You are not able to, prevent this issue unless you, like, you update to a valid patch. And like like I was saying, like, over 2,000,000 of them are specifically for 7.4. And so this, like like I was saying, has, like, a minimal back port, and that makes it even harder to to patch it. So, ideally, you want to try and make an inventory of everything that you own or that's owned by third parties. Try to identify what's running on top of PHP. It can be an application that depends on PHP and not exactly, directly PHP. And you have to assume that somewhere along those many layers of third party that, for sure, there will be some kind of PHP exposure in there. Next slide, please. So, one thing that we should try to focus on when it comes to this kind of fetching and how we can actually go for the low hanging fruit, because we know threat actors will do the same. They will try to focus on things that are easy to achieve, things that are easy to exploit. And one big key thing here is to follow, official disclosure update. So if we go into, the official disclosure, this is a quote from from the blog post, and they specifically mention those applications, as well as some arbitrary PHP scripts. So what this means... And if you have to prioritize in terms of multiple PHP applications, we will likely see first exploits coming to these kinds of applications like WordPress, Drupal, Joomla, etcetera. And then following those, we'll likely see, applications, arbitrary PHP applications. And because third quarters follow, these publications, these blog posts, so they are actively trying to find exploits that are reliable for this. And with all the AI that people have been throwing into these vulnerabilities, it's only just a matter of time until people actually get a reliable exploit that will start being shared on the internet. Next slide, please. So, we can still kind of take a deep breath, and it's thoroughly so, and people are still trying to figure out weaponization of this. So we have to, you know, follow the the follow the the big thing of trust that verifies. So there are many public, POCs. Many of them are fake. Many of them are different vulnerabilities that appear similar. Some of them work, but under very specific lab conditions. And because a lot of repositories, a lot of code is showing up claiming, like, how you can test this and so on, I can guarantee that a lot of tract actors will, you know, will capitalize on this and will, develop exploitation code that if you try to run it to test your PHP version, it will compromise you, for example. So be very careful with what kind of code you are running or looking at to try and verify or to try and exploit, this vulnerability. So what we've seen is that the indicators for this exploitations are very scarce, so we haven't seen them ourselves. A lot of people, there's a lot of things, like I said, it's very early for people. There's a lot of, things going around. We've seen that there are some confirmed exploitations that are starting to appear for specific applications. And And these are the ones that I previously mentioned, like WordPress. I think the one that has a confirmed exploitation is for MediaWiki. And so what... Again, what this means is that near term risks, is basically disruption because the way the vulnerability or the vulnerabilities work is that they they have to send, a significant amount of requests and they have to... And many of them will crash the application, the PHP application. So you'll likely see, a lot of verbose information into logs, and that will be helpful to try and identify some attempts and exploitations. So like denial of service and these kind of crashes are a good indicator, like a first indicator to try and, you know, consider that something might be happening. One other thing, I feel like at the at the exploits and the actual vulnerabilities, and it's likely that these will have to be tailored to your specific system and the version that's running and so on. So this gives us a little bit of time to try and and and be fast on patching. And, nonetheless, what we should do is we should still, you know, patch under the assumption that exploitation is coming because it will, even if it means tailored to your system. Because with all the AI, the the the... How fast it is to generate code and to do all of this tailoring, things will will will come in in in a very short time. And, now I'll I'll, hand it back to to Steven. Thanks, Moe. I would say don't take too deep a breath. So say, hey. Breathe. But, this is about act, right, and and taking action pretty fast. And so, you know, first view and everything that we try to do is say you gotta map the attack surface. You gotta have the visibility, and do, an inventory here, of what's exposed. Right? So, the difference here between, you know, Log four j was just... Was harder to find. Right? You gotta go figure out which libraries are plugged in but relatively easy to fix, right, because you just put in the library. This is relatively easy to find but harder to fix. Right? So you really have to be able to understand your state, and then, of course, that expands to your vendor ecosystem. Right? That is just not your own state. I think everyone knows that now, which is, hey. Even if even if you run no PHP anywhere in your enterprise, which is maybe rare given that, you know, hey. It's 70% out there on the Internet. Then You've got to look at that across that, what we call extended attacks for business supply chain for others that may be impacted. Clearly, there are patches available, so patch the runtime as soon as you can, right, and there are some, you know, back ports, you know, there for for other versions. There is a lot, as you wanna talk about, end of life versions out there. And so those are probably not gonna get patches going back to PHP five. And so you think about some of these, and then there's a lot that we see that you can't see the version. I was just looking at some firewall vendors. You can't see the version, but now they know, you know, that those things are vulnerable, maybe not exploitable yet, but could have some, you know, availability challenges. And so there's kind of getting that visibility, and then there's hunting this stuff down, and looking for areas of exploitation. As Joao said, Hey, we're not seeing widespread exploitation yet, but this is, Hey, just just a hunt on Wednesday, maybe have been leaked four days before, and say, Hey, this is going to... My prediction, come and come pretty fast. So you want to be able to look for any evidence of exploitation. In the past, we've seen vulnerabilities, that were exploited, and then Teams patched thinking that they were okay, but the actual web show was there sitting, on their systems, and they didn't know. So you definitely wanna hunt this stuff, and, you know, be able to, look for any indications of compromise, different files getting dropped and any new processes dropped out of that PHP runtime. And, of course, you may not be able to see that across your supply chain, so that's where close collaboration and follow-up here, is critical. I'm going to just go quickly through because I know we wanna get to the the demo, the next slide here. But just really kind of a rough, hey. What... You know, how are we thinking about this in hours, days, and minutes? Just hours. You got to, and we dive capability. We'll just give you the demo and get that visibility, trying to get to patches, patching. And if you are in a spot where you can patch, obviously, get those, things deployed, then you're looking to kind of... If you can get to in the day scale and, you know, anything else you can look for that might be, you know, evidence of compromise, and then working with your vendors to get those things deployed. So let me go and, I'll come back and talk a little bit here in a second, but what we are going to show you is capabilities that you can use in BitSight, you know, to address this and attack these things, And we're making capabilities available. I'll give more detail on that. But, you know, some levels for our customers didn't, give all this visibility, and so we're now enabling that, for everybody. So let me hand it over to Will, and you can take the screen for a demo. Thanks, Steven. Appreciate it. Alright. Let me get my screen up here. Great. So what I wanted to do is start with, a couple use cases and then actually get into some new, agentic workflows that could be run with, Bidsights AI mode, which everyone has access to now, and then actually show you some some in, more agentic workflows or leveraging our MC... MCP server, specific to this use case as well. But where I where I first wanna start was kinda from the beginning where, you know, hey. We have a vulnerability or flaw that's announced. You know, it's hour zero. There's no CVE potentially for it just yet, or, you know, the CVE has not been added into BitSight, at the moment. So for this, I'll start with kind of your own organization's view, looking at your own attack surface, and then identifying where instances of PHP lie across my assets. The first where I would go here is actually under, attack surface and then infrastructure. And from here, I would navigate to my assets table, and we have a nice products filter down here below. And what I went ahead and did is actually select all the PHP versions since the blast radius is so wide on this to identify all of my assets right here, running a version of PHP that I selected. Hey, Will. Will, real quick. Can you... I just got a request. Can you pop out of dark mode? It's a little bit harder to see For sure. on the screen. Let me... Thanks, Barb. Yeah. No problem. It'll take a minute. K. Here we go. Get some vampires out there. There we go. Alright. Thank you. Yep. Just have to reload a few pages here. But, once I apply those filters here, I have many assets in this. I can then search quickly for PHP, and then I can select all the different versions that have been identified here. Once populated, I'll then be able to download this list. It'll download all of the assets into a CSV file that I could share out internally or work off of, you know, outside of the platform. However, this is kind of our zero. Once we do have the the vulnerability or the CVEs, in the platform today, I can then how to head on over here to, the vulnerability detection dashboard, which will then populate all the assets associated with the particular vulnerability. Again, I can then download this. There's also additional context from the first time we saw it and the last time we saw it. And I'll start to, change my light mode here. Great. So from here, I'll kinda shift over... This is kind of how you would tackle it initially from, you know, your own organization's point of view. I'll kinda shift over now into the, the third party risk use case. So within that continuous monitoring, what I would initially look up since the blast radius is so wide, if we do not have a CD in the platform just yet is look at our fourth party product data. And from here, to Joao's point, I could take a look at Drupal. I could also take a look at PHP. I could look... Take a look at WordPress or any sort of, framework or tool that's associated, you know, with PHP and get an understanding, okay, which of my vendors are using this tool right now. So I'm casting a a really broader net to understand, you know, what's my potential exposure here. From there, since we now have the, the vulnerability uploaded into the platform or vulnerabilities, I can then understand, okay. Well, who's, who's actually exposed to this, at the moment? And I can look through all my all my vendors right here, all 1,600 plus, again, very widespread, and then do... And then download some... Into a CSV file and export it from the platform if I would like to. Let me. And then moving on over to how I can leverage AI both from, the first party use case or looking at my own organization as well as the third party risk use case. We have some predetermined prompts right here, even one specific to PHP right now where I could launch and ask it, hey. Which of my critical assets do I own that use PHP? So it's narrow... Narrowing down the scope to, which assets that we have deemed as critical to the organization. And, it'll quickly give me a list of assets that, I need to look into as well as the specific versions of PHP that are running on them. Then from the third party risk use case, we have a nice, actually, agentive workflow, prebuilt out for you, that, is specific to security events. And so for this one, I can come click into this workflow. I can then select the particular suit... Major security event that we've identified. And for this, we would do PHP. I can let that agent run. It's then gonna look across my entire portfolio, and it's going to provide me a a good overload or overview or initial scope of all the vendors impacted, which ones are my top exposed vendors based on the tier that I've applied to them so they're inherent risk to my organization, and then provides me some recommendations on which vendors, that I need to reach out to initially first. I can also download this into a PDF file as well and share it out internally. If I have any additional questions about the, the the data here or the event itself, I can actually, analyze this a bit further and interact with our with our AI mode as well. From here, if everybody's not aware, we do have an MCP server. I highly recommend, leveraging this and setting it up. There's, much more customization, that you can do around this. And, for this specific particular incident or events, I did create a nice prompt here, where I... What I wanted to do was, look at all the vendors that we've identified in my portfolio being exposed to these two CVEs. And then since this is such a wide radius of of organizations, you know, me tackling 1,600 vendors, and sending out 1,600 outreaches, is going to take some time in managing the responses of those, you know, those outreaches. So what I wanna do is understand, okay. Well, how can I prioritize? And what I did was I I... In this prompt, I asked, okay. Well, I have my 1,600 vendors that are exposed here, but let me look at BitSight's critical vulnerability management data on these vendors as well. And I wanna understand, okay. Well, which of these vendors that have been identified as being exposed to these vulnerabilities are historically known to, are historically slowed in patch for for new or existing vulnerabilities. And so what this will do is it'll look at, specific grades that I determined, and and highlight those, for outreach. So they have the vulnerability exposed, and, historically, they are slow to patch renew or existing vulnerabilities based on our critical vulnerability management data. So if I scroll down here, I have this prompt already and, the output gives me a nice list. But what I wanted to do even further was actually give me, one, an executive overview dashboard that I could share internally, which it did create here for myself. And it shows all my vendors, shows me the ones that are in scope based on the the parameters that I defined. It then gives me a nice, chart here, a plot chart here that shows me based on the number of assets, the vendor has and, where they lie in terms of their grade, within critical vulnerability management. But then it gives me a nice list of who I should need to contact first, the actual endpoints or IP addresses, where the CVE has been identified, and then gives me, what their current critical vulnerability management rate is right now as as long as their overall headline bit site rating and the tier that they fall into. So from here, I have a nice kind of way to say, hey. You know, here's where we have our exposure with our most critical vendors who are historically slow to patch for new or existing vulnerabilities. While the dashboard's great, I do also wanna sometimes work out of a CSV file. So from here, it gives me a nice file, that I can then, prioritize and work out of. But it shows me the same data just in a raw format. So the the MCP within BitSight is is very powerful, especially within, you know, certain events like this. And, I find... I myself find it extremely useful not only from this type of event, but even just, asking it, you know, basic questions around inside the data, having to dive a little deeper, and actually creating any sort of dashboards, or even, you know, spreadsheets like this for myself. Steven, anything anything you think I'm missing here or we should further discuss? We got a lot of questions come in. We can we can tackle those. And, you know, one of the this is a comment was this went really fast, which... Yeah. We're trying to to put this in and and leave time for questions. So this is all recorded, and then there's a bunch of follow-up. Like, one example, well, was what's that prompt? And we can... I think we can get that out. Right? And, I mean, there are a bunch of things here that we want to, to be able to share some more additional questions around, hey. I don't see. this access. What, you know, what should what should I do? So, let's kick out of this, go back into the slides, and then we can just start tackling and answer these questions really until we run out of time. Did did you actually show, BII, or were you gonna show BII? Well, I was gonna show the II right after, your next slide. Yeah. Okay. Let's let's, let's go into this. So let's go to the next slide. So, this is super beta, but we're getting this out because, you know, the Internet is burning. It has been quoted a couple times here. We have made our entire dataset searchable, and so there are a lot of questions here, like, oh, this is my portfolio or not my portfolio, and so what Will's gonna show you is our ability to search and show you some of the parameters. We'll share those searches as well. Hey. How do I find this? How do I find this on my Palo Alto management? Is Palo Alto Management exposed? Because we know that has PHP. Right? So, this is where we wanna be able to look at this, and they're making an assets that we don't have attributed to your organization or your supply chain that you need to be able to to query on. And so we are making this available, as a beta. So if you have some questions about this, you can hit that orange button, toss to a BitSight expert, and, also, in the docs tab, there's, you know, link to to get a demo. So there's... We're going to we're going to show you this. It's not even really released, but we're kind of sort of releasing it if you came to this webinar, to join, really, kind of the beta here. Super powerful capability. We'll show you how our team, our own research team, has been using it, and show you some example queries, about what you can do. So let's do that, and then I'll kinda come back. Go ahead, Moe. Sure there. We just need to remove the slides, then they can share. Here we go. Great. So this is BitSight Internet intelligence here. It allows. you to search all of our, you know, scanning data across the entire Internet even for, you know, assets that we haven't necessarily mapped, to organizations just yet. So, it truly is the the the widest search that we can do across all of BitSites scanning data. And the query I have lined up here, is a query looking at the two specific. Take it. Sorry. I stopped. associated with PHP, but I'm also casting a wider net, by looking at, the CVEs associated with, the affected versions of PHP. And so when I do that... When I launch this query, it's going to show me all of those versions that Joao was showing earlier across his bar chart there. And so I have over 50,000 results here, and I can click into any one of these results to understand a little bit more. I can see the specific CPEs with the versioning of the build. Also, you know, Joomla and or Drupal running on them as well. And I also take a look at the raw, JSON output for more details. Obviously, it'll show you the domain, IP address associated with it, the port we detected it on, yeah, the geolocation, you know, where it is located around or hosted around the globe, and the last time that we saw it. You can expand these searches out from the last seven days up to the last thirty days. So seven, 14, and thirty. I chose just the last seven. There is a API, associated with, BitSights Internet intelligence as well, so you don't necessarily need to use the UI. Anything else you... You'd add, Steven, here? Hey. Thanks for the tip on the background noise from the group. It's it's a super powerful capability. We love the the feedback here. I've been playing with it the last couple days, looking at different queries and and seeing the different kind of results sets. This is where we really try to give you that view into that exposure, what's running in PHP, which versions, which applications, which products, etcetera, because, you know, PHP is the runtime. Right? There are a lot of applications, you know, built on top of that, so we wanna give you that visibility. Okay. If you can close it out and go back to the slides as well. So for this, we want to give you beta access. Let us know. Just sign up. We want to be able to enable that, test it out, and give us feedback. I've already got a lot of feedback from the team on this one as it is truly alpha going into beta here, but we're really pushing this out to get this out to you, fast and that this is probably an unprecedented time. In addition, all of our customers who have SPM or security posture management who do not have attack surface or EASM enabled, you will. So we are making this available, let's say, through November, into November. Forget the exact thing. And, let's say, November 20, somewhere in there. We're making that capability available to respond here. And so this is... Right. We've never done this before, but this is so important. We we think everyone needs this sort of visibility. And so if you didn't have asset level visibility here on this, we're going to enable that if it's not already enabled. And, if you have questions on that, just send us a note. We tried to get some, messages out yesterday. You probably should have seen a message yesterday about this being enabled. So really two key capabilities, key view to EASM, external attack service management, to be able to see, the vulnerabilities, and the assets, and then getting access to what we call bit side Internet intelligence, which is really kind of all that scanning, meaning that you can query over, using a standard kind of query language. So I'd say key takeaways here is this is a big deal. The response here is super important. I think we have light evidence of exploitation, meaning it's happening, but it's light, not broad and widespread yet. This is pervasive, so you're gonna have to take some action. Getting visibility is a key first step. Obviously, we're here to help you, get that visibility. Of course, it certainly costs your own attack surface on that broader supply chain. So, with that, I'm going to pause. And, Nufar, do you want to kind of walk us through some of these questions? Yes. Certainly. First of all, this is a very interesting session. So many curious, answers, queries on the chats that I can see. But thank you, Stephen, Joao, and Will for walking us through the research and the practical implications of these vulnerabilities. We have got a ton of questions, and, let's let's see. So I can start with... If PHP is not an option under products filter, does that mean bit site does not have or has not identified an asset running PHP? Will, do you wanna take this? So the question was if if we have not identified any of the products built in, I'm assuming this is for your own organization. If PHP isn't present, we haven't identified it just yet and associated or attributed to us particular assets of yours. I mean, it would be high potential that we have not seen anything just yet. However, as more of our vulnerability scanning data does come into the platform, which we do have more coming in, later this afternoon, particularly, more higher confidence around being able to see patches and remediation that's been applied. I think, that... That's where I would look, in addition if we're not, identifying, at the assets table level any products, associated with PHP. So while we might not have attributed anything on the asset itself, I I would then check the vulnerability detection dashboard to just be sure. Great. Now there's another question from David. If upgrading PHP is not immediately possible, what interim measures can organizations take to reduce their exposure? Yeah. So this is a this is a great one, and this is the million dollar question. What we've seen is some people have just started blocking, straight up just started blocking it. Some people are just taking it offline. Certainly, if you can't patch it in the end of life, you've got... Obviously, then you've got potential mitigations. You gotta be monitoring it. But this is why this one is tough, because there just aren't, as far as I know, you know, someone else does, like, a clear mitigation, like flip this off, disable this module. This is baked in. This is part of the runtime. What I read is even a simple hello, world is is vulnerable here. Right? So, right now, maybe, hopefully... And maybe we do this in another week if if there's interest. We kinda catch up. I mean, this... We're we're a day and a half in. Right? So, my understanding is there isn't really, which is why this is scary. And so for the most part, we're hearing people disabling access or shutting down applications or watching. Right? So I think that's... That... If it... If it's a business critical app, then you may just have to keep it running. But then I would be watching watching those systems very, very careful. That's that hunt piece that I talked about. You're watching for anything that would be some sort of signal, of exploitation. Absolutely. I wish I had better, news. I wish I had better news, but I but I don't. another question for you, Stephen, from Joanna. How should security teams communicate the urgency of these vulnerabilities to business leaders and the board and justify immediate remediation. Hopefully, we gave it to you on this call. Right? We'll give you this content. We've got reports. We'll put them in the docs. Run the query so we can show you just how how big... Or he's gotta quantify it. Right? So I'd say this is a... If if you need justification, say this is about as bad as it gets. And, and what I mean by that is, like, this is pervasive, and this is... If it's exploited, you know, you've got system level access. So I'd say run the queries, find out how broad and wide this is. But if you have any exposure for you and your supply chain, this is a code red. And so I'd say that is a... Use this material. There's a lot of other material. Maybe we'll put together a document or a white paper on this, and we just try to get this webinar up and running by the day. What do you need to say to be able to justify? But I'd say it's like, Hey, if you need to lean on any of this content, you've got it. We'll provide the slides. There's a lot of content out there. This is super rapidly evolving, but I would say you've got a lot of justification for a code red. This has got to escalate. Yeah. I think I think we have a lot coming up as well at this site in terms of articles and white papers. And as we come up. with more, we can share that with the group. Alright. Sure. So another question is, how can we verify that a vendor has actually remediated the vulnerability rather than simply confirming that they have patched? Well, Will you wanna take a? shot? Yeah. Yeah. That's a great question. What I would look for, obviously, within the the vulnerability detection dashboard for that particular vendor, seeing if they have changed over to mitigation apply. And once they have, it it might still be worth, you know, maybe an outreach to them just to confirm, that they have applied, you know, all forms of remediation, you know, not just updating to the newest version, if anything else is recommended. It's okay. And I do I do think a follow-up is still good around just, hey. Have you seen any signs of exploitation? Right? I mean, just even if they have patched, I would just I would just make stare a, you know, what else have you done around this, to. to give yourself confidence? Obviously, in our versions, you can check which versions they're on. So if they're on a version that didn't get a patch or that's end of life, there's your answer. Yep. Right? So then you then you know if we've got... And this is where our updates are coming in. If we can see that the latest patch is applied, well, they wouldn't have had that before Wednesday, so. you will have known that they've taken some sort of action. Yeah. But I think that other part is, you know, you have a lot of people who, on these platforms, they may be running their app on some other platform. So we had to be able to check, is that platform, you know, like we already said, WordPress or some of those others, what else is there, and what else might be done? But, yeah, that we can help you provide the version, the last time we saw it, and, I think that's going to be as good as you can get. And if you see them on a past version, I'd say that's pretty good. If you've got it prioritized, that may be one you can say, okay. I'm moving on. Yeah. That that... That's a great point. Particularly with the, the, lower versions that involve back porting, those are the ones that maybe would prioritize, you know, outreach to to make sure they've applied that. I think we have answered this question to some extent in our... In your previous responses, but, it's Leonardo's question. Does BitSight show third party risks for the PHP vulnerability, and will it show what's exactly affected? Yes. That's exactly what we were trying to show here. For the assets that we see, obviously, caveated by the assets that we see that we've attributed for those vendors, that's what we're showing. Right? So you follow those workflows. If you got additional questions, reach out. We're trying to make this as easy as we can with AI mode. We'll share the prompt that Will used, so you can connect this, and try and even with any of your own, agentic harnesses to try to get this. But that is exactly what we're trying to get to is, like, how quickly can we show this to you? The other part, though, and the reason why we added BII or Internet intelligence here is maybe there are assets you know about that aren't attributed that you wanna check as well. Right? Then you can search on those specific domains, host names, IPs, etcetera, and we'll give you back the results. Great. This is a longer question from Asta. If PHP exploitation can spread across our entire estate through vulnerable run times and container images. How do we distinguish between simply patching the vulnerability and truly eliminating the risk, especially when we may have already been compromised? And the same vulnerable dependency exists across multiple environments. This is a tough one. This is this is a this is... I mean, this is, like, this is a great question. This is why we're on this call today because this is tough. I'd say, first step, try to close down the vulnerability. Right? Just try to shut down the ability to be exploited because as of right now, you may not have been. Right? So I'd say, first step, try to to mitigate that at least initial, exposure. But if it's pervasive, then I... That's why I'd say that next step is you gotta start looking for any indications of compromise, especially if you can't do anything quickly around that, a cluster of different, you know, clusters and, all the dependencies. Like, that's where it's like... I I wouldn't be more vigilant on on monitoring at this point, especially if you can't update. But, yeah, this is a... That's why this is is is a challenge here. So I'd say step one, get visibility, understand what's there. Step two, look for anything, right, that's... That that may already be a compromise. Step three is, you know, get a mitigation, ideally patched, but that's not always true. That's great. Then we have a question from Mahendra. What is your recommendation on CV 2026115560? Okay. I can take that. So, I I know that's... It... I think... I believe it was today, that vulnerability was, disclosed. My understanding is that it... It's focuses on the very specific, configuration of PHP. I know that they they have some kind of Band Aids that you can apply in terms of configuration to try and avoid it, and that they're available on the p3.net, website specifically that tells you exactly what it is. I I don't believe they have released the the new patchwork yet. But, actually, I... That raises one interesting thing that I also wanted to to to pinpoint is that, because these vulnerabilities, the PHP to show vulnerabilities have been discovered using AI. A lot of people are using AI as well to try and find exploits for these vulnerabilities or PHP to show vulnerabilities. And I'm I'm certain that in the next couple of days and weeks, we'll likely see other vulnerabilities pop up because this code base is gonna be scrutinized a lot with AI. So, even though we're talking about PHP to shell right now, be on top of the... Everything that's being talked about on the disclosures because I believe more things will come out of this. And an example is the... That one, the 11, the 1155601. And, Joao, do we have that one in our platform yet? I don't believe we do. It was just released. I think it was earlier today, or late yesterday. Okay. Okay. We'll we'll get to work on that. Alright? Alright. We'll take just one last, question before we can wrap up. If we have already patched our PHP systems, how can we check whether they were compromised before the patch? Will you wanna take this? I might lean on, Joao or Steven. Ajay, Ajayo, go ahead and you go first and I'll go next. Yeah. Can can you can you, repeat the question just to to. confirm? If we have already patched our PHP systems, how can we check whether they were compromised before the patch? Yeah. So, the main thing here is looking at the logs, at previous logs. So, you should have logs that should be... Exploitation logs would would be very verbose, have a lot of errors, and have big requests, big post requests. And if an exploitation is successful, you will likely see some web shells being dropped, weird processes showing up where they shouldn't, maybe as a child of the Apache or the PHP, workers. So that would be like the main things after applying a patch, trying to check if you were compromised before that. That's great. Amazing. Steven, do you have a point? And we can then wrap up for today. I'd say that, yeah, this is this is moving fast, so I think that it will be IOCs that get published. I don't have any yet on tip of my finger, but maybe we schedule a follow-up where we can share those. But I think, you know, as well, hey. You're looking for any anomalous, behavior files that got dropped. There shouldn't be processes that got spawned that shouldn't have been there, additional lateral movement, that may be moving off of those servers onto others in the environment. Right? So this is where logging is is critical and having some forensics, capability is also, super important. But my expectation is in the coming days or weeks, we'll get lists of indications of compromise or also called IOCs, that others can can start to look forward to run against their systems. Amazing. I still see there are a lot of questions coming in on the chat. How do we get our assets into bedside and a lot of other queries? So for those questions, all the chats are being recorded. What we will do is we'll patch you to your account owners who will be able to answer those queries. In case you still have certain queries, just click on the talk to a bit side expert button at the top so that we can sync you up with your contact owners, and they will schedule a demo session with you to get all your queries answered. After this, webinar, we are gonna share the link to the deck that we have shared, the presentation, and the session is being recorded. So the link to this recorded session will also be shared with you so that you can share it with your teams. And, again, thank you so much for joining with us today and spending this hour with us. This is our continuous effort to give you all the recent updates, and don't forget to, again, come up to our new BitSight webinars in the future. Thank you again. Thank you, everyone. Thanks, everyone. Thank you, Rob.