AI Found the Bugs, a Leak Started the Race: PHP2Shell Knocked Government Sites Offline. What to Patch Today (AI Trends, 22 October 2026)

admincybersecurityTagged , , , , , , , , , , ,

What’s trending in AI on 22 October 2026: The biggest AI story this morning is not a model launch. It is a pair of bugs in PHP, the language behind WordPress, Drupal, Joomla and a large share of the web, that frontier AI models helped find, weaponize in the lab and then help fix. The flaws, nicknamed PHP2Shell and tracked as CVE-2026-109618 and CVE-2026-109619, let an attacker run code on a vulnerable web server without logging in. Details leaked a day early, PHP rushed out patches on 21 October, several European governments took public websites offline as a precaution, and watchTowr now reports exploitation attempts. Below: what happened, how AI changed the timeline, who is exposed, the stopgaps that do and don’t work, and a set of questions to send your web host or agency today.

Key takeaways

  • Two critical PHP flaws, both CVSS v4.0 9.2. They allow unauthenticated remote code execution on PHP installations that serve web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed.
  • Patch to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart every PHP worker. PHP says updating is the only complete fix. Version 8.1 and older need a vendor backport or an upgrade.
  • AI found them first. Calif found the first bug in August using OpenAI’s GPT-5.6 Sol; Wiz found both independently using Gemini 4 Argon and GPT-5.6 Sol, and used the models to build and adapt exploits.
  • The defenders’ head start was cut short. A leak on 20 October pushed the release forward a day, and a proof-of-concept circulated before patches existed.
  • Your risk is mostly someone else’s server. Most small businesses run PHP through a host, agency or plugin vendor. The job today is getting a dated confirmation that every site was patched.
PHP2Shell: AI found two critical PHP flawsTitle card. Headline: AI found the bugs. Now patch PHP. Subhead: PHP2Shell, CVE-2026-109618 and CVE-2026-109619, allow unauthenticated code execution on PHP web servers. Three stat cards: CVSS 9.2 for both flaws; about 70 percent of websites run PHP by Wiz’s estimate; PHP 5.4 is the oldest affected release. An icon shows a server rack with an orange warning badge. AI TRENDS · 22 OCTOBER 2026 AI found the bugs. Now patch PHP. PHP2Shell (CVE-2026-109618, CVE-2026-109619) allows unauthenticated code execution on PHP web servers. 9.2 CVSS v4.0, both flaws ~70% of websites run PHP 5.4 oldest affected release ! delana.co · Sources: PHP security advisory (21 Oct 2026); Wiz Research (21 Oct 2026). 70% is Wiz’s estimate of websites using PHP.
Two memory-safety bugs in PHP’s core reach almost every PHP web server, regardless of how well the application on top is written.

1. What PHP2Shell is, in plain terms

PHP2Shell is Wiz Research’s name for a set of memory-safety bugs in the PHP engine itself, not in any particular website’s code. PHP’s own advisory describes two of them. CVE-2026-109618 is an out-of-memory problem: if PHP runs out of memory at the wrong moment, it can be interrupted while internal request data is only half set up, and the clean-up step then treats that broken data as valid. CVE-2026-109619 is a stale-state problem: internal data belonging to one request can survive after its memory is freed, and the next request handled by the same worker can use it before it is reset.

That sounds abstract, but the consequence is not. Both are rated 9.2 on CVSS v4.0, and PHP says they allow unauthenticated remote code execution. Wiz showed working attacks against the latest WordPress, Drupal and Joomla container images, and a separate path that leaks server memory, which can expose passwords, tokens and API keys. Because the bugs sit below the application, Wiz notes that even a trivial “Hello World” page on an affected version can be exposed. Apache with mod_php carries the highest demonstrated risk, because the attack can fire before any application code runs.

The affected range is wide. Calif, Wiz and Cloudflare put the oldest affected release at PHP 5.4, which means roughly a decade of installs. PHP’s maintainer Volker Dusch called it the most severe issue the project had faced in over ten years and compared it to Heartbleed, according to The Next Web.

