"How a critical PHP vulnerability changed the way I think about internet infrastructure, shared dependencies, and the systems we depend on."
The Internet Doesn't Have a Single Off Switch
How a critical PHP vulnerability changed the way I think about internet infrastructure, shared dependencies, and the systems we depend on.
I had been seeing videos and discussions about the internet breaking.
And I found myself asking a much more basic question:
"how do you even break the internet? Does it have a source? is there some box out there running the internet?"
I wasn't necessarily asking about a particular vulnerability. I wanted to understand what the internet actually depends on.
Is there a single source? A central machine? Some underlying infrastructure that, if compromised, could bring everything down?
I contemplated this the rest of the day. The next day, I came across information about PHP and its importance to a significant portion of the web.
My reaction was essentially:
"Ohhhh, wow."
The connection stood out to me because I had been thinking about the internet as something abstract, almost invisible, and then encountered a concrete piece of software infrastructure that helped make the question less abstract.
But the more I investigated, the more I realized that the question itself needed to change.
The internet isn't one machine. It isn't one application. And it certainly isn't one giant server sitting somewhere waiting to be switched off.
However, that doesn't mean it is immune to widespread disruption.
In fact, understanding why it isn't centralized also helps explain how vulnerabilities in widely deployed components can have consequences far beyond the individual application in which they exist.
1. First, what exactly is the internet?
We use the terms "internet" and "web" almost interchangeably, but they aren't the same thing.
The internet is the underlying global network of interconnected networks. It allows devices and systems to communicate using shared protocols and standards.
The World Wide Web is one of the services built on top of that infrastructure.
Websites, browsers, web applications, and content management systems operate within this larger environment.
The distinction matters.
You can have a functioning internet while individual websites are unavailable. You can also have a website operationally intact while a DNS provider, hosting provider, or another dependency prevents users from reaching it.
According to the Internet Society, the internet consists of tens of thousands of interconnected networks operated by service providers, companies, universities, governments, and other organizations.
There isn't one organization operating every part of it.
That distributed structure is one of its greatest strengths.
It also means that failures can occur at different layers without necessarily affecting the entire network.
This was my first important distinction:
The internet doesn't need one central point of failure to experience widespread disruption.
It only needs dependencies that are widely shared enough for a failure in one component to affect many otherwise independent systems.
2. The layers beneath an ordinary website
Let's bring this down to something more familiar.
Imagine opening a website.
You enter a domain name, your browser attempts to resolve it, your device establishes a connection, and a server eventually processes your request.
What happens behind that experience can involve several independent systems:
- DNS resolution.
- Network routing and connectivity.
- CDN or reverse proxy infrastructure.
- Load balancers and web servers.
- Server-side application runtimes.
- Application frameworks and dependencies.
- Databases and storage.
- Authentication, credentials, and external services.
These components don't necessarily exist on one machine or belong to one organization.
A website might use one provider for DNS, another for hosting, a third for its CDN, and several external services for authentication, analytics, payments, and other functions.
The user sees one website.
The actual system is a collection of dependencies communicating with one another.
This is where I started becoming more interested in the architecture itself.
Because when something goes wrong, the visible application isn't necessarily where the problem originated.
A website might be perfectly fine at the application level, but if one of its underlying dependencies is unavailable or compromised, the experience changes.
This is also why understanding the dependencies of a system matters just as much as understanding its visible functionality.
3. PHP: A concrete example of shared dependency risk
Now, this is where the original question became much more interesting.
PHP is a server-side programming language used to power websites and web applications.
It is present in many different environments, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed.
It isn't the internet itself.
It doesn't control global network routing, DNS, or the physical infrastructure connecting networks.
But it is a widely deployed component within the web ecosystem.
And that distinction matters when a vulnerability affects the runtime itself rather than an individual application.
On October 21, 2026, the PHP development team published an emergency security announcement addressing two critical remote code execution vulnerabilities.
The vulnerabilities were:
- CVE-2026-109618: Remote code execution through out-of-memory handling and memory corruption.
- CVE-2026-109619: Remote code execution involving stale global state and previously freed request memory.
Both vulnerabilities received a CVSS v4.0 score of 9.2.
The PHP team explicitly warned that unauthenticated remote code execution could be possible under affected conditions.
Sources:
- PHP Official Security Announcement
- Google Cloud: Responding to Critical PHP Vulnerabilities
- ENISA: Joint Statement on Critical PHP Vulnerabilities
What makes this particularly interesting is that the vulnerabilities existed in the PHP runtime itself.
They weren't simply flaws in a particular WordPress plugin or an individual website's custom code.
The problem existed at a lower layer of the software stack.
That changes the scope of the investigation.
Instead of asking which individual application contains a vulnerability, administrators need to identify which applications, servers, containers, and services depend on affected PHP installations.
What was actually affected?
The PHP security announcement identified affected versions extending from PHP 5.4 through PHP 8.5.11.
The official fixed releases included:
| PHP branch | Fixed version |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
Older branches require particular attention because they may no longer receive normal upstream security releases. Distribution maintainers and long-term support vendors may provide backported fixes.
Another important detail: PHP identified mod_php as the highest-risk deployment configuration because a demonstrated exploit could trigger the issue before application-level code executed.
This is an important reminder that application-level protections cannot automatically compensate for a vulnerable runtime underneath them.
The security of an application is also influenced by the security of the environment executing it.
4. When a shared dependency becomes a shared risk
This is the part I find particularly important.
Imagine hundreds or thousands of independent websites using the same underlying software component.
Each website might have its own owner, hosting provider, database, framework, and security configuration.
They are independent applications.
But they share a dependency.
If that dependency contains a serious vulnerability, the impact can extend across multiple otherwise unrelated environments.
This is what I would describe as a shared dependency risk.
It isn't necessarily a centralized failure.
It is a common-mode failure: different systems can experience similar consequences because they depend on the same vulnerable component.
There is a difference between:
- One website being compromised.
- Multiple websites using the same vulnerable software being exposed.
- An entire hosting provider experiencing an incident.
- A widespread disruption affecting an underlying infrastructure provider.
These are different levels of impact.
They shouldn't be treated as interchangeable.
For example, a vulnerability in PHP doesn't automatically mean every PHP website was compromised.
Exposure depends on the affected version, runtime configuration, accessibility, and exploitation conditions.
Nor does remote code execution in a PHP worker automatically mean an attacker has root access to the underlying operating system.
The privileges and boundaries of the affected process still matter.
But the potential reach is significant enough that the issue cannot be treated as an isolated application problem.
The problem with dependency visibility
One challenge is that organizations don't always know everything their systems depend on.
A company might know that it operates a website.
It might not immediately know:
- Which PHP version is running.
- Whether PHP is bundled inside another product.
- Whether a container image contains an affected runtime.
- Whether a hosting provider manages the installation.
- Whether an application includes an outdated dependency.
- Whether the same runtime exists across development, staging, and production.
This is where asset inventory and software dependency management become important.
You cannot reliably secure what you haven't identified.
The NCSC-NL PHP2Shell tracking repository is particularly useful here because it tracks software products and their relationship to the affected PHP vulnerabilities.
It demonstrates how a vulnerability in one underlying component can require investigation across a much larger software ecosystem.
5. The incidents weren't necessarily one incident
During the same period, I was also looking into discussions about API-key exposure, AI model distillation, coding agents, and software replication.
Some of the reporting described unauthorized API usage, potential financial losses, and the collection of model outputs.
These are interesting developments, especially when considered alongside the increasing accessibility of AI-assisted software development.
However, I want to make an important distinction.
A PHP vulnerability, a stolen API key, and a model-distillation operation are not automatically parts of the same attack.
They represent different technical problems and require different evidence.
For example, consider an exposed API key.
Depending on its permissions, that key might allow someone to:
- Consume paid compute resources.
- Access application data.
- Interact with external services.
- Perform actions under the identity of the application that owns it.
But even if a stolen key is used to query an AI model, that alone doesn't establish that the outputs were collected for training another model.
There are separate stages:
- Credential compromise.
- Unauthorized API access.
- Collection of model outputs.
- Potential use of those outputs for training.
- Deployment of a resulting model.
Evidence of one stage does not automatically prove the others.
I think this distinction is important because cybersecurity reporting can become misleading when several developments are compressed into one dramatic narrative.
The connections are worth investigating.
But the evidence still matters.
Sources for the broader security context:
6. What happened after disclosure?
The PHP vulnerabilities were not simply theoretical issues that administrators could leave for another maintenance cycle.
On October 26, 2026, CISA added both CVEs to its Known Exploited Vulnerabilities catalog.
Subsequent reporting documented successful exploitation in the wild.
The Canadian Centre for Cyber Security also updated its advisory to reflect exploitation reporting and recommended immediate remediation.
This is important because the security response changed as new evidence became available.
An initial vulnerability disclosure establishes that a weakness exists.
A proof of concept demonstrates that an exploitation technique may work.
Confirmed exploitation in the wild provides evidence that attackers have successfully used the vulnerability against real systems.
Those are different stages of a security incident.
By November 9, the NCSC-NL operational tracking repository continued updating its affected-product inventory, including vulnerable, fixed, and still-investigated products.
That is a useful example of why vulnerability response doesn't end when the initial patch is released.
Organizations still need to identify where the affected component exists, determine whether their particular deployment was exposed, apply the appropriate fix, and investigate potential compromise.
Sources:
- Canadian Centre for Cyber Security — PHP2Shell Advisory
- CISA Known Exploited Vulnerabilities Catalog
- NCSC-NL — PHP2Shell Operational Information
7. What should developers and administrators take away from this?
I don't think the answer is to panic every time a critical vulnerability appears.
The answer is to understand what your systems actually depend on.
For developers and administrators, there are several practical considerations.
Know your runtime
Identify the actual PHP version running in your environment.
Don't assume that the version installed on your local development machine is the same version running in production.
Check hosting environments, containers, managed services, and third-party products.
Keep dependencies updated
Follow official security advisories rather than relying exclusively on social media discussions.
For PHP2Shell, use the appropriate fixed release or a verified vendor package containing the security fix.
Understand your execution boundaries
Remote code execution is serious, but the privileges available to the compromised process still matter.
Avoid running web applications with unnecessary administrative privileges.
Separate services and environments where possible.
Protect credentials
API keys and other secrets should not be embedded in public repositories, frontend bundles, screenshots, or application logs.
Use secret stores, least-privilege permissions, credential rotation, and usage monitoring.
Monitor what happens after patching
Applying a patch doesn't establish that a system was never compromised.
Review relevant logs, unexpected processes, outbound connections, authentication events, and application behavior.
The Canadian Centre for Cyber Security advisory provides additional remediation and monitoring guidance.
8. The question changed for me
I started with a relatively simple question.
How do you break the internet?
Is there a source? Is there a box somewhere?
What I found was something much more interesting.
The internet is not one system that can simply be switched off. It is a collection of independently operated networks, infrastructure, protocols, software, and services that depend on one another to function.
But independence doesn't mean isolation.
A system can be independently operated and still depend on the same software, infrastructure provider, library, or authentication service as thousands of others.
And that is where the real complexity begins.
A vulnerability doesn't need to affect the entire internet to have an enormous impact.
It can affect one shared component, and that component can exist inside countless independent systems.
The more I looked into these developments, the more I became interested in the architecture beneath the headlines.
Not just what happened, but why it happened.
Not just which vulnerability was discovered, but where the vulnerable component sits, what depends on it, and what boundaries exist when something goes wrong.
I think that distinction becomes even more important as AI makes software development, reverse engineering, and automation increasingly accessible.
Building something is becoming easier.
Understanding everything that something depends on is another matter entirely.
And securing it is another matter again.
The internet doesn't have a single off switch. But the systems we build on top of it can share weaknesses that we don't always recognize until something goes wrong.
That is the part worth understanding.
References and further reading
The following sources were used to develop the technical context of this article.
Internet Society — How the Internet Works — Internet architecture and decentralized network structure.
PHP — Official 2026 News Archive — Official security releases, vulnerability identifiers, and fixed PHP versions.
Google Cloud — Responding to Critical PHP Vulnerabilities — Technical explanation and research context for PHP2Shell.
ENISA — Joint Statement on Critical PHP Vulnerabilities — European cybersecurity authorities' response.
Canadian Centre for Cyber Security — PHP2Shell Advisory — Affected configurations, exploitation updates, and remediation recommendations.
Jamaica Cyber Incident Response Team — PHP Remote Code Execution Alert — Local cybersecurity advisory and recommendations for PHP-based environments.
NCSC-NL — PHP2Shell Operational Repository — Continuously updated software inventory and operational information.
Microsoft Security Response Center — Patch Now — Broader discussion of shared software dependencies and coordinated security response.
This article is an independent research and awareness publication. It does not claim that the author independently discovered, reproduced, or exploited the vulnerabilities discussed. Technical information and remediation should be checked against current vendor advisories.
More of My Work
The Projection Engine is part of a larger body of experiments around AI, cybersecurity, creativity, and personal systems.
The whole library: TagzAuthor
Support the work: ko-fi.com/tagzauthor
Top comments (0)