The Internet’s Unlocked Back Door: How Dangerous Is the PHP Flaw?

By Matthew Parish

Friday 23 October 2026

There are moments when the extraordinary technological sophistication of modern civilisation is exposed as resting upon foundations of surprising fragility. We entrust our money to electronic banking systems, our medical histories to computerised databases, our governments to digital communications and much of our daily intellectual life to websites whose internal workings are almost entirely mysterious to us. Then somebody discovers a defect in a few lines of computer programming, and suddenly substantial portions of this elaborate architecture appear vulnerable to intrusion by people who ought never to have been allowed through the front door.

Something of this kind has happened with the discovery of two serious vulnerabilities in PHP, one of the world’s most widely used computer programming languages. On 21 October 2026, emergency security updates were issued amid warnings from European and British cybersecurity authorities that affected websites could be taken over remotely by unauthorised intruders. Some government websites were temporarily taken offline as administrators scrambled to assess their exposure, and security specialists began speaking in unusually grave terms about the potential consequences. We ought to understand precisely what has happened, because the danger is genuine, although not quite the approaching digital apocalypse that some commentators appear inclined to describe.

What is PHP?

PHP is a computer programming language that performs much of the invisible work necessary to make the internet function. When we visit a website, we generally see words, pictures, menus and opportunities to interact with the information presented to us. Behind this apparently simple interface, computers are executing elaborate instructions, retrieving information from databases, verifying passwords and deciding what material each visitor is entitled to see.

PHP is one of the languages in which these instructions are written. It operates principally upon the computers hosting websites, rather than upon the phones or laptops with which ordinary people visit them. It is therefore rather like the kitchen of a restaurant: the customer sees the finished meal, but not the complicated sequence of instructions and activities necessary to prepare it.

A remarkable proportion of the internet relies upon PHP. It is a fundamental component of WordPress, the publishing system used by millions of websites, and also plays important roles in systems such as Drupal, Joomla and MediaWiki, the software underlying Wikipedia. Approximately 70 per cent of websites whose server-side programming language can be identified use PHP in some capacity. That is an extraordinary concentration of digital dependence upon a technology about which most internet users have never heard.

This does not mean that 70 per cent of the internet has been hacked, or even that 70 per cent of websites remain vulnerable. It means that a vulnerability affecting the foundations of PHP potentially creates an enormous number of targets, depending upon which versions of the software are installed and how individual servers are configured. The distinction is fundamental to understanding the present emergency.

What has actually gone wrong?

The newly publicised vulnerabilities, formally designated CVE-2026-109618 and CVE-2026-109619 and collectively nicknamed PHP2Shell, concern the manner in which PHP manages computer memory when something goes wrong during its operations. Each has received a critical severity rating of 9.2 out of 10. This is an exceptionally serious assessment, although it is not a prediction that nine out of every ten vulnerable websites will be compromised.

Computer memory is rather like an elaborate filing system in which temporary documents are constantly created, amended, consulted and discarded. To operate efficiently, a computer must know precisely which portions of its memory contain valid information and which have been emptied and can safely be reused. When a programme finishes using a piece of memory, it ought not subsequently to behave as though the original information were still there.

The problem with PHP is that, under particular circumstances, the programme can become confused about precisely this distinction. One vulnerability involves the handling of a request that exhausts an allocated quantity of memory, interrupting a sequence of operations before the computer has properly organised its internal information. The second involves circumstances in which PHP continues to refer to memory that has already been released for other purposes.

Imagine an administrative office in which a clerk begins preparing a confidential dossier, is interrupted by an emergency and abandons the task without properly recording what has been completed. Another clerk subsequently arrives, finds documents that ought to have been destroyed or reclassified and treats them as legitimate instructions. A sufficiently ingenious intruder might manipulate this confusion to persuade the office to undertake activities it would ordinarily refuse.

The analogy is imperfect, as all analogies involving computer programming inevitably are. Nevertheless, it captures the essential difficulty: PHP can sometimes lose track of which information should still be trusted, and an attacker may be able to exploit that confusion to influence what the computer subsequently does.

