PHP2Shell (CVE-2026-109618/109619), Part 1: How AI Found It…

AI-assisted researchers found two critical flaws that had been hiding in PHP for more than a decade. The same class of tools now lets attackers turn the public patch into a working exploit within hours. PHP2Shell shows both sides of AI in security at once.

On October 21, 2026, governments across Europe pulled websites offline as a precaution. The Dutch National Cyber Security Center, Finland’s public network services, France’s Interior Ministry, and Denmark’s national school platform all went dark (Reuters via US News, RTÉ). The cause was two remote code execution flaws in PHP itself, which runs roughly three in four websites whose server language is known (W3Techs, cited by Reuters).

Part one covers the issue: what happened, how AI found it, how big it is, and how to check, patch, and stay ahead of the next one. Part two briefly describes how our team responded.

What happened

PHP shipped emergency fixes on October 21 for CVE-2026-109618 and CVE-2026-109619, together called PHP2Shell. Both are rated 9.2 on CVSS v4.0 and let an attacker with no login run code on a web server (PHP security advisory).

Three facts make this unusual:

The bug is in the runtime, not your app. A secure WordPress, Drupal, or Laravel site is still exposed if the underlying PHP is vulnerable. Even a “Hello World” page can be attacked (The Hacker News).
It reaches almost every deployment. PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed are all affected, back to PHP 5.4 (PHP security advisory). Attackers can also read worker memory holding passwords, tokens, and API keys (The Hacker News).
Much of the web cannot take the fix. Censys found about 1.5 million of 2.6 million PHP hosts running a version with no official fix; other counts, using different methods, are lower (Reuters via US News).

Fixed versions by branch:

PHP 8.5: fixed in 8.5.12 (supported)
PHP 8.4: fixed in 8.4.27 (supported)
PHP 8.3: fixed in 8.3.36 (supported)
PHP 8.2: fixed in 8.2.35 (end of life on December 31, 2026)
PHP 8.1 and older: no official release; source backports exist for 7.4, 8.0, and 8.1, so check your distro or LTS vendor

Source: PHP security advisory.

Timeline: 22 years from bug class to emergency patch

The flaw class is old; the response was measured in hours. All times are UTC.

Before the disclosure

2004: Stefan Esser finds the first PHP memory-limit remote vulnerability, the ancestor of this bug class (Lopez-Kurtz, citing Calif).
2012: PHP 5.4.0 ships the oldest code path later shown to be exploitable (Sansec).
2020: Bug report #78876 flags the out-of-memory behavior again; little comes of it (Lopez-Kurtz, citing Calif).
2024: In PHP’s external audit, a core developer spots signs of the OOM flaw, but no route to code execution is found (The Hacker News, citing the PHP Foundation).
August 1, 2026: Calif finds its first trigger a few days into an AI-assisted audit under OpenAI’s Patch the Planet program (Lopez-Kurtz).
August 19: Wiz independently finds the first of the two flaws using Wiz Atlas, Gemini 4 Argon, and GPT-5.6 Sol (Fortune).
August 24: Wiz reports to the PHP security team (Lopez-Kurtz).
September: OpenAI’s own team finds a fuller version, and OpenAI convenes the coalition (Decrypt).
Early October: Cloudflare starts building WAF protections (Cloudflare); distros and LTS vendors receive patches in advance (PHP).

October 20, 2026

Details leak on the Hacker News forum, and watchTowr reproduces CVE-2026-109618 (The Hacker News, SecurityWeek).
PHP posts an advance notice of a release at 14:00 UTC the next day (PHP).
CERT-EU issues advisory 2026-018 (SecurityWeek).

October 21, 2026

