The PHP project has fixed two critical remote code execution flaws in the PHP engine, now known as PHP2Shell. They’re tracked as CVE-2026-109618 and CVE-2026-109619, and each has a CVSS v4.0 score of 9.2. Wiz, OpenAI and Calif reported the bugs in August. Fixes shipped October 21 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, a day earlier than planned, after the CVE identifiers and some mitigation guidance leaked online.

Amazon Threat Intelligence says the first exploitation attempt hit one of its honeypots on October 17, four days before patches were available. The attempts came through commercial anonymization networks, and the payloads and infrastructure varied, which points to more than one actor. Amazon CISO CJ Moses warned that defenders “should not assume the public disclosure date is the earliest date of exploitation.”

The current threat is real but limited. Sansec, Wordfence and Dataminr report scanning and failed exploits but no confirmed compromises. Sansec says public exploits fail on default PHP settings. Sophos linked some blocked attempts to “Potassium,” which it believes is a Mirai variant. Separately, VulnCheck says it has built an exploit for CVE-2026-109618 that works against hardened production setups with ASLR enabled, available only to its paying customers. CISA had not added either CVE to its Known Exploited Vulnerabilities catalog as of October 26, according to vendor tracking from Tenable.

The bigger issue is exposure. SecurityWeek, citing Qualys data, reports that about 71% of the PHP instances Qualys sees (roughly 110 million) run end-of-life branches 5.4 through 8.1. Another 44 million run supported versions that haven’t been updated. The UK’s NCSC told organizations to patch immediately or take PHP servers offline until they can.

Why it matters / what to do

  • Patch internet-facing PHP first: move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. The PHP developers say patching is the only permanent fix.
  • Find end-of-life PHP: it often sits in vendor appliances, marketing sites and legacy apps. Isolate it, put it behind a WAF, or replace it.
  • Look for pre-disclosure activity: review web logs from October 17 onward, not just from October 21.
  • Check vendors: ask your SaaS and hosting providers whether they’ve patched.

Sources: SecurityWeek (Oct. 23, 2026); BleepingComputer (Oct. 22, 2026)