The most alarming potential consequence is something cybersecurity specialists call remote code execution. In ordinary English, this means that somebody operating another computer, potentially on the opposite side of the planet, can cause the vulnerable computer to execute instructions of the intruder’s choosing. In demonstrated attacks involving certain configurations, the intruder does not even need a username or password.

That last point is particularly important. Most website security is designed around the assumption that an attacker must somehow defeat the normal protections governing access to the website. But these vulnerabilities arise within PHP itself, sometimes before the website’s own programming has had an opportunity to check who is making a request. It is rather like installing elaborate locks upon every door in a building, only to discover that a defect in the foundations permits somebody to enter through the floor.

What could an attacker actually do?

The possible consequences are substantial. Depending upon the permissions granted to the compromised server and the other safeguards in place, an intruder might steal customer records, extract passwords or authentication credentials, modify published information, install malicious software or use the affected computer to attack other systems. A criminal might attempt to steal personal financial information, while a politically motivated attacker might seek to replace the contents of a government website with propaganda.

There are more subtle possibilities. A compromised server might be employed to send fraudulent emails, collect confidential communications or provide an apparently legitimate starting point for attacks against other institutions. In a more serious incident, the initial intrusion could become the first stage of a ransomware attack, in which important computer files are encrypted and their owners are presented with demands for payment.

Nevertheless, the ability to execute instructions upon a website server is not identical to unlimited control of everything connected to it. Modern computer systems generally allocate different levels of authority to different programmes. A PHP process may have permission to read certain files and communicate with certain databases while being prohibited from performing more sensitive operations. Properly configured isolation between systems can therefore significantly limit the damage an intruder causes.

Nor does the discovery mean that simply visiting a PHP-powered website will infect one’s telephone or personal computer. The vulnerability principally threatens the computers hosting affected websites. Ordinary users face secondary risks if those computers are compromised and their personal information is stolen, or if a trusted website is subsequently used to distribute malicious material.

This is the distinction between a dangerous vulnerability and a universal catastrophe. The former creates the opportunity for wrongdoing. The latter requires criminals to exploit that opportunity successfully, overcome whatever additional protections exist and achieve consequences sufficiently extensive to threaten the broader functioning of the internet.

Has anybody actually exploited the flaw?

Here the evidence requires careful consideration. On 21 October, Amazon’s threat intelligence division disclosed that its monitoring systems had detected an apparent attempt to exploit PHP2Shell on 17 October, four days before the public release of the security updates. Other attempts were observed around the time of disclosure, including activity directed against systems deliberately established to attract and observe malicious computer traffic.

These findings establish that the danger is not confined to theoretical discussions amongst computer scientists. Attackers are already experimenting with methods of exploiting the vulnerabilities, and publicly available demonstrations have made it easier for others to follow. Amazon subsequently reported widespread exploitation attempts directed against its monitoring infrastructure.

But there is an important qualification. An attempted attack is not necessarily a successful attack, and a demonstration that a vulnerable computer can be compromised does not establish that criminals have already compromised substantial numbers of real websites. As of 23 October, the publicly available evidence reviewed for this article does not establish the scale of successful intrusions into operational systems.

It would therefore be irresponsible either to dismiss PHP2Shell as a theoretical curiosity or to announce that the world’s electronic infrastructure has already been penetrated. The more reasonable assessment is that a very serious vulnerability has become publicly exploitable at a time when the tools required to exploit it are becoming increasingly accessible.

The unexpected role of artificial intelligence

Perhaps the most intellectually interesting aspect of the affair is the role played by artificial intelligence in identifying the vulnerabilities and demonstrating their seriousness. Researchers working with advanced AI systems, including models developed by OpenAI and Google, were instrumental in establishing how longstanding weaknesses within PHP could be transformed into practical attacks.

OpenAI has described the work as part of a coordinated initiative called Patch the Planet, while the cybersecurity company Wiz has explained how its researchers used frontier AI models to accelerate the identification and development of working demonstrations. Another security company, Calif, identified a critical flaw using GPT-5.6 Sol. The striking conclusion is that weaknesses that had existed in some form for many years became much easier to understand and exploit once advanced AI tools were applied to them.

