

The hosts revisit the “PHP 2-Shell” PHP core vulnerability (high CVSS ~9.8) and why it did not trigger mass exploitation. They argue that threat-actor “business processes” and exploit value matter more than scary ratings, and that this bug was hard/brittle to weaponize broadly.
Tom Uren and The Grugq (Rob? “Rob” is mentioned at the end). Both are cybersecurity commentators/analysts; they discuss threat-actor behavior, exploitation difficulty, and incident dynamics.
Mass chaos didn’t happen because (1) the most common mass-exploitation targets are email/document/workflow systems, not arbitrary web-server PHP shells; (2) memory-corruption exploitation is fragile across diverse PHP builds/mitigations; (3) patching/monitoring reduces “legs”; (4) honeypot claims of months-earlier exploitation are likely implausible.
Exchange/SharePoint mass exploitation; Barracuda email campaigns; Clop ransomware-style document/edge targeting; “VPN appliance” hypothetical; SolarWinds and Accellion/Kiteworks as “unknown until exploited” cases.
Written by AI. May contain mistakes.
Discussion of the PHP 2-Shell vulnerability and its implications.
“So I thought we might revisit PHP 2-Shell.”
Exploration of why the expected mass exploitation did not occur.
“Now, I think that's just not right because pretty much everyone was concerned about it in the cybersecurity field.”
Insights into how threat actors prioritize and exploit vulnerabilities.
“because by all rights it should have been.”
Analysis of the difficulties in exploiting memory corruption vulnerabilities.
“If you say, here's a way to exploit an arbitrary number of, like here's a way to exploit Microsoft Exchange.”
Final thoughts on why PHP 2-Shell didn't lead to large-scale exploits.
“So one of the things on the other side is that it actually turns out quite hard to exploit.”
Discusses the self-limiting nature of PHP2Shell exploits and their usability.
“It feels like maybe it's a bit self-limiting when everyone is warning people to patch and take systems offline if you can't.”
Analyzes the difficulties and limitations in exploiting PHP vulnerabilities effectively.
“It sounded like it had all the components of like, this is going to be a big deal.”
Evaluates claims about early detection of PHP2Shell exploits and their implications.
“It seems like it'll have narrow impacts rather than really broad ones, I guess.”
Discusses the worst-case scenarios of PHP vulnerabilities and their broader impacts.
“It didn't work, but for whatever blah blah blah.”
Compares PHP vulnerabilities to more severe exploit cases like VPN devices.
“People get a lot of shells on web servers that then need to be local privilege escalated and then need to be used for something else.”
Analyzes how new exploits fit into existing business processes and value generation.
“People would make the effort because it would be very valuable.”
Discusses the unpredictability of impactful vulnerabilities and their visibility.
“And then everyone who runs an enterprise Fortune 500 going like, what are you talking about?”

