How AI turned decades-old PHP bugs into an Internet-Scale Security Problem
Two critical vulnerabilities in the PHP runtime have turned a familiar software-maintenance problem into something much more urgent for cloud and DevOps teams. Disclosed on October 21, 2026, CVE-2026–109618 and CVE-2026–109619 carry CVSS scores of 9.2 and can lead to unauthenticated remote code execution on affected systems. The PHP project has released fixes across its supported branches, but the exposure extends far beyond PHP itself because the runtime sits underneath a huge number of websites, frameworks, CMS platforms, and internal applications.
What makes this incident different is how the vulnerabilities were found. OpenAI and Google’s Wiz independently used advanced AI systems to investigate difficult PHP memory-safety bugs and develop working exploit chains. Wiz demonstrated unauthenticated remote code execution against current WordPress, Drupal, and Joomla container images, while OpenAI reported a separate critical vulnerability through its Patch the Planet research initiative.
The immediate advice is simple: patch the PHP runtime. The larger lesson is harder to ignore. AI is reducing the cost of finding and exploiting weaknesses in software that enterprises have depended on for years, which means runtime inventory, patch management, container hygiene, and exposure assessment are becoming more important even for applications that otherwise appear well maintained.
The Vulnerabilities are in PHP, not WordPress
PHP’s enormous installed base is what gives this incident its reach.
W3Techs currently measures PHP on 69.3% of websites where the server-side programming language is known. That is lower than the frequently repeated 77% figure, but it still represents an enormous amount of infrastructure. More concerning for defenders is the age of some of those installations: W3Techs’ October 2026 data shows PHP 7 and PHP 5 still present across a substantial portion of PHP deployments.
That distinction matters because the current vulnerabilities are in the PHP runtime itself.
A WordPress site doesn’t become vulnerable because WordPress introduced a particular insecure function. A Laravel application doesn’t become vulnerable because Laravel contains the affected code. The application can be perfectly patched while the PHP binary underneath it remains vulnerable.
WordPress has explicitly told site owners that these vulnerabilities are not WordPress-specific and that no WordPress core update is required to address them. The PHP runtime needs to be updated by the hosting provider or infrastructure team.
This is a useful reminder for cloud teams: application inventory and runtime inventory are different things.
Knowing that an organization operates 300 WordPress installations does not tell you which PHP versions those installations actually execute.
What PHP2Shell actually exploits
The two vulnerabilities involve different memory-management problems inside PHP.
CVE-2026–109618 is associated with an out-of-memory condition during request processing. Under particular circumstances, PHP can terminate processing while internal request state is only partially initialized. Cleanup code can subsequently operate on invalid or incomplete state, producing memory corruption that researchers were able to develop into an exploitation primitive.
CVE-2026–109619 involves stale global state. Information associated with one request can remain available after the memory backing it has been released. A subsequent request handled by the same worker can then interact with that stale state before the normal initialization process resets it.
Neither description sounds like the sort of vulnerability that normally generates an immediate enterprise-wide alarm.
Memory corruption bugs often require significant expertise to turn into reliable remote exploits. Attackers need to understand the runtime, memory layout, request lifecycle, configuration, mitigations, and the exact conditions under which the vulnerable code executes.
That complexity is part of what has changed. AI is getting better at navigating it.
How Wiz turned the bugs into an Exploit Chain
Wiz researchers developed what they call php2shell, an exploit chain that combines the PHP vulnerabilities with additional primitives to achieve unauthenticated remote code execution.
Their testing demonstrated exploitation against containerized WordPress, Drupal, and Joomla environments running vulnerable PHP versions. The researchers also showed that the vulnerabilities could expose sensitive information in memory, including credentials, tokens, and API keys.
The important point is not that WordPress, Drupal, and Joomla are suddenly unsafe platforms.
They are examples of applications that can sit on top of the vulnerable runtime.
Wiz’s research demonstrates why runtime vulnerabilities deserve attention even when the application layer has been kept current. The application can have no known critical vulnerability while the interpreter, runtime, web server module, or underlying library introduces the actual attack path.
That distinction becomes especially important in container environments.
A development team can update its application dependencies, pass its SAST checks, scan its source code, and deploy a clean build while still shipping an old PHP base image.
The application pipeline may be green. The runtime can still be vulnerable.
Cloud Hosting doesn’t make the problem disappear
Cloud infrastructure changes how PHP is deployed, but it doesn’t remove the dependency.
A PHP application might run inside a Kubernetes pod, a virtual machine, a managed application service, a serverless container, or a traditional Apache and PHP-FPM deployment. The underlying PHP runtime still needs to be patched.
Google Cloud’s response to the vulnerabilities makes this explicit. Its guidance tells customers to identify affected PHP workloads, rebuild or update the relevant images or runtime environments, and redeploy them with patched versions.
That creates a familiar DevOps problem.
The vulnerable component may not exist in the application’s source repository. It may exist in a base image maintained by another team. It may have been baked into an internal golden image months ago. It may be installed by a hosting provider. It may exist inside an old VM that nobody remembers still serves production traffic.
Modern infrastructure makes patching easier when everything is immutable and centrally managed.
Legacy infrastructure makes discovery the first challenge.
The Versions you need to check
The PHP project released fixes for the supported branches in response to these vulnerabilities.
Affected systems should move to:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
PHP 8.1 and older are no longer supported upstream, which makes the situation more complicated for organizations that still depend on those branches. Some operating-system vendors and commercial support providers may provide backported security patches, but organizations should verify the exact support status rather than assuming an unsupported PHP branch is protected.
The first operational question should therefore be:
Where are we running PHP, and which binary is actually executing production traffic?
Not which PHP version appears in the developer documentation. Not which version the application was originally designed for. The version running on the production worker is what matters.
A PHP Exposure audit should start with the Runtime
A useful audit needs to move beyond application names.
Start by identifying every production environment that can execute PHP. That includes direct PHP installations, PHP-FPM pools, Apache mod_php, CGI deployments, container images, managed hosting environments, and application platforms that package PHP behind a managed runtime.
Container registries deserve particular attention.
Search image definitions and dependency manifests for PHP base images, then verify the actual image digest deployed to production. An image tagged php:8.3 tells you very little by itself because the tag can point to different builds over time. Your deployment inventory should identify the exact artifact that reached production.
Next, verify the runtime from inside the deployed environment. The goal is to establish that the production process is actually running a patched release.
This sounds mundane.
It is also where many incident-response exercises discover that the organization’s asset inventory and production reality don’t match.
Rebuilding Matters More Than Restarting
Containerized applications introduce another subtle problem.
Updating PHP in a developer environment doesn’t update the PHP binary already embedded inside a production image.
If the vulnerable runtime exists in the image, the correct remediation is to rebuild from a patched base image, run the normal test suite, scan the resulting artifact, and redeploy it.
Simply restarting an old container reproduces the same vulnerable environment.
The same principle applies to machine images. If PHP is baked into an AMI, VM image, or internal base image, updating a package on one running server doesn’t necessarily remediate the next instance created from the old image.
This is where software supply-chain practices become part of vulnerability response. Your security team’s patch recommendation is only complete when the fixed runtime has propagated through the artifact pipeline and into the actual workloads serving traffic.
Don’t Assume the WAF Solves It
Network controls can help, but they aren’t the final fix.
Cloudflare deployed WAF protections ahead of public disclosure, providing a layer of defense for customers while organizations worked on patching.
That is valuable during an emergency.
A WAF can reduce exposure to known exploit patterns, buy engineering teams time, and provide additional telemetry. But it doesn’t repair the memory-management flaw in PHP.
The PHP project’s own guidance remains clear: upgrading to a fixed release is the complete remediation.
That distinction is important in cloud security because layered controls sometimes create false confidence.
A workload behind a CDN isn’t necessarily patched.
A container behind a WAF isn’t necessarily safe.
An application passing a dependency scan isn’t necessarily running a current runtime.
Compensating controls reduce risk. They don’t replace fixing the vulnerable component.
The AI Part Is the Real Story
PHP has had vulnerabilities before.
Memory corruption has existed for decades.
Legacy runtimes have remained deployed long after their maintainers recommended upgrades.
None of that is new.
What is changing is the economics of vulnerability research.
OpenAI says its researchers found one of the critical PHP vulnerabilities through its Patch the Planet initiative and were able to identify and responsibly disclose it before public exploitation. The company frames this as part of a broader “defender’s window,” where advanced AI systems can help defenders find weaknesses before attackers do.
Wiz’s research provides the other side of that equation.
Its team used AI to accelerate the investigation of the PHP memory-corruption vulnerabilities and develop a practical exploit chain. The company describes php2shell as an example of AI reducing the effort required to turn complicated low-level vulnerabilities into reliable remote code execution.
That creates a security race.
Defenders can use AI to scan more code, investigate more vulnerabilities, and develop patches faster.
Attackers can use the same technology to analyze targets, understand unfamiliar code, develop exploit chains, and adapt existing techniques.
The difficult part of an old vulnerability may no longer be enough to keep it safe.
“Hard to Exploit” is becoming a less reliable Risk Assessment
Security teams traditionally consider exploitability when prioritizing vulnerabilities.
A memory-corruption bug deep inside a runtime may receive less immediate attention than an easily exploitable authentication bypass because developing a working exploit requires more specialist knowledge.
AI changes that calculation.
If a frontier model can help a researcher understand the vulnerable code, reason about memory state, generate test cases, interpret crashes, and iterate on an exploit, then the expertise required to reach reliable exploitation falls.
That doesn’t mean every CVE becomes immediately exploitable.
It means organizations should be careful about treating technical complexity as a durable security barrier.
The php2shell research is a concrete example of that shift. The vulnerabilities had existed in the runtime for years, but the capability required to turn them into an internet-facing attack path is becoming more accessible.
The age of a vulnerability is therefore less important than the capabilities available to whoever discovers it.
This is why Runtime Inventory Matters
Most modern DevSecOps programs have become good at tracking application dependencies.
They generate SBOMs. They scan containers. They monitor packages. They integrate SAST and SCA into CI/CD. They alert when a dependency receives a critical CVE.
The harder question is whether those systems provide complete visibility into the runtime.
A PHP application might depend on a framework that is fully patched while its container inherits a vulnerable PHP image. A container scanner might identify the vulnerable package, but the finding can disappear into hundreds of other alerts if nobody owns the runtime layer.
The organizational model needs to reflect the architecture.
Application teams should know what frameworks and libraries they run. Platform teams should know which base images and runtimes they provide. Security teams should be able to correlate vulnerabilities with internet exposure and business criticality.
A CVE becomes operationally useful only when someone can answer:
Which production workload is running it, who owns that workload, how exposed is it, and how quickly can we replace it?
Legacy Infrastructure makes this Harder
The PHP incident is also a useful modernization argument, but not in the simplistic sense that enterprises should abandon PHP.
PHP itself is actively maintained. The project has released patched versions across supported branches, and PHP remains one of the most widely deployed server-side languages on the web.
The architectural problem is older infrastructure that organizations can no longer reliably inventory or update.
A PHP application running on an immutable container with automated image rebuilding is one problem.
A PHP application running on a five-year-old virtual machine, managed through undocumented scripts, with an unknown deployment owner and an unsupported runtime is another.
The language isn’t necessarily the modernization problem.
The inability to reliably patch the runtime is.
That distinction makes a much stronger CTO conversation.
Modernization isn’t only about replacing an old programming language or framework. It is about moving workloads toward an operating model where infrastructure can be identified, rebuilt, tested, patched, and replaced without depending on institutional memory.
What DevOps teams should change after this incident
The immediate remediation is to patch affected PHP installations.
The longer-term work is to make the next runtime vulnerability easier to handle.
That starts with making runtime versions visible in the same inventory used for applications and infrastructure. Container images should be traceable to their source Dockerfiles and base images. Production workloads should have identifiable owners. Unsupported runtime branches should have explicit exceptions and migration plans rather than silently remaining in service.
CI/CD pipelines should also verify runtime versions before deployment. If a base image contains a vulnerable PHP release, the build should fail before the artifact reaches production.
For internet-facing systems, exposure should feed into vulnerability prioritization. A vulnerable internal development container and a vulnerable PHP worker serving public traffic do not represent the same risk.
Finally, organizations should have a defined emergency process for runtime vulnerabilities. When a critical CVE lands, the team should already know how to identify affected workloads, rebuild artifacts, deploy fixes, inspect logs, and verify remediation.
The goal isn’t to make every security response an incident.
The goal is to make critical patching routine enough that it doesn’t require a crisis meeting to figure out who owns the server.
What we see at 0xMetaLabs
The most interesting part of PHP2Shell isn’t that PHP had two critical vulnerabilities.
Mature software will continue to have vulnerabilities.
The bigger change is that AI is beginning to compress the distance between vulnerability discovery and practical exploitation.
That changes the assumptions behind enterprise patch management.
Organizations have historically operated with some buffer between a vulnerability being discovered and an attacker being able to exploit it at scale. AI can reduce that buffer. Security teams therefore need to treat runtime visibility and patch velocity as architectural capabilities rather than administrative tasks.
A well-designed cloud platform should make it easy to answer where a runtime is deployed, what version it uses, which artifact supplied it, who owns it, and how quickly it can be replaced.
If answering those questions requires a week of manual investigation, the problem exposed by PHP2Shell isn’t only the PHP vulnerability.
It’s the platform.
The Real PHP2Shell Lesson
PHP2Shell is a serious vulnerability story because of the scale of PHP deployment and the severity of the affected runtime bugs. The AI component makes it more consequential because it demonstrates how advanced models can help security researchers work through complex vulnerabilities that once demanded highly specialized manual analysis.
The immediate response should be straightforward: identify affected PHP workloads, upgrade to fixed releases, rebuild vulnerable images, redeploy them, and investigate exposed systems for signs of exploitation.
The longer-term response belongs in platform engineering.
Enterprises need runtime inventories that are as reliable as application inventories. They need immutable artifacts, repeatable builds, automated vulnerability gates, clear ownership, and enough deployment automation to replace vulnerable infrastructure quickly.
Cloud platforms don’t eliminate legacy risk. Containers don’t eliminate runtime vulnerabilities. WAFs don’t replace patching.
And AI doesn’t make old vulnerabilities new.
What AI changes is the amount of expertise and time required to turn those vulnerabilities into something operational.
That is why the PHP2Shell incident deserves attention beyond PHP.
The security window between “someone found the bug” and “someone can exploit the bug” is getting smaller. Enterprise infrastructure needs to be designed for that reality.