Indeed, the PHP Foundation has acknowledged that indications of one underlying problem had already emerged during a security review in 2024. The difficulty was not simply ignorance of the potential defect. Developers had struggled to determine how to correct the problem without introducing other serious difficulties, and the relatively small team of specialists responsible for PHP lacked the resources to resolve these competing considerations promptly.

Artificial intelligence changed this equation by helping researchers demonstrate that the vulnerability was not merely an obscure theoretical possibility but a practical route to unauthorised control of a computer. Once this became clear in August 2026, the problem assumed a dramatically greater urgency.

There is a paradox here. For years, we have been warned that artificial intelligence will create unprecedented dangers by furnishing malicious individuals with powers that previously belonged only to highly specialised experts. Yet in this case AI-assisted researchers helped identify and repair a dangerous weakness before its full consequences became widely understood.

The lesson is not that artificial intelligence is inherently benevolent or malevolent. It is that AI is reducing the amount of specialised human effort required to analyse extraordinarily complicated software. This benefits defenders who wish to discover security defects, but it may equally benefit criminals who wish to exploit them. The same technological capabilities can serve both purposes.

Indeed, the more troubling long-term implication is that the time available to repair vulnerabilities may be shrinking. In the past, a weakness requiring months of specialised research to exploit might remain relatively harmless while programmers worked upon a remedy. If artificial intelligence can compress months of investigation into days or hours, the traditional assumptions governing cybersecurity become less reliable.

There is no need to invoke conscious machines, malevolent superintelligence or the more extravagant predictions of AI doom enthusiasts. The immediate problem is more prosaic and considerably more plausible: increasingly powerful software is allowing human beings, including criminals, to perform sophisticated technical operations much faster than previously possible.

The vulnerability of Ukraine

For Ukraine, the implications deserve particular attention. The country already confronts an unusually hostile cybersecurity environment as a consequence of Russia’s continuing war of aggression. Ukrainian government institutions, telecommunications providers, businesses and civil society organisations must maintain computer systems while facing both ordinary criminal threats and the possibility of politically motivated cyber operations.

A vulnerability such as PHP2Shell potentially creates another opportunity for hostile activity. An adversary seeking to disrupt a local authority website, steal correspondence from a charitable organisation or compromise a commercial service might regard an inadequately maintained PHP server as an attractive target. Many smaller Ukrainian organisations understandably concentrate their limited resources upon immediate operational necessities rather than employing specialist cybersecurity teams.

This does not establish that Russian intelligence agencies have successfully exploited PHP2Shell against Ukrainian targets. No such conclusion should be drawn without specific evidence. It does, however, mean that the consequences of failing to install available security updates could be particularly serious for institutions already operating in an adversarial environment.

There is also a broader issue of institutional resilience. Ukraine’s experience of war has illustrated that resilience rarely depends upon any single dramatic technological achievement. It depends upon the maintenance of countless ordinary systems, from electricity supplies and railway signalling to emergency communications and administrative databases. Cybersecurity belongs in precisely the same category: a largely invisible public necessity whose importance becomes apparent when it fails.

What should be done?

Fortunately, PHP2Shell is not a problem for which no remedy exists. The PHP security team released corrected versions on 21 October 2026, including PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Organisations using affected installations have been advised to update immediately, and those relying upon older, unsupported versions must seek an appropriate maintained replacement or a verified security fix supplied by their software distributor.

For the ordinary website proprietor, the essential question is whether the company responsible for hosting the website has installed the necessary PHP security updates. Updating WordPress itself, for example, is not necessarily the same thing as updating the underlying PHP interpreter. The distinction matters because the problem lies beneath the familiar website software, in the machinery upon which it depends.

For larger organisations, the task is more complicated. Administrators must identify every affected installation, determine which systems are accessible from the public internet, apply the relevant fixes and investigate suspicious activity that may have occurred before those fixes were installed. Where a vulnerable system cannot promptly be secured, temporarily removing it from public access may be the prudent course.

