AI has made breach close to certain for anything reachable from the internet. How far an attacker gets once inside is now the number that matters most.
Two security warnings came out this week that every leadership team should treat as a rehearsal. The first, called php2shell, is a pair of serious flaws in software that runs most of the world’s websites and a long list of business systems behind them. The second is a failure at eMudhra, one of the organizations the internet relies on to vouch that a website or service is genuine. Amazon reported this morning that exploitation attempts began October 17, four days before the patch, and that the flaws are now broadly exploited. That gives every company a short window to fix what it can and to answer a question that fixing can’t, which is how far an attacker could get if they broke into one of these systems tomorrow. That distance is your blast radius, meaning everything an attacker can reach from the first system they compromise. I’ll go deeper below on why knowing your blast radius as a fact, rather than a guess, matters so much. In this new cyber environment, it is THE metric every executive should demand and understand.
Why? A few weeks ago I wrote about why the physics of cyber changed. AI has made elite hacking cheap and widely available. I believe cyber has hit its AlphaGo moment. AlphaGo was the AI system that beat one of the world’s best Go players in 2016, and today no human can beat the best AI at Go or chess. There likely isn’t a hyper-skilled cyber expert alive who can outcompete an attacker armed with a top AI system in an offensive campaign. Attackers using AI don’t get tired or give up, and for a growing share of flaws the attack now arrives before the fix. This week is a useful example of what that looks like in practice. If you run a company or its technology, someone probably asked you this week whether you were exposed. For most organizations, the answer was that they didn’t know yet.
That answer, more than either flaw, is what this piece is about.
Why Flaws Keep Turning up in Software Everyone Has Already Tested
It’s fair to ask how a flaw this serious could still be sitting in PHP, which has been in use for about 30 years and examined by thousands of security researchers. The answer is that finding these flaws has always depended on a small number of people with rare skill and limited time. For twenty years, the scarcity of that talent did a large share of the world’s defensive work, and nobody paid for it. Software stayed safe less because it lacked flaws and more because there weren’t enough experts to find them all.
AI removed that limit. In April, Anthropic reported that during safety testing its Mythos model developed working exploits 181 times in a testing harness mimicking a Firefox 147 content process (without the browser's process sandbox or other defense-in-depth mitigations). Firefox is a browser scrutinized as closely as almost any software on earth. The previous generation of the same model found two. Nobody trained Mythos to hack. The skill appeared on its own as the model got better at writing and reasoning about code. Weeks later, a Chinese company released a model with nearly comparable capability that anyone can download and run, with no safety restrictions. Once a model is released that way, it can’t be called back.
I don’t know whether AI played any part in finding php2shell. What I do know is that software everyone considered well tested is now being reexamined by tools that are faster and more thorough than the people who tested it, and those tools are finding what the people missed. eMudhra makes the same point from a different direction. Its weak keys passed two independent audits over 18 months before one outside researcher noticed them. The checks we rely on are run by people, and people miss things.
Why Attacking Got So Easy
Finding a flaw is only half the work. Turning it into a working attack used to take a skilled person days or weeks. In the same testing, Mythos took a 17-year-old flaw in the FreeBSD operating system and built a working attack in about four hours with no human help. That work now costs roughly what the computing time costs, and that price keeps falling.
The effect is about numbers more than sophistication. The doors on your systems didn’t change. The number of people able to test every one of them did. Work that only a handful of intelligence agencies and elite researchers could do a few years ago is now available to anyone with intent and a credit card, and the elite are still out there too.
The clock changed with it. Companies have always counted on a window between the day a flaw is announced and the day attackers start using it, long enough to test and install a fix. That window is closing, and often it runs backward. The php2shell details leaking a day before the fix is an immediate example of this problem.
Why Anything Reachable from the Internet Will Eventually be Breached
Human attackers get tired, bored, or reassigned. That is why making things difficult used to work as a defense, because some share of attackers gave up. An AI system doesn’t give up. It runs around the clock, tries again after every failure, and has no opinion about the fact that attempt four hundred didn’t work.
Think about a lock that stops 999 out of 1,000 attempts. Against a burglar who tries a few times and moves on, that is an excellent lock. Against a machine that tries thousands of times a night, every night, it is a lock that will eventually open. Any protection that works most of the time will fail at some point when the attempts are effectively unlimited and nearly free. Anthropic published a clear demonstration of this. In a test, a malicious instruction told its Claude Code agent to read the cloud credentials stored on a computer and send them to an outside server, and the agent did it in 24 of 25 tries. The only thing that held was a hard boundary on what the agent was able to reach.
So for any system directly reachable from the internet, the realistic questions are when it will be breached and what the attacker can do next. The second question is where most companies are weakest. Attackers typically move from the first system they compromise to others in about 29 minutes. The average company takes 247 days to find and contain a breach. No amount of hiring closes the gap between 29 minutes and 247 days.
php2shell, a Flaw in the Software Behind Most Websites
PHP is a programming language most executives have never heard of, though nearly all of them use it every day. It is the software behind a website that handles the interactive parts, such as logging in, filling out a form or uploading a file. By one widely used count, it runs on roughly seven of every ten websites. It also reaches well beyond public websites. WordPress and Drupal sites run on it, so do many internal business applications, and it is built into the management screens of products companies buy from vendors, from network equipment to monitoring tools. Matt Snyder, who leads our security operations and threat research, put it to our team this way: “don’t think of this as a website problem.”
On October 21, the people who maintain PHP released fixes for two flaws rated 9.2 on a 10-point severity scale. Together they are known as php2shell, because they could let an outsider send a specially built request to a server and take control of it, running whatever commands they choose. Control of one server is the foothold an attacker needs for everything that follows.
Two details make this more urgent than a routine fix. The technical details leaked onto social media a day before the fix was released, so attackers had a head start. And older versions of PHP, which are still common, will never receive a fix at all. The Dutch National Cyber Security Centre has said it expects large-scale exploitation soon. With a flaw this widespread and a head start this long, I would plan as if working attacks are days away rather than months.
eMudhra, a Crack in how Computers Trust Each Other
Every time your browser connects to your bank, or one of your company’s systems connects to another, each side needs a way to confirm the other is genuine. The internet does this with digital certificates, which work much like passports. A small number of certificate authorities act as the passport offices. Every browser, phone, VPN and server carries a list of the offices it trusts, and it accepts any passport those offices issue.
eMudhra is one of those trusted offices, based in India. On October 18, a researcher reported that eight of its branch offices, known as intermediate certificates, had been set up in April 2025 with security keys an outsider could reproduce. Keys like these are supposed to be practically impossible to guess. The weakest had fewer possible combinations than a two-digit PIN. eMudhra shut the eight down the day after the report and says none was ever used to issue a certificate to a customer.
This matters because of what a branch office can do. Whoever reproduced one of those keys could issue a convincing passport for any website or service, whether a bank, a cloud provider or your company’s VPN, and any device that still trusted eMudhra would accept it without a warning. Using it requires the attacker to sit in the middle of someone’s connection. That sounds hard until you think about hotel or airport wifi, a hacked piece of network equipment inside a company, or a government that monitors traffic at its border.
The major web browsers blocked the eight certificates within a day. Everything else updates on its own schedule, and some of it never will. That includes VPN software, internal tools, the software packages development teams build and ship, and the devices on a factory floor or in a hospital.
Why These Two are a Lesson
Each one shows a different side of the new landscape. php2shell shows how large the target is. PHP is so common, and so often buried inside products a company didn’t build, that most organizations can’t list every place it runs. In our researchers’ experience, organizations that go looking find two to three times more PHP than they expected once they count vendor products and outside hosting. A company’s website can be fully up to date while the hosting provider’s PHP underneath it is years old. A company can’t fix what it can’t find, and the older versions will never be fixed at all.
eMudhra shows how deep the problem goes. The flaw wasn’t in anything a company built or bought. It was in the trust system underneath everything, it was checked by auditors, and it still sat there for 18 months. When the browsers were fixed, every other device that depends on certificates was left to catch up on its own. Much of the trust your business runs on is borrowed from outside providers, and you can inherit their failure without having had any say in the decisions that caused it.
Together they show why patching can’t be the whole strategy. Some of the exposure a company will never find, some it can’t fix, and some sits in systems it doesn’t control. The one thing a company fully controls is what each of its systems is allowed to reach, which determines how far an attacker gets once inside. That is the blast radius, and it is set by decisions a company can make before anything goes wrong.
We Saw This Pattern in March
In March, our teams and our customers were dealing with an active attack. A group known as TeamPCP broke into the account used to publish Trivy, a popular tool companies use to scan their own software for security flaws, and planted malicious code in it. The irony was that the most diligent companies, the ones scanning every piece of software they built, had the most exposure. Within days, the attackers used passwords and access keys stolen from those victims to break into other widely used software, including LiteLLM, which many companies use to connect their applications to AI models. Each step was funded by what they stole in the step before. In August, the Cloud Security Alliance estimated potential exposure at more than 2,100 organizations.
The customers who came through March cleanly didn’t do it by fixing things faster. One Fortune Global 500 customer took four internet addresses the attackers were using, listed in an advisory from our Threat Research Center, and added them to a single blocking rule. That rule took effect across their entire cloud environment at once, in every region, including the systems running LiteLLM. Their logs then showed infected systems trying to reach the attackers and failing. No passwords or keys left the company. The engineer who added the rule didn’t know what those addresses were connected to. He didn’t need to, because the architecture to enforce that rule everywhere was already in place.
What This Means for Strategy
Companies should still fix php2shell immediately. Fixing known flaws is basic hygiene. But when serious flaws arrive this often, and the attack sometimes arrives before the fix, fixing faster can’t be the whole plan. The plan also has to assume someone will eventually get in, and make sure they can’t get far. That protection doesn’t depend on knowing where every copy of PHP runs. If servers aren’t allowed to start conversations with the internet by default, and systems are separated so one can’t reach all the others, the rules cover the server nobody knew about as well as the ones on the list. An attacker who gets in will struggle to take control or carry anything out.
When prevention fails and detection is too slow, that design decides whether an incident stays small or becomes the kind of breach that reaches the board and the press.
Five Questions to Ask Your Team
Leading through this doesn’t require understanding the technical details. It requires asking the right questions and expecting clear answers. The first two questions are about this week, and they end once the fixes are in. The last three are about every week after, because they protect the systems that no list will ever fully capture.
Where do we run PHP, and who is responsible for each copy? This list drives the fix. It should include vendor products and outside hosting as well as the applications we built, and how long it takes to produce is useful information in itself. For eMudhra, the matching question is which of our systems check certificates outside a web browser, such as VPN software and internal tools, and whether each one has been updated. Expect both lists to be incomplete. The remaining questions are what cover the gaps.
What can’t we fix this week, and what are we doing about it instead? The order is fix it, protect it, or take it offline. Systems on old versions of PHP will never get a fix, so they need extra protection placed in front of them or they need to come off the internet.
Are any of our servers allowed to start conversations with the internet without a reason? Most servers have no business doing that, and a compromised server reaching out to the attacker is how the attacker takes control and moves data out. When the default is no for every server, the rule protects the ones nobody knew about along with the rest. Systems should also automatically block addresses known to belong to attackers. In March, many of our own customers hadn’t turned on the basic threat feed we provide for exactly this. The ones who had were blocking TeamPCP automatically.
If any one of our systems were taken over tonight, what else could it reach, and how do we know? This is the blast radius question, and the answer should come from evidence of how systems are actually connected rather than from a diagram or someone’s memory. Test systems shouldn’t be able to reach production systems, and older devices that will never be updated belong in their own separate area with tight rules. This matters for eMudhra too, because using those keys requires a position in the path of a connection, and inside the network is where most companies have the fewest controls.
Would we notice, and could we prove what was touched? The warning signs are servers starting programs they shouldn’t or reaching out to unfamiliar places. If the team sees them, the first step is to preserve the records before cleaning up. A company that limits what each system can reach, and keeps a record of every blocked attempt, can show exactly how far an attacker got. That shortens recovery, because the team rebuilds what was touched instead of everything that might have been.
What This Approach Does Not Do
Separating systems and controlling what they can reach won’t prevent the first break-in. It won’t fix PHP or repair a weak key, and it can’t stop misuse of a connection the company has already approved. What it does is limit how far a single compromise can spread, which is the one part of the problem a company can settle before anything goes wrong. Aviatrix builds this kind of protection, so weigh my view with that in mind. Most of the questions above can be answered with tools a company already owns.
Changing the Scorecard
Most security leaders I talk with are measured almost entirely on prevention, meaning how many flaws they closed and how fast. That work matters. But, in this world of the new physics of cyber, the better measure is blast radius, and whether an attacker who got in reached what they were after. If they got in and couldn’t get anywhere, the company won. For CEOs and boards, here is the question to bring to the next security review.
If one of our servers were taken over tomorrow through a flaw we didn’t know about, what could the attacker reach, and how do we know? If you want a quick read on how far a compromise could travel in your environment, our free Containment Assessment takes about five minutes.
References
Anthropic, “Claude Mythos Preview’s Cybersecurity Capabilities,” April 7, 2026, https://red.anthropic.com/2026/mythos-preview/
Anthropic, “How We Contain Claude Across Products,” May 25, 2026, https://www.anthropic.com/research/how-we-contain-claude
Aviatrix, “144 to 1: The Security Blind Spot in Cloud Environments,” https://aviatrix.ai/resources/144-to-1-security-blind-spot-in-cloud-environments/
Aviatrix, “The Containment Era: Beyond Detection-First Security,” https://aviatrix.ai/why-aviatrix/the-containment-era/
Aviatrix Threat Research Center, “Eight Certificates That Can Impersonate Anyone: The eMudhra Key Failure and Your Real Attack Surface,” Oct. 21, 2026, https://aviatrix.ai/threat-research-center/research-insights/emudhra-tls-cert-compromise-attack-surface/
Aviatrix Threat Research Center, “php2shell: Two Critical PHP RCEs, a Pre-Patch Leak, and the PHP You Didn’t Know You Had,” Oct. 21, 2026, https://aviatrix.ai/threat-research-center/research-insights/php2shell-two-critical-php-rces-a-pre-patch-leak-and-the-php-you-didnt-know-you-had/
Bleeping Computer, "Amazon says PHP2Shell exploitation began 4 days before patches," October 22, 2026, https://www.bleepingcomputer.com/news/security/amazon-says-php2shell-exploitation-began-4-days-before-patches/
Cloud Security Alliance, “TeamPCP’s LiteLLM Backdoor: New Data Shows 2,100+ Orgs Exposed,” Aug. 12, 2026, https://labs.cloudsecurityalliance.org/research/csa-research-note-litellm-trivy-supply-chain-compromise-2026/
CrowdStrike, “2026 CrowdStrike Global Threat Report: AI Accelerates Adversaries and Reshapes the Attack Surface,” Feb. 24, 2026, https://www.crowdstrike.com/en-us/press-releases/2026-crowdstrike-global-threat-report/
Cybersecurity Insiders, “Why the Physics of Cyber Changed,” Oct. 14, 2026, https://www.cybersecurity-insiders.com/why-the-physics-of-cyber-changed/
eMudhra, “Certificate Security Incident,” https://emudhra.com/en/post/certificate-security-incident
FBI, “FLASH-20260702-01: Cyber Criminal Group TeamPCP,” July 2, 2026, https://www.ic3.gov/CSA/2026/260702.pdf
Huntress, “Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities (CVE-2026-109618 & CVE-2026-109619),” Oct. 20, 2026, https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities
IBM, “Cost of a Data Breach Report 2026,” July 29, 2026, https://www.ibm.com/reports/data-breach
Jackalsyn, technical analysis of CVE-2026-109618 and CVE-2026-109619, Oct. 21, 2026, https://jackalsyn.com/posts/php-up-2026.html
NCSC-NL, “php2shell Vulnerabilities (CVE-2026-109618, CVE-2026-109619),” Oct. 21, 2026, https://github.com/NCSC-NL/php2shell
PHP, “News Archive - 2026,” https://www.php.net/archive/2026.php
SANS Institute, “When the Security Scanner Became the Weapon: Inside the TeamPCP Supply Chain Campaign,” March 25, 2026, https://www.sans.org/blog/when-security-scanner-became-weapon-inside-teampcp-supply-chain-campaign
Unit 42, “Weaponizing the Protectors: TeamPCP’s Multi-Stage Supply Chain Attack on Security Infrastructure,” March 31, 2026, https://unit42.paloaltonetworks.com/teampcp-supply-chain-attacks/
W3Techs, “Usage Statistics and Market Share of PHP for Websites, October 2026,” Oct. 21, 2026, https://w3techs.com/technologies/details/pl-php
Z.ai, “GLM-5.1,” https://huggingface.co/zai-org/GLM-5.1
Ready to see Aviatrix in action?
Get a personalized live demo walkthrough or explore our latest deep-dive cloud threat research intelligence.
Gartner Strategic Roadmap for Zero Trust Security Programs 2025 Report
Download and gain actionable insights to advance your cloud security strategy.