03:02: Cloudflare WAF rules go live by default for every plan, including Free (Cloudflare).
Morning: Governments and companies across Europe take sites offline (Reuters via US News).
11:26: watchTowr still sees no exploitation in the wild (The Hacker News).
13:44: WordPress.org publishes its advisory: no WordPress update is needed; update PHP (WordPress News).
About 14:00: PHP releases 8.5.12, 8.4.27, 8.3.36, and 8.2.35, plus source backports for 7.4, 8.0, and 8.1 (PHP).
14:17: NVD publishes CVE-2026-109618 (Tanium), and cPanel posts its advisory (cPanel).
14:19: watchTowr reports active exploitation attempts against both CVEs (The Hacker News).
16:45: cPanel’s EasyApache 4 packages are patched, including backports for 7.4, 8.0, and 8.1 (GoDaddy).
17:20: WordPress VIP tells customers no action is required (WordPress VIP).
17:50: AlmaLinux’s patched packages reach testing for every PHP stream, including retired ones (AlmaLinux).
19:30: GoDaddy’s Managed WordPress is fully patched; its shared and Windows hosting is mitigated while it waits for vendor packages (GoDaddy).

If you were on the list, when would you have known?

It depends on which list. Warning time ranged from weeks to minutes:

Coordinated partners (CDNs, cloud providers, Automattic): heard weeks ahead, under embargo, and had rules and patches staged before disclosure (Cloudflare, WordPress VIP).
Linux distributions and LTS vendors: received the patches before release, so packages were ready at or soon after it (PHP).
Anyone following php.net news or the php-announce release list: heard on the evening of October 20 through the advance notice, which gave about a day to inventory and prepare (PHP, The Hacker News).
Customers of hosts that post notices: heard on October 20, often with no action needed (Acquia, GoDaddy).
WordPress.org security news readers: heard at 13:44 UTC on October 21, about 15 minutes before the fix (WordPress News).
Everyone who learned from the news: heard on October 21, after governments went offline, with no warning at all and already racing attackers (Reuters via US News).

The advance notice gave no details, only the date, the severity, and a warning to prepare. That was enough. A day is long enough to find every PHP runtime you own, stage builds, and line up a maintenance window.

Who went offline, and why

Almost every outage was a deliberate precaution, not a breach. CERT-EU, the UK NCSC, and the NSA advised operators who could not patch at once to take systems offline (Computer Weekly), and the FBI’s cyber division gave the same advice (AP via WRAL). No one has published a total count of sites pulled; the exposure numbers are the better guide.

Netherlands: The National Cyber Security Center, MijnOverheid, DigiD, the Tweede Kamer, and several education systems went offline (The Hacker News, citing NOS), as did Overheid.nl, the Port of Rotterdam, the KNVB, the five largest political parties’ sites, and several hospitals (Reuters via US News).
Finland: State IT provider Valtori took government public network services offline (RTÉ); the government site was only partly available (AP via WRAL).
France: The Interior Ministry put all its sites into preventive maintenance, including prefecture sites (RTÉ, The Next Web).
Denmark: Kombit shut down several services, including the national school communication platform (Reuters via Express Tribune).
Belgium: The foreign ministry took its websites down after reports of attacks, though the national cyber center saw none on Belgian sites (The Next Web).
United Kingdom: Edinburgh Council and some BBC program pages went dark (Computer Weekly).
Global: Wikipedia’s operator and the Internet Archive briefly took systems offline until they patched them (Newsy Today, citing Reuters).
Private sector: BambooHR took its whole service offline in the US, Canada, and Ireland, interrupting payroll (The Hacker News).

The exposure behind those decisions (counts vary by source and method):

PHP runs roughly 70–75% of websites whose server language is known (W3Techs, cited by Reuters).
Censys counted about 1.5 million of 2.6 million PHP hosts on a version with no fix (Reuters via US News).
Shodan-based counts found about 884,000 hosts on PHP 8.1 or older, plus 740,000 hiding their version (Mallory).
Shared hosting puts many sites on one IP, so affected websites far outnumber affected hosts (Mallory).

The good: AI found what humans missed for 14 years

PHP is one of the most scrutinized codebases on the internet, yet the main bug had been in PHP for 14 years, according to OpenAI President Greg Brockman (Fortune). No one stumbled on it. Researchers went looking, with AI as a force multiplier:

