Imagine a call coming in during the small hours of the night. Within the hour, the on-call security team has confirmed the worst: a widely shared weakness in a programming language that underpins about 70% of the world's websites, with no way to predict how far the disruption would spread.
Now imagine what made it worse. Not the downtime itself, but the moment an engineer pulls up their dependency map and realizes the document they used to claim they understood their own software stack was missing most of the picture.
The 70 percent was never the real lesson
The headline stuck because it was a big number. Seventy percent of the world's websites run on PHP, two critical vulnerabilities surfaced in it, and governments and companies pulled their websites off the internet before they could be attacked and so they could patch the fault. But the 70 percent said less about how catastrophic a single bug could be than about how much of the modern internet is built on shared, unreviewed code.
Security experts said the risk was particularly acute for small websites run by individuals or organizations with limited technical resources, often on shared hosting services where customers do not directly manage the underlying servers. Such sites could take longer to patch and remain exposed well after fixes became available.
For a business operator, the lesson is not to panic about the next flaw. It is that your exposure stays largely invisible until you have mapped the code beneath your products, and most people have simply not done the work.
Your dependency map is probably a fantasy
Most companies can draw a rough picture of their stack. The front-end framework, the database, the two or three platforms that power the website, plus the marketing tool and the analytics dashboard.
The real map is far messier, and far larger.
Those frameworks pull in libraries, those libraries pull in more libraries, and beneath much of that stack sits the shared code at the center of this episode: PHP, a programming language that underpins about 70% of the world's websites, whose flaws forced operators to take sites offline as a precaution while patches were applied. The chain is not a neat tree you can trace with a pencil. It is a tangled graph, and most of it lives outside the company that built your product, outside the people who wrote the code, and outside the teams that sign off on security.
Transitive dependencies are the hidden exposure
The problem is transitive dependency: the things your software depends on, that depend on other things. You may have cleaned up the first layer. The second and third layers were installed automatically, quietly, and forever.
This is why a flaw can spread so far. The people who shipped the upstream component never knew how far down the chain it would end up, and the people who built on top of it had no idea it was there.
Your product is likely in that hidden chain too, sitting a level or two below something someone else already knew about.
Start with the systems that make money
Before you can audit your exposure, you have to know which systems matter. Start with revenue. If the tool that processes your payments, books your deals, or delivers your product went down for a week, would the company keep making money or hemorrh it?
Those are the systems you cannot afford to take for granted. They are also the systems most likely to lean on shared components you cannot see.
Make a short list of three or maybe five, then ask a harder question about each. Who actually controls the code that makes this work, and what happens when that code is not yours to fix?
Build a real bill of materials
A Software Bill of Materials, or SBOM, is a parts list for your software. It names every component plus the version, so you can see exactly what you are running instead of guessing.
The goal is to answer a simple question fast: when a new flaw is published, can you look at your SBOM and know within an hour whether you are affected?
This is harder than it sounds, because you need the transitive chain, not just the components you added on purpose. That is the whole point of the morning sites went dark. The bad code was never added deliberately. It had been present in PHP for roughly 20 years, and nobody had treated it as a live threat until researchers showed it could be exploited.
Hold your vendors to the shared component
When you find that a revenue system depends on a component you do not control, you face a real decision. You cannot patch it. You cannot ship a fix. Someone else owns that code, on their schedule.
This is where procurement and legal matter. Shared components are exactly the thing vendors quietly underwrite, because the downside looks like everyone else's problem. The contract is where you force the issue: require disclosure when an upstream component is affected, require a response SLA tied to your exposure, and make the vendor responsible for the part of the stack you never asked about.
If a vendor's sales deck promises uptime while their security appendix treats third-party libraries as out of scope, that gap is your risk, and it stays your risk until the contract says otherwise.
Plan for the outage you cannot prevent
Even with a perfect SBOM and ironclad contracts, some of your business will still rest on software you do not control. You cannot patch that away.
So the practical question becomes resilience. Can your revenue-critical systems survive a week where the shared component is degraded or gone? Do you have a manual fallback, and can you keep serving customers if the thing you depend on stops working?
The hardest part of any such morning is whatever you have not built for. The organizations that handle the next one are the ones who assume they are exposed and decide what they would do anyway.
How much of your business actually rests on software you don't control
Here is the honest answer. More than you currently know, because you have not measured it, and probably more than you would want to admit.
The systems your revenue depends on are very likely standing on shared components you cannot see and cannot fix. You cannot quote a percentage until you map them, and the default assumption should be that your exposure is real and significant, not negligible.
This is a solvable problem. Map the code beneath your revenue systems, build a real parts list, hold your vendors accountable for the stack they never told you about, and plan for the outage you cannot prevent.
Until then, a significant portion of your business still rests on software you do not control, on someone else's schedule, with someone else's patch. The only way to turn that into a number you can manage is to start the audit while you still can.
Updated October 30, 2026: We reviewed this article against its sources and corrected statements they did not support.
Sources
- Websites across world hit by millions of attempts to exploit PHP code flaw (The Guardian, 2026-10-22)
- PHP: The three letters that shut down sites all over the internet today (The Verge, 2026-10-21)
- Government websites go dark as software flaw sparks security scramble (CNBC, 2026-10-21)