2. How AI changed the timeline

This is why the story belongs in an AI trends briefing. According to Wiz’s timeline, the first bug was discovered on 19 August, remote code execution was confirmed against Drupal and then WordPress within two days, and the report reached PHP’s security team on 24 August. PHP acknowledged it on 21 September and shipped fixes on 21 October.

Two teams got there separately. The security firm Calif found the first flaw during a PHP source-code audit funded by OpenAI’s “Patch the Planet” initiative, using GPT-5.6 Sol. Calif says it used only generally available models with no special tooling, and that knowing PHP’s history mattered more than the model. Wiz found both flaws independently using its Wiz Atlas platform plus Google’s Gemini 4 Argon and GPT-5.6 Sol. Wiz says the models helped with discovery, exploit development, detection and patch validation, adapting exploits to different PHP versions and memory layouts within hours, and that one researcher finished in a week what would once have taken a team months.

OpenAI frames the gap between an AI-assisted discovery and public disclosure as a “Defender’s Window”, a period in which maintainers and security providers can prepare fixes and protections before attackers know the bug exists. It described PHP2Shell as “one of the most impactful security issues in recent memory,” and has committed $1 billion in subsidized access to its Daybreak cyber programme for under-resourced defenders. It also says plainly that the same capabilities could help attackers build exploits. We have tracked that tension all month, from AI flooding bug bounty programmes to Anthropic’s free scans for open-source projects.

PHP2Shell timeline from AI discovery to emergency patchTimeline with six milestones. 19 August: first bug found with AI help. 20 to 21 August: code execution confirmed against Drupal and WordPress. 24 August: reported to PHP security team. 21 September: PHP acknowledges and starts the fix. 20 October: details leak and a proof of concept circulates; PHP posts advance notice. 21 October: patched releases ship, Cloudflare firewall rules already live, governments take sites offline. A bracket marks the roughly two-month defender’s window, cut short by one day. Nine weeks of head start, one day lost From AI-assisted discovery to emergency release, 2026 19 AugFirst bugfound with AI 20–21 AugRCE on Drupal,then WordPress 24 AugReportedto PHP 21 SepPHP startsthe fix 20 OctLeak; proof ofconcept circulates 21 OctPatches ship;sites go offline The “Defender’s Window”: about two months of quiet preparation Planned release moved up a day delana.co · Sources: Wiz Research; Huntress; watchTowr; PHP advance notice (20 Oct 2026). Not to scale.
AI compressed discovery and exploit-building into days. Coordinating the fix still took two months.

3. The leak, and the scramble that followed

The plan was a tidy release. PHP had posted an advance notice for 21 October at 14:00 UTC, with the wider embargo due to lift a day later. Instead, on the morning of 20 October, a post on Hacker News claimed two critical PHP flaws were about to be disclosed. It was removed, but screenshots spread. watchTowr confirmed the bugs were real, and by its account a proof-of-concept tool called “PHP2Shell” was circulating before any patch existed. watchTowr’s own summary of the mood: “we were all supposed to wait until Thursday at 11am ET.”

The response was fast and uneven. Cloudflare switched on web application firewall rules for all customers, including free plans, at 03:02 UTC on 21 October, about nine hours before disclosure, and says it watched attackers change their payloads to get around them. CTO Dane Knecht was blunt: “This is a STOPGAP only. Patch as soon as PHP releases the update.” Huntress reports PHP’s patched releases landed at roughly 9:30 to 10am ET, and full technical write-ups from Calif and Wiz followed that afternoon.

Governments did not wait. TechRepublic reports that the Netherlands temporarily took Overheid.nl, MijnOverheid.nl and the DigiD login service offline, France pulled prefecture websites, Finland’s state IT centre shut public web services, and agencies in Germany and Belgium suspended sites, all as precautions. CERT-EU advised organizations that cannot patch to consider isolating vulnerable internet-facing applications, the UK’s NCSC issued an alert, and the US National Security Agency published its own warning. Pinboard, the GrapheneOS forum and OBS took parts of their sites down, and Laravel paused Cloud deployments while rebuilding on patched images.

