TL;DR
- PHP2Shell refers to 2 critical vulnerabilities affecting the PHP engine (PHP 5.4 through to PHP 8.5)
- The vulnerabilities can lead to remote code execution
- Any web application using an affected version of PHP could be vulnerable
- A quick update policy and a defence in depth approach remain the best defence mechanisms against this and other future vulnerabilities
Introduction
On the 20th of October two critical vulnerabilities affecting the PHP engine were publicly disclosed, collectively known as PHP2Shell.
The vulnerabilities were discovered through research involving Wiz, Calif, and OpenAI, with AI playing a significant role in both vulnerability discovery and exploit development.
Unsurprisingly, much of the attention has focused on the AI angle. There’s something rather newsworthy about AI helping researchers find and exploit vulnerabilities in software that has been running much of the web for decades. However, defenders are still facing the same “classic” security questions they always have:
- Are we vulnerable?
- Can we patch our systems in time?
- Can we check for indications of compromise?
Although the AI angle is interesting, the reason organisations should be paying attention to this is the severity of the findings, and the widespread nature of the PHP engine.
What is PHP2Shell?
Both bugs are rated as “critical” on the CVSS vulnerability scoring system and can lead to remote code execution without authentication or user interaction. They stem from how PHP handles requests that are cut off abnormally:
- CVE-2026-109618: An attacker can deliberately trigger an out-of-memory condition with a crafted file-upload request. Running out of memory at the wrong moment leaves PHP’s internal data in a corrupted state, which the attacker can turn that into code execution.
- CVE-2026-109619: After fatal errors, some contexts leave global state pointing to memory that is freed when the request ends. Later requests can then read or act on that invalid state.
An attacker that successfully exploits these vulnerabilities would gain remote access to the underlying system. The security boundary then becomes the system itself, however at a minimum the attacker would have access to data and infrastructure available to the PHP process that was exploited. This could mean sensitive information in configuration files, sensitive data if this is stored locally and opportunities to use this access to move laterally into other systems in the environment.
It is important to note that, even though purported public exploits have cropped up in GitHub repositories, these are not confirmed at the time of writing and could also pose a risk to those attempting to use them. Malware hiding in proof-of-concept repositories are not uncommon.
Finding out whether you’re affected
The first thing to do is identify whether an organisation’s environment has a potential to be affected: are there any PHP deployments in the environment and, if so, are they publicly facing? Anything external would take obvious priority over internal systems, although both need to be dealt with.
It is also important to not ignore any development, test or staging environments when making the above assessment. Environments may be connected in non-obvious ways, so a compromise in a non-production environment – although itself quite serious – could even escalate to the compromise of production assets.
Additionally, any managed or third-party application and services should be looked at to ensure that the things not under your direct control are not introducing vulnerabilities in your own environment.
This is where a Software Bill of Materials (SBOM) comes in really handy, as it could serve as an initial source of truth for understanding your level of exposure.
In terms of any current Indicators of Compromise (IOCs), at the time of writing there are unfortunately few solid ones. Currently the best advice is to keep a lookout on your chosen threat intelligence sources, and be extra vigilant for things like:
- Errors coming from the PHP process itself
- Unexpected outbound connections from the PHP process or the host running the PHP engine
- Crashes in the PHP logs
Does AI change the story?
Much of the attention around PHP2Shell has focused on AI-assisted vulnerability discovery. While this is interesting, organisations face the same challenge they always have: identifying affected systems and responding quickly.
Major vulnerabilities existed before modern AI. What has changed is the speed at which vulnerabilities can be analysed, understood and potentially exploited. Attackers and defenders alike (and this is important to keep in mind) now have access to tools that can reduce the time needed to find and investigate security issues.
The unfortunate reality is that attackers only need to be right once. Defenders need to be right every time. Any reduction in the time between discovery and exploitation only increases the pressure on organisations to understand their assets, monitor emerging threats and deploy fixes quickly.
This is also why organisations should be using the same technologies and techniques that attackers are. Security testing should not be the first time weaknesses are discovered. Penetration testing is most valuable when it validates an organisation’s existing understanding of its environment and security posture. It should be treated as the exam, not the mock test.
Rather than focusing on how PHP2Shell was discovered, organisations should focus on whether they can identify exposure, deploy patches and investigate potential compromise before attackers can take advantage of it.
What should you do?
The primary recommendation is to patch as soon as possible:
Supported branches 8.2 through to 8.5
The PHP project has released fixed versions in the supported branches (8.5.12, 8.4.27, 8.3.36 and 8.2.35) and upgrading to one of these versions is the only complete remediation.
If you are unable to patch immediately, the PHP security advisory includes several temporary configuration changes that may help reduce the risk of exploitation; however, these should be treated as short-term measures and not as a substitute for patching.
End-of-life branches 5.4 through to 8.1
Organisations still running end-of-life PHP versions (5.4 through 8.1) face a trickier situation. While some controls may provide limited protection against CVE-2026-109619, no fix is available for CVE-2026-109618 on unsupported branches. If you are running an end-of-life version, you should consider migration to a supported release a priority.
As part of remediation, keep in mind that patching removes the vulnerability but does not indicate whether the vulnerability has already been exploited on your systems. Systems should be reviewed for signs of compromise and abnormal activity before being considered fully remediated.
Check the websites of the specific vendors of technologies you use in your stack (for example AWS, Azure etc.) for any guidelines around compensating controls for these vulnerabilities using their specific technologies. Both AWS and Microsoft have published advice or customers using their WAF solutions, for example.
One important point to make is that patching for and protecting against these vulnerabilities may not do much to fix an existing compromise. If you suspect one of your hosts has already been compromised, ensure that it is isolated and perform any necessary forensic investigation to determine whether it poses a threat to your environment.
Conclusion
Organisations should give PHP2Shell immediate attention and take any remediation and compensating actions as soon as possible. Beyond this, it is important for defenders to not only react to singular vulnerabilities, but to take away general lessons for the future and adjust their security postures and attitudes in the ever-changing security landscape.
As always, a great place to start is to know your assets, understand your dependencies, monitor and be prepared to patch quickly.
AI is accelerating both the discovery and exploitation of vulnerabilities, leaving organisations with less time to respond. This makes getting the security fundamentals right more important than ever. Critical vulnerabilities will continue to emerge, but organisations with strong security foundations and effective defences will be far better placed to manage the risks and limit the impact when they do.
Further reading
PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet | Wiz Blog
Patch the Planet: global response coordination as agents uncover critical vulnerabilities | OpenAI
