AI helped find two critical PHP flaws; patches are out

On 21 October 2026, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical security flaws. Its security advisory says they “can allow unauthenticated remote code execution”: in plain words, an attacker who has no account on a website could make its server run their own code. The researchers who found them call the family PHP2Shell, and say AI did much of the work. The Wall Street Journal broke that part of the story in an exclusive, announced on X as “one of the most severe online bugs ever”.

What happened, in plain words

PHP is the programming language behind a large share of websites, including WordPress, Drupal and Joomla. When a visitor opens a page, a PHP “worker” on the server handles the request, then moves on to the next one.

The two flaws are in how PHP cleans up when something goes wrong mid-request, for example when it runs out of memory or hits a fatal error. According to the first GitHub advisory, running out of memory at the wrong moment can leave the request’s data half set up, and the cleanup step then treats it as valid. According to the second advisory, some internal state can outlive the memory it points to, and the next request handled by the same worker can use that leftover state. Both are memory-safety bugs. A skilled attacker can shape what ends up in that memory and turn it into control of the server.

	CVE-2026-109618	CVE-2026-109619
PHP’s name for it	RCE via OOM (out-of-memory) corruption	RCE via stale global state
Severity (CVSS v4.0)	9.2, critical	9.2, critical
Login needed	No (privileges required: none)	No (privileges required: none)
Attack complexity	High	High
Confirmed exploit	Apache with mod_php, default input and memory limits	mod_php; the session upload path was also validated on PHP-FPM
Fixed in	8.5.12, 8.4.27, 8.3.36, 8.2.35	8.5.12, 8.4.27, 8.3.36, 8.2.35

PHP’s advisory says everyone serving web requests with PHP is at risk, “including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed”, and that the risk is highest for mod_php, where an unauthenticated request can trigger the attack before any of the site’s own code runs. For PHP-FPM, the most common setup behind nginx, the GitHub advisories are more careful: one says source analysis supports FPM being affected but no complete FPM exploit was shown for that flaw; the other confirms a working FPM attack that depends on a suitable path in the application.

The severity score of 9.2 out of 10 is high but not the maximum, because PHP rates the attack as complex and dependent on conditions. The researchers’ advisory website says they showed pre-login code execution on WordPress, Drupal and Joomla, and that even a simple Hello World test page on an affected PHP version can be vulnerable. It also describes a way to read passwords, tokens and keys from the server’s memory.

Who found it, and which AI

The research came from Wiz Research (Sagi Tzadik, Shir Tamari, Nir Ohfeld and Tomer Schwartz), with Amy Burnett of OpenAI Codex Security and Ryan A. of Calif, according to the advisory website. In Wiz’s write-up, the team says it used its own tool, Wiz Atlas, and two frontier models, Google’s Gemini 4 Argon and OpenAI’s GPT-5.6 Sol, and that Gemini 4 Argon made “an invaluable contribution to finding the vulnerability, exploit development, attack detection, and validation of the patch”. Sagi Tzadik wrote on X: “As expected in 2026, AI did most of the work here.”

Wiz says the flawed code had been in PHP for more than a decade. What AI changed, in its account, was turning it into working attacks: the team says “a single researcher completed in a week what previously would have taken a world-class team months of work”. Its timeline: first flaw found on 19 August 2026, reported to PHP on 24 August, patched and disclosed on 21 October.

The leak

Disclosure did not go to plan. PHP gave advance notice on 20 October of a release at 14:00 UTC on 21 October, and said it might release earlier if details became public or attacks appeared. Security firm Huntress reported that details leaked online on 20 October, before the patches. A news flash on X said the patch was pushed “A DAY EARLY AFTER DETAILS LEAKED OUT”; PHP’s own pages show the fixed releases dated 21 October, the day it had announced.

What “70%” means

The figure is PHP’s share of websites, not the share known to be vulnerable. W3Techs says PHP is used by 69.3% of websites whose server-side language it can detect. The WSJ headline says up to 70% of the world’s websites are at risk. How many of those sites are actually exploitable depends on their PHP version, setup and whether they have already updated, and no source gives that number.

Has AI found serious bugs before?

Yes, several times, though not at this scale.

