PHP2Shell is the name given to two critical security vulnerabilities in PHP. PHP is a programming language used to build websites and online applications. The software that runs PHP on web servers supports platforms such as WordPress and Drupal. The vulnerabilities affect this underlying software, putting websites that depend on it at risk.
On 21 October 2026, government agencies and other organisations took websites offline while responding to the disclosures. PHP issued emergency security updates after information circulated ahead of the planned release. Website operators and hosting providers had to identify affected systems and apply the fixes urgently.
The weaknesses could allow an attacker to run commands on an affected server without logging in. Depending on the server's setup and the permissions available to PHP, this could expose data, allow changes to website content or disrupt a service. A website could be affected even if its own code was secure, because the problem was in the software running beneath it.
Some operators temporarily withdrew services to reduce the risk while updates were prepared or applied. Those shutdowns were precautionary measures, not proof that every affected website had been hacked. They nevertheless left users unable to reach services they normally relied on.
Why AI Changes the Risk
Some affected versions are more than a decade old. Researchers identified vulnerable versions as far back as PHP 5.4, released in 2012. The PHP Foundation says developers found signs of one underlying problem in 2024, but had not established a practical way to exploit it. The 2026 research demonstrated how serious the consequences could be.
AI-assisted research helped researchers show how longstanding PHP weaknesses could be turned into working attacks. This gave the maintainers clearer evidence of the danger and helped establish the need for fixes.
The software can stay the same while the risk changes. A weakness once considered difficult to exploit may become easier to use as research tools improve. AI can help defenders find these problems, while similar capabilities may also help attackers analyse fixes and develop attacks more quickly.
The evidence here concerns AI-assisted security research. It does not establish that autonomous AI agents carried out the reported attacks. The wider concern is the time between discovering a serious weakness and protecting the systems that depend on the affected software.
This is also a governance issue: warnings need to reach the people responsible and lead to protective action. PHP2Shell illustrates why those connections matter when a shared software weakness affects many services at once.
The software beneath: PHP runs on servers like these, underneath the websites people see. Photo: Thomas Kvistholt, Unsplash (CC0).
The Technical Detail Behind PHP2Shell
Two Vulnerabilities in the PHP Runtime
PHP2Shell covers two vulnerability classes in PHP's core runtime. CVE-2026-109618 and CVE-2026-109619 both carry a critical CVSS v4.0 score of 9.2. Exploitability depends on the server configuration and the attack path.
CVE-2026-109618: out-of-memory corruption. PHP's handling of an out-of-memory error can interrupt processing while internal request data is only partly initialised. The shutdown process may then act on invalid memory. Researchers demonstrated that this can lead to unauthenticated remote code execution.
CVE-2026-109619: stale global state. A PHP worker can retain references to data from a request after the memory holding that data has been freed. A later request handled by the same worker may access those references before normal initialisation resets them. This use-after-free condition can enable memory disclosure or remote code execution through suitable attack paths.
PHP identified Apache with mod_php as the highest-risk configuration, with an exploit demonstrated before application code begins running. This explains why controls implemented inside an application cannot be relied on to stop that path. Other PHP deployments also require assessment; the demonstrated attack paths and prerequisites differ.
Longstanding Exposure, Newly Demonstrated Impact
Wiz identified affected releases dating back to PHP 5.4, released in 2012. That does not mean both vulnerability classes were entirely unknown for fourteen years. The PHP Foundation says signs of the underlying out-of-memory problem were identified in 2024, although practical exploitation had not been established then. It acknowledged that technical trade-offs, decision-making and resource constraints had delayed remediation.
OpenAI says Calif used its models through the Patch the Planet initiative. Wiz describes using AI to investigate the weaknesses and develop working exploit chains in controlled environments. PHP's maintainers led the fixes and release.
The coordinated disclosure plan was disrupted on 20 October when vulnerability identifiers circulated publicly. The PHP Foundation says a mistakenly published demonstration video later exposed limited technical information. The project brought its planned release forward from 22 to 21 October 2026.
Amazon Threat Intelligence reported an exploitation attempt against its MadPot honeypot network on 17 October, before the public announcement, and further attempts on 21 October. It said the effectiveness of the pre-release attempts against real systems was unclear, while subsequently reporting broad exploitation attempts in the wild. These accounts do not establish that autonomous AI agents conducted the attacks. Amazon also warns that AI-assisted analysis lowers the cost of turning patches into working exploits.
Remediation and Evidence of Completion
PHP released fixes in 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Operators need the appropriate fixed PHP release or an applicable vendor-patched package. Vendor backports can retain an older version number, so package details and vendor confirmation matter.
Updating WordPress alone does not fix the underlying PHP vulnerabilities. The PHP runtime must be addressed, whether it is managed internally or by a hosting provider. Technical teams should verify that the fixed build is running across affected services, including after required worker restarts.
Temporary controls can reduce exposure to particular attack paths, but PHP states that an update is the complete solution. EU cybersecurity authorities advised considering isolation of exposed applications where immediate remediation was impractical.
Closing a remediation task should require evidence that the protection is in place. Applying a fix addresses the vulnerability; it does not establish whether an earlier attack succeeded. Potentially affected systems also need investigation for signs of compromise.
