What is PHP?
Firstly, PHP (originally Personal Home Page) is a server-side scripting language built and widely used for web page development.
PHP runs code on a web server (on within a user browser) so when a user requests a page, the server executes the PHP code and fetches data from other sources e.g. a database and sends an HTML response back to a browser. The user never actually sees the PHP, just the returned result.
What Is the PHP2Shell Vulnerability and Why Does It Matter?
- PHP embargoed two critical PHP vulnerabilities (listed at the start of this article) which were only published on availability of vendor security patch updates on day of notification on 21/10/2026.
- Research uncovered multiple critical vulnerabilities in core PHP prior to this date and release, which affected over 70% of all websites in the world. Successful exploitation could allow attackers to take control of affected servers, steal sensitive data, and deface the websites running on them.
- PHP, and also incorporated via WordPress and other template platforms, is a backbone of the web: it’s the programming language powering WordPress, Joomla, Drupal, Wikipedia’s MediaWiki, and many others.
- These PHP vulnerabilities include memory disclosure and unauthenticated remote code execution in PHP itself, independent of the application running on top of it, putting every affected website in immediate risk.
- Every PHP version released in the last decade is affected by at least one of these vulnerabilities, going back to version 5.4. Attackers can exploit them remotely, in some cases fairly easily. Immediate patching is strongly advised.
- There are significant number of users operating unpatched 5.x, 6.x and 7.x versions of PHP which are affected by this issue.
- On October 21, 2026, PHP released the patch fixing multiple memory-safety vulnerabilities in the core engine. They also publicly acknowledged the existence of the vulnerability.
- Frontier AI models have enabled the chaining of multiple vulnerabilities in PHP to enable active exploitation.
What Should Boards Do About the PHP Vulnerability?
One of the two bugs (CVE-2026-109618) actually dates back to 2024 and has been very complex to solve. PHP is an open-source organisation and completed a major external security review in 2024 which is when the issue was first identified.
It presented the development team with conflicting challenges in terms of scale of architectural changes required impacting many 3rd party extensions and versus the denial of service and compromise potential.
The change impact was deemed significant and as no known exploitation path to remote code execution could be identified at the time, the development of a fix was not viewed as a critical priority.
A large number of websites operate with various versions of PHP.
It is a widely adopted and excellent technology. The scope of the issue as of 22/10/2026 from VirusTotal analysis highlights 5.1 million active IP addresses operating PHP. Only the latest version 8 is a supported PHP instance so only these (after version 8.2 to be exact) will receive the published updates to resolve CVE-2026 109618 and 109619.
The most recent scan highlighted only 85,115 PHP instances were operating at this level whilst 50.3% were on unsupported PHP versions.
In 2026, the emergence of Generative AI has enabled code review at scale and this is not and will not be the last.
A cybersecurity researcher at Calif reported the bugs to PHP on 11/08/2026. This was also validated by Wiz and Trail of Bits who confirmed AI had created a valid exploit path to these enabling remote code execution. Resolving the PHP issues immediately became a top priority as these are critical vulnerabilities.
To contain exploitation, an embargo via a coordinated disclosure process was applied until a fix had been developed, tested and was ready for release given the scale of update requirements.
Given the volumetrics involved in this issue, containing awareness of this whilst minimising exploitations has been very challenging. To everyone’s credit, it has not seen widespread exploitation until wider awareness.
Distributors received the security updates in advance of general release as part of the coordinated disclosure to expedite update processes.
- For any Board, firstly get your PHP updated and maintain it now. Today.
- Secondly, in over 50% of discussions we have with small businesses around identified external exposure issues, the businesses take no action. The technical debt builds. Third parties and developers explain there is limited risk or no known exploitable path or it will involve significant backward compatibility rework. As AI is changing this landscape very quickly, this is no longer an acceptable response for any Board.
- With over half of all PHP instances operating at an unsupported level, when critical vulnerabilities are identified and exploited at speed, technical debt creates greater risk and exposure. So the Board Question is: What is the impact to your business of taking your offline or a compromised website vulnerability?
How Much Damage Could a PHP Attack Cause?
The Blast Radius is the scope of damage a compromise prior to containment. The exploitation of these vulnerabilities which have architecturally existed in multiple PHP versions for over a decade is now enabled at speed by AI. This statement applies equally to nearly every technology stack utilised.
- The Scope: Nearly every PHP version is affected by at least one of these issues, including releases dating back to PHP 5.4. These vulnerabilities can allow unauthenticated attackers to execute code on affected servers or read sensitive process memory. The issue centres on the ability to execute additional remote commands remotely in stale memory routines. That memory may contain passwords, authentication tokens, API keys and certificates belonging to other requests or the server itself.
- Connected Technologies: PHP is the programming language behind much of the web, powering WordPress, Drupal and Wikipedia, the software that runs associated connections.
- The Blast: The PHP2Shell as this is currently known, illustrates how AI can change the practical exploitability of longstanding vulnerabilities. Building the exploit required chaining multiple flaws and adapting to each target’s memory layout through repeated testing and debugging. Frontier models have been critical to making this process practical, enabling bad actors to develop and adapt working exploits across multiple applications in hours. As the time and expertise required for this work decrease, complexity no longer provides a meaningful barrier to protection, changing how defences must change and respond faster to these newly identified vulnerabilities in practice.
CloudGuard Threat Research would like to thank the PHP team, Wiz, Trail of Bots, Recorded Future, Calif and OpenAI for their work on discovery, coordination and patch verification. OpenAI and Calif also published blogs containing details on the vulnerability, its history, technical details, and insight into the disclosure process. PHP posted as well.
We’d also like to express our sincere gratitude towards Automattic, Akamai, AWS, Cloudflare, Fastly, Google, Imperva, Microsoft, Vercel, and many others, for helping prepare guidance and out-of-the-box mitigations for customers who cannot apply the patch immediately.
How Do CVE-2026-109618 and CVE-2026-109619 Work?
All of the disclosed vulnerabilities are memory-safety issues that stem from bugs in how PHP handles fatal errors while processing requests, particularly out-of-memory errors.Â
These bugs can leave a corrupted internal PHP state behind after a request ends unexpectedly. A later request or worker can reuse that stale state, leading to memory disclosure or corruption.
Below you can find a table that demonstrates what type of impact was demonstrated by each of the bugs we reported to PHP.Â
The applications listed below are targets we chose for the RCE demonstrations. They are representative targets – exploitation does not require one of these CMSs, as the vulnerable code is in PHP itself.
While this article covers only four instances of exploitable bugs (grouped under two CVEs) that follow this problematic pattern, there are other tracked, and likely untracked, variants of this issue in the PHP codebase.
These variants have different requirements for exploitation and can lead to different types of impact. In any case, the patch provided by the PHP team fixes the issue at its core and eliminates all variants in the patched release.
Which Websites Are Affected: WordPress, Drupal, Joomla and More
These vulnerabilities were combined into a single exploit script, php2shell, and demonstrated that it could execute code remotely without authentication on deployments of WordPress (wordpress:latest), Drupal (drupal:latest), and Joomla (joomla:latest), using their latest container images at the time of testing.
These platforms illustrate the impact, but the vulnerabilities are in PHP itself. Exploitation does not depend on a flaw in the application’s code. Separately, Wiz demonstrated that attackers could read sensitive data from the PHP process’s memory, including passwords, tokens, and API keys, without needing to achieve remote code execution.
Summary: What the PHP2Shell Vulnerability Means for Your Business
Frontier AI models have made it practical to chain these flaws into a working attack in hours rather than months, and that pattern will repeat across other technologies. Only currently supported PHP 8 releases receive the fix, yet more than half of PHP websites still run unsupported versions. For those organisations, outdated software is now a direct business risk rather than a technical inconvenience.
Update PHP today, and then make sure it stays updated.
“There’s no known way to exploit it” is no longer an acceptable reason to delay a fix. If you’re unsure which versions of PHP your websites and systems are running, CloudGuard can help you find out and close the gap fast.
PHP2Shell won’t be the last. See what attackers see first.
More than half of PHP websites run unsupported versions, and AI now turns old flaws into working exploits in hours. Our free External Exposure Analysis maps your public-facing attack surface, including domains, web servers, open ports and known vulnerabilities in public-facing components.
Our security experts then walk you through the high and critical risks and how to close them. It’s non-intrusive, with no strings attached, and we run a limited number each month.
