PHP2Shell (CVE-2026-109618 and CVE-2026-109619): the AI-assisted PHP flaws, affected versions, patches and early exploitation

Update, October 23, 2026: Linux's kernel security rules tell anyone who finds a kernel bug with AI to treat it as public. See the Linux kernel disclosure story.

Update, October 23, 2026: PHP published an informational advisory for a separate, related issue, CVE-2026-115560, and suggests keeping session.upload_progress.enabled=0 until its next regular release (see the mitigation section). NVD has scored CVE-2026-109619 8.1 under CVSS v3.1. This story now quotes Amazon's post as it reads on October 23: PHP2Shell "is now seeing broad exploitation attempts in the wild." There have been no new PHP releases since October 21.

PHP2Shell is the name Wiz gave to two critical security flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, which the PHP project fixed on October 21, 2026. Both let an unauthenticated attacker run code on some PHP web servers, and both were found with heavy help from AI models. Amazon says attackers were already probing for them on October 17, four days before the patches shipped.

This story is based on the PHP project's advisory and GitHub security advisories, the PHP Foundation's post, Wiz's research, Amazon's threat-intelligence post and security bulletin, Cloudflare's post, the NVD records, CISA's Known Exploited Vulnerabilities catalog, and reporting by BleepingComputer, The Next Web and Techzine, checked October 22 and re-checked October 23, 2026. How the disclosure was coordinated is the subject of our companion analysis of OpenAI's Patch the Planet framework.

The short version

• What: two remote code execution bugs in how PHP handles out-of-memory errors and leftover request state.
• Fixed in: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released October 21, 2026.
• Severity: CVSS v4.0 9.2 from PHP for both; NVD's own CVSS v3.1 scores are 9.8 for CVE-2026-109618 and 8.1 for CVE-2026-109619; early leaks said 10.0.
• Exploited: Amazon reports exploitation attempts starting October 17; whether any succeeded is unclear, and how well the early exploits worked is disputed. CISA hadn't listed either CVE as known exploited as of October 23.
• AI's role: Calif (using OpenAI's GPT-5.6 Sol), OpenAI and Wiz reported the bugs; a human PHP developer first saw signs of one in 2024.

What is PHP2Shell?

Two bugs with a shared root. CVE-2026-109618 ("RCE via OOM corruption"): when PHP runs out of memory, it can be interrupted while request data is only partly set up, and cleanup then treats the invalid data as valid. CVE-2026-109619 ("RCE via stale global state"): state from one request can outlive its memory, and the next request handled by the same worker may use it before it's reset.

PHP's advisories say the first was confirmed as unauthenticated code execution, as the web server's user, against Apache mod_php with default settings; PHP-FPM is "susceptible in principle," and FrankenPHP and LiteSpeed likely are. PHP rates the risk "highest for mod_php." For the second CVE, the strongest case uses PHP 8.5 with fatal_error_backtraces enabled, and a session-handling path was validated against both mod_php and FPM.

Wiz says it used the bugs for pre-authentication code execution against the then-current WordPress, Drupal and Joomla container images, and that "even a simple 'Hello World' application" on an affected version can be vulnerable.

Which PHP versions are affected, and where are the patches?

Last verified: October 23, 2026

PHP says Linux distributions and long-term-support vendors got the patches in advance, and that distribution builds may carry the fix without changing the upstream version number. Amazon's bulletin 2026-143, last updated October 22, says updated Elastic Beanstalk PHP platform versions are out for PHP 8.2 through 8.5, Amazon Linux packages are out for commercial regions, and Lightsail users must create new instances from updated blueprints. OpenAI published a version checker, openai/php2shell-checker, which reads only version headers; its README warns that "UNKNOWN does not mean the target is patched."

On old branches, PHP links source backports for 7.4, 8.0 and 8.1 "to help people building from source," while Amazon's bulletin says 5.4 through 8.1 have "no upstream fix released": patches exist in the source tree, but no official releases.

Is PHP2Shell being exploited?

Amazon says yes. Its October 21 post by CISO CJ Moses says a MadPot honeypot logged an exploitation attempt on October 17 from a commercial anonymization network, and that it "remains unclear how the actor acquired exploit information prior to disclosure." Proof-of-concept exploits appeared around 02:00 UTC on October 21, and more followed within hours of the patch. "PHP2Shell is now seeing broad exploitation attempts in the wild," Amazon says, adding that its analysis is ongoing and "it's unclear if any of these attempts would have succeeded in real-world systems." CISA hadn't added either CVE to its Known Exploited Vulnerabilities catalog as of October 23, and CISA's October 21 assessment in the CVE records lists exploitation as "none."

The details had leaked first. The PHP Foundation says the CVE IDs appeared online around 15:00 UTC on October 20 with a wrong 10.0 score, so the release was moved up a day; Calif then mistakenly posted a proof-of-concept video that spread. BleepingComputer reported on October 22 that, according to the PHP team, the proof-of-concept exploits published before the patches were not functional.

