# PHP2Shell: How AI Found It and Who Went Offline

Who found the PHP2Shell bugs, which AI tools each source credits, and which organisations and products were affected. As of 27 October 2026, no breach of a named organisation is confirmed.

Published 2026-11-01. 7 min read. Category: Web development. By Mutahar Aslam, Founder & CEO of Paraline Tech.

## Key takeaways

- PHP2Shell is two critical PHP flaws, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October 2026.
- Calif, Wiz and OpenAI each reported the bugs, and the AI tools they used differ by source.
- Many sites went offline as a precaution, but no primary source confirms a breach of a named organisation.
- Updating your CMS does not help. Update PHP itself, restart it, and check your logs from 17 October.

PHP2Shell is the name for two critical flaws in PHP itself, and they affect almost every PHP site on the web. Two questions about PHP2Shell keep coming up: who found the bug, and how much did AI help? And which big websites and organisations were actually hit? This post answers both, with each claim linked to the source that makes it.

**Updated 27 October 2026.** This story is still moving. Fix tables and outage lists change daily.

## What PHP2Shell is, briefly

PHP2Shell covers two bugs in the PHP engine, CVE-2026-109618 and CVE-2026-109619. The [PHP project says](https://www.php.net/archive/2026.php) both "can allow unauthenticated remote code execution". In plain terms, an attacker may be able to run code on your server without logging in.

- **CVE-2026-109618** sits in out-of-memory handling. It can leave request data half set up.
- **CVE-2026-109619** lets request state outlive the memory behind it, so a later request can reuse it.

PHP fixed both on 21 October 2026, with one release per supported branch:

| Branch | First fixed release |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |

PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed are all affected. PHP rates the risk highest for mod_php, and it says plainly: "There are no complete mitigations, updating is the only safe choice."

## How AI helped find PHP2Shell

Several teams found the same flaw at different times. The sources also credit different AI tools. So here is each credit, next to the source that makes it.

### Who reported PHP2Shell, and with which tools

**Calif came first.** Researcher Ryan Austin at [Calif](https://calif.io/php2shell/) found the first bug on 1 August 2026. Calif reported it to PHP on 11 August and sent a second bug on 21 August. Calif's own write-up names no AI model. It says it used generally available models through OpenAI's "Patch the Planet" initiative, with "No special harness". However, [Fortune reports](https://fortune.com/2026/10/21/ai-tools-discovered-the-php-vulnerability-that-could-take-down-70-of-the-internet-now-the-race-is-on-to-patch-it-before-ai-powered-hackers-attack/) that Calif found the first issue "on Aug. 1 using GPT-5.6 Sol". OpenAI and Wikipedia (citing the Wall Street Journal) give the same model.

**Wiz reported on 24 August.** Fortune says Wiz identified the issue on 19 August. Wiz and the PHP Foundation both give 24 August as the report date. [Wiz names its own tools](https://www.wiz.io/blog/php2shell-php-rce): "We used Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol throughout this research." [Google Cloud adds](https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619) that Gemini 4 Argon helped Wiz find the flaw, build an exploit, detect attacks and check the patch. Keep in mind that Google supplies that model, so it has an interest.

**OpenAI reported it independently.** The [PHP Foundation says](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/) OpenAI reported the same root cause on its own, then sent more attack paths on 18 September. It thanks "OpenAI Codex Security, especially Amy Burnett". The [CVE record](https://cveawg.mitre.org/api/cve/CVE-2026-109618) lists OpenAI as a finder.

### Two names that did not find it

Two other names come up, and neither found this bug:

- **Quarkslab's 2024 audit did not find it.** While fixing a separate audit finding, a core developer saw "the first signs of the OOM problem". An exploit was theorised, but no concrete path was found.
- **Anthropic's Claude Mythos** was used by Alpha-Omega to scan PHP earlier in 2026. The Foundation states no findings from that scan.

The Foundation calls the gap between the August reports and the October fix "a structural failure". It now uses AI, including OpenAI's Daybreak Red, to sort incoming reports. A person still makes every decision.

### PHP2Shell timeline

| Date (2026) | Event | Source |
|---|---|---|
| 1 Aug | Calif finds the first bug | Calif, Fortune |
| 11 Aug | Calif reports it to PHP | Calif, PHP Foundation |
| 24 Aug | Wiz reports to PHP | Wiz, PHP Foundation |
| 18 Sep | OpenAI sends further attack paths | PHP Foundation |
| 17 Oct | Amazon logs an exploit attempt | Amazon |
| 21 Oct | PHP releases the fixes | php.net |
| 26 Oct | CISA adds both CVEs to KEV | CISA |

The release was moved up a little, too. The CVE IDs leaked on forums on 20 October, so PHP shipped on 21 October at 14:00 UTC.

## Who was affected by PHP2Shell

First, the key point. **As of 27 October 2026, no primary source confirms a successful breach of any named organisation.** Every organisation below either acted as a precaution or is a vendor with affected products.

What has been seen is attack *attempts*. [Amazon's honeypots](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/) logged one on 17 October, four days before the fix. Amazon says "it's unclear if any of these attempts would have succeeded". On 26 October, [CISA added both CVEs](https://www.cisa.gov/news-events/alerts/2026/10/26/cisa-adds-two-known-exploited-vulnerabilities-catalog) to its Known Exploited Vulnerabilities (KEV) catalog. That is serious, but it is not proof of victims. Under [CISA's own criteria](https://www.cisa.gov/known-exploited-vulnerabilities), "Successful malicious code execution on a honeypot is considered attempted exploitation".

### Organisations that went offline

[CISA told](https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching) anyone who could not patch to take PHP systems offline. The [UK NCSC](https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php) said to "consider taking the system offline" if mitigations could not be applied quickly. Many organisations did just that.

| Organisation | What happened | Who says so |
|---|---|---|
| NCSC Netherlands | NCSC.NL taken offline as a precaution | [The organisation itself](https://www.rijksoverheid.nl/actueel/nieuws/2026/10/21/ncsc-ernstige-kwetsbaarheden-in-php) |
| Dutch government | Overheid.nl, MijnOverheid.nl and DigiD taken offline preventively | [The government itself](https://www.rijksoverheid.nl/actueel/nieuws/2026/10/21/aantal-websites-rijksoverheid-preventief-offline-na-kwetsbaarheden-php) |
| MijnOverheid, DigiD | Back online the same evening | [NOS](https://nos.nl/liveblog/2636066-websites-kwetsbaar-voor-softwarelek-rtl-nieuws-digid-en-mijnoverheid-uit-de-lucht) |
| Wikimedia Foundation | Many supporting services offline, partly restored by 27 October. Wikipedia was not shut down. | [The organisation itself](https://diff.wikimedia.org/2026/10/21/impact-of-php-vulnerabilities-on-wikimedia-tools-and-services/) |
| Tweede Kamer (Dutch parliament) | Website offline as a precaution | [NOS](https://nos.nl/artikel/2636055-websites-van-overheid-en-in-onderwijs-offline-vanwege-lek-risico-op-hacks) |
| Dutch data protection authority, ANP, Notubiz, several hospitals | Offline | NOS |
| Tweakers, RTL Nieuws | Unavailable, back by the afternoon. NOS gives no reason. | NOS |
| Valtori (Finland's state IT centre) | Public web services offline, called "a precautionary measure" | [Reuters](https://www.koreatimes.co.kr/world/20261023/governments-companies-take-websites-offline-over-php-flaws) |
| French Interior Ministry | Prefecture websites offline as a precaution | Reuters |
| ITZBund (Germany) | Several federal websites switched off, "purely preventive" | Reuters |
| Internet Archive | Portal offline briefly for emergency patches, now back | Reuters |

Reuters also lists the Czech government, some BBC portals, Edinburgh council, some Government of Canada sites, and Japanese agencies and firms.

### Products with vendor advisories

These products bundle PHP. Status is as of 27 October 2026.

| Vendor | Affected products | Fix status |
|---|---|---|
| [Palo Alto Networks](https://security.paloaltonetworks.com/CVE-2026-109618) | PAN-OS management web UI and XML API | Some hotfixes out, the rest due 27 to 30 October. Not aware of malicious exploitation. |
| [Siemens](https://cert-portal.siemens.com/productcert/html/ssa-566512.html) | RUGGEDCOM APE1808 (runs PAN-OS) | No patch listed; contact support |
| [Cisco](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-php-october26-Jj384Daq) | Expressway, Duo Access Gateway, URWB | Fixes for Duo and Expressway; URWB due Feb 2027. Four products still under investigation. No known malicious use. |
| [Fortinet](https://fortiguard.fortinet.com/psirt/FG-IR-26-186) | FortiDDoS, FortiSOAR under investigation | No fixed versions yet; IPS signatures out. FortiOS not affected. |
| [CloudLinux](https://blog.cloudlinux.com/php-cve-2026-109618-and-cve-2026-109619) | alt-php and ea-php (incl. cPanel servers) | Fixed packages for most versions; CloudLinux 6 not yet confirmed |

### Platforms exposed because they run on PHP

The flaw is in PHP, not in your CMS. [Cloudflare](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/) warns that "updating website code or a plugin(s) alone does not fix these vulnerabilities".

Calif says it confirmed pre-login code execution on current versions of WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCS. Wiz showed it on WordPress, Drupal and Joomla. [Sansec](https://sansec.io/research/php2shell) adds Shopware and WooCommerce, even when their own code is clean. Sansec also now thinks mass exploitation is less likely, because attacks need specific conditions on the target.

How big is the exposure? Wiz estimates 70% of the internet. [W3Techs](https://w3techs.com/technologies/details/pl-php) measures something different: PHP runs on 69.2% of websites whose server-side language it knows. [Unit 42](https://unit42.paloaltonetworks.com/cve-2026-109618-cve-2026-109619/) counted over 22.6 million exposed instances that are "potentially vulnerable".

## What site owners should do

1. **Update PHP** to the fixed release for your branch (see the table above) or anything newer. On managed hosting, ask your host.
2. **Restart PHP** (PHP-FPM, Apache, FrankenPHP or LiteSpeed). Running workers keep the old code.
3. **Check backports by changelog.** Distro and CloudLinux packages may show an older version number. Look for "CVE-2026-109618" in the changelog rather than trusting `php -v`.
4. **On PHP 8.1 or older,** use a vendor backport, or the source-only patches PHP published for branches 7.4, 8.0 and 8.1, then plan an upgrade. Our [PHP 8.2 end-of-life guide](https://blog.paralinetech.com/php-8-2-end-of-life) covers the upgrade path.
5. **Set `session.upload_progress.enabled=0`** in php.ini or the FPM pool (not with `ini_set()` or `.user.ini`), then restart. Keep it off even after patching. A related bug, CVE-2026-115560, is not fixed yet.
6. **If you cannot patch today,** turn on WAF rules from Cloudflare, [AWS WAF](https://aws.amazon.com/blogs/security/using-aws-waf-to-apply-mitigations-for-php2shell-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619/), Google Cloud Armor or Imunify360. Every vendor says a WAF is not a fix. If nothing else works, take the site offline until it is patched.
7. **Check for compromise from 17 October onward.** Look for new web shells, odd cron jobs and new accounts. Save your logs before you change anything.

## What to do next

Check your PHP version today, patch it, and restart. Then review your logs back to 17 October. For the rest of the week's news, see [tech news this week](https://blog.paralinetech.com/tech-news-this-week-october-2026).

If you would rather hand this off, our [managed tech service](https://paralinetech.com/services/managed-tech) covers hosting and security updates. You can also [contact us](https://paralinetech.com/contact) for a one-off PHP check.

## Common questions

### Was any website hacked through PHP2Shell?

As of 27 October 2026, no primary source confirms a successful breach of a named organisation. Exploit attempts were seen on honeypots, and the organisations that went offline did so as a precaution.

### Does updating WordPress or my plugins fix PHP2Shell?

No. The flaw is in PHP itself, so you need a patched PHP build or a vendor backport, followed by a restart of PHP.

### Did an AI find PHP2Shell on its own?

No. Researchers at Calif, Wiz and OpenAI used AI models in their work, but people reported, checked and fixed the bugs.

Canonical page: https://blog.paralinetech.com/php2shell-who-was-hit