PHP2Shell: While we were sleeping, AI found a vulnerability of staggering proportions

Disclaimer: Local AI models were used to edit, enhance and create media for this article. Humans vetted everything twice.

For those who have lost the ability to read, here is a summary video.

What Happened

On 21 October 2026, the PHP security team released an emergency patch for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, collectively dubbed “PHP2Shell.” These flaws, each rated 9.2 on the CVSS v4.0 scale (NVD later listed CVSS 3.1 9.8 for both), exist in the PHP interpreter itself rather than in specific applications. They affect PHP installations serving web requests from version 5.4 onward (roughly 70% of websites whose server-side language is known, per Wiz and W3Techs estimates).

The vulnerabilities were independently discovered by researchers at Calif (using GPT-5.6 Sol as part of OpenAI’s “Patch the Planet” initiative) and Wiz (using Wiz Atlas together with Gemini 4 Argon and GPT-5.6 Sol). OpenAI also participated in coordination, further research, and patch verification. Exploitation attempts were observed in the wild starting 17 October (Amazon MadPot honeypots, four days before official disclosure), with volume rising sharply after the 20 October leak and the 21 October release (Cloudflare reported thousands of attempts in the hours before announcement, tens of thousands within 45 minutes after, and millions shortly thereafter). In response, numerous Dutch sites—including the Tweede Kamer (House of Representatives), Tweakers, NCSC, DigiD, MijnOverheid, and others - went offline as a precaution; similar actions occurred in Finland and elsewhere.

PHP stated that no configuration change fully mitigates the issues; the only complete remediation is updating the core software

Why It Matters

The stakes are high because the vulnerability lies in the language runtime, not application code. WordPress, Drupal, Joomla, Magento, custom PHP apps, and many frameworks are therefore exposed “out of the box,” independent of how carefully their own code is written.

The episode underscores that a foundational piece of web infrastructure remains difficult to keep fully current across the long tail of deployments.

CVE-2026-109618 involves out-of-memory (OOM) handling that can interrupt PHP while request data is only partially initialized (commonly during multipart/form-data parsing); cleanup then treats the invalid state as valid, enabling use-after-free. CVE-2026-109619 involves stale request-owned global state (session, error/backtrace, object, or extension state) that can survive after its backing memory is freed; a later request on the same worker can reuse it. Both can lead to unauthenticated remote code execution and/or information disclosure (including Heartbleed-style memory reads). Risk is highest on mod_php (where exploitation can occur before application code runs); PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed are also affected.

The practical consequence is a large patching scramble. Organizations on supported branches can update - those on EOL versions must rely on vendor backports or migrate. Temporary measures (e.g., blocking multipart requests at the proxy) break legitimate file uploads.

What Others Are Saying

Broader conversation echoes Amazon/Cloudflare telemetry (attempts from 17 Oct, rapid post-disclosure volume), Dutch/Finnish precautionary outages, and the AI-assisted discovery angle (Wiz/Calif/OpenAI).

The real fix is an updated PHP version. Before it can be installed on your server, the Linux distributions and PHP repositories (Debian, Ubuntu, the sury.org PHP packages and others) have to build and publish the new packages. That can take some time, and PHP versions that are already end of life may never get a fix. — ISPConfig

Mass exploitation of PHP2Shell is less likely than we expected on release day. An attack needs specific knowledge of the target server and specific conditions on it. The public exploits do not work against a default PHP installation. You do not need to take your store offline. Update PHP anyway.” — Sansec

PHP considers the risk highest for mod_php, where an unauthenticated request can trigger exploitation before application code runs. PHP states that no configuration change fully mitigates these vulnerabilities. — watchTowr / NCSC-NL guidance

The vulnerabilities enable the creation of the following exploits: Remote Code execution, Information disclosure. Whereas both vulnerabilities can be used to achieve either. — JFrog Security Research

How this will play out

In the short term a “patch gap” exists: newer systems update while older ones lag, creating opportunity for opportunistic (and increasingly targeted) attackers. Temporary mitigations will disrupt some legitimate functionality. Over coming weeks and months the focus shifts to hunting for compromise from 17 October onward (logs, unexpected PHP files in upload directories, new admin users, cron jobs, .htaccess/`.user.ini` changes, etc.). Longer term, the incident reinforces pressure toward managed/containerized PHP environments with automated updates and away from long-lived EOL installations.

