• home
• about
• new
• essays
• AI
• book

Frank Visser, graduated as a psychologist of culture and religion, founded IntegralWorld in 1997. He worked as production manager for various publishing houses and as service manager for various internet companies and lives in Amsterdam. Books: Ken Wilber: Thought as Passion (SUNY, 2003), and The Corona Conspiracy: Combatting Disinformation about the Coronavirus (Kindle, 2020).

PHP Under Fire

How Two Critical Vulnerabilities Exposed the Fragility of the Modern Web

A worldwide security scare, a delayed fix, and the uncomfortable question of who pays for open-source security

Frank Visser / ChatGPT

On Wednesday, October 21, 2026, a security crisis swept through the infrastructure of the internet. The PHP development team released emergency updates to address two critical vulnerabilities capable of allowing unauthenticated attackers to execute code remotely on affected servers. Government agencies issued urgent warnings. Organizations temporarily shut down public-facing websites. In the Netherlands, even the National Cyber Security Centre's own website was taken offline as a precaution.

The incident, widely associated with the name “PHP2Shell,” was not simply another software vulnerability. It exposed a deeper problem in the way the digital world is maintained: an enormous amount of critical infrastructure depends on software whose security is ultimately entrusted to a comparatively small group of developers.

The most disturbing revelation was that one of the underlying problems had been identified as a potential vulnerability in 2024. It took further research, including AI-assisted security work, to establish the severity of the problem and develop a decisive response. The PHP Foundation subsequently acknowledged that the delay was a structural failure.

The central question is therefore larger than whether website administrators installed the latest patch. How did a programming language underpinning such a substantial part of the web reach this point, and what does the episode reveal about the future of software security?

1. What actually happened?

PHP is a server-side programming language used to generate dynamic web pages, process requests, communicate with databases, and run applications. It underpins major content-management systems and countless business, media, educational, and government websites.

Two vulnerabilities were disclosed on October 21 under the identifiers CVE-2026-109618 and CVE-2026-109619. Both received a CVSS v4.0 severity score of 9.2 out of 10. Their significance lay in the possibility of remote code execution, commonly abbreviated as RCE.

Remote code execution is among the most dangerous classes of software vulnerability. Rather than merely viewing information that should have remained private, an attacker may be able to make the vulnerable server execute commands of the attacker's choosing. Depending on the permissions and configuration of the compromised process, this can open a path to sensitive files, databases, credentials, and other systems.

The danger was amplified by the possibility of exploiting the flaws without first authenticating as a legitimate user. In the most concerning documented configuration, an attacker could trigger the problem before the web application itself had begun executing its own code.

That distinction matters. A website can have sensible login controls, carefully written application code, and good password policies, yet remain vulnerable if the underlying language runtime can be compromised before those protections take effect.

The PHP team released patched versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The team advised administrators to update immediately and stated that no complete mitigation could substitute for installing the fixes.

2. Two flaws in the machinery beneath the website

The vulnerabilities were not simply mistakes in a particular website's login form or a defective third-party plugin. They involved PHP's internal handling of memory and errors.

The first vulnerability, CVE-2026-109618, concerned memory corruption associated with an out-of-memory condition. When a request reached PHP's memory limit at a critical moment, internal data could be left only partially initialized. Subsequent cleanup or processing could mistakenly treat that data as valid, creating conditions in which memory corruption could be exploited.

The second, CVE-2026-109619, involved a use-after-free condition. In simplified terms, PHP could retain internal state referring to memory that had already been released. A later request handled by the same worker could then interact with memory that no longer belonged to the original operation.

These are familiar categories of programming-language security defects, but their location made them particularly serious. Memory management and error handling are fundamental operations, not peripheral features that administrators can simply disable.

The PHP Foundation reported demonstrated remote-code-execution scenarios involving Apache's mod_php configuration. It also reported that exploitation of the first vulnerability had been confirmed through application-level code paths under PHP-FPM. The risks therefore were not confined to one unusual deployment architecture.

The episode illustrates an important security principle: software can behave correctly under ordinary circumstances for years while retaining a flaw that becomes catastrophic under a carefully engineered sequence of events. The absence of visible failures is not proof of the absence of exploitable defects.

3. The two-year question: why did the fix take so long?

Here the story becomes an investigation into institutional responsibility rather than merely technical failure.

According to the PHP Foundation's account, an external security audit in 2024 helped uncover the first indications of the out-of-memory problem. At that stage, the potential exploitability had been theorized, but researchers had not established a concrete path to remote code execution.

