There is no shortage of security vulnerabilities. Threat actors have never needed sophisticated exploits to breach organizations; they can and do use simple methods of initial access. They don’t even need a CVE: stolen credentials and good old-fashioned social engineering are still painfully effective. So when various AI products are marketed with doomsday warnings that they will revolutionize vulnerability discovery and exploit development in every single piece of technology, thereby bringing about Ye Olde VulnpocalypseTM, I can’t help but be skeptical. Even in the wake of a difficult month that has been dubbed “Black October” by the community for a slew of major incidents.
I don’t think the doomsday rhetoric is realistic. For one thing, more vulnerabilities don’t necessarily mean more risk. Despite how it feels on social media, most CVEs come and go without starting a global crisis. According to Google Threat Intelligence Group, vulnerability disclosures doubled in the first eight months of 2026, but only 0.23% were observed being exploited in the wild. Roughly 5,000 Linux kernel CVEs were reported in the first 8 months of this year, with no observed zero-day exploitation. Obviously these are only two statistics measuring two specific things in what is a very broad ecosystem, but they illustrate how little raw vulnerability counts tell us about the risk most organizations actually face.
What actually matters is how easily a vulnerability can be exploited and what an attacker could accomplish with it. And this is where AI could really change things. At first it seemed bogus: I recall plenty of zero-days that came with overhyped reports of mass exploitation, only to find GitHub littered with vibe-coded proof of concept scripts that didn’t actually work. But that’s changing: AI is not just getting better at finding new vulnerabilities, but also making it much cheaper and faster to turn existing, obscure bugs into working exploits.
Much of the discussion I hear has focused on changes in speed, but I think the cost matters just as much, if not more. Time and expertise have historically been significant barriers for attackers, and AI is putting techniques that once required highly specialized researchers and serious resources within reach of a much wider range of bad actors. As a fellow ARC researcher put it, it’s like giving an enthusiastic researcher unlimited coffee and willpower.
PHP2Shell, last week’s global security crisis, is the latest example of this. If you have been off-grid the past couple weeks, here’s a short recap: two critical memory-corruption bugs in PHP were disclosed that could allow an unauthenticated remote attacker to gain code execution on PHP web servers under certain conditions. The underlying bugs were in the codebase for over a decade, but turning them into working exploits required unusually complex research, until AI helped lower that barrier.
If this had been in some niche software, it would have made for an interesting technical writeup that we could all geek out over before moving on. But this was PHP, a core technology that powers so much of the web. Many Rapid Response advisories we publish at Censys involve hundreds to hundreds of thousands of hosts; this one involved tens of millions of Internet-facing PHP services.
There has always been heat on core technologies like this; that is not new. What I’m interested in is: if AI is making aging software easier to exploit, are we getting any better at maintaining and protecting it?
PHP2Shell has already been written about a thousand times, and will be until our collective amnesia kicks in and we latch onto the next allegedly “world-ending” bug. But the systems that remain unpatched don’t disappear when the headlines do. What happens to those old, forgotten corners of the Internet? Does any of that software ever get updated?
To answer that, it’s worth looking at what we’ve learned from watching the Internet respond to vulnerabilities over much longer periods of time.
What actually happens to software when it gets old?
PHP has been declared dead many times. Yet incidents like this one remind us just how much supposedly outdated software, in its earliest releases, is still running on the Internet.
This is not at all unique to PHP: lots of old things stick around. A good deal of the Internet is dynamic and ever-changing, but a lot of it isn’t. In our 2026 State of the Internet Report, we studied enterprise software lifecycles over two and a half years. Or, in less fancy words, we wanted to know: for all that we say “Patch!!!11”, does anybody actually do it? How often, and does the timing correlate with major vulnerability disclosures or active exploitation? What gets left behind?
We tracked the Internet-facing populations and versions of four very different enterprise products: Telerik Report Server, Jenkins, Cleo Managed File Transfer, and Microsoft SharePoint Server. We compared version movement with vulnerability disclosures and additions to CISA’s Known Exploited Vulnerabilities catalog. PHP wasn’t included, but the findings offer some useful context.
Across all of these very different products, the most consistent finding was that the oldest software barely moved. Versions a few years out of date were gradually phased out, but the oldest releases (between 8 to over 20 years out of date) only really changed by roughly a percentage point as a proportion of the overall population over two and a half years. The oldest software (represented by the teal segments in the graph below) seems to be the stickiest. We still see Windows SharePoint Services 2.0, originally released in 2003, exposed on the Internet.
Lots of things could explain this. Some systems may be so deeply embedded in operations that upgrading them is no longer routine maintenance. Of course, we can’t tell from the outside whether an organization hasn’t prioritized updates because they have some other mitigating protections in place. But either way software that’s a few releases behind presents a very different maintenance problem from software that hasn’t been updated in decades.
We also observed distinct patterns in the timing of that maintenance:
- Routine versus crisis-driven upgrades. Jenkins had a steady baseline upgrade rate of 7.3% of returning hosts, peaking at 9.1%. Cleo MFT barely moved until reports of active exploitation triggered a massive 63% spike. Different products and circumstances, but a striking contrast between routine maintenance and emergency response.
- Release cadence appears to matter. Products with frequent releases, such as Jenkins and SharePoint, tended to see steadier upgrades. We can’t establish causation, but the maintenance practices surrounding a product may matter as much as patch availability.
Basically, some software is continuously maintained, some sees bursts of upgrades during emergencies, and the oldest may barely get touched at all. One thing that stood out to me is that the products that were more routinely updated, Jenkins and SharePoint, both have large user communities, well-established maintenance practices, and plenty of documentation and automation tooling and support to help people keep them updated. It makes me wonder how much the ecosystem surrounding a product matters in whether people actually maintain it. Whereas for the more niche products, critical vulnerabilities clearly can spur organizations into action, even when they rarely update otherwise. But that doesn’t mean the whole affected population moves, or that the systems left behind will be any easier to update when the next crisis hits.
I’m increasingly less interested in expecting everyone to get on the latest and greatest version of every technology they depend upon, and more interested in what we can do for those who simply can’t keep up. What makes software maintainable over decades, whether it’s backed by a big corporation or an open-source community? And how can we make that shelf life longer, without leaving people stuck on vulnerable software or expecting them to overhaul their systems every few years?
Which brings us back to PHP2Shell.
How are orgs actually responding to PHP2Shell?
Our public PHP2Shell dashboard tracks how the Internet is responding to the incident, and the numbers so far are encouraging. As of October 29, over 11 million PHP services have moved from affected to fixed versions since patches became available on October 21. Most of that happened in a huge burst of patching during the first few days, with more than four million services first observed on fixed versions on each of October 22 and 23. That tapered off over the subsequent days.
So yes, people do patch! Large portions of Internet-facing services can respond remarkably quickly when a serious enough security event occurs, like we saw in our longer-term case study research. But as that research also found, the initial rush of upgrades is only part of the story: there’s always a long tail.
Over 30 million PHP services were still reporting affected versions as of our most recent scans. Roughly three-quarters of those, around 23 million, were running PHP 8.1 or older, branches for which no official PHP2Shell fixed release is available. Even among supported branches, we’re seeing differences: after nine days, nearly 83% of services reporting the newer PHP 8.5 were on fixed releases, compared with around 57% of the older PHP 8.3 services. We also saw this in our longer-term research: relatively newer, middle-aged software tends to see more upgrade activity (plausibly because it is more actively maintained), while comparatively older versions lag behind.
So what actually motivates and/or enables patching?
A big part of the answer lies in how the software is maintained and distributed in the first place. PHP is used in so many different ways that these numbers don’t necessarily tell us much about the maintenance habits of individual organizations. Some run PHP directly, while others rely on hosting providers or applications like WordPress, where the underlying PHP runtime is managed separately. A WordPress site on managed hosting might automatically receive a PHP security update without its owner having to lift a finger, while another user might need to test and upgrade a business-critical application that depends on a particular PHP version.
The PHP team coordinated with downstream distributors ahead of the release, and some hosting providers were able to deploy fixes almost immediately. One provider, VertexIT, reported applying patched packages within two minutes of their availability, without outages. That’s a pretty good example of what established update processes can make possible. An interesting other example is vendors like CloudLinux and Plesk that have backported fixes to older PHP branches, sometimes without changing the reported upstream version, so that users don’t even need to move releases.
Not everyone has access to those options. For organizations running supported PHP branches, remediation for PHP2Shell may be a relatively straightforward security update. For those running older versions, it may require figuring out application compatibility issues, or reworking software that hasn’t been meaningfully maintained in years.
Even figuring out what even needs to be updated can be a challenge.
As Michael Schwartz, our VP of Security & ARC Research, put it:
“Visibility and ownership compound the problem. Teams may not know all their Internet-facing systems or realize that an application they use depends on PHP. Once they identify an affected system, patching may require coordination between internal IT, a hosting provider or an external agency. Older applications can also require compatibility testing or a broader upgrade. Having a patch available is only the first step.”
This is an important part of the conversation, and it goes way beyond PHP or even conventional enterprise software. More and more we need to talk about the parts of the Internet that simply have no way of patching. This is especially difficult in the realm of operational technology, where software is embedded in physical infrastructure. We saw this play out with the recent Danfoss refrigeration controller hacks, which affected both newer systems with outdated firmware and older models that no longer received security updates, leaving operators of those legacy systems without a vendor patch and facing the much more difficult choice of replacing or isolating equipment that still needed to operate. The fridge needs to keep running, after all!
We’re only a little over a week into PHP2Shell, so it’s too early to tell how much of the remaining seemingly unpatched population will eventually respond.
What interests me in the meantime is how much of an operator’s ability to respond to PHP2Shell was determined long before PHP2Shell and will remain the same for the next PHP2Shell. Some already had the processes in place to deploy fixes almost immediately. Others could rely on vendors with more hands-on support for older software. And some may still be trying to plan a major migration, or have no clear path to a fix at all.
Those differences seem worth paying a lot more attention to.
How do we make this easier?
This brings us back to the fun topic of the Vulnpocalypse. Whether or not AI dramatically accelerates vulnerability discovery and exploitation, the window that defenders have to respond after a disclosure will probably continue to shrink. Frankly, that trend began before AI, as automation became cheaper and attacker tactics evolved.
But I don’t think this fundamentally changes what defenders need to do. They still need to know what they’re running, where it is, and be able to update it when something goes wrong.
What does desperately need to change is how difficult we make that last part.
I think there’s a greater role for software manufacturers here. Making software easy to upgrade should be treated as a security feature in itself, not just an operational convenience. That means providing reliable migration paths, backward compatibility where possible, and designing products so customers can apply security updates without risking major disruption to the applications that depend on them.
Also: more and more, “update” is no longer a viable remediation path for some systems, and we can’t assume remediation will always mean applying a patch, or that a patch will always be enough. The need becomes even clearer for software embedded in systems expected to remain operational for decades. The actual lifespan of a piece of infrastructure and the period during which its software receives security updates aren’t always aligned.
This is going to become even more of a conversation as AI lowers the barrier for anyone to develop and release software. As we discussed in the State of the Internet Report, a good deal of the emerging AI technologies we observe exposed on the Internet are hobbyist projects created by lone developers, rather than products built for enterprise use. Yet these tools find their way into enterprise environments without proper controls (a phenomenon often called “shadow AI”). This isn’t surprising – these projects are experimenting with new and exciting technologies! But what responsibility do developers have to secure and maintain software they release publicly to the world, even if it is a passion project, particularly as it becomes so much easier to build and distribute? Is it their responsibility at all? I would say so, since there are increasingly more tools available to do that work.
There’s an interesting opportunity here for the same technology that’s generating so much anxiety about the future of vulnerability discovery. Could we leverage AI to just make software maintenance cheaper and easier? We already see one-off examples of this use case: helping developers understand legacy codebases, update dependencies, generate compatibility tests, and migrate applications onto supported platforms. None of this eliminates the need for testing or human oversight, and of course isn’t a one and done solution, but reducing the engineering effort involved could make a meaningful difference for systems that have been left behind.
Perhaps, then, instead of measuring only how quickly we can discover vulnerabilities or produce patches, we should also continue to pay more attention to how readily those patches can actually be deployed. This seems to be what actually matters in the end, because much of what determines an organization’s ability to respond to a critical vulnerability was decided long before that vulnerability was discovered – and long before AI ever entered this whole conversation. If updating a system requires months of engineering work, untangling years of dependencies, or replacing expensive physical equipment, the next emergency won’t suddenly make that work any easier.
Maybe the Vulnpocalypse really is coming, or already upon us. Maybe AI will make it trivially easy to discover and exploit vulnerabilities that would previously have gone unnoticed for decades. But where is the equivalent effort to make it easier to fix them? Doing so is one of the best things we can do to prepare.
To end: none of this is to downplay how difficult things already are for defenders. It has been a rough month. When multiple critical vulnerabilities drop one after another, people have to juggle an enormous amount of context-switching and coordination, and deal with real disruptions to their business and their lives. My optimistic take is that as the tools get better, so too will our ability to improve outcomes for defenders, bit by bit. Be kind to one another.
Download Censys’ 2026 State of the Internet Report for more research into the trends shaping the Internet. Our public PHP2Shell dashboard is still live and tracking the Internet’s patch response.
