PHP2Shell Explained: The Critical PHP Flaw AI Helped Find, and What to Do Now

Last updated: 23 October 2026. This is a fast-moving story; we will update this post as official guidance changes.

The short version

PHP2Shell is the name given to two critical vulnerabilities in the PHP engine itself — CVE-2026-109618 and CVE-2026-109619, each rated 9.2 (CVSS v4.0) — that can let an attacker run code on a server without logging in. They were found with the help of AI models, and the PHP project released fixes on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

If you run PHP anywhere — WordPress, Laravel, Drupal, Magento or custom code — the action is simple and urgent: make sure the PHP runtime that serves your website is on one of those versions (or a vendor build that includes the fix), restart PHP, and check your logs.

What is PHP2Shell?

The flaws sit in how PHP handles requests at a very low level, below any framework or CMS — which is why a perfectly written application can still be vulnerable.

According to Wiz Research, which co-discovered the issues, the problems are triggered when a PHP worker runs out of memory while processing a request. That can leave corrupted state behind in the worker, which a later request handled by the same worker can then abuse. The researchers describe paths involving multipart file-upload handling and session handling, and a memory-disclosure issue that works even if an application never starts a session. Wiz states that every PHP version released in the last decade is affected by at least one of the two flaws, going back to PHP 5.4.

Because the bug is in PHP itself, Wiz reports that even a trivial “Hello World” script on an affected version can be exposed. Its researchers confirmed unauthenticated remote code execution against both Drupal and WordPress within days of finding the first issue.

How AI helped find it

AI did not find PHP2Shell on its own — but AI models were central to how quickly human researchers found, understood and weaponised the flaws.

• Calif, an AI red-teaming firm taking part in OpenAI’s “Patch the Planet” initiative, chose PHP as a high-impact target and, as reported by Fortune, found the first issue on 1 August 2026 using OpenAI’s GPT-5.6 Sol. OpenAI then investigated further and helped coordinate disclosure.
• Wiz Research independently found the vulnerabilities, with its first discovery on 19 August 2026, using Google’s Gemini 4 Argon, GPT-5.6 Sol and its own Wiz Atlas tooling. Wiz credits AI with contributions to discovery, exploit development, attack detection and patch validation.
• The issues were reported to the PHP security team on 24 August, and fixed releases shipped on 21 October after a coordinated process.

Why this matters beyond PHP

For years, bugs this deep in a mature, heavily reviewed runtime were rare and slow to find. PHP2Shell shows that AI-assisted research can now uncover and exploit them in days. The uncomfortable corollary, which OpenAI itself acknowledged, is that the same capabilities help attackers. The window between disclosure and mass exploitation is shrinking — and so is the time defenders have to patch.

Is it being exploited?

Reports point to active, large-scale exploitation attempts, so treat unpatched servers as at risk now.

• Amazon Web Services reported on 21 October that the flaw was “now being broadly exploited in the wild”, and that it had seen some attempts before public disclosure.
• Cloudflare reported tens of thousands of exploit attempts within 45 minutes of the news spreading, rising to millions by that evening, according to CEO Matthew Prince as quoted by Fortune.
• Other early reports were more cautious about confirmed compromises and working public exploit code. Either way, the safe assumption for an unpatched public server is that it is being probed.

How hosting providers are responding

Most major platforms moved quickly, but “my host handles it” is only true if you check — and some responses are temporary mitigations, not fixes.

The weak spot across providers is old PHP. The PHP project only ships fixed releases for 8.2 to 8.5. Sites on PHP 8.1, 7.x or 5.x depend on a host or vendor backporting the fix — or need to be upgraded.

How PHP developers should respond: a step-by-step plan

1. Find every PHP runtime you are responsible for

Production, staging, development servers, Docker images, CI runners and forgotten client sites. Shadow environments are where breaches start.

2. Check the version that serves web requests — not the command line

The PHP you see with php -v in a terminal is often not the PHP-FPM, mod_php or LiteSpeed process serving your site. Check the web runtime directly, for example with php-fpm8.4 -v (adjust for your version) or a temporary, access-restricted phpinfo() page that you delete straight afterwards.