What Calif was doing. OpenAI invited the security firm Calif into Patch the Planet, a program to find and fix flaws in critical open-source infrastructure. Calif chose PHP for its impact and did not expect to find anything critical (Fortune). Calif’s Ryan Austin is credited with the discovery, made with GPT-5.6 Sol (Crypto Briefing); the first trigger came on August 1, a few days into the audit (Lopez-Kurtz).
No special tooling. Calif says its first discovery used no special harness and only a generally available model (Lopez-Kurtz, citing Calif).
Human knowledge still mattered. Calif traced the bug’s lineage to 2004 research and says current models do not reliably start from obscure, twenty-year-old primitives on their own (The Hacker News). The expert asked the right question; the model did the exhaustive reading.
Independent confirmation. Wiz Research found the same bug family using its Wiz Atlas agent with Gemini 4 Argon and GPT-5.6 Sol, and demonstrated pre-authentication code execution on WordPress, Drupal, and Joomla (Wiz). Wiz says Gemini helped find the bug, build exploits, detect attacks, and validate the patch (CellCog summary of Wiz).
Coordination. OpenAI then brought Wiz, Calif, the PHP team, Cloudflare, and others into one coalition (Fortune). Per the researchers, AI let one person do in about a week what would otherwise have taken a team months (The Hacker News).

The root cause is architectural. When PHP hits a memory limit or fatal error, it jumps to a recovery point mid-operation and leaves half-built data behind; cleanup code then treats that data as valid (Cloudflare). Fastly notes this bailout mechanism is called from many places in PHP, so further variants are likely (Fastly).

This is the optimistic case for AI in security. The same capability that worries us is already finding old, deep flaws in the foundations of the web, and handing them to the people who can fix them.

The bad: the gap between patch and exploit is collapsing

The careful two-month process did not survive contact with the internet. On October 20, details leaked on a public forum, and PHP pulled its release forward a day (The Hacker News). Cloudflare put firewall rules live at 03:02 UTC, about 11 hours before the fix shipped, and was already watching attackers mutate payloads against them (Cloudflare).

Arctic Wolf’s Ismael Valenzuela said what changed was not the code but “the ability to find those weaknesses and turn them into working exploits” (AP via WRAL). Three dangers follow:

Patches are now exploit blueprints. Once a fix is public, AI tools can diff it and reconstruct the attack quickly (Lopez-Kurtz). A 30-day patch habit is no longer safe for critical flaws.
Old code is no longer “proven.” Code that survived a decade of review is not safe by default; AI changes what counts as exploitable (AP via WRAL).
End-of-life software becomes a permanent hole. Nearly 700,000 internet-facing hosts on PHP 5 and 7 stay exploitable until someone upgrades them or turns them off (Phoenix Security, citing Mallory).

The window closed fast. At 11:26 UTC on October 21, watchTowr still saw no exploitation in the wild. At 14:19 UTC, minutes after the patch shipped, it reported active exploitation attempts against both CVEs (The Hacker News). No confirmed break-in had been published at the time of writing.

How big is this, compared with what we have seen before?

PHP2Shell belongs in the same conversation as Log4Shell and Heartbleed for reach, though not for ease of exploitation. Reach and timing for past incidents are approximate, from the public record; each CVE links to its NVD entry.

Heartbleed (CVE-2014-0160, 2014): an OpenSSL memory read affecting roughly a sixth of HTTPS servers; attacks followed within days.
Shellshock (CVE-2014-6271, 2014): Bash command injection across countless Unix systems and CGI scripts; attacks within hours.
Drupalgeddon 2 (CVE-2018-7600, 2018): Drupal core code execution on about a million sites; mass attacks within about two weeks.
Log4Shell (CVE-2021-44228, 2021): code execution in a Java logging library on hundreds of millions of devices and apps; attacks within hours.
PHP-CGI (CVE-2024-4577, 2024): PHP on Windows in CGI mode, a subset of Windows PHP servers; Akamai saw attacks within 24 hours (Hollweck, citing The Hacker News).
PHP2Shell (CVE-2026-109618/9, 2026): code execution and memory disclosure in the PHP runtime itself, reaching most of the web’s PHP, with 1.5 million hosts on versions with no fix; attempts against web application firewalls began before the patch shipped (Cloudflare).