On exploitation, the picture is moving. Huntress had seen none on its partners’ systems as of late afternoon on 21 October. watchTowr says it is observing active exploitation attempts against both CVEs. Treat any unpatched, internet-facing PHP server as a target from today.

4. Who is exposed

PHP’s guidance is broad on purpose: every PHP installation that serves web requests is in scope. In practice, the question for a business is less “do we use PHP?” and more “where is PHP running on our behalf?” It is inside WordPress and WooCommerce sites, Drupal and Joomla sites, many customer portals and booking tools, control panels such as cPanel, and the admin interfaces of some vendor appliances. watchTowr notes that Session Upload Progress, one confirmed trigger, is enabled by default, so most default setups meet that precondition.

Where PHP2Shell can reach your businessThree columns. Server setups in scope: PHP-FPM, Apache mod_php with highest demonstrated risk, php-cgi, FrankenPHP, LiteSpeed. Common places PHP hides: WordPress and WooCommerce, Drupal and Joomla, customer portals and booking tools, hosting control panels, vendor appliance admin pages. Who usually patches: managed host, web agency or freelancer, internal IT, appliance vendor. Where PHP2Shell can reach you The flaw is in PHP itself, so the website’s own code does not protect it Server setups in scope PHP-FPMApache mod_php (highest risk)php-cgiFrankenPHPLiteSpeed PHP 5.4 through 8.5.11 Where PHP hides WordPress, WooCommerceDrupal, JoomlaCustomer portals, bookingHosting control panelsAppliance admin pages Who usually patches Managed hostWeb agency or freelancerInternal ITAppliance or SaaS vendorYou, if nobody else is named delana.co · Sources: PHP security advisory; watchTowr; Huntress (21 Oct 2026)
For most small and mid-sized firms, the real exposure map is a list of suppliers.

5. The fix, version by version

PHP’s advisory is unusually direct: updating is the only complete fix, and no configuration change fully substitutes for it. After updating, restart every PHP worker, otherwise old code can stay in memory. Linux distributions and long-term-support vendors received patches in advance, so their packages are the preferred route. The volunteer-run Remi repository, popular on Red Hat-family servers, said it would not have updates on release day.

Your PHP branchFixed releaseStatusWhat to do
8.58.5.12SupportedUpdate now and restart workers
8.48.4.27SupportedUpdate now and restart workers
8.38.3.36SupportedUpdate now and restart workers
8.28.2.35Security fixes until 31 Dec 2026Update now, and plan a move to 8.3 or later
8.1, 8.0, 7.4No official releaseEnd of lifeUse a distribution or LTS vendor backport, or PHP’s minimal source backports; otherwise isolate
7.3 and older (back to 5.4)NoneEnd of lifeUpgrade or take off the internet
Source: PHP security advisory and release announcements, 21 October 2026; Huntress; watchTowr.

If you truly cannot update today, PHP lists stopgaps that reduce exposure but, in its words, do not make a server safe. The most widely cited is disabling session upload progress in the main configuration and restarting workers. PHP stresses that setting it with ini_set() or a .user.ini file is not enough.