The problem was difficult to resolve. Different approaches to fixing it risked breaking backward compatibility, creating denial-of-service vulnerabilities, or requiring changes across a large ecosystem of third-party extensions. The security team had to weigh these competing consequences while operating with limited personnel and relying on a consensus-oriented decision process.

The work repeatedly stalled and restarted. Only after additional research made the exploitability much clearer did the issue become an overriding priority.

The Foundation's own assessment was unusually candid: the delay was a structural failure caused by both the security team's decision-making process and its lack of resources.

This admission deserves to be taken seriously. It would be easy to portray the incident as a story of a clever attacker discovering an obscure defect. But the institutional record points to a more complicated failure: a known risk remained unresolved because the people responsible could not readily agree on a technically acceptable solution.

That does not mean the developers were indifferent or incompetent. Maintaining a mature programming language requires difficult trade-offs. A fix that breaks widely used software can itself create security and reliability problems. Nor does the identification of a theoretical vulnerability automatically establish that an exploitable attack exists.

Nevertheless, once software becomes critical infrastructure, unresolved high-impact security problems cannot be allowed to languish indefinitely simply because the available options are uncomfortable.

A mature security organization needs a mechanism for escalating such disputes, allocating additional resources, and imposing deadlines. Technical uncertainty should trigger disciplined investigation, not indefinite postponement.

4. The worldwide consequences: precautionary shutdowns

The international response demonstrated how a vulnerability in one component can disrupt services across many countries and sectors.

Reports on October 21 described temporary shutdowns or disruptions affecting government websites and other public services in several European countries. The Dutch government's response included precautionary measures affecting public-facing services, while the Dutch NCSC temporarily took its own website offline. Germany, France, Belgium, and Finland also reported protective shutdowns or disruptions. Wikimedia said it was addressing the vulnerabilities and had taken some systems offline as a precaution.

These actions should not automatically be interpreted as evidence that the affected organizations had been hacked. A preventive shutdown is a risk-management decision, not a declaration of compromise.

That distinction is crucial. At the time of the initial Dutch advisory, the NCSC said it had not observed active exploitation. Canada's Cyber Centre likewise reported that public proof-of-concept material existed but that active exploitation had not been identified in the reporting available to it. Those assessments were snapshots in a rapidly changing situation, not guarantees that no attack had occurred anywhere.

The security dilemma was immediate. Administrators had to choose between keeping potentially vulnerable services online and temporarily denying access to legitimate users. For a commercial website, the consequences might include lost revenue. For a government portal, hospital service, or public information system, the consequences could be more serious.

Yet taking a site offline can be the responsible choice when the alternative is allowing an attacker to compromise the system and potentially move deeper into an organization's infrastructure.

The real failure is not necessarily the shutdown. It is the fact that a defect in a common software component can force so many unrelated organizations into the same emergency at once.

5. Why open-source software presents a collective-action problem

PHP is open-source software. Its source code is publicly available, and organizations around the world can use it without negotiating an individual commercial license for the language itself.

This openness has enormous advantages. Developers can inspect the code, build upon it, identify defects, and contribute improvements. The shared ecosystem has enabled the web to grow far beyond what any single vendor could have built.

But open source does not mean cost-free maintenance.

A programming language used by millions of developers may ultimately depend on a relatively small number of people who understand its most complicated internal mechanisms. Those specialists must handle bug reports, review patches, preserve compatibility, coordinate releases, and respond to security researchers. They cannot be replaced overnight by volunteers with only a general knowledge of the language.

The PHP Foundation's account explicitly identifies this imbalance. It describes a small pool of deeply experienced developers and calls for sustained financial support from companies, hosting providers, cloud platforms, software distributors, and public institutions that rely on PHP.

This is a classic collective-action problem. Each organization benefits from a shared software ecosystem, but each has an incentive to assume that someone else will pay for its maintenance.

The result can be a dangerous mismatch between the economic value of a technology and the resources allocated to its security.

If a multinational company earns substantial revenue from software built on PHP, its dependence on the language is real even if it does not employ the developers who maintain PHP's core. The same applies to government agencies that procure web services from contractors without adequately assessing the security of the underlying technology.

The question is not whether open-source software should become closed or whether every user should pay a mandatory fee. It is whether organizations that depend on shared infrastructure should contribute proportionately to keeping that infrastructure secure.