Three things set it apart:

It is runtime-wide. Drupalgeddon hit one CMS, and the 2024 PHP flaw hit one Windows configuration. PHP2Shell hits every web-facing PHP deployment, whatever framework sits on top (PHP security advisory).
It is harder to weaponize than Log4Shell. Known PHP2Shell exploits need knowledge of the target’s binary and memory layout on 64-bit servers (Fastly). That buys time, not safety.
AI was on both sides from day one. It found the bugs, helped build the proof-of-concept exploits (Wiz), and now shortens the attacker’s path from patch to exploit.

Guardrails: when the AI says no

Ask Claude to write a working exploit for CVE-2026-109618, and it declines. Ask it to inventory your PHP fleet, write a version-check script, read a distro changelog, or plan a staged rollout, and it gets straight to work. That asymmetry is the point: a general-purpose assistant should make defense easier, not hand a weapon to whoever asks.

Anthropic has leaned into the defensive side. A day before PHP2Shell went public, it published research in which Claude flagged 493 attack-surface issues across 25 open-source projects, aimed at shrinking code that outsiders can reach but should not need to (FourWeekMBA summary of Anthropic’s post).

But be clear-eyed. Refusals are one layer, not a security control. Proof-of-concept code circulated within hours of the leak (SecureLayer7), and well-resourced attackers do not need a polite assistant. Guardrails slow down the casual attacker. Only patching stops the serious one.

How PHP and the vendors patched

The fix flowed down a chain: PHP first, then distributions, control panels, and hosts on their own schedules. Where you sat on that chain decided how much work you had.

PHP project: shipped four fixed releases, minimal source backports for 7.4, 8.0, and 8.1, and patches to distributions in advance. Users must update and restart every worker. Users of the volunteer remirepo repository were told to switch, because it would have no updates that day.
AlmaLinux: patched packages for every PHP stream, including retired ones. Users update from the repository.
cPanel: patched EasyApache 4 packages for 8.2 to 8.5, with backports for 7.4, 8.0, and 8.1. Admins run /scripts/rpmup; below 7.4, cPanel points to TuxCare Extended Lifecycle Support.
GoDaddy: patched Managed WordPress and mitigated shared and Windows hosting while waiting for vendor packages. Managed customers do nothing; VPS owners patch themselves.
WordPress VIP: Automattic worked with PHP’s security team to protect sites as early as possible. Customers do nothing.
Acquia: notified in advance, prepared its platform, and posted status updates. Customers subscribe to its Trust Center for updates.
WordPress.org: no WordPress release, because it is a runtime flaw. Site owners check their PHP version in Site Health; self-hosters below 8.2 should consider going offline.

The pattern is clear. Managed platforms absorbed the work for their customers. Self-managed servers and VPS owners carried it all.

What the edge is seeing: Cloudflare, Fastly, and Akamai

The CDNs saw attackers before most site owners saw the advisory. None had published attack counts by October 21.

Cloudflare had rules live for every WAF plan, including Free, from 03:02 UTC on October 21. Because of the leak, it saw attack traffic against customers and watched attackers mutate payloads to slip past its rules. It built a new capability for this incident: full-transaction detection, which inspects the origin’s response as well as the request and can block a leaking response before it reaches the attacker.
Fastly reported evidence of attacks against its WAF customers before the fix shipped and shipped an opt-in virtual patch for its Next-Gen WAF. Its read is sobering: the only log trace may be a routine out-of-memory error, and new variants were expected in the following two weeks. One small mercy: known exploits need details of the exact PHP binary and memory layout on 64-bit servers. Fastly says 32-bit deployments should likely assume compromise.
Akamai is listed among the partners that prepared detections and mitigations before disclosure on the joint advisory site. Akamai had not published attack telemetry by October 21. For context, Akamai saw the first attacks on the 2024 PHP-CGI flaw within 24 hours (Hollweck, citing The Hacker News).