StopgapTargetsCaveat
session.upload_progress.enabled = 0 in php.ini, FPM pool or server config, then restart all workersCVE-2026-109619Blocks one confirmed trigger; watchTowr says it is not the only path
On PHP 8.5 only, fatal_error_backtraces = 0CVE-2026-109619Version-specific
Low post_max_size (8M without uploads, 32M with) and request limits at the proxyCVE-2026-109618Reduces, does not remove, out-of-memory triggers
Web application firewall rules (Cloudflare, Fastly, Google, Vercel and others)Known payloadsAttackers were already mutating payloads to evade them
Put the server behind a VPN or take it offlineBothThe only stopgap that removes internet exposure
Sources: PHP security advisory; Huntress; watchTowr; The Next Web. None of these replaces the update.
Decision path for patching PHP2ShellDecision flow. Start: Is the server on PHP 8.2 or newer? If yes, update to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 and restart every worker. If no, is a vendor backport available? If yes, apply it and restart. If no, isolate the server from the internet or take it offline, then plan an upgrade. Final step for all paths: verify the running version and check logs for signs of compromise. Patch path: three questions, one rule Configuration tweaks buy time; only an update or isolation closes the door On PHP 8.2 or newer?check the running version YES: update to fixed releaserestart every worker NO: vendor backport?distro or LTS provider YES: apply and restartthen plan the upgrade NO: isolate or take offline Everyone:verify version, thenhunt for compromise delana.co · Sources: PHP security advisory; Huntress; watchTowr (21 Oct 2026)
Whichever path you take, finish by confirming the version that is actually running.

6. How to tell if you were hit

Patching stops new attacks; it does not undo old ones. Because the bugs fire below the application, Wiz warns that application logs may show very little. The signals it and Huntress suggest watching for are lower-level:

  • Unusual multipart requests followed by memory-limit errors, bursts of HTTP 500 responses, oversized or malformed PHPSESSID cookies, and unexplained PHP worker restarts (Wiz).
  • PHP worker processes such as php-fpm, php-cgi, httpd or apache2 starting shells, scripting interpreters, or download tools like curl and wget, and reconnaissance commands such as whoami or uname -a run from the web server (Huntress).
  • New files in the web root, unexpected scheduled tasks or cron jobs, and new user accounts (Huntress and watchTowr).

watchTowr’s advice is to preserve PHP and web server logs, configuration snapshots and any suspicious files before you change anything, so an investigation still has evidence. Because the memory-disclosure path can expose secrets, any server that was unpatched and internet-facing after the leak should also have its database passwords, API keys and session secrets rotated. That matters more than ever as AI tools turn stolen keys into fast follow-on attacks, a pattern we covered in the Cairn agent-swarm break-ins.

7. Why this is an AI story, not just a patch story

Three things are new. First, discovery speed. PHP is one of the most scrutinized codebases on the internet, and models found decade-old flaws in it in days. The Next Web notes this is the second time in a few months that AI-found bugs forced a mass update of web software, after the WordPress bugs exploited in July. Expect more, and expect them in mature, widely deployed code.

Second, the defender’s head start is fragile. AI gave the good guys about two months; one leak cut the final day and put a working exploit in public before patches existed. Microsoft’s Digital Defense Report warned that attackers now move within 24 hours, and PHP2Shell is a live example of that window.

Third, the bottleneck has moved from finding bugs to shipping fixes. PHP needed a month just to acknowledge the report and another to release. Downstream, every host, agency and appliance vendor now has to repeat the work. That is the same gap we saw when IBM and Red Hat patched 400 AI-found Java flaws and when open-weight models matched elite hacking skills. Your patch speed is now a competitive and insurance issue, not just an IT metric.

AI sped up finding bugs, but not fixing them everywhereComparison of stages. AI-accelerated stages: discovery took days; exploit adaptation across applications took hours. Human-paced stages: PHP acknowledgment took about four weeks from the report; the fix and coordinated release took about four more weeks; downstream patching by hosts, agencies and vendors is still under way. Note: one researcher did in a week what once took a team months, per Wiz. Finding got fast. Fixing did not. Approximate time per stage in the PHP2Shell response Discovery (AI-assisted)days Exploit adaptationhours Report to acknowledgment~4 weeks Fix and coordinated release~4 weeks Downstream patchingongoing Wiz: one researcher finished in a week what once took a team months delana.co · Sources: Wiz Research timeline; PHP advisory; The Next Web (21 Oct 2026). Bars illustrative, not to scale.
The slowest part of the chain is now the part that involves people and suppliers.

8. Questions to send your host, agency or IT provider today

