The code had been there for years. AI changed how quickly researchers could turn a difficult memory bug into a working attack. PHP2Shell is a lesson in what happens when software maintenance has to keep up with that change.
Independent analysis of public disclosures by the PHP project, the PHP Foundation and Wiz Research. This is not a RETRIXDEV client incident. Sources and guidance checked on .
What is PHP2Shell?
PHP2Shell is the name used for critical PHP runtime vulnerabilities disclosed in October 2026, tracked as CVE-2026-109618 and CVE-2026-109619. They can allow unauthenticated remote code execution under exploitable conditions. The immediate response is to install a fixed PHP package, restart the affected workers and verify the runtime actually serving each website.
What happened—and why it matters
On 21 October, the PHP project released an urgent security advisory and fixes across its supported branches. The two CVEs concern out-of-memory corruption and stale internal state after a request fails. PHP warned that installations serving web requests—including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed—needed attention. It identified mod_php as the highest-risk case, with an attack demonstrated before application code ran.
That location matters. A website can have a current CMS, sensible application code and a vulnerability in the interpreter underneath it. Updating a WordPress plugin or a Laravel dependency does not replace the PHP runtime. A hosting control panel can also run several PHP versions at once, with different websites assigned to different pools.
Wiz reported remote-code-execution demonstrations against WordPress, Drupal and Joomla deployments, as well as disclosure of process memory. These are reported research demonstrations, not evidence that every PHP website was compromised. Application behavior, server integration and configuration affect the available attack paths.
How a failed request can affect the next one
A long-lived PHP worker handles more than one request. Data associated with a completed or failed request must be cleaned up so later work cannot accidentally use it. The PHP advisories describe failures where that separation broke: partially initialized data could be treated as valid, or a reference could survive after the memory it pointed to had been freed.
The consequences can extend beyond a crash. Depending on the path and the surrounding conditions, memory corruption can enable code execution, while memory disclosure can reveal data the process was handling. The important distinction for an operator is between the visible symptom—a failed request—and the state left in the worker afterwards.
There are multiple variants under these CVEs. A diagram cannot capture every prerequisite, and a single configuration change does not cover every path. Use the PHP project's advisory for the technical scope and remediation guidance.
What AI changed in the research
The AI story is more useful than a claim that a model suddenly “took over the internet.” According to Wiz, frontier models helped researchers discover flaws, analyze failures, adjust to different memory layouts and validate fixes. Those repeated analysis-and-testing steps are a substantial part of making a complex vulnerability practical.
The PHP Foundation's account adds important history. The first signs of the out-of-memory problem had emerged during work following a 2024 security audit. A fix was difficult because competing approaches had compatibility, performance and ecosystem trade-offs. Reports from Calif, OpenAI and Wiz later made the impact clearer. The Foundation describes the earlier delay as a structural failure involving decision-making and limited resources.
Faster discovery only helps if a team can turn a finding into a tested fix—and get that fix into the running system.
RETRIXDEV's engineering takeaway
AI helped both sides of that workflow: understanding dangerous behavior and checking candidate fixes. It did not remove the need for experienced maintainers. The Foundation explicitly says people make the decisions and work on the patches. A tool can accelerate investigation; it cannot supply an organization with a maintenance owner, an agreed release plan or enough engineering time.
The timeline worth remembering
Early warning signs
The PHP Foundation says signs of the out-of-memory problem emerged after an external security audit; a practical fix faced difficult trade-offs.
Concrete exploit reports
Calif reported a remote-code-execution path on 11 August. Wiz says it reported its findings on 24 August. Further reports and coordinated work followed.
Public advisory and fixes
PHP released security updates after bringing the coordinated release forward. The published CVSS score was 9.2, not the 10.0 circulated before release.
Follow-up configuration guidance
PHP published an additional notice about session upload progress and an unusual serialization-handler configuration.
Timeline sources: the PHP Foundation's disclosure account and the PHP project's October announcements. Dates describe the public record, not a RETRIXDEV investigation.
Which PHP versions contain the initial fixes?
The releases below were the initial upstream fixes announced on 21 October 2026 for the two PHP2Shell CVEs. Install the appropriate current security release from your vendor, and read the later guidance too. A distribution may backport a fix without changing the displayed upstream version number.
| PHP branch | Initial fixed release | What to verify |
|---|---|---|
| 8.5 | 8.5.12 | Current vendor package and active web workers |
| 8.4 | 8.4.27 | Current vendor package and active web workers |
| 8.3 | 8.3.36 | Current vendor package and active web workers |
| 8.2 | 8.2.35 | Security package, plus an upgrade plan before end of support |
PHP 8.1 and older are outside normal upstream support. PHP provided exceptional minimal source backports for 7.4, 8.0 and 8.1; that does not restore ongoing support. Confirm an explicit fix with your distribution or LTS provider, or plan a tested migration to a supported branch. The 8.2 release announcement also notes its end of support on 31 December 2026.
A practical response for website owners
Map the runtime
List every website, PHP pool, container image and background worker. Record which package actually serves each application. A terminal's PHP version may differ from the web server's.
Patch the right layer
Use the distribution or hosting provider's security packages. For containers, rebuild and redeploy from a fixed base. Include staging and low-traffic sites in the inventory.
Replace old workers
Follow the vendor's restart procedure for the affected service. Installing a package does not prove that long-running workers are using it. Plan continuity and rollback.
Check the running system
Confirm the active web runtime and package provenance, then test login, forms, uploads, queues and scheduled work. Record what changed and who owns the next update.
On managed hosting, ask for the installed package build, the provider's advisory covering these CVEs, and confirmation that all affected workers were restarted. If an update is delayed, the PHP advisory documents temporary mitigations with limitations. Changes to memory limits and request handling need capacity and application testing; they are not a universal substitute for a patch.
Wiz suggests investigating unusual multipart requests, memory-limit errors, repeated server failures and unexplained worker churn. These are investigation leads, not proof of compromise. If other evidence points to unauthorized access, preserve relevant logs and involve the incident owner before cleaning up. Patching closes a vulnerability; it does not undo a past compromise.
The engineering lesson
The strongest response to faster vulnerability research is a shorter, repeatable path from advisory to verified deployment. Know what you run. Assign ownership. Keep builds reproducible. Practice the update and recovery steps before an urgent release arrives.
That is why this belongs in AI & Security: the case connects advances in research tools to the everyday work of maintaining software. The lasting lesson is not to abandon PHP or assume that AI replaces maintainers. It is to make the maintenance process as deliberate as the development process.
RETRIXDEV can help inventory PHP deployments, plan upgrades and check application behavior after changes. Explore our server and cloud support, read the Laravel deployment checklist, or send the current setup and the change you need.
Sources and review notes
- PHP: Critical remote code execution vulnerabilities21 October 2026 · affected integrations, initial fixed releases and mitigation limits.
- PHP: Session upload progress advisory23 October 2026 · follow-up configuration guidance.
- The PHP Foundation: Today's security release21 October 2026 · discovery history, coordination and the human work behind the fixes.
- Wiz Research: PHP2Shell21 October 2026 · research demonstrations, reported AI contribution and investigation signals.
Research demonstrations are attributed to their authors. We have not independently reproduced an exploit or measured affected websites. This article explains the public disclosures and operational lessons; consult current vendor guidance for a specific deployment.
CEO of RETRIXDEV. Leading work across web applications, mobile apps, AI automation and deployment.
About Lokesh Nain ↗