Discovery was accelerated by frontier AI models; patching and ecosystem propagation remain human- and supply-chain-bound. That asymmetry - machine-speed discovery versus slower remediation- is likely to recur.

🫤 Dileep’s Skeptical Takeaway

The speed of discovery is impressive: AI-assisted analysis helped surface and weaponize long-standing memory-management issues in a decades-old codebase. Yet the fix still depends on human engineers, package maintainers, and administrators rebuilding and redeploying across a fragmented landscape. The continued presence of PHP 5.x / 7.x / early 8.x on critical systems in 2026 is a maintenance-culture problem as much as a code problem. Blocking uploads or disabling features is a bandage - the underlying disease is the difficulty of keeping legacy runtimes current.

Sources:

- [ISPConfig – php2shell Critical PHP Vulnerabilities](https://www.ispconfig.org/blog/php2shell-critical-php-vulnerabilities-cve-2026-109618-cve-2026-109619/)

- [Sansec – PHP2Shell: PHP RCE](https://sansec.io/research/php2shell)

- [JFrog Security Research – PHP2Shell: All You Need to Know](https://research.jfrog.com/post/php2shell-all-you-need-to-know-about-cve-2026-109618-and-cve-2026-109619/)

- [watchTowr – PHP2Shell FAQ](https://watchtowr.com/intelligence/php-cve-2026-109618-faq/)

- [Tenable – php2shell FAQ](https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote)

- [Picus Security – PHP2Shell Explained](https://www.picussecurity.com/resource/php2shell-the-two-critical-php-rce-flaws-cve-2026-109618-cve-2026-109619-explained)

- [Wiz Blog – PHP2Shell: AI uncovers critical RCE vulnerabilities](https://www.wiz.io/blog/php2shell-php-rce)

- [Censys Advisory – php2shell (updating live)](https://censys.com/advisory/cve-2026-109618-cve-2026-109619/)

- [NCSC-NL GitHub – php2shell operational info](https://github.com/NCSC-NL/php2shell)

- [VulnCheck – PHP2Shell Vulnerabilities](https://www.vulncheck.com/blog/php2shell-vulnerabilities)

- [ThreatWire – PHP2Shell update now](https://www.threatwire.tech/news/php-critical-security-release-oct-21-two-cvss-9-2-flaws)

- [FOSSA – Finding and Fixing PHP2Shell](https://fossa.com/blog/php2shell-finding-fixing-cve-2026-109618-cve-2026-109619/)

- [Tanium – Responding to PHP2Shell](https://www.tanium.com/blog/php2shell-responding-to-cve-2026-109618-and-cve-2026-109619)

- [Intruder – what is php2shell](https://www.intruder.io/blog/what-is-php2shell)

- [php2shell.io – independent resource](https://php2shell.io/)

- [LFW – what we checked](https://lfw.com/blog/php2shell-cve-2026-109618-cve-2026-109619/)

- [Securelist (Kaspersky) – Description of the vulnerabilities](https://securelist.com/tr/php2shell-critical-vulnerabilities-in-php/121596/)

- [Check Point – PHP2Shell critical vulnerabilities](https://blog.checkpoint.com/security/php2shell-what-we-know-about-the-leaked-critical-php-vulnerabilities-cve-2026-109618-cve-2026-109619/)

- [PXL – php2shell: what to do now](https://pxl.no/en/articles/php2shell)

- [Help Net Security – Critical PHP vulnerabilities patched](https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/)

- [Hadrian – leaked critical PHP RCEs](https://hadrian.io/vulnerability-alerts/php2shell-leaked-critical-php-rce-cve-2026-109618-cve-2026-109619)

- [OffSec – Critical Vulnerabilities in PHP Core](https://www.offsec.com/blog/php2shell-critical-vulnerabilities-in-php-core/)

- [SecurityWeek – Exploitation started days before patches](https://www.securityweek.com/php2shell-exploitation-started-days-before-patches/)