Cybersecurity Awesomeness Podcast · 2026-10-30 · 14 min
Key moments - from our scoring
Substance score
45 / 100
Five dimensions, 20 points each
The episode centers on a critical lesson from recent PHP vulnerabilities: the time from vulnerability announcement to active exploitation has collapsed to 17-22 minutes, a window that far outpaces traditional human-driven patch management processes. Steffen walks through a realistic best-case scenario where an organization learns of a vulnerability, performs risk assessment, obtains approvals, and deploys a patch - a process that realistically takes 2-3 hours minimum, even without lunch breaks or bureaucratic delays. By that time, millions of exploit attempts are already underway. The core insight is that modern security cannot rely solely on patches; it requires defense-in-depth compensating controls deployed at machine speed. Steffen recommends virtual patching at the WAF layer (Cloudflare deployed rules 9 hours before disclosure), network segmentation to limit lateral movement from compromised PHP hosts, runtime application self-protection (RASP) to catch exploits independent of patch status, and reducing attack surface by eliminating unnecessary PHP instances. This episode is essential for security leaders managing organizations running PHP (which powers ~70% of web servers) and anyone responsible for incident response decision-making under extreme time pressure.
Hosted by Enterprise Management Associates. The show scores 62.5/100 on substance across its analysed episodes. See the full show profile.
According to Cloudflare CEO Matthew Prince, the PHP vulnerability was exploited just 17 minutes after public disclosure; another Cloudflare vulnerability went from announcement to exploitation in 22 minutes. Within 45 minutes there were tens of thousands of exploit attempts, and millions within a few hours.
Even in an ideal scenario with minimal bureaucracy, the process of learning about a vulnerability, assessing risk, requesting approval, and deploying a patch takes 20+ minutes minimum, but realistically 2-3 hours when accounting for human delays like lunch, approvals, and CVE discovery. Attackers exploit vulnerabilities in 17-22 minutes.
WAF virtual patching (Cloudflare pushed rules 9 hours before disclosure), network segmentation to limit lateral movement, runtime application self-protection (RASP) to catch exploits in execution, and reducing attack surface by eliminating unnecessary instances of vulnerable software like PHP.
PHP runs on approximately 70% of web servers globally, meaning the PHP vulnerability affected a massive portion of internet infrastructure and was nearly impossible to avoid through simple asset reduction.
Security operates at human speed through manual processes requiring multiple decision-makers and approvals, while AI attackers operate at machine speed, creating a fundamental velocity mismatch that makes patch-only strategies ineffective for zero-day exploits.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode contains a genuinely useful 'moment zero' timeline decomposition showing why patching can't keep up with AI-speed exploitation, backed by real figures from Cloudflare. However, the compensating controls section is standard advice (WAF, segmentation, RASP, attack surface reduction) and there is notable padding and repetition for a 14-minute runtime.
from the time of the published vulnerability to the time that it was exploited was 17 minutes
At two hours it was hundreds of thousands of attempts and then probably a couple hours after that it was in the millions
The 'moment zero' walkthrough framing is a reasonably original way to illustrate an increasingly discussed problem, but the core thesis - human processes can't match AI-speed attacks, so use compensating controls - is circulating widely in security discourse. The conclusions are standard.
your security is operating at human speed. And human speed is not the same as AI speed
From the initial download to the reading, to the risk assessment, to the approvals. Those are four different, separate human processes. And humans take time
This is a solo monologue by an industry analyst (VP of Research at EMA), not a practitioner who has built or run security programs at scale. Cloudflare executives (CEO Matthew Prince, CISO Grant) are name-dropped as sources but do not appear in the episode, so their credibility cannot be credited to guest caliber.
I am your host. My name is Chris Steffen
when talking with Matthew Prince, who's the CEO of Cloudflare, he mentioned that from the time of the published vulnerability to the time that it was exploited was 17 minutes
The episode offers a solid cluster of concrete data points - specific exploitation timelines, attempt volume milestones, CISA remediation dates, and Cloudflare's pre-disclosure rule-push window - that give the argument real grounding. Some claims are hedged vaguely ('depending on who you believe') and the CVE is never formally named.
45 minutes past announcements, thousands, tens of thousands of attempts were happening. At two hours it was hundreds of thousands of attempts
CISA adds it to, on the 26th they added it to the known exploit vulnerabilities catalog. The remediation deadline was the 29th
This is an uninterrupted solo monologue with no interviewer, no follow-up questions, and no pushback - so the dimension essentially cannot be satisfied. The host's self-structuring is reasonable but the delivery includes significant filler and self-apologetics that undercut the substance.
I know it and I'm sorry about it, but this is something that was unique
Let me repeat that for a moment
Computed from the transcript - who did the talking, and the words that came up most.
In this episode of the Cybersecurity Awesomeness Podcast, host Chris Steffen shares key takeaways from his recent attendance at the Cloudflare Connect conference in San Francisco, focusing on the critical PHP remote code execution vulnerabilities (CVE-2026-109618 / CVE-2026-109619, dubbed "PHP2Shell"). Steffen highlights a jarring insight directly from Cloudflare leadership: from the moment the vulnerability was publicly announced, it took just 17 to 22 minutes for automated AI bots to begin actively exploiting it in the wild. Walking step-by-step through a best-case human patch cycle - reading the CVE, conducting risk assessments, securing emergency change approvals, and staging code - Steffen demonstrates that even the fastest human response takes at least 20 minutes, during which millions of automated attack attempts have already launched. Because security patching operates at human speed while threats move at AI speed, Steffen urges organizations to rely heavily on defense-in-depth and compensating controls.
Transcribed and scored by The B2B Podcast Index.
Speaker A: Foreign welcome to the Cybersecurity Awesomeness Podcast hosted by Enterprise Management Associates, an industry leading technology research and consultant group that provides deep insights across the full spectrum of technology and cybersecurity solutions. The Cybersecurity Awesomeness Podcast will take a deep dive into the security topics that are top of mind for information security practitioners, IT professionals and technology business leaders. Join security expert Chris Steffen, Vice President of Research at EMA, for some truly awesome conversations. Chris, Take it away.
Speaker B: Good morning, good afternoon, good evening. Welcome to the Cybersecurity Awesomeness Podcast. I am your host. My name is Chris Steffen. Today I am going to talk a little bit about my past week and some of the craziness that has happened in that week. I had the distinct honor and privilege privilege of attending the Cloudflare Conference this last week in San Francisco. It was outstanding. I can't recommend taking and checking them out enough. They're not again paying for this podcast or anything like that. But while I'm there we had the PHP vulnerabilities that kind of hit the world and if you know anything about Cloudflare, they were actually some of the instrumental folks taking and defending the Internet against these kind of attacks to begin with. Really impressed with how things went down with Cloudflare and the team there. Got a lot of really good one on one time with some of their executives, from their CEO to the CIO to the ciso. We'll be talking about them more a bit later at a different time, but I really wanted to talk a little bit about the PHP attacks and some of the information there. So first of all, when talking with Matthew Prince, who's the CEO of Cloudflare, he mentioned that from the time of the published vulnerability to the time that it was exploited was 17 minutes. Let me repeat that for a moment. From the time that the world was announced that these were a real vulnerability to the time that the bad guys, either AI bots or humans or were exploiting that particular vulnerability was 17 minutes. That is absolutely crazy. During the conference itself, Grant, who is their ciso, their CISO had a slide that was talking about a different vulnerability that from time to announcement to time to exploit was 22 minutes. No matter how you look at it, the time from the vulnerability being discovered to the time that it is being used by almost universally now AI bots to cause havoc is extremely short. 22 minutes. And we'll talk about that here in a minute. I want to give you an example of trying to understand why that's so short, but if you Think that you somehow have your ducks in a row enough that this PHP attack was going to be solved by you know, applying a patch in your good and living happily ever after? Let me tell you that's just not how it is. So I want to give you a little bit of history about the php2 shell attack. Uh, sometime in end of September, beginning of October, it was made known to our friends at Cloudflare and then Wiz announced it as well and did a little bit of searching and at the same time Google was taking and researching one as well. Lot of different vulnerabilities that are out there and the companies that are in charge of protecting us from this stuff, like Cloudflare, like Google, like whoever else, they were spending a lot of time coming up with compensated controls. PHP on the other hand was in the process of trying to understand the vulnerability and creating a patch for it. So two different work streams, you got to have them both, it makes all the sense in the world. So when PHP will finally released a patch, it was announced and so on. So where people could take an update their, their PHP code. PHP runs on half the web browsers. In fact I think uh, I read a number that was like 70% of the web browsers web servers in the world. Obviously it was going to have an impact, it had an impact and quite bluntly at recording this the next week it is already still having an impact of people trying to deal with it. But the key of all that was the compensated controls, right? If you had a properly configured waf, if you had some other defense in depth layer of cybersecurity, you were probably okay. And then you had an emergency patch deployed for the PHP vulnerability and you lived happily ever after, right? When you start reading some of uh, the timeline CISA adds it to, on the 26th they added it to the known exploit vulnerabilities catalog. The remediation deadline was the 29th. So basically that moment and so uh, you can tell that these were going on and being remediated as fast as possible depending on who you believe. 45 minutes past announcements, thousands, tens of thousands of attempts were happening. At two hours it was hundreds of thousands of attempts and then probably a couple hours after that it was in the millions. So again let's just be abundantly clear here and I want to take and go through a timeline so that you can kind of really understand. So let's talk at moment zero. Moment zero is when someone either SISA or someone else takes and announces that there is a vulnerability. If you are. And I'M going to give you the absolute best case scenario here. This is not realistic, by the way. This is the best possible case scenario. So at moment zero, you are on the ball. You are a information security practitioner. You found out about this vulnerability and it took you, let's, uh, say two minutes to read the vulnerability. Then you spent another two minutes doing a risk assessment. Is this actually impacting us? What does it really look like in our organization? And again, you realize that it's php, and so you almost certainly have this vulnerability within your environment. Okay, so you're four minutes down. So then you decided, well, uh, we got to take and figure out what we're going to do. A couple things can happen in parallel here. You start taking a, looking to see if there's a patch. You start taking and filling out the paperwork to get this thing patched within your environment. Getting the paperwork, getting permission to take and do the patch takes another two, three minutes. So now you're at six, seven minutes. When it's all said and done, then to get the approval. Again, this is a human process, mind you, to get the approval to take and deploy the patch off cycle immediately takes another 2, 3, 5 minutes maybe, because again, it has to have that conversation. You got to explain to whoever the decision maker is why this is really important. Heaven forbid that they're at lunch or something like that. But again, we're talking an ideal situation, so we'll just use the number of five minutes that it took to get the approval to take and deploy the patch. So you're at 12 minutes right now. Now you want to take and get the patch deployed and you need to get it deployed in the most quick, quick way humanly possible. Taking down production the little, the least amount possible. And that takes time. You might have been doing some of this in parallel. Maybe your tier one team was taking and working on some of this while you were getting approval, so on and so forth. But even under all those circumstances, it still takes time, maybe five, six, seven, eight minutes when it's all said and done to really get it staged correctly. Get, get the patch that you were already downloading from PHP installed. But if you believe in the eight minute number, okay, now you're already at 18 minutes, reminding, keeping in mind that it was first exploited at 17 minutes. And then you still got to deploy the patch and then you got to get your systems back up and running, which is at least another two, three, five minutes. So using this example, using these human controls, human processes that you have in place, and it takes 20 minutes at minimum, from the time that you actually even hear about the vulnerability to even the smallest chance that you can get it deployed. That doesn't take into account people at lunch. It doesn't take into account the approval process. It doesn't take into account the idea that maybe you didn't read one of the billions of CBEs that happens to come out seemingly every single day. And, and you just happen to notice this one right away as a critical. There's a lot of human things in there that would show you that by the time that you took and actually read the CVE to the time that it got it done in reality is something in two or three hours. And even that's a stretch. My point in sharing that is, even with that example, there was millions of exploits happening in that amount of time and, and who knows if you are going to be on that list. So I wanted to share this example. I wanted to share this timeline. It isn't the idea that your patch management is not working right. It isn't the idea that you have poor security, your environment, but your security is operating at human speed. And human speed is not the same as AI speed. There is no way that you as a human operate at the same velocity that AI does. Especially when you take and have multiple people and multiple steps in there where humans have to come in contact with the process. From the initial download to the reading, to the risk assessment, to the approvals. Those are four different, separate human processes. And humans take time. Why are we talking about this specifically? And I'm not going to belabor it a whole lot more than I'm actually writing a blog and a paper about it right now. But I do want to be very clear. It isn't the idea that again, that you have poor security, it's that you have to have security in depth and you got to have compensating controls. In this case, a WAF would have been perfect to absolutely be able to figure out a way to give yourself more time to allow your controls, uh, to allow your processes to actually work. So let me give you three or four examples of things that you could have done with compensating controls that would have given you time. You could have had virtual patching at the WAF layer, meaning that you could have take and had your WAF automatically update. This is very common. Cloudflare pushes firewall rules to every customer at free terror, even nine hours before the disclosure. In this particular case, those kind of compensated controls are outstanding. You can also have a segmented network. I know that I seem to talk about that all the time. It is one of my more favorite pieces of information security maturity that everybody should be taking and looking at. And that gives you some ability to limit what a compromised PHP host can actually reach. You're never going to stop everything, but you can at least limit the spread. Another one is you can have some kind of rasp right runtime protection. You want to catch the exploit in the act independent of, uh, patch status. And then the last one, I think it's obvious, is that you want to reduce your attack service. You want to get rid of PHP that shouldn't be in your environment. You, you want to have a real assessment of where those things are. Uh, that way not only do you reduce what your exposure might be, but you also reduce the amount of time that it's going to take to fix a lot of information here. I know it and I'm sorry about it, but this is something that was unique. It's something that I'm particularly interested in. This is not the last time that this is going to happen. I'm, um, not trying to pick on php, the PHP foundation. I'm not trying to pick on anybody in particular. I am here to tell you that these kind of extremely hypervelocity, hyper speed, AI type attacks are just now starting and this is the latest example. If you have questions about this, ping me. I am happy to have the conversation and I would love to have the conversation again. I don't think that we're done talking about it, but this is something that you're going to see more and more in the industry and we need to start thinking about better ways to dealing with the problem. I hope this is interesting. We'll keep on talking about it and keep on doing the research, but until next time, thanks for listening.
Speaker A: Thanks Chris, for all your great insights today. Make your next podcast awesome. When you work with the EMA team on your organization's next project, demonstrate thought leadership, differentiate your solution and add the credibility of a third party expert to your message. Visit cybersecurityawesomeness.com to listen to past episodes.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.
CMMC Level 2: Documentation, Costs, and Audit Readiness | Interview with Bruno LecoqSecure & Simple · on Cybersecurity89 / 100
Mastercard CEO: The $15.6 Trillion Threat Most Investors Are IgnoringMotley Fool Hidden Gems Investing · on Cybersecurity88 / 100
The Evolution of Modern GRC ft. James Huang, Head of GRC @ GongSecurity & GRC Decoded · on security86 / 100
AI-Accelerated Supply Chain Attacks with Mackenzie JacksonRunAs Radio · on Cybersecurity83 / 100
Trump's Golden Post-Quantum EO(s)Security Cryptography Whatever · on security80 / 100
Edge AI Security: Why Secure-by-Design Engineering MattersEmbedded Insiders · on security79 / 100