Fastly’s indicators are worth adding to your monitoring now: Allowed memory size ... exhausted errors in Unknown on line 0, bursts of Apache segfaults (AH00052), and PHP workers spawning /bin/sh.

The operator playbook: check, patch, verify

If you run PHP, here is the shortest safe path. Updating PHP is the only complete fix.

1. Find out what you are running. Check the runtime that serves web traffic, not just the CLI.

php -v # CLI version
php-fpm -v # or php-fpm8.2 -v, php-fpm8.3 -v, php-fpm8.4 -v or php-fpm8.5 -v, per your install

In WordPress, go to Tools → Site Health → Info → Server. In Drupal use the status report at /admin/reports/status, or drush status. Distro packages may carry the fix under an older-looking version, so check the changelog for the CVE:

# Debian/Ubuntu
apt changelog php8.3-fpm | grep -E 'CVE-2026-10961(8|9)'
dpkg -l php8.3-fpm
apt-cache policy php8.3-fpm

2. Patch and restart. Update to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, then restart Apache, PHP-FPM, and any long-running workers. For containers, rebuild on the fixed base image and redeploy. On 8.1 or older, get a backport from your distro or LTS vendor, or upgrade.

3. Scan your own estate with Nuclei. Community templates for both CVEs were published on October 21 (php2shell-nuclei-templates); a pull request to the official ProjectDiscovery repository is pending. Read the YAML before running it, and scan only systems you own.

git clone https://github.com/Ademking/php2shell-nuclei-templates
nuclei -validate -t php2shell-nuclei-templates/templates/php2shell/
# Version fingerprint and behavioral check across a list of your sites
nuclei -l our-sites.txt \
 -t php2shell-nuclei-templates/templates/php2shell/CVE-2026-109618.yaml \
 -t php2shell-nuclei-templates/templates/php2shell/CVE-2026-109619.yaml

Skip the end-to-end exploitation template on production. Version and behavioral checks are enough to tell you what to patch.

4. If you truly cannot patch today, apply the advisory’s interim measures, knowing they reduce risk but do not remove it:

CVE-2026-109618: set memory_limit=-1, keep post_max_size low, and cap request size at the web server or proxy. Remove the unlimited memory setting once you have patched.
CVE-2026-109619: set session.upload_progress.enabled=0 and restart every worker; on PHP 8.5 also set fatal_error_backtraces=0.
Put the site behind a WAF with PHP2Shell rules as a stopgap, or take it offline, as the UK NCSC and others advise.

5. Assume you may already have been probed. Look for unusual multipart requests followed by memory-limit errors, repeated HTTP 500s, oddly large PHPSESSID cookies, and unexplained worker restarts. If a host was exposed while unpatched, rotate its stored credentials.

6. Recheck memory settings after patching. The fix adds a hard memory limit that ends the process when reached, so confirm memory_limit and post_max_size fit what your apps need.

Sources for this playbook: fixed versions and interim mitigations from the PHP security advisory; signs of compromise from The Hacker News; the changelog check from Debian’s security FAQ; credential rotation from Censys; scanning from the community Nuclei templates.

The message for every PHP framework and CMS

Your application can be flawless and still be compromised. WordPress said no WordPress update is required or planned, because the flaw is in PHP (WordPress News). Sansec confirmed unauthenticated code execution against Magento 2.4.9 and ten other PHP applications (Sansec). The Drupal Association’s interim CEO, Tiffany Farriss, warned that servers on any PHP version from the last 20 years are vulnerable (Reuters via US News).

Every framework and platform below is exposed when its PHP runtime is unpatched. None needs its own update for PHP2Shell; the server does.