The PHP incident supplies a compelling argument for sustained funding, professional security teams, independent audits, and clearer accountability. Voluntary goodwill remains valuable, but goodwill alone is not a dependable security strategy for critical infrastructure.

6. AI discovered the danger—but that is only half the story

One of the most consequential aspects of this incident is the role of artificial intelligence in security research.

According to the PHP Foundation, further research by security firms and AI-assisted teams helped establish the practical severity of the memory-corruption problem in 2026. The Foundation's account describes reports from Calif, OpenAI, and Wiz that helped clarify the exploitability, alongside broader efforts involving additional security tools and researchers. The Associated Press also reported that AI agents helped uncover the vulnerabilities.

The importance of this development should not be understated. AI-assisted systems can help researchers examine large codebases, identify suspicious patterns, generate candidate explanations, and test whether a suspected defect can be turned into an exploit.

A defect that once seemed merely theoretical can become a demonstrable security threat when researchers have better tools to investigate it.

But the discovery of a vulnerability is only the beginning. A useful security process must still establish that the report is valid, reproduce the problem, determine its scope, develop a fix, test that fix, coordinate disclosure, and distribute updates to affected systems.

AI can accelerate some of those steps. It cannot automatically settle the compatibility trade-offs involved in modifying a mature runtime, nor can it guarantee that every proposed patch is safe.

The PHP Foundation describes using AI tools alongside sanitizers, reproducible test environments, and human review. That is a more credible model than treating AI as an autonomous security engineer that can independently solve every problem.

There is, however, a more unsettling implication. As AI-assisted vulnerability discovery improves, the time between the existence of a defect and the ability to exploit it may shrink. Defensive researchers may gain a substantial advantage, but attackers can also benefit from the same general advances.

The result could be a world in which discovering vulnerabilities becomes easier while fixing and deploying remedies remains constrained by organizational inertia.

The speed of discovery is increasing faster than the speed at which much of the world's software infrastructure can be repaired. That is the strategic challenge revealed by the PHP crisis.

7. The disclosure process: a second source of risk

The vulnerabilities themselves were not the only problem. The coordinated disclosure process also came under pressure.

The PHP Foundation reported that the vulnerability identifiers began circulating online on October 20, two days before the originally planned release. The premature disclosure prompted the project to move its announcement forward and advance the release date to October 21.

The Foundation also described an incident in which a security firm's video inadvertently revealed proof-of-concept activity, followed by the circulation of copies online. It further reported that a distributor published fixed binary images before the coordinated disclosure, potentially allowing attackers to study the changes while other users were still waiting for the official release.

These events illustrate the difficulty of coordinating security fixes across a global supply chain.

A project may need time to prepare patches, test them across supported versions, notify distributors, and ensure that hosting providers can deploy the updates. But every additional hour before disclosure can also be an hour during which a vulnerability remains exploitable.

Prematurely revealing details can put unpatched users at greater risk. Conversely, keeping a critical flaw secret for too long can prevent defenders from taking informed protective action.

There is no perfect disclosure process. There can, however, be a disciplined one, with clearly defined embargo rules, secure handling of pre-release patches, contingency plans for leaks, and explicit criteria for accelerating publication.

The incident shows that disclosure coordination is itself part of the security architecture. It cannot be treated as administrative housekeeping after the technical work is finished.

8. The patch is necessary, but it is not the end of the investigation

The immediate technical response is straightforward: identify affected systems and install the appropriate security updates.

For supported PHP branches, the releases announced on October 21 were 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Organizations using older versions need particular care. PHP 8.1 and earlier no longer receive security fixes directly from the PHP project, although some operating-system vendors and other maintainers may provide backported patches. Administrators should verify the status of their specific distribution rather than assume that a version number alone tells the whole story.

But patching addresses only one part of the risk.

Organizations also need to establish which applications, containers, appliances, and hosted services contain PHP. It is not enough to update the most obvious web server while overlooking a forgotten application, an embedded runtime, or a service managed by an external supplier.

After applying the fixes, administrators should examine relevant web-server, application, authentication, and endpoint logs for suspicious activity. Unexpected processes, files, accounts, or outbound connections may warrant further investigation. If a system was exposed while vulnerable, patching it does not prove that it was never compromised.

This is a distinction often lost in emergency announcements: removing the vulnerability does not automatically remove an attacker who may already have exploited it.