• Google Big Sleep, 2024. Google’s Project Zero and DeepMind reported that their AI agent found an exploitable memory bug in SQLite, a widely used database. It was caught before it reached an official release, so no users were affected.
• Google OSS-Fuzz with AI, November 2024. Google said adding AI-written tests to its open-source fuzzing service found 26 new vulnerabilities, including CVE-2024-9143 in OpenSSL.
• DARPA AI Cyber Challenge, August 2025. In the final round, teams’ AI systems found 54 of the competition’s planted vulnerabilities and 18 real ones in open-source code. Team Atlanta won.

How this one compares

Those earlier cases showed AI could find real bugs, usually one at a time, often in less exposed code, and in Big Sleep’s case before release. PHP2Shell is different in three ways. It sits in the language runtime under a large part of the web, not in one app. The researchers say they built working pre-login attacks on the three best-known PHP content systems, not just a crash. And AI was used for the hardest step, turning a complex memory bug into a reliable exploit across different setups, which Wiz says used to take a top team months.

The leak also shows the downside: Huntress reported that details were out a day before the fix, so attackers and defenders were working from the same information at the same time.

Who should care

• Anyone who runs a PHP site on their own server or virtual machine, including WordPress, Drupal, Joomla, Magento or custom code. Updating WordPress or a plugin does not update PHP itself; the advisory website makes this point.
• Hosting providers and agencies that run PHP for many customers, especially on Apache with mod_php, which PHP names as the highest-risk setup.
• Anyone still on PHP 8.1 or older. The PHP project no longer updates these versions. Its advisory says some Linux distributions and long-term support vendors provide fixes, and the PHP security team published minimal source patches for 7.4, 8.0 and 8.1.
• People on managed hosting should check that their host has updated, rather than assume it.

What to do now

These steps come from PHP’s security advisory and the two GitHub advisories.

1. Check your PHP version. The phpinfo() function shows the version the web server is actually using; the command-line version can differ. Hosting control panels usually show it too. Check every server and container, since the advisory website says nearly every release back to PHP 5.4 is affected by at least one of the issues.
2. Update to a fixed version: 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (see the ChangeLog). PHP says Linux distributions received the patches in advance, so check your distribution for updated packages. Then restart Apache, PHP-FPM and any long-running PHP workers.
3. If you use the volunteer-run rpms.remirepo.net packages, PHP urges switching to distribution packages or building from source, because that repository would not have updates on 21 October.
4. On PHP 8.1 or older, contact your vendor for backported fixes, use the PHP team’s minimal patches for 7.4 to 8.1 if you build from source, or upgrade to a supported branch. PHP 8.2 itself reaches end of life on 31 December 2026.
5. If you truly cannot update today, PHP lists measures that reduce exposure but “do not make an installation safe”:
   • For CVE-2026-109618: set memory_limit=-1 in a way applications cannot override (for example php_admin_value), set a low post_max_size (8M without uploads, 32M with them) with upload_max_filesize below it, enforce request limits at the web server or proxy, and use a container or cgroup memory limit, not RLIMIT_AS or RLIMIT_DATA.
   • For CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini or the server or pool configuration (not ini_set() or .user.ini) and restart every worker; on PHP 8.5, also set fatal_error_backtraces=0; remove invalid or deprecated per-request settings; and fix fatal errors and timeouts that an attacker could trigger.

PHP’s release notes put it simply: “There are no complete mitigations, updating is the only safe choice.”

Our take

This is an opinion.

PHP2Shell is the clearest case so far of what AI does to software security: it makes the hard part cheap for both sides. The bug class had sat in PHP for over a decade, not because nobody looked, but because turning it into an attack was too much work. Frontier models removed that barrier for a defensive team, which reported it, helped verify a fix and coordinated with hosts and cloud providers. That is the good outcome.

The leak shows the other one. Wiz itself warns that AI lowers the barrier to adapting and scaling attacks, so the time between a fix and mass exploitation is shrinking. We think that changes what updating promptly, as Huntress urges, means: for internet-facing PHP, it now means hours, not the next maintenance window. It also strengthens the case, central to the wider debate about whether advanced AI is dangerous, for giving defenders early access to the most capable models. Here the AI-assisted defenders got there first. Nothing guarantees they always will.

Correction, 22 October 2026: an earlier version put the words patch promptly in quotation marks without a source. It now says updating promptly, as Huntress urges, and links the word worker to PHP’s GitHub advisory.