Recent guides here used test scripts, scorecards, worksheets, traffic lights, a role-by-role plan and if-then triggers. This one is a message you can paste into an email or ticket, with the answer you should expect back. If a supplier cannot give the good answer, escalate.

  1. Ask: “Which of our sites, portals and tools run on PHP?” Good answer: a named list, including staging sites, old microsites and admin panels, not just the main website.
  2. Ask: “What PHP version is each one running right now?” Good answer: exact versions, for example 8.3.36, checked on the live server rather than read from a config file.
  3. Ask: “When was each patched, and were all PHP workers restarted?” Good answer: a date and time for each, with a yes on the restart.
  4. Ask: “Which sites are on PHP 8.1 or older, and what is the plan?” Good answer: a named backport source or an upgrade date, with the site isolated until then.
  5. Ask: “Are we relying on a firewall rule or a php.ini change instead of the update anywhere?” Good answer: no, or only briefly and with an end date.
  6. Ask: “Did you preserve logs and check for web shells, new cron jobs and new accounts?” Good answer: yes, with the window checked starting 20 October at the latest.
  7. Ask: “Will you rotate database passwords, API keys and session secrets on any server that was exposed?” Good answer: yes, with a completion date.
  8. Ask: “Which of our other vendors’ products bundle PHP?” Good answer: a list of appliances and SaaS tools with each vendor’s advisory status.
  9. Ask: “How fast can you patch a critical web flaw next time?” Good answer: a written target measured in hours, not a monthly maintenance window.

Keep the replies. Cyber insurers and auditors increasingly ask for evidence of patch timing, and AI-found flaws will make that question routine. For the bigger picture on AI-era infrastructure risk, see our briefing on attacks against AI stacks and the AI control plane flaws in GitLab and AWS.

9. The bottom line

PHP2Shell is the clearest case yet of AI’s double edge in security. Frontier models found deep, old bugs in core internet software and helped build the fix, and that gave defenders a real head start. But one leak erased part of that advantage, governments chose to switch sites off rather than gamble, and attackers began probing within hours. The lesson for businesses is practical: the speed at which flaws are found is no longer the limit. The speed at which you, and every supplier that runs code for you, can patch and prove it is. Start with the nine questions above, and get answers in writing today.

Frequently asked questions

What is PHP2Shell?

PHP2Shell is the name Wiz Research gave to critical memory-safety flaws in PHP’s core engine, tracked as CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 on CVSS v4.0 and allow unauthenticated remote code execution on PHP installations that serve web requests. Patches were released on 21 October 2026.

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. PHP 8.1 and older no longer receive official releases, so they need a backport from a Linux distribution or long-term-support vendor, PHP’s minimal source backports for 7.4 to 8.1, or an upgrade. Restart all PHP workers after updating.

Is my WordPress site affected by PHP2Shell?

Very likely, if it runs on an unpatched PHP version. The flaw is in PHP, not WordPress, so updating WordPress or plugins does not fix it. Wiz demonstrated working attacks on the latest WordPress, Drupal and Joomla images. Ask your host which PHP version your site is running and when it was patched.

How did AI help find the PHP vulnerabilities?

Calif found the first flaw in August 2026 using OpenAI’s GPT-5.6 Sol during an audit funded by OpenAI’s Patch the Planet initiative. Wiz found both independently using Gemini 4 Argon, GPT-5.6 Sol and its own platform, and used the models for exploit development, detection and patch validation.

Is PHP2Shell being exploited?

watchTowr reports active exploitation attempts against both CVEs, and a proof of concept circulated after the 20 October leak. Huntress had not seen exploitation on its partners’ systems as of 21 October afternoon. Treat any unpatched, internet-facing PHP server as at risk.

Can a firewall rule or php.ini change protect me instead of patching?

Only briefly. PHP says no configuration change fully replaces the update. Disabling session upload progress and using web application firewall rules reduce exposure, but Cloudflare called its rules a stopgap and saw attackers adapt payloads. If you cannot update, isolate the server from the internet.

Sources