PHP usually stays out of sight. It runs on web servers, helping websites build pages, process requests, and connect to databases. Most visitors never know whether a site uses it. Many site owners do not manage the PHP installation themselves.
That changed on October 21, when PHP’s maintainers released emergency updates for two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619. Under certain conditions, an unauthenticated attacker could use either flaw to execute code on a vulnerable server. In practical terms, that could give an attacker control over a website or access to data on its server. (PHP security advisory; ENISA joint statement)
The flaws were rated 9.2 out of 10 on the CVSS severity scale. European cybersecurity agencies urged organizations to identify systems running PHP, apply the fixes, and isolate exposed applications if they could not update promptly. Some public websites were taken offline while their operators worked to secure them. (ENISA; Reuters)
The phrase “the whole internet is compromised” goes too far. A vulnerability does not mean every website has been hacked. These flaws affect systems running vulnerable PHP versions; attackers still need to reach and exploit an affected server. But PHP is common enough that one defect in its core can put a very large number of systems in the same race to patch.
Reuters, citing the technology tracker W3Techs, reported that PHP runs on nearly 70% of websites whose server-side programming language can be identified. That figure describes how widespread PHP is. It does not mean that 70% of websites are vulnerable, exposed, or compromised. (Reuters)
The problem is bigger than a single website
A vulnerability in a programming language has a different reach from a flaw in one application. Many separate websites and products may depend on the same underlying software. A site can be affected even if its owner has never heard of PHP, because the language may be bundled into a platform, content system, or hosting service.
That dependency also complicates the response. A company may know which website it owns but not which PHP version runs behind it. On shared hosting, the provider may control the server and apply its own updates. Products that include PHP as a component may need a separate fix from their vendor. European authorities specifically advised organizations to check with hosting and service providers, and to look for PHP in software that does not appear to use it directly. (ENISA)
The PHP team has released fixed versions: 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The team says that installing an update is the only complete fix. For older versions, server operators should check whether their Linux distribution, long-term support vendor, or hosting provider supplies a patched package. (PHP security advisory)
A shared foundation creates shared risk
The incident is a reminder that the internet is not a single system with one owner and one control room. It is a collection of networks, servers, applications, and services built on shared components. Those components make it possible for millions of websites to operate without each one reinventing the tools beneath them.
That arrangement brings efficiency. It also concentrates risk. When a widely used component has a serious flaw, many organizations must act at once, even when they have different budgets, technical teams, and levels of visibility into their own systems.
The answer is not to expect every website owner to understand every layer of software. It is to make responsibility clear. Hosting providers need to identify affected customers and patch the systems they manage. Software vendors need to update products that bundle PHP. Site owners need to know who maintains their server and how to confirm that a security update has been applied.
Users should also be cautious about interpreting an alarming headline as proof that their personal accounts or devices have been compromised. This is a server-side vulnerability. The immediate task belongs to the operators responsible for affected servers and services. The risk is serious, but its scope is specific.
The most important lesson is about dependence. Digital services often appear independent because they have different names, designs, and owners. Underneath, many may rely on the same languages, libraries, cloud platforms, or network providers. When one of those shared foundations fails, the effects can spread across services that seem unrelated.
The PHP vulnerabilities did not bring down the internet. They showed how much of the internet depends on foundations that most people never see—and how quickly a flaw in one of them can become a problem for organizations around the world.
