PHP2Shell deserves attention beyond the usual security alert: It combines widespread exposure, exploitation attempts before public disclosure, and a practical demonstration of how AI can make difficult vulnerabilities easier to exploit.
In other words, it has the potential of creating a lot of problems for many companies and individuals - in fact, the majority of people and organisations who run a website, as according to some statistic up to 70% of websites are *potentially* vulnerable.

For organisations, there are two immediate questions:

Where are you exposed?

How quickly can you confirm that exposure has been removed?

What happened?

On 21 October 2026, PHP released emergency fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell.
Under exploitable conditions, they allow attackers to execute code on affected servers without authentication and PHP identifies all installations serving web requests as at risk, with the highest risk associated with Apache’s mod_php.
These flaws affect the PHP engine itself: A website can therefore be exposed even when its application code is secure.
Wiz’s research also describes the potential to read sensitive server memory, including passwords, authentication tokens and API keys.

And this is already being exploited as AWS reported an exploitation attempt against its honeypot infrastructure on the 17th of October, four days before public disclosure! followed by further attempts.
However, AWS cautioned that it remains unclear whether those early attempts would have succeeded against real systems

Where AI changes the risk

As we discussed in previous blog posts, advanced AI models substantially reduced the work required to turn *any* flaws into working exploits, it is now often a matter of hours if not minutes.
There is a positive side: AI helped researchers uncover weaknesses and coordinate fixes and the PHP Foundation also acknowledges that signs of one underlying problem had been identified in 2024, but technical trade-offs, limited resources and decision-making difficulties delayed remediation. In other words, they were already aware of a potential fix and the complexity of exploitation was a factor not to prioritise it.

So the negative side is that an exploit too complicated to exploit, by a human, is no longer a reson to delay a fix or a patch, now that we have AI to help creating those exploits... One could argue it was never a good reason to start with!

Three priorities now

1. Find the exposure, including outsourced services:
Ask IT teams, application owners and hosting providers to identify PHP installations supporting websites and business applications.
Request confirmation of the running PHP version and remediation status.

2. Patch the underlying runtime.
The fixed releases are:

PHP branch -> Minimum fixed release
8.2 -> 8.2.35
8.3 -> 8.3.36
8.4 -> 8.4.27
8.5 -> 8.5.12

For older branches, upgrade or obtain a confirmed vendor fix.
Some distributions backport security fixes, so the package revision and vendor advisory matter as well as the displayed PHP version.

Please note that PHP warns that configuration workarounds do not provide complete protection.
If immediate updating is impossible, the NSA recommends taking affected systems offline until fully mitigated. That requires a prompt business decision on service availability and exposure.

3. Check for compromise as well as patching.
For exposed systems:
Review historical activity from at least 17 October: Look for unexpected processes, file changes and suspicious web requests.
Note that patching removes the vulnerability; it does not remove an attacker who has already gained access!
AWS provides investigation guidance and observed indicators.

For management, the useful question today should be simple:
Can each service owner demonstrate that their PHP exposure has been checked, patched and investigated where necessary?