PHP2Shell from first report to exploitation, 2026

1. Aug. 11Calif and OpenAI report the out-of-memory root causePHP FoundationConfirmed
2. Aug. 24Wiz reports further attack pathsPHP Foundation; WizConfirmed
3. Oct. 17First exploitation attempt on an Amazon honeypotAmazonReported
4. Oct. 20, ~15:00CVE IDs leak with a wrong 10.0 scorePHP FoundationConfirmed
5. Oct. 21, 03:02Cloudflare starts WAF protectionsCloudflareConfirmed
6. Oct. 21, 07:41Chainguard publishes fixed images earlyPHP FoundationConfirmed
7. Oct. 21PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 releasedPHPConfirmed

• Confirmed
• Reported

Cloudflare says it deployed managed WAF rules from 03:02 UTC on October 21, about nine hours before disclosure, including for Free plans, and saw attackers "mutating the attack payload." The PHP Foundation criticized Chainguard for publishing fixed images at 07:41 UTC, before the coordinated release. Chainguard CEO Dan Lorenc told The Register, as relayed by Techzine, that the company found the same bugs with its own AI harness after a researcher tipped it off, and helped test the patches.

How bad is it? Severity claims side by side

Alexandre Daubois of the PHP security team wrote that the panic was right about severity, but that the widely shared session.upload_progress setting only addresses CVE-2026-109619.

How do I patch or mitigate PHP2Shell?

Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution's patched build. PHP says "there are no complete mitigations." If you can't update right away, its advisory lists partial measures:

• CVE-2026-109618: set memory_limit=-1 (ideally with php_admin_value), cap post_max_size at 8M (32M if you need uploads) with upload_max_filesize below it, and use a container or cgroup memory limit. Don't use RLIMIT_AS or RLIMIT_DATA, which can trigger the bug.
• CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini or the FPM pool (not ini_set() or .user.ini) and restart every worker; on PHP 8.5 also set fatal_error_backtraces=0.

On October 23, PHP added an informational advisory for a separate issue, CVE-2026-115560, which it calls "an unlikely RCE vector." It needs an unusual setup: an application sets session.serialize_handler to php_binary or php_serialize in its configuration, then switches it to php with ini_set() before session_start(), with session upload progress still enabled. PHP suggests setting session.upload_progress.enabled=0 until its next regular bugfix release; if you applied that setting for CVE-2026-109619, keep it. PHP says it will handle the issue in the regular release cycle and publish a full advisory then, so the October 21 releases aren't described as fixing it.

Amazon adds: consider blocking multipart uploads, look for POST requests containing PHP_SESSION_UPLOAD_PROGRESS, start investigations from October 17, and treat critical internet-facing fixes on hour-scale timelines rather than 7- or 30-day targets. That pressure is growing, as Microsoft's record October Patch Tuesday showed. For the same week's AI supply-chain incident, see our LiteLLM 1.107.0 guide.

Was PHP2Shell really found by AI?

Mostly, with an important human footnote. The PHP Foundation says signs of the out-of-memory bug first surfaced in 2024, when a PHP core developer was fixing an issue from an external audit by Quarkslab arranged through OSTIF; the fix stalled, which the Foundation calls "a structural failure." Calif's researcher, working under OpenAI's Patch the Planet program, and OpenAI reported the root cause on August 11, 2026. OpenAI says Calif used GPT-5.6 Sol. Wiz reported further attack paths on August 24 and says Gemini 4 Argon, GPT-5.6 Sol and its own Wiz Atlas helped with discovery, exploit development and patch validation. The Foundation adds that Alpha-Omega scanned PHP earlier in 2026 with Anthropic's Claude Mythos, the model behind the OSS Scanner. GitHub's advisories credit reporters lcfr-hax, sagitzadik-wiz, tomash-areion and amyb-oai.

AI also cuts the other way: the Foundation says its security team now gets "far more reports than before," more than 100 of them invalid, duplicate or unreproducible since July 1.

What's confirmed, reported and uncertain

• Confirmed (PHP): the two CVEs, 9.2 scores, fixed versions, affected server setups, mitigations, the October 20 leak, and the October 23 advisory for CVE-2026-115560.
• Confirmed (NVD, CISA): NVD's 9.8 and 8.1 scores; no KEV listing as of October 23.
• Confirmed (vendors, about their own actions): Amazon's bulletin and honeypot observations, Cloudflare's rules, OpenAI's checker.
• Reported: the PHP team's view that pre-patch exploits weren't functional (BleepingComputer); Chainguard's account (Techzine, citing The Register).
• Uncertain: how the October 17 attacker got exploit details, whether any exploitation attempt succeeded, how many servers have been compromised, and whether PHP-FPM setups can be reliably exploited.