Skip to content

PHP2Shell: Two Critical PHP Flaws Allow Unauthenticated Takeover of Web Servers

PHP2Shell (CVE-2026-109618, CVE-2026-109619) lets one unauthenticated request run code on PHP servers. Fixed versions, who is exposed and what to do now.

PHP2Shell: Two Critical PHP Flaws Allow Unauthenticated Takeover of Web Servers

PHP shipped fixes on 21 October for two remote code execution flaws that let an attacker run code on a web server without logging in. Nicknamed PHP2Shell, the pair are tracked as CVE-2026-109618 and CVE-2026-109619, each rated 9.2 on the CVSS v4.0 scale. Exploitation attempts began before the fixes were public, and on 26 October CISA added both flaws to its Known Exploited Vulnerabilities catalogue, giving US federal civilian agencies until 29 October to act.

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and only an update is a complete fix.

What the two flaws are

Both bugs are in the PHP runtime, not in the application running on it. Wiz's research write-up says even a "Hello World" script on an affected version can be vulnerable, so updating a CMS or its plugins doesn't help.

  • CVE-2026-109618, out-of-memory corruption. If PHP runs out of memory part of the way through setting up a request, internal request data can be left half-built, and the cleanup code that runs afterwards may treat it as valid.
  • CVE-2026-109619, stale global state. Some internal state outlives the request memory it points to, so the next request on the same PHP worker can pick it up before it's reset.

PHP's advisory describes a demonstrated exploit in which one unauthenticated request triggers the attack before any application code runs, and it rates Apache with mod_php as the highest risk.

Who is exposed

Every PHP installation that serves web requests is in scope: PHP-FPM, Apache mod_php, php-cgi, LiteSpeed and FrankenPHP. Palo Alto Networks' Unit 42 says its Cortex Xpanse telemetry found over 22.6 million exposed instances potentially vulnerable to the pair.

The flaws also reach appliances that ship PHP inside them. Palo Alto Networks lists affected releases in every PAN-OS branch from 10.2 to 12.2, through the management web interface only, with several hotfixes still due by 30 October. At Cisco, Expressway, Ultra-Reliable Wireless Backhaul and Duo Access Gateway are vulnerable, in an advisory last updated on 27 October. Fortinet clears FortiOS and dozens of other products in advisory FG-IR-26-186 and is still investigating FortiDDoS, FortiSOAR and FortiSOAR PaaS.

Exploitation attempts began before the patch

The PHP Foundation's account of the disclosure says the two CVE IDs began circulating on forums and social media around 15:00 UTC on 20 October, with a wrong release time and a wrong score of 10.0. No technical details leaked, but PHP moved the release forward a day, from 22 October to 14:00 UTC on 21 October.

Amazon Threat Intelligence said its MadPot honeypots recorded an exploitation attempt on 17 October, four days before public disclosure, from an IP address tied to a commercial anonymisation network. How the attacker got the exploit information that early is unclear. From 21 October, watchTowr's Attacker Eye honeypots saw exploitation in the wild. Cloudflare's chief executive Matthew Prince said on 22 October that attempts across its network went from thousands in the ten hours before the announcement to tens of thousands in the 45 minutes after it, and to millions by the time he posted.

How many of those attempts work is less clear. Amazon couldn't say whether the attempts it saw would have succeeded against real systems. Wiz's 27 October update reports a limited number of attempts and no successful end-to-end exploitation in its own telemetry, though it calls a researcher's report of confirmed code execution on single-worker mod_php honeypots the strongest public evidence so far. In Singapore, the Cyber Security Agency said in alert AL-2026-151 on 23 October that it was aware of widespread exploitation attempts.

Found with AI

The security firm Calif found its first path to remote code execution on 1 August, during an audit for OpenAI's Patch the Planet programme, and reported the first bug to PHP on 11 August. Fortune reported that Calif's researcher used an OpenAI model. Wiz sent PHP further attack vectors on 24 August. Wiz's write-up credits frontier AI models with making the long exploit chain practical.

What to do now

  1. Find every PHP installation, appliances included. watchTowr advises starting with internet-facing servers that run PHP as an Apache module.
  2. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution's patched package, and restart every PHP worker afterwards so the fix takes effect.
  3. On PHP 7.4, 8.0 or 8.1, get a backported package from your vendor or build from PHP's source backports, and plan the move to a supported branch. On 7.3 or older, that move is the fix.
  4. If a server can't be patched yet, apply PHP's stopgaps, such as setting session.upload_progress.enabled=0 in php.ini or the FPM pool (not through ini_set() or .user.ini) and, on PHP 8.5, fatal_error_backtraces=0. They block the confirmed paths but not other variants. If neither patching nor the stopgaps is possible, the UK's NCSC advises considering taking the system offline, and Cloudflare has deployed WAF rules for the known exploit paths on all plans, including Free. Keep the upload-progress setting after patching too: PHP recommends it until the next regular release against a related flaw, CVE-2026-115560.
  5. Check exposed hosts for compromise from 17 October onwards, the start date Amazon gives for investigations. Searchlight Cyber's open-source php2shell-scanner tests a host for both flaws, and the commands are in a separate guide to checking and patching a server.