No amount of changing ordinary user passwords will, by itself, repair this defect. Nor should website administrators assume that conventional firewalls or antivirus software necessarily provide comprehensive protection against an attacker manipulating the internal behaviour of PHP. Such safeguards can help, but the decisive remedy is to correct the vulnerable software itself.

The underlying difficulty is not technical knowledge alone. It is organisational discipline. Many security disasters occur because somebody has postponed an update, forgotten an obsolete server, failed to establish responsibility for maintaining a system or assumed that a hosting company was attending to matters that nobody had explicitly asked it to address.

In cybersecurity, the spectacular failures often begin with extremely ordinary forms of negligence.

The deeper problem with the internet

The PHP affair also reveals something uncomfortable about the economic foundations of the modern internet. Much of the software supporting global commerce, public administration and personal communications is maintained by surprisingly small groups of highly specialised developers. These individuals perform work of enormous public importance, frequently without resources remotely commensurate with the commercial value of the systems that depend upon them.

PHP is an open-source project, meaning that its underlying programming code is publicly available and can be examined and improved by others. This has produced remarkable innovation and enabled countless small businesses, independent publishers and charitable organisations to establish an internet presence at relatively low cost. But it has also created an awkward problem of collective responsibility.

When millions of organisations benefit from a shared technological foundation, each has an incentive to assume that somebody else will pay for its maintenance. The result can be an essential public good sustained by a relatively small number of experts working under persistent constraints. The PHP Foundation’s acknowledgement that insufficient resources and slow decision-making contributed to the delay in addressing the underlying weakness is therefore particularly significant.

The lesson extends well beyond PHP. Governments and large commercial organisations are increasingly dependent upon software that they neither own nor adequately understand. They may spend fortunes upon sophisticated digital services while devoting comparatively little attention to the obscure programming libraries and infrastructure upon which those services depend.

If the modern world wishes to avoid recurrent crises of this kind, it may need to treat the maintenance of critical software much as it treats the maintenance of roads, bridges and electricity networks. Security cannot be left exclusively to emergency intervention after a defect has become sufficiently dangerous to attract international headlines.

How worried should we be?

We ought to be considerably concerned, but not terrified. PHP2Shell represents a genuinely critical security problem because it affects a foundational component of an enormous number of websites, because practical exploitation has been demonstrated and because attackers may not need ordinary login credentials to reach vulnerable systems. The fact that attempted exploitation was detected before public disclosure adds to the urgency.

Nevertheless, the existence of a vulnerability does not demonstrate that every affected website has been compromised. Security updates are available, responsible hosting companies are applying them and multiple defensive measures can reduce the consequences of an intrusion. The worst possible outcomes should not be confused with the most probable outcomes for every individual organisation.

The immediate danger is greatest for systems that remain exposed to the public internet while running vulnerable software, particularly where they contain valuable information or provide access to other important systems. For ordinary internet users, the most sensible response is to expect the institutions holding their information to take appropriate security precautions, rather than to abandon online services in a general atmosphere of alarm.

There is a temptation, whenever a cybersecurity crisis attracts widespread attention, to imagine that the internet is about to collapse. In reality, the internet has always been an imperfect collection of technologies maintained by fallible human beings. Its resilience arises partly from the capacity to identify mistakes, circulate warnings and repair defects before their consequences become unmanageable.

The distinctive feature of the present episode is that artificial intelligence may be accelerating both sides of this process. It helps discover weaknesses that human investigators have overlooked, but it may also make those weaknesses easier for malicious actors to exploit. Whether the balance ultimately favours security or insecurity will depend less upon the intelligence of machines than upon the competence of the human institutions responsible for deploying them.

PHP2Shell is therefore neither an insignificant programming error nor the end of the digital world. It is a serious warning about the fragility of technological systems upon which civilisation has become almost casually dependent. The machines may be extraordinarily sophisticated, but their security still relies upon people noticing defects, accepting responsibility and undertaking the unglamorous business of putting things right.

Perhaps that is the most reassuring aspect of this otherwise disturbing affair. The internet has not become uncontrollable merely because somebody discovered a flaw in its machinery. We have instead been reminded that, however elaborate our technology becomes, the final responsibility for maintaining it remains stubbornly human.