Every Chief Information Security Officer has had this week before. A critical flaw is disclosed just as operations is getting ready to lock down production for the seasonal change freeze, right when nothing in production is supposed to change. Just recently, that difficult scenario happened three times in five days, in three different layers of the stack. All three incidents point at the same conclusion: patching cannot be the control that decides whether an intrusion becomes a breach.
Three incidents in one week
The web layer: On October 20, details of two critical remote code execution flaws in PHP (CVE-2026-109618 and CVE-2026-109619) leaked a day ahead of the planned disclosure, along with proof-of-concept exploit code. Researchers named the pair php2shell. PHP shipped fixes on October 21. The same day, the security firm watchTowr saw the flaws exploited against its honeypots, decoy servers set up to attract attackers. By W3Techs’ count on October 22, PHP runs 69.3 percent of the websites whose server-side language is known. The Dutch National Cyber Security Centre (NCSC-NL) told organizations that could not patch quickly to consider taking exposed systems offline.
The trust layer: On October 17, a researcher reported that the private keys behind eight eMudhra intermediate certificate authority certificates were so weak that anyone could compute them from the public certificates. A certificate authority is one of the organizations that browsers trust to vouch for websites. With those keys, an attacker could create a trusted certificate for any website and present it to any client that still trusted the chain. Chrome blocked the certificates within two hours, and Firefox within three. eMudhra revoked them within two days and said the researcher may have used AI-assisted techniques. Security researcher Scott Helme then recovered all eight keys on a laptop in under a second, and an AI agent did the same from a single prompt. The browsers were the easy part. Go binaries, Python services, Node.js applications, Linux trust stores, the lists of authorities a system trusts, and the containers built on them keep trusting a chain until someone rebuilds them.
The AI layer: On October 21, LiteLLM 1.107.0 went out on the Python Package Index and Docker Hub with a credential stealer and a remote code loader inside. LiteLLM is an open-source gateway many enterprises use to route application traffic to large language models. The attackers held stolen GitHub credentials for three of the project’s developers. They used one to change the release process and force it through, a second to approve the release and a third to delete the records of what they had done. The malicious code ran every time Python started. It collected cloud credentials, the keys used to call AI models, private keys and environment variables, and sent them to a domain the attackers controlled. Then it checked every hour for more code to run. The project’s own incident report said that anyone who installed 1.107.0 on a host with outbound internet access should assume the data left. It was LiteLLM’s second compromise this year.
Why patching cannot decide the outcome
For decades the standard practice has been to detect, then patch. That only works if disclosure comes before exploitation and a fix can be tested and rolled out in the gap between the two. Last week the PHP exploit details leaked before the patch existed, and the LiteLLM backdoor arrived as the update, through the trusted channel.
Qualys’s Threat Research Unit went through more than 1 billion remediation records from 10,000 organizations, covering 2022 to 2025. Organizations closed roughly 6.5 times more vulnerabilities over that period, yet the share of critical vulnerabilities still open at day seven rose from 56 percent to 63 percent. More effort produced a worse outcome. In its M-Trends 2026 report, Google Cloud’s Mandiant team put the mean time to exploit at an estimated minus 7 days. Exploitation now routinely begins before a patch exists. AI widens that gap. An AI agent recovered the eMudhra keys from one prompt. The same tools that help a security team work through its alerts help an attacker find flaws and turn them into working attacks. They do it faster than any change advisory board can meet.
None of this makes patching optional. It still reduces the number of ways in and shortens how long an intruder stays. It just cannot be the control that decides the outcome anymore. If a workload is going to be compromised sooner or later, the question that matters is what that workload can reach.
The architectural answer
The answer is containment. Containment is the enforcement of an explicit communication policy at every workload, governing what it can reach and what can reach it, by workload identity and protocol, on every path available to it, whether or not a compromise has been detected. That last clause is the point. A web runtime that can reach only the few destinations and database identities it needs has a small Blast Radius, the set of things a compromised workload can still reach. That holds whether or not a Security Operations Center has noticed anything. The LiteLLM stealer needed only an outbound path to a domain nobody had approved. Default-deny outbound at the workload, a policy under which a workload may reach only the destinations it is allowed, would have blocked that connection. Nothing would have been stolen and no further code loaded.
The industry has known this for years and still runs most production environments without it. Every security leader has a zero trust strategy, the principle that no connection is trusted by default. Very few have zero trust workloads. The architecture was never what stopped them. Enforcing policy at every workload has been possible for years. The policy stopped them, for three reasons.
First, fear of breaking production. Platform and site reliability teams have watched a strict firewall rule take down billing or cut off a payment integration. They paid for that outage in a way they never paid for a possible breach. Put a certain outage next to a possible breach and uptime wins every time. Second, no fast way back. When a rule is wrong, the team needs to undo it in one step, not open a change ticket. Third, nobody can keep the policy current. Default deny needs an allow-list for every workload, the list of destinations and peers each one is permitted to reach, and nobody holds that knowledge in one place. The list goes stale the day after it is written, so it becomes a backlog of firewall rules that a person maintains by hand. The job of security leadership is to remove all three reasons, so nobody has to make that trade.
What makes default deny deployable
Monitor before enforcing. A policy needs to run against live traffic before it blocks a single connection. That means a monitor mode that shows exactly which connections a rule would have blocked, over days or weeks. It also means a way to back the rule out in one action once it is enforced. A rule set that has run alongside billing traffic for two weeks without a false positive is one a platform team will sign off on. One that has not is a risk the team cannot measure, and they are right to refuse it.
Workload identity on every path, not an address at a single inspection point. Containers, serverless functions and AI agents change addresses by the hour. A central hub firewall never sees the traffic between workloads that does not pass through it. It cannot tell a compromised workload from a healthy one when both sit in the same address range. The policy has to follow the workload and the protocol it speaks, on every path available to it, including the ones that never touch the hub.
A policy that keeps itself current. A policy written from the configuration management database is stale the moment a pipeline deploys. This is the capability missing from most products today, and it has three jobs. The first job is to know the estate, meaning every workload and network the organization runs. That model has to be built from the estate itself, its applications, environments and owners, with no tagging project and no inventory to import. The second job is to write and prove the allow-list. The environment has to watch what each workload actually talks to and draft the policy each application needs. It then runs that policy in monitor mode on live traffic and shows exactly what would have been denied before anything is. People then review and approve the policy. They do not have to write it from nothing. The third job is to keep it current. Every deploy and every new AI agent changes the list, so the policy has to change with it, with people approving the changes rather than writing them. That is what removes the backlog of firewall rules a team otherwise maintains by hand.
The guardrails matter as much as the automation. Everything the system writes should be standard policy a person can read, change or back out in one action. It should never touch a rule a person wrote. When the evidence is weak it should ask a person rather than guess. The rule in one sentence is that nothing is denied that was not observed, judged and tested in monitor mode first.
What to ask for
The next incident will arrive the way one of last week’s did. Ahead of the fix, inside the fix, or in a trust chain that half the estate has no way to revoke. Vendors who sell infrastructure and security owe their customers containment that can be turned on without an outage, and buyers should ask for it in four terms. Policies that can be watched before they are enforced and backed out in one action. Enforcement tied to workload identity on every path. A policy drafted and proven from the organization’s own traffic rather than written from nothing. And a policy that stays current as the estate changes, without a person maintaining the rule backlog by hand.
The same class of tools that recovered the eMudhra keys from one prompt is now being put to work on the defender’s side. It drafts and proves the policy that contains the next intrusion. Get that in place and patching goes back to being what it should have been all along, methodical work on the organization’s own schedule. It runs behind a layer that holds whether or not anyone has spotted the exploit yet.
About the author
Willie Tejada is Senior Vice President and General Manager, Cloud Native Security Fabric, at Aviatrix, the network containment company. He leads Aviatrix’s security business. He writes on containment, default deny and the operating discipline that lets security teams enforce policy at every workload without breaking production.
