In the span of a few days, we saw PHP2Shell, a set of critical remote code execution vulnerabilities in core PHP itself. That’s not in an application built on PHP, but in the engine that powers roughly 70% of the websites on the internet. Every PHP version released in the last decade was affected. We saw a GitLab RCE with a CVSS score of 10.0 that let an unauthenticated attacker run arbitrary code on a GitLab server, the development platform that over 30 million users and more than half the Fortune 100 rely on. And we saw the eMudhra certificate authority disaster, where eight intermediate CA private keys were so weak they could be reverse-engineered, potentially allowing anyone to forge trusted TLS certificates for any domain.
Three different types of failure at three different layers of the stack. All in one week. And the thing is, security just looks like it broke this week. Actually, it exposed what has been broken for a long time.
The Traditional Process Was Already Broken
In the era of mostly AI-built software, the traditional vulnerability management process is going to have a hard time keeping up if it still involves someone reading an advisory, assigning a severity, opening a ticket, and waiting for the next maintenance window to apply a patch. That process was already struggling before the “vulnpocolypse.”
And the data backs this up. The 2026 Verizon DBIR reported only 26% of critical vulnerabilities (defined as those appearing in CISA’s Known Exploited Vulnerabilities catalog) were fully remediated by organizations in 2025. That’s a steep drop from 38% the prior year. We can assume AI is participating in this widening gap.
To top it off, for the first time in the report history, software vulnerability exploitation has overtaken credential abuse as the number one initial access vector for breaches. It now accounts for 31% of confirmed incidents, up from 20% the year prior.
What can be done about all this risk? The answer has traditionally been patching, and typically with a very manual process involved. It’s clear that strategy doesn’t stand a chance in the era of AI-assisted development.
You Will Always Have a Window of Exposure
You can’t count on keeping every system perfectly patched all the time. There will always be a window of exposure. So one of the most important things organizations can do is build systems that are resilient to individual components being compromised. If you compartmentalize authorization, network access, services, and data, then a remote code execution vulnerability in one service doesn’t automatically give an attacker access to everything else. That doesn’t mean you can ignore critical patches, but it does give you some breathing room and greatly reduces the consequences of getting caught with an unpatched system. I call this resilience by design.
Know What You Have and Where You’re Exposed
The other big opportunity is getting much better at knowing what you have and where you’re exposed. Asset inventory and attack surface discovery have improved considerably. Organizations should be able to quickly determine whether they’re running vulnerable software, where it is, whether it’s reachable by attackers, and what an attacker could access if they exploited it. Combine that with intelligence about which vulnerabilities are actually being exploited, and you can make much smarter decisions than simply patching everything with a critical CVSS score in the order it was announced.
Operational Reliability Is Security
There’s a connection between security and operational reliability. One reason organizations are slow to patch is that they’re afraid of breaking production systems. If you’ve invested in automated testing, staged deployments, rapid rollbacks, and reliable recovery of systems and data, you can deploy security fixes much more aggressively. You don’t need weeks of testing for every change if you have confidence that you can detect a problem quickly and recover. Getting better at deploying software safely is one of the best things you can do to improve security.
The Trust Problem
The GitLab and eMudhra incidents also remind us that some components carry an enormous amount of trust. A compromised development platform can potentially affect everything you build and deploy. A compromised certificate authority can undermine trust in systems that are otherwise completely patched. We need to think carefully about where we’ve concentrated privilege and trust, and what happens when those assumptions fail.
This is why the conversation around software trust (provenance, continuous verification, autonomous remediation, governance, and attestation) matters more now than ever. If you’re interested in going deeper on what a real trust framework looks like in practice, we wrote about that here.
The Path Forward
We are not going to solve the “vulnpocolypse” by hiring enough people to triage every new vulnerability. We have to engineer systems that are easier to understand, harder to compromise broadly, and faster to fix. The rate at which vulnerabilities are discovered and software changes is not going to slow down. Our security architecture and operational practices have to catch up.
That means:
- Architect for resilience. Compartmentalize so a single compromise doesn’t cascade. Make blast radius a design constraint, not an afterthought.
- Know your exposure. Invest in asset inventory and attack surface discovery. Prioritize based on real risk, not CVSS scores alone.
- Build deployment confidence. Automated testing, staged rollouts, rapid rollback. The faster you can safely deploy, the faster you can secure.
- Examine your trust concentrations. Identify the components where compromise would be catastrophic. Reduce single points of trust where you can; monitor them relentlessly where you can’t.
In 1998, we told the Senate the bar was too low. In 2026, the bar hasn’t moved fast enough, but the pressure on it has. The week security broke wasn’t a fluke. It was a preview. The question isn’t whether another week like this will come. It’s whether your architecture will be ready for it.