Nor does the publication of a patch mean that all organizations are protected. Some will update quickly; others may be constrained by legacy applications, unmaintained products, incompatible extensions, or third-party vendors who control the underlying runtime.

The global incident will therefore have a longer tail than the announcement of the fixes. The practical outcome depends on the speed and completeness of deployment, not merely on the existence of corrected source code.

9. Who is responsible?

It would be simplistic to blame the PHP developers alone. The Foundation's account describes genuine technical difficulties, scarce specialist resources, and a difficult compatibility problem. The developers ultimately coordinated fixes across multiple supported branches and worked with outside researchers and distributors to prepare a response.

It would be equally simplistic to declare the incident an unavoidable accident.

Responsibility is distributed across several levels.

The PHP project and its Foundation are responsible for maintaining effective security processes, escalating unresolved critical problems, and ensuring that decisions do not stall indefinitely. The candid admission of a structural failure is an important first step, but its significance will depend on whether the promised organizational reforms are implemented and sustained.

Commercial organizations that build products and services on PHP have a responsibility to help finance the maintenance of a technology on which they depend. They cannot reasonably treat the security of their underlying software as somebody else's problem while extracting substantial value from it.

Hosting providers and distributors must communicate clearly about affected runtimes and deliver patches promptly. Organizations that outsource their websites remain responsible for understanding whether their service providers have a credible security-update process.

Finally, governments and public institutions must treat software maintenance as an ongoing cost of digital infrastructure. Procurement that emphasizes the lowest initial price but neglects long-term security creates incentives for underinvestment.

None of these parties can guarantee that vulnerabilities will never occur. The relevant standard is not perfection. It is whether the system can discover, prioritize, repair, and communicate serious defects before the consequences become intolerable.

10. The deeper lesson: the internet is only as resilient as its maintenance system

The PHP crisis exposes a paradox at the heart of digital modernization. Governments, businesses, and citizens increasingly depend on online services that appear seamless and permanent. Yet those services rest on layers of software maintained by people and institutions with finite resources.

The web is not a finished product. It is an enormous, continually changing construction site.

The danger is that institutions often invest heavily in new digital capabilities while underinvesting in the maintenance of the foundations beneath them. Security audits, dependency management, version upgrades, and specialist engineering are less visible than new features, but they are indispensable to the continued operation of digital services.

The PHP episode also shows why software security cannot be reduced to a checklist. The vulnerability discovered in 2024 was not ignored simply because nobody cared about security. It remained unresolved amid uncertainty about exploitability, competing technical options, compatibility constraints, and limited staffing.

That is precisely why institutional design matters. Good intentions do not substitute for escalation procedures, adequate resources, clear decision-making authority, and a willingness to accept the disruption that a necessary fix may cause.

A resilient ecosystem must be capable of dealing with difficult security problems before an external shock forces everyone to pay attention simultaneously.

Conclusion: an avoidable emergency?

The events of October 21, 2026, do not establish that PHP is inherently unsafe, that open-source development has failed, or that every affected website was compromised. Such conclusions would go beyond the evidence.

They establish something more specific and arguably more important. Two vulnerabilities in fundamental PHP mechanisms created a serious risk of unauthenticated remote code execution. One underlying problem had been recognized earlier, but institutional and resource constraints delayed its resolution. AI-assisted research helped turn a difficult security question into an urgent, demonstrable threat. The resulting emergency forced organizations around the world to choose between rapid remediation and temporarily withdrawing services from the internet.

The PHP Foundation deserves credit for acknowledging its structural failures and for delivering fixes. That candor should not be mistaken for absolution. An admission of failure creates an obligation to demonstrate that the underlying causes have been addressed.

The decisive test will come after the headlines fade. Will the PHP security team receive sustained resources? Will difficult vulnerabilities be escalated sooner? Will companies and governments that rely on PHP contribute meaningfully to its maintenance? Will organizations verify that patches have been installed and investigate possible compromises rather than simply restore their websites and move on?

There is also a broader lesson for the AI era. Better tools can uncover weaknesses faster than ever, but discovery alone cannot secure a global software ecosystem. The ability to repair and deploy fixes must improve alongside the ability to find defects.

The internet did not suddenly become fragile on October 21. The incident made an existing fragility visible.

The ultimate scandal would not be that software contains bugs. All complex software does. It would be to learn the lessons of this emergency, return to business as usual, and wait for the next critical vulnerability to demonstrate—once again—that the digital world has built an enormous dependency on infrastructure whose maintenance it has not adequately organized.