PHP2Shell: AI-assisted research found two critical PHP RCE flaws

01What happened

Wiz Research published PHP2Shell on October 21, 2026, the same day the PHP project released the four versions that fix it. The PHP security team assigned CVE-2026-109618 and CVE-2026-109619, rated both CVSS v4.0 9.2 and labelled them Critical. Wiz names Sagi Tzadik, Shir Tamari, Nir Ohfeld and Tomer Schwartz as the authors, and says OpenAI and Calif helped with discovery, coordination and patch verification.

02How it works

Both flaws begin when PHP aborts a request mid-way, most reliably through an out-of-memory condition. The PHP advisory explains that PHP uses longjmp() to leave the current context on out-of-memory, which can leave request memory invalid while request shutdown later reads or branches on it. The second flaw lets request-owned internal state outlive the memory behind it, so a later request on the same worker can use that stale state before initialization resets it. The patch drops longjmp() for out-of-memory in favour of a delayed soft limit and an immediate _exit() at a higher threshold.

03Who is affected

Every PHP installation serving web requests is at risk, according to the PHP project, which lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The project reports confirmed unauthenticated code execution as the web worker account against mod_php with default settings, and says FPM and FrankenPHP are susceptible on source analysis, with FPM exploitation not fully demonstrated. Wiz says every PHP release of the past decade carries at least one of the bugs, back to PHP 5.4, so applications are exposed even when their own code is sound.

04What to do

Update to one of the four patched releases listed below, which the PHP project calls the only complete fix, or take the patched packages from your distribution. If an update must wait, the project's advisory lists partial measures and says none makes an installation safe. 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 churn.

Questions people ask

Which PHP versions fix CVE-2026-109618 and CVE-2026-109619?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix both flaws, and all four shipped on October 21, 2026. The PHP security team also published minimal source backports for PHP 7.4, 8.0 and 8.1 on branches in php-src, because those lines no longer receive project updates. Linux distributions and LTS vendors received the patches in advance of the announcement.

Will PHP 8.1 and older get an official patch?

PHP 8.1 and earlier no longer receive updates from the PHP project, which instead published minimal source backports for 7.4, 8.0 and 8.1 to help people building from source. The project advises contacting a distribution or LTS vendor for packaged fixes, or upgrading to a supported version, and warns that the volunteer-maintained rpms.remirepo.net had no update on release day.

What can I do if I cannot patch PHP immediately?

The PHP project lists partial measures and states plainly that none makes an installation safe: setting memory_limit to -1 somewhere applications cannot override, lowering post_max_size, disabling session.upload_progress.enabled, and on PHP 8.5 setting fatal_error_backtraces to 0. Each blocks a confirmed path rather than the class of flaw. The project also warns against substituting RLIMIT_AS or RLIMIT_DATA.

How did AI contribute to finding PHP2Shell?

Wiz says it used Wiz Atlas together with Gemini 4 Argon and GPT-5.6 Sol, and that the models helped adapt working exploits across PHP versions, configurations and memory layouts by analysing failures and iterating on fixes. Wiz credits Gemini 4 Argon with contributing to discovery, exploit development, attack detection and patch validation. Those claims come from Wiz's own write-up.

How would I hunt for PHP2Shell exploitation?

Wiz suggests looking for unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, unusually large or malformed PHPSESSID cookies, and unexplained PHP worker churn. The PHP advisory describes a demonstrated exploit against mod_php that fires before any application code runs, so web server and PHP-FPM error logs are the first place to look.

Sources 3 links, all fetched

1. 1wiz.ioWiz Research Post
2. 2php.netPHP Security Advisory
3. 3github.comPHP Source Advisory