Get the gist, explore an idea or ask about something said.
On Risky Bulletin, what are the key points of this episode?
Automatic transcript. May contain errors.
0:02Tom Uren: Hello everyone, this is Tom Uren. I'm here with The Grugq for another Between Two Nerds. G'day, Grugq, how are you? G'day, Tom. I'm fine, and yourself? I'm well. This week's edition is brought to you by Airlock Digital. They make a layout listing solution that actually works. You can listen to a sponsor interview with their CTO Peter Boesman out on the channel this week. So I thought we might revisit PHP 2-Shell. So a couple of weeks ago, this was the... So in cybersecurity years, that's like seven months or something now? Decades. A couple of weeks ago, I actually started our discussion mentioning it, and I said it looked like there was about to be some sort of mass exploitation event.
0:48Tom Uren: So it was a problem in core PHP, which is a scripting language that is used in something like 70 % of websites. It's a little bit popular, yeah. It was rated 9.8, I believe, and you could remotely take control, get remote code execution. So it sounds like a big deal. When you put it that way, it doesn't sound particularly great. A lot of warnings about it. We mentioned them. And then effectively nothing significant happened. So I thought we could talk about why that didn't eventuate. And that's partly because I got kind of triggered by a couple of tweets I saw. So the first one from Zach Gorman, and he says, the fact that the PHP vulnerability didn't immediately turn into mass chaos is only surprising to people who don't know anything about cybersecurity or people trying to tell you something.
1:49Tom Uren: Now, I think that's just not right because pretty much everyone was concerned about it in the cybersecurity field. It didn't feel like this is being hyped for no reason, right? Right. So if someone comes to you and says, there's an RCE, remote code execution, in PHP, that's a 9.8 and it affects almost all the versions out there. Don't worry about it. It's fine. Not a biggie. It's just time. We've got those CVSS scores for nothing. You wouldn't think this guy knows cybersecurity. That is a clue. I thought that was not correct. I think there was a lot of mainstream media hype, and maybe this is a reaction against that.
2:35Tom Uren: And in retrospect, I can see reasons why it didn't happen, but it wasn't clear to me beforehand what those... And with hindsight, I know exactly why. That's right. Yeah. You know, at the time, I thought it was going to be a big deal. Yeah. Just because that's what it sounded like. Like it had all of the things that made it sound very exciting for. Good times. Yeah. Something to look forward to. Yeah. Like it was just going to be, it was going to be wild. Like it seemed like this is going to be a mass event. and the fact that it wasn't was a little bit like you have to explain why. You don't have to explain it.
3:15If it wasn't a mass event, you wouldn't have had to explain why it became a mass event. But the fact that it wasn't requires an explanation because by all rights it should have been. So what went wrong? What went wrong? What went wrong? Come on, guys. Get it together.
3:31Tom Uren: Marcus Hutchins replied to that tweet. Life is a lot easier once you stop seeing threat actors as hackers who want to break into systems by any means possible and start seeing them as businesses with well-defined business processes. So this felt like something that perhaps you or I might write. I literally wrote about that in 2020. Yeah, so I think this is absolutely correct. Yes, correct. A bakery isn't going to start making dog food because there's a dog food shortage. Well, okay. I think in the pandemic, there were lots of businesses that pivoted to different things. Exactly what I was thinking.
4:12That ends like, look, if there's a dog food shortage, dogs don't have to eat kibble, right? Dogs can actually eat human food if they need to. Anyway, I understand the analogy. It's a bad one for this case, but I know what he's getting at.
4:31Tom Uren: I think probably I'm being a bit pedantic there. Click fix and phishing actors aren't going to drop everything to Vibe Code exploits just because a critical CV came out. I think this is also true. Yeah. So far, there's nothing to disagree with, except... Well, I think this is actually a really interesting example. The fact that the only actors exploiting this are the actors whose MO is exploiting things isn't a coincidence. it's entirely predictable if you understand threat actor behavior so i mean to me that sentence doesn't really say anything my immediate thought was there are threat actors whose uh air quotes day job is to go around mass exploiting things when the opportunity occurs to use an example uh if there's a dog food shortage the dog food factory could ramp up production just because the bakeries don't do it doesn't mean that the dog food companies don't do it either I can think of several examples there was the Microsoft Exchange mass exploitation event there was a similar one in SharePoint a couple of years later there was a mass barracuda email exploitation campaign and so um and i'm sure there's been others clop regularly does mass exploitation campaigns and so yeah it's not unheard of yeah so it feels like the everything marcus said was correct but in the context of mass exploitation it almost felt like irrelevant because it's there are actors that's their job that's what they do if there's an opportunity there that they can um collect and put it on the shelf in a way yeah so but i feel like it's like it goes deeper than that right i was gonna say like i think you're getting it exactly why this wasn't a big deal in that way and it's it's because basically uh the threat actors who do that sort of thing right they they do as you would say they have a business process right these are intelligence agencies that are able to take in certain types of data, like emails or so on, process them and produce an intelligence product that they can use.
6:55And so that's what they do. If you say, here's a way to exploit an arbitrary number of, like here's a way to exploit Microsoft Exchange. To them, that's like sugar water for like hummingbirds or something. It's like, it's what they live on. It's the thing that they need. So they're just going to go for it. They're going to go wild. but the same actors are not going to have much use for something that gets them a php nobody nobody shell running on a web server somewhere like that's just a lot of work that
7:25Tom Uren: they're going to need right like it's yeah yeah so the commonality of all the things i listed was email documents email and these are all like standard inputs like you say to intelligence And for CLOP, their mass exploitation events have been documents, basically. So edge devices, the old sensitive information. And so the fact that it was a website, like what does an intelligence agency do with access to every website in the world? I don't know. Get really high Google rankings, like take over SEO. I mean, like it's not entirely clear what the benefit is. There would be times where access to a specific website is really valuable.
8:09Tom Uren: Right. I don't imagine they have a process to go, let's just compromise all websites and we'll sort them out later. I think the thing is, you might consider going for all websites or just a large number of them if there's no alternatives out there. If you have no other option of gaining access to anything and this is the one and only bug that exists in the world, Sure, you might mass exploit it because you've got no other options. But that's the opposite of the situation we're in right now. We have too many bugs. So if something comes along and it's not exactly perfect, you can discard it and get one of the three exactly perfect ones that you already have.
8:53You don't need to make something that's a little bit janky, sort of kind of work, sort of doing a little bit of what you need, but not exactly, when you have all these other things that you could do instead. Right, right.
9:06Tom Uren: So one of the things on the other side is that it actually turns out quite hard to exploit. And it seems like PHP to shell. And then the same week, there was another one, which was in Google-built decompression library. And both of them are really widely distributed. And both of them were memory corruption. But I think just the fact that they were so widely distributed meant that they were on many different systems, many different software configurations, many different hardware configurations, all with potentially different mitigations and memory protections. Right. So it's going to be this thing of memory corruption exploits are quite brittle.
9:50It's very hard to get one that works on everything everywhere. That takes a lot of effort and time. And so particularly when you take something as unique as PHP, where there's all these different versions, there's all these different distributions that have different modules compiled in and different command line settings that are used by node. There's so much variety and variation that inherently it's going to be very, very fragmented and difficult to get something working everywhere. So from my understanding is that the bug itself was complex and hard to exploit. And all of the people, like there's a lot of people who posted on Twitter, like within a few days saying, I don't know why everyone's saying it's hard.
10:35You know, I did it in less than 24 hours with my like harness. And there are all these top tier exploiters going like.
10:46Tom Uren: It's perfectly easy to exploit. You just have to be perfect to start with.
10:53I only have 20 years of experience and I was able to do it easily. I don't know.
11:00Tom Uren: So one tweet that I saw after PHP to Shell, which I thought was interesting, is from this account called Brian in Pittsburgh. So what we know about memory corruption exploitation over the last decade, there are basically two core scenarios. There's state-level actors investing a lot to buy, develop, ODAs and key things. Somewhat more widespread exploitation of NDAs in products without modern era defenses. So I guess that is what I was talking about. When it's widely deployed, it's sort of almost by definition, it's deployed on at least some percentage of modern things with modern defenses. There's the people who have exquisite capabilities for exquisite and special targets.
11:45And then there's like everyone else, like the middle class of hackers who just, you know, like they get their used Honda Civic. Yeah.
11:56Tom Uren: And Brian goes on to talk about basically logic bugs being, and those were the kinds of bugs that were in Exchange and SharePoint. Right. Being far easier to exploit. Well, I'd say that they're not necessarily easier to exploit, but that they're more reliable because it's happening at a higher layer than the memory. so like if we're using Halvar's weird machine theory like constructing a weird machine out of memory addresses and the way that a CPU works is inherently very fragile because it's going to be dependent on the memory layout and the CPU architecture of every specific thing. So that's a very tricky thing.
12:42Whereas if your weird machine is just making the existing program behave a little bit differently like it's already running the program's already running making it behave differently is a lot easier as long as the program already runs you don't need to worry about what architecture it's on or what's right you don't need to make the machine you just have to modify the machine i guess right it's just it's a lot more reliable because it's less context dependent right it's context dependent on having the right application running already not right the right i feel like
13:18Tom Uren: It's taking advantage of building blocks that are already there instead of building the building blocks in the first place. So I feel like if it had been something that gave access to a lot of valuable targets, intelligence agencies would have gone, yes, there's an opportunity here, let's do it. And it wouldn't have taken... If it was PHP to email. Yeah. Yeah, but there's also the point you made about there being a lot of vulnerabilities around right now. It seems like a high-profile one where perhaps the organizations you care about will patch quickly. It's almost like, okay, how much effort do we have to put in?
14:02Tom Uren: It feels like maybe it's a bit self-limiting when everyone is warning people to patch and take systems offline if you can't. Right, and monitoring otherwise because you know to look for that. So it's sort of, it's the brightly lit alleyway that, you know, someone's like, don't walk down there. You might get mugged. And it's, you know, it's got cops on both sides. And like, you know, like, yeah, avoid alleyways. But this is one of the worst ones for a mugger to be in. Right. If you want to be doing nefarious stuff, you want to pick something else. Not the one that's, I think it was the prime minister of Japan tweeted about it.
14:39Right. Like, that's not a low profile bug to go after. I would say that there's a lot of things not going for this bug. So initially it did sound very exciting. It sounded exciting. It sounded like it had all the components of like, this is going to be a big deal. And then when it came out and it was a bit of a like, oh, it's actually really hard to do. It'll get you like this PHP shell, which doesn't run with permissions and is sandboxed and all of this stuff. It's like, it's hard work. it gets you very little and then it's very hard to use that to do something else because like you need more things afterwards anyway so it's it's not even a it's not a complete uh package like the exchange ones where it's a small part of a complete system and it's i think what we're getting at is this is not a great one if you are an intelligence agency who are the sort of people who use this if you're a ransomware group it's not necessarily a good one either you want to be in people's networks, not on their web servers at a colo or something, right?
15:46Like it's web servers do not necessarily have access to everything else. They tend to be sort of isolated these days. So, I mean, I'm not saying that no one will exploit it, but it doesn't have legs, I guess. Like it doesn't, it's stuck in a...
16:03Tom Uren: It seems like it'll have narrow impacts rather than really broad ones, I guess. So, like, speaking of this mass exploitation thing, one of the tweets that I saw come out was someone claimed that they detected the PHP to shell exploits being used several months ago, and they noticed it on their honeypots. And, like, I'm not going to call bullsh**. I'm just going to say that doesn't sound right to me. I'll explain why, because it's very, very obvious once you think about it. if you've got a bunch of honeypots out there and they get hacked with stuff, it's because there's mass scanning going on and people are just trying stuff.
16:41So it's a mass attack. If you're an intelligence agency and you have this sort of bug that you're using, you're not mass scanning the internet and just hacking whatever shows up. You're going after specific targets because that's your job. Yeah.
16:56Tom Uren: I think especially this bug, which was hard to exploit, you would do all your homework to figure out what's the target, what version, what platform, et cetera, et cetera. Right. And then you'd be like, okay, of all the things, this is the one that's going to work for us. So we'll do that and then whatever. So you're not going to be hitting honeypots because that's literally the opposite of what you want to do, right? Like you'd put all of your work into making sure that you're hitting exactly the right thing and it's going to work. So a honeypot wouldn't be a target. On the other hand, if you're doing mass scanning to try and just break into things and you have an exploit like this there's no way you keep it secret for months yeah right like you're going to be part of an ecosystem that trades and steals and you know shares like it's just these are not well i mean the whole point of honeypots is also to pick up on those things right so right i mean if you saw it seven months beforehand and you did nothing with it doesn't that kind of defeat the purpose of what a honeypot is for?
17:56Yeah, to me it just doesn't feel right. I think you might have like you can see something being done against PHP and then go like, well, there's a probe on a PHP thing and maybe some shellcode got sent. It didn't work, but for whatever blah blah blah. It could have looked very similar for whatever reason. Yeah, a lookalike. It's a copycat before the original came out. So I think that's the kind of thinking
18:22Tom Uren: that is exactly in Marcus's tweet, right? Like there's a way people work. They've got a business process. It's just that in the context of PHP, that tweet doesn't really make sense because I think there's other factors at play that are explanatory. So I feel like now after having this conversation, I would be able to go back in time and say, well, is it easy to exploit? What's the driver for people to exploit? What's the worst case impact? So this is one of the things that you do in intelligence analysis of the, like, what's the best case? What's the worst case? What's the likely case? And it's like, best case, no one exploits it.
19:05Don't worry about it. Worst case, what actually is the worst case? People get a lot of shells on web servers that then need to be local privilege escalated and then need to be used for something else. So worst case to me is feeling like a lot of defacements or maybe a lot of leaks of forum membership or.
19:25Tom Uren: Well, I mean, there's a lot of websites that run commerce, right? So potentially monetary stuff, stealing financial stuff, perhaps. But it feels like to me the organizations with the most to lose are the ones that are most likely to do well. right so it feels like the more effective it is the more likely that people will take those warnings seriously so it becomes kind of self-limiting once once one bank gets taken offline i think the other banks pay attention right right um which is i think that's an extreme example but yeah all right so i i agree it's just i i think that the like even if you're trying to worst case, I don't think it's that bad.
20:10Tom Uren: But I think that hypothetical of what if it was a service that had something that intelligence agencies really wanted. I think it was actually valuable at the other end. Yeah. I think that would change the dynamics or the... Like, if you come out with, like, here's a bug in all of the VPN appliances that people have, that stuff gets mass exploited because it's very easy to transform access. like you can transform access to VPN devices into compromising an entire network. Right. And that you can turn into cash money or you can extort or you can collect. Like that's a useful thing to do. So I would expect that.
20:53Tom Uren: So that would be ransomware actors you're talking about in that case. Right. Ransomware or yeah, like any sort of criminal can do that easily. Intelligence agencies would do that. Like that's the thing that's got a very, very high conversion factor. It's very easy to exploit. So I would think that if there was a 9.8 that came out in a very, very common VPN device, that would be a problem. It doesn't matter how hard to exploit it would be. People would make the effort because it would be very valuable. It feels like that example, because it's a VPN appliance, it's more likely to be a monoculture where even if an exploit is hard to develop, it's likely to have a higher applicability to whatever that appliance is.
21:39Right. So I was going to say, I feel like the part that's missing to Marcus's tweet to his logic is that it's true that people don't change their business processes just because a new thing shows up. But that's not really the case here, right? Like you've got people who have existing business processes. and if a new thing shows up that can be made to fit in a way that they can like their business
22:05Tom Uren: is about exploiting value from something like they're extracting value from it and if there's a way that they can do that that fits in with whatever the new exploit is they will use it this is not one of those times right like it's not that the the business process doesn't use whatever it's just that it doesn't fit the way that they generate value so even if it was super easy the mass exploitation that would be going on wouldn't necessarily be um i mean it would be more like a script kitty type thing it could be fun to deface yep because that's how they realize value with exploits is the right yeah so i i guess to me this whole thing makes me think that yeah i'd be better able to assess whether something really will go big or not but it also makes me think that the things that will have wide impact are the things that no one will talk about until afterwards so they'll just be surprises that come out of the blue because of for whatever reason they have the alignment of something people want aren't really broadly distributed but are broadly distributed enough in enough valuable places that they're right it's it's the intersection of like Like us going, I haven't ever heard of that.
23:16And then everyone who runs an enterprise Fortune 500 going like, what are you talking about? We all have those, right? Like there's 500 licenses that have been sold for this thing. Like all the Fortune 500 and no one else, right? So like that feels to me like a thing that's going to happen, right? Like when Klopp was hitting those like weird, like the file sharing things that no one's ever heard of. And it turns out that they're actually widely deployed.
23:41Tom Uren: Yeah. Yeah, Accelion, Kiteworks. I wrote about them a number of times. SolarWinds, I guess, is another example. I was literally going to say SolarWinds. It's like no one had heard of SolarWinds until they got hacked. Even though they were deployed on millions of devices, no one's ever heard of them. So I guess the good news is if we're talking about a named vulnerability, it probably won't be a big deal.
24:06Thanks a lot, Tom.
24:07Tom Uren: Thanks, Rob.
24:11you
In this edition of Between Two Nerds Tom Uren and The Grugq talk about why PHP2Shell failed to live up to its hype. A critical bug in a very widely used web scripting language amounted to… not much. The pair dissect the reasons why.