PHP2Shell: when a software vulnerability becomes a global emergency
Two vulnerabilities in the engine powering most of the world’s websites were accidentally revealed, and this literally caused panic. Here’s what happened
Recent reports indicate that a number of European institutional websites have been taken offline as a precaution. The decision to suspend services was prompted by the discovery of two serious security flaws in PHP, a programming language used by a vast proportion of the web. Yesterday, in fact, two vulnerabilities in the engine powering most of the world’s websites were accidentally revealed, and this literally sparked panic amongst IT managers in companies.
What is Php2Shell?
The vulnerability, known as PhP2Shell, consists of two separate flaws (assigned the CVE identifiers CVE-2026-109618 and CVE-2026-109619), which, when combined, allow attackers to take control of many web-facing servers, giving them unrestricted access to the data and files stored on them. This means that criminals can disrupt internet services and steal stored data. In reality, it is estimated that ‘only’ 70 per cent of websites use PHP as their engine, and not all of these are vulnerable. The fact remains that it appears at least half are successfully exploitable, and those that are not yet affected cannot be certain they are safe; consequently, they are working hard to determine what countermeasures to adopt and to restore services that have (often) been taken offline. Among the sites that went offline were the BBC’s website, several Finnish government sites, the website of the Dutch cybersecurity agency, and so on. From their perspective, consumers can do nothing but wait; however, the situation is now returning to normal, as on 21 October the PHP project released emergency updates for the versions still under support. The seriousness of the situation also led to a joint statement from the European Commission, ENISA, CERT-EU, Europol and the European CSIRT network, which urged organisations to take immediate action, prioritising systems exposed to the internet. And as the dust settles, it is becoming clear that there are many pieces of the puzzle to put in place and many lessons to be learnt from this incident.
Let’s start with the vulnerabilities
A very interesting aspect of this whole crisis is that the first signs of it date back two years. The underlying issue behind CVE-2026-109618 had, in fact, already come to light in 2024, during an external security audit of the PHP engine. At the time, however, the PHP development team had been unable to find a satisfactory solution. The flaw concerned a particularly sensitive part of the language’s internal workings, and the possible fixes carried consequences that were difficult to assess: incompatibility with existing software, new risks of denial-of-service attacks, and potential problems for the numerous extensions developed by third parties. This is something that often happens with widely used software such as PHP, which underpins the operations of companies, institutions and services that are more or less indispensable. Furthermore, there was no convincing evidence that the problem could be exploited to execute code remotely. It was known that there was a problem, but it was not certain that it could actually be exploited for illegal purposes. The decision was made to wait: a move that, in modern computing, almost always spells big trouble. And trouble did indeed come in the form of AI systems designed to assist with cybersecurity: following the launch of Mythos by Anthropic, disturbing reports began to emerge, showing that the dormant vulnerability was indeed a potential threat. The PHP Foundation began to step up its efforts, drawing on AI tools and advice from companies specialising in cybersecurity, but the task remained complex.
The turning point comes on 11 August 2026: someone finds a way to hack into the servers.
In August, Ryan A, a researcher at the security firm Calif, reported a potential arbitrary code execution vulnerability to the PHP project, which stemmed from the same root cause as the memory management issue identified in 2024. On the same day, the same report was submitted independently by OpenAI, confirming the same root cause. This was followed by further findings from Wiz on 24 August, and new attack vectors identified by OpenAI on 18 September.
At this stage, according to a statement from the PHP Foundation, fixing the issue has become the security team’s main priority, with developers working even at weekends and late into the night.