3. Update to a fixed build

• Upstream versions: 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later.
• Linux distributions (Debian, Ubuntu and others) often backport fixes while keeping an older version string. Confirm the fix by checking the package changelog for the CVE numbers rather than trusting the version number.
• Docker: rebuild images on a patched base image tag and redeploy — a running container does not update itself.
• Managed or shared hosting: updating WordPress or Laravel does not update PHP. Ask your host, in writing, which build you are on and whether it includes the fix for both CVEs.

4. Restart PHP properly

New packages do nothing until the PHP processes restart: restart PHP-FPM (for example systemctl restart php8.4-fpm), Apache for mod_php, or the lsphp processes on LiteSpeed.

5. Upgrade anything older than PHP 8.2

Treat PHP 8.1 and older as unpatched unless a vendor explicitly confirms a backport. Note that PHP 8.2 itself reaches end of life on 31 December 2026, so plan the move to 8.3 or later now.

6. Use mitigations only as a bridge

If you genuinely cannot patch today, put the site behind a WAF with PHP2Shell rules, restrict access where possible and consider temporarily blocking multipart uploads at the web server if your application can live without them. The PHP project is clear that there are no complete mitigations. Separately, on 23 October PHP published an informational advisory for a different issue (CVE-2026-115560) recommending session.upload_progress.enabled=0 until the next regular release — sensible to apply, but not a substitute for the PHP2Shell update.

7. Look for signs of attack — and rotate secrets

Wiz suggests watching for unusual multipart requests followed by memory-limit errors, repeated HTTP 500 responses, unusually large or malformed PHPSESSID cookies and unexplained PHP worker restarts. Because one flaw can leak data from other requests, consider rotating secrets that pass through your PHP apps — database passwords, API keys, payment and email credentials — if a server was exposed while unpatched.

8. Reduce the blast radius for next time

• Run PHP with least privilege and keep credentials out of web-readable files.
• Limit what a compromised server can reach — cloud roles, databases and internal networks.
• Automate runtime patching and keep an inventory of every PHP version you run.
• Send logs off-server so an attacker cannot erase them.

What this means for businesses running PHP sites

PHP2Shell is a reminder that “the website works” and “the website is secure” are different things — and that the gap between a vulnerability being found and being exploited is now measured in hours. If your site was built by an agency or freelancer who no longer maintains it, find out today who is responsible for patching the server it runs on.

Frequently asked questions

Am I affected if I use WordPress or Laravel?

Very likely, unless your PHP runtime is already on a fixed build. The vulnerabilities are in PHP itself, so the framework or CMS on top does not protect you, and updating WordPress or Laravel does not update PHP.

Does a WAF like Cloudflare fully protect me?

No. WAF rules block known attack patterns for traffic that passes through the WAF. They are a useful stopgap while you patch, but attackers can find new paths, and direct traffic to your server bypasses the WAF entirely.

Which PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026, or distribution and host builds that backport the fix for CVE-2026-109618 and CVE-2026-109619.

Did an AI agent hack PHP?

Not by itself. Security researchers at Calif and Wiz used AI models to find the flaws, understand them and build working exploits far faster than traditional methods. Humans directed the research and coordinated disclosure with the PHP project.

I am on PHP 7.4 or 8.1. What should I do?

Upgrade to a supported PHP version as a priority. Until then, ask your host or vendor whether they have backported the fix, isolate the server and put it behind a WAF.

Need help checking or patching your PHP stack?

Obii Kriationz has built and run PHP applications since 2009. We can audit your servers and PHP versions, patch and harden them, and upgrade legacy applications to supported PHP — see our DevOps services, vulnerability testing and Laravel development, or talk to us today.

Sources

• PHP.net — security advisory and releases, 21 October 2026; informational advisory, 23 October 2026
• Wiz Research — PHP2Shell: AI uncovers critical RCE vulnerabilities
• Fortune — AI helped discover the PHP vulnerability
• The Hacker News — PHP2Shell: what actually protects you
• Help Net Security — PHP2Shell vulnerabilities patched