A week after the emergency patch for PHP2Shell, no major incidents have been reported. According to Fox-IT, it is still too early to say the danger has fully passed.
Rarely has a software vulnerability made the news like PHP. On 21 October, the PHP Foundation released an emergency patch for two critical vulnerabilities in the programming language. They were already being exploited before the patch was available. In Belgium, DPG Media, the VUB and several hospitals, among others, took their websites offline as a precaution.
The vulnerability was probably being exploited before that. The Dutch security company Fox-IT saw reports of possible abuse as early as 17 October, four days before the patch was released. Frank van Oeveren, interim Director Cyber Intelligence & Response at Fox-IT, takes stock a little under a week later. As far as that is possible, because in his view the potential consequences of the vulnerability are still far from known.
Break-ins not yet visible
The fact that no major incidents have been reported a week later does not reassure Van Oeveren. “It is too early to say that now. You can’t always tell whether someone has actually broken in somewhere. Moreover, patched systems may also have been hacked earlier.”
“Perhaps the exploitation was too complicated,” says Van Oeveren. “But incidents can happen over months to years. Many servers are still far from patched, which means many systems are still vulnerable.” He points to Log4Shell, the vulnerability in the Java library Log4j that surfaced at the end of 2021. Back then too, systems were hacked long after the disclosure.
According to Van Oeveren, there are ways to find traces of a break-in. “You can see whether attempts have already been made to get in. The trickiest part is that you don’t see it right away.” Organisations with monitoring have a good chance of spotting an attacker when they try to move further through the network or make strange login attempts. “That only happens after the initial attack. By then you’ve actually already been hacked.”
His advice is to stay vigilant in the coming period. “Keep monitoring your network, your applications and everything connected to the network. You need to have that in good order, so that you have a picture of whether attempts have been made.” Amazon recommends looking back to at least 17 October.
Sensible precautions
Worldwide, websites went offline as a precaution. Even the Centre for Cybersecurity Belgium (CCB) put its own site in maintenance mode and advised Belgian organisations to do the same. Organisations heeded that call. Van Oeveren considers that choice justified in hindsight.
“Better safe than sorry. You can make the case for not doing it, but the risk isn’t worth it. For retailers the trade-off was harder, because an offline webshop immediately costs revenue. Even there, they preferred to keep the site offline for a while and accepted the lost revenue.”
You usually only see exploitation at the initial attack. By then you’ve actually already been hacked.
Frank van Oeveren, interim Director Cyber Intelligence & Response Fox-IT
Messy disclosure
A lot has been said and written about how the vulnerability reached the general public. Panic messages about the flaw circulated widely, and the security company Chainguard published patched images more than six hours before the official release. The PHP Foundation was not pleased about that afterwards.
“The vulnerabilities entered the public domain, everyone could see them,” says Van Oeveren.. “The leak was quickly removed again, but everyone had already taken screenshots.” In his view, the uproar also had a good side. “Without media attention, something like this can get buried. Now everyone took action immediately.”
The pressure also meant PHP had to roll out the patch faster than planned. “Actually this should be possible without the media jumping on it first, but it has woken everyone up. All things considered, it turned out well this way.” As a result, the risks of the early disclosure weighed less heavily, according to Van Oeveren.
Flaw had been known for longer
The PHP Foundation later acknowledged that the first signs of one of the vulnerabilities had been known since 2024. Because there was no known attack route at the time, other problems took priority. According to Van Oeveren, that is not unusual. “Sometimes a vulnerability is known, but there is no logical path to exploit it. Then you need a second vulnerability to reach the first. AI has chained them together here.”
How serious and how urgent a vulnerability is requires a judgement call every time. “When assessing severity, you first look at the CVSS score,” Van Oeveren explains. “It tells you what access a flaw gives, which with PHP2Shell is full administrator access. On top of that, it matters whether a proof of concept exists and whether the flaw is being exploited in the wild.”
“If it’s above a certain threshold, you have to make a decision and weigh it against the risk: patch immediately, take the system offline or investigate further.” As a security provider, Fox-IT designs detection rules for clients and goes looking for abuse itself. “A lot of cogs start turning right away,” Van Oeveren continues.
AI speeds things up
AI models reportedly played a major role in discovering the vulnerability. That is gradually becoming the new normal in software security. Once a vulnerability is known, we are no longer talking about months, but about days to hours before it can be exploited. By default, a vendor gets ninety days to close a flaw before it is made public.
Van Oeveren thinks it is exaggerated to say AI has suddenly changed the rules completely. “Patching ultimately isn’t very different from before, but it is much faster. AI speeds up many things, especially in software security. Vulnerabilities are discovered faster and so must also be patched faster.”
Attackers and defenders have the same capabilities, and a human remains necessary for verification, says Van Oeveren. “Vendors use LLMs themselves to track down vulnerabilities, but criminals do that too. When such a flaw becomes public, you don’t always know. That used to happen as well, but on a much smaller scale and at a slower pace than now.”
Everyone is responsible
In recent days, there has been a lot of finger-pointing over who bears responsibility. The PHP Foundation called on users of the programming language to contribute more to security. Doubting the safety of open source code now would be the wrong reflex, according to Van Oeveren. “With proprietary software, the vendor can keep a vulnerability hidden. That is impossible with open source.
He sees the openness of the code mainly as a strength. “Anyone can access the code, and that’s a good thing. A company can keep a vulnerability hidden. Open source we can all test, and people do. They see the software as their own and treat it that way.” That responsibility is shared. “Companies that build open source code into their offering to customers also benefit from putting people on it,” he adds.
Even now that AI is being used in software security, open source has its advantages. “To test for vulnerabilities with LLMs, you need the source code. Software without public code can’t be tested that way. Open source therefore ultimately comes out safer.”
Know what you have running
Vigilance remains necessary, according to Van Oeveren. PHP code is everywhere: some 70 percent of the internet depends on it. Organisations must therefore know exactly what they have running. “Most organisations have a good picture of this. That goes hand in hand with maturity. There are also some that have no overview at all of their own environment.”
Regulation helps here. NIS2 enforces that overview, including at SMEs. “In the past, this was too often done on a best-effort basis. Now this kind of thing is imposed. Companies are more dependent on each other and therefore also have more obligations towards each other. As a consumer or user of services, you must be able to rely on this too.”
His main lesson for CISOs and IT managers sounds familiar. “It’s the same thing we’ve been saying for five to ten years: make sure you know what you have running, what is exposed to the internet, and that your patch management is in order. It starts with that basic advice, then you go a step further. That also includes knowing, if you get hacked, and that can always happen, when someone is inside.”
Van Oeveren does not dare predict how much damage PHP2Shell will ultimately cause and how long we will still be talking about it. “We don’t know what and how much is still to come out.” Whether the PHP flaw turns out to be a storm in a teacup or a devastating tsunami, we may therefore only know in a few years.