CMS: WordPress, Drupal, Joomla, TYPO3, Craft CMS, Statamic, Concrete CMS, October CMS, ProcessWire, Grav
Frameworks: Laravel, Symfony, CodeIgniter, CakePHP, Yii, Laminas (formerly Zend), Slim, Phalcon
Commerce: Magento / Adobe Commerce, WooCommerce, Shopware, PrestaShop, OpenCart
Collaboration and learning: Moodle, MediaWiki (Wikipedia’s software), Nextcloud, phpBB, SuiteCRM

My view, as an architect who has built on these platforms for years:

The runtime is part of the product. Framework communities should treat the PHP version as a security dependency, not a hosting detail. Clearer minimum-version policies and louder in-dashboard warnings would help site owners who never look below the CMS.
Hosting is where risk concentrates. Shared hosts and self-managed VMs carry the most exposure. Managed and SaaS platforms patched fastest in the week of October 19.
Architecture is a security decision. Composable and headless designs that keep PHP off the public edge, behind a CDN and WAF, shrink the attack surface. That is not an argument to abandon PHP. It is an argument to design for the day the runtime breaks.
Fund the foundations. Volunteers maintain PHP. If your business runs on it, support the PHP Foundation and your CMS’s security team.

Open source is free to use, not free to own

Teams on the right channels saw PHP’s advance notice on the evening of October 20 and had about a day to prepare. Teams that learned about PHP2Shell from the news were already behind.

Open source lets you ship quickly. Running it in production is a commitment to stay part of its community: read its advisories, upgrade off end-of-life versions on a schedule, and give back where you can. Discipline is the price of speed.

PHP itself

php.net news and the php-announce release list: the advance notice appeared here. Subscribe by emailing php-announce+subscribe@lists.php.net (php.net mailing lists).
PHP security advisories on GitHub: choose Watch → Custom → Security alerts (php-src advisories).

CMS and commerce platforms

Drupal: security-news mailing list and RSS feeds (subscribe, advisories)
WordPress: the Security category of WordPress News, by RSS or email (WordPress security news)
WooCommerce: GitHub security advisories (woocommerce advisories)
Joomla: the Security Strike Team announcements feed (Joomla Security Centre)
TYPO3: TYPO3 security advisories (TYPO3 advisories)
Craft CMS: GitHub security advisories (craftcms advisories)
Magento / Adobe Commerce: Adobe Security Notifications and Commerce Security Alerts (Commerce security)
Shopware: GitHub security advisories (shopware advisories)
PrestaShop: GitHub security advisories (PrestaShop advisories)

Frameworks

Laravel: GitHub security advisories for the framework (laravel/framework advisories)
Symfony: the security advisories blog category, with RSS (Symfony advisories)
CodeIgniter: GitHub security advisories (CodeIgniter4 advisories)
CakePHP: GitHub security advisories (cakephp advisories)
Yii: GitHub security advisories (yii2 advisories)

Collaboration and learning

Moodle: Moodle security announcements (moodle.org/security)
Nextcloud: Nextcloud security advisories (Nextcloud advisories)

Infrastructure and threat intelligence

Debian and Ubuntu: debian-security-announce and Ubuntu Security Notices (Debian, Ubuntu)
cPanel servers: the EasyApache 4 change log (EasyApache 4 change log)
Cloudflare users: the WAF managed rules change log (WAF change log)
Everything: the CISA Known Exploited Vulnerabilities catalog (CISA KEV)
This incident: the joint advisory site from the research teams (php2shell.com)

On GitHub, you can watch any repository you depend on for security alerts only, and turn on Dependabot alerts for your own code. Route all of it to a shared channel, not one person’s inbox.

The bottom line

PHP2Shell is a preview of the next few years. AI will keep finding old flaws in foundational code faster than any human team. That is good news for teams with the habits to act on it: subscribed to advisories, inventoried, tested, and ready to ship a fix in hours. For everyone else, the same capability is a countdown.

AI will not make anyone secure on its own. Discipline does. AI makes that discipline fast.

If you run PHP and have not patched yet, stop reading and start with step one above.

Continue to part two.

← All news and insights