Overview
In this post, we explain how frontier AI helped us find and fix vulnerabilities that had remained hidden in the PHP codebase for more than a decade. The issues described below all stem from key architecture decisions, some made over a decade ago, and were grouped under two CVEs, with severity reaching CVSS 9.2. The work grew into a cross-industry effort to protect customers, find variants, deploy detections and mitigations, and verify a patch in time for coordinated disclosure.

Nearly every PHP version is affected by at least one of these issues, including releases dating back to PHP 5.4. The vulnerabilities can allow unauthenticated attackers to execute code on affected servers or read sensitive process memory. That memory may contain passwords, authentication tokens, API keys and certificates belonging to other requests or the server itself.

PHP is the programming language behind much of the web, powering WordPress, Drupal and MediaWiki, the software that runs Wikipedia. A flaw in its core engine can affect websites across this ecosystem, even when their own application code is secure.

Some vulnerabilities become turning points because they challenge fundamental assumptions about security. In 2014, Heartbleed exposed the fragility of shared infrastructure securing the internet. In 2021, Log4Shell revealed how deeply embedded software dependencies could create widespread exposure that organizations struggled to identify. We believe PHP2Shell could mark a similar turning point for the AI era, illustrating 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 were critical to making this process practical, enabling us to develop and adapt working exploits across multiple applications in hours. As the time and expertise required for this work decrease, complexity may no longer provide a meaningful barrier, changing how we define what is vulnerable in practice.

Wiz Research would like to thank the PHP team, 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.

The Vulnerabilities
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 blog 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.

Impact
We combined these vulnerabilities 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: even a simple “Hello World” application running on an affected PHP version can be vulnerable.

Separately, we 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.