Skip to content
Patch Now: php2shell: What We Know About the Leaked Critical PHP Vulnerabilities (CVE-2026-109618 & CVE-2026-109619)

Patch Now: php2shell: What We Know About the Leaked Critical PHP Vulnerabilities (CVE-2026-109618 & CVE-2026-109619)

Blog.Checkpoint •[email protected] • October 21, 2026

Check Point Intrusion Prevention System (IPS): IPS protection was just released to active this evening – PHP Remote Code Execution (CVE-2026-109618, CVE-2026-109619). Always Make sure gateways pull IPS updates automatically and set new critical protections to Prevent , not Detect. Watch Check Point Advisories for a new CPAI entry covering these CVEs, and install it as soon as it ships.

Existing web shell coverage: Keep PHP Webshell Upload Over HTTP (CPAI-2021-0286) active in Prevent mode. It catches a common post-exploitation step, not the exploit itself.

Check Point Web Application Firewall (WAF): Based on the early exploit POC we did, Our WAF engine was able to protect the remote shell execution, we recommend to enable the latest signatures in blocking mode, making sure best coverage and visibility are deployed

Access and segmentation: Restrict outbound traffic from web servers to only what they need, limiting the reach of a successful exploit.

Endpoint and server detection: Alert on web server processes spawning shells or download tools, and on new files appearing in webroots.

Check Point Endpoint Security: Confirm detection coverage for web server processes spawning shells and webshell activity.

Gateway controls reduce risk, but they do not replace the PHP update: the flaw lives in the interpreter, and encrypted traffic that isn’t inspected bypasses network signatures.

See What Attackers Would Find in Your Environment: Get a free Agentic Exposure Validation scan and walk away with evidence.

On October 20, a post on Hacker News claimed that two critical remote code execution (RCE) vulnerabilities in PHP – tracked by researchers as CVE-2026-109618 and CVE-2026-109619 – would be publicly disclosed on Thursday, October 22, before any patch was available. The post was taken down, but screenshots had already spread across social media. Researchers at watchTowr then confirmed the leaked information was real and that the flaws were under embargo, and reported reproducing CVE-2026-109618.

That evening (19:33 UTC), the PHP security team published an advance notice of an out-of-cycle security release for two critical vulnerabilities, both rated CVSS v4.0 9.2 (the leaked post had claimed 10.0). The release is scheduled for today, Wednesday, October 21, at 14:00 UTC – a day ahead of the original embargo – and PHP says it may ship even earlier if technical details go public or exploitation is observed. PHP has not published any workaround in the meantime.

Researchers have dubbed the pair “php2shell” – a name that signals the worst-case scenario: a single web request that hands an attacker a shell on the server. Note that both the name and the CVE identifiers originate from researchers and the leaked post; PHP’s official notice names neither.

PHP is everywhere. It powers WordPress, Drupal, Joomla and Magento sites, shared hosting platforms, control panels such as cPanel and Plesk, and a long tail of commercial software that bundles PHP without advertising it. Because the vulnerabilities sit in PHP itself rather than in a single application built on top of it, the potential attack surface is enormous – and much of it lives on internet-facing web servers that are rarely monitored closely.

What do we know so far?

Only three facts come directly from PHP: two critical flaws, CVSS 9.2 each, and a release on October 21 at 14:00 UTC. Everything else comes from researchers and the leak, so we flag confidence below.

Severity (confirmed): CVSS v4.0 9.2 for both vulnerabilities, per PHP. Early leaked posts cited 10.0.

Type (high confidence): Remote code execution in the PHP core interpreter – not in application code. Updating WordPress, Magento or Drupal alone will not fix it.

Authentication (medium confidence): Likely none required, as CERT-EU infers from the score.

Affected versions (medium confidence): Reports claim every version from PHP 5 onward (Sansec says 5.4+). PHP has not confirmed the range and will publish it with the release.

Fix availability: PHP only patches its four supported branches – 8.2, 8.3, 8.4 and 8.5 . Anything on 8.1 or older stays exposed unless a distribution or vendor backports the fix.

Attack vector (unconfirmed): Early research points to crafted multipart/form-data POST requests that reach PHP before any application script runs. One report describes CVE-2026-109618 as a use-after-free. Both claims are low confidence.

Exploit tooling: Screenshots of an exploit tool called PHP2Shell, claiming to work against PHP 5.4.0 and later, are circulating. POC examples started to surface, example watchTowr says it has reproduced CVE-2026-109618.

Exposure: Security firm Mallory counted roughly 884,000 internet-facing hosts advertising PHP 8.1 or older in their Shodan banners on October 20 – 59% of the ~1.5 million hosts that reported a version – plus another ~740,000 reporting PHP without a version. These are banner counts, not confirmed vulnerable systems.

Exploitation: None reported in the wild so far, and the flaws are not listed in CISA’s Known Exploited Vulnerabilities catalog.

Expected fixed versions are based on Alpine Linux trackers and researcher Kevin Beaumont, as reported by The Hacker News. Confirm against php.net before rolling out.

Speed is the main concern. Because details leaked a day early, the usual head start is gone – and once the patch is public, anyone can diff it to build a working exploit. The last core PHP RCE at this scale, CVE-2024-4577, drew botnet scanning within 24 hours of disclosure. We recommend treating the 72 hours as incident readiness, not a routine patch cycle.

What do you need to do to remain protected?

We urge IT and security teams to act now according to these guidelines:

Inventory every PHP instance – internet-facing first. Look beyond web servers: PHP-FPM pools, container base images, vendor appliances and Windows software bundling php.exe or php-cgi.exe, hosting control panels such as cPanel and Plesk, and CMS platforms such as WordPress, WooCommerce, Magento, Shopware and Drupal.

Stage the update path for each platform – distribution packages, container images and hosting providers – and book a change window for 14:00 UTC (17:00 Israel time) .

Patch at release – read the official php.net advisory to confirm affected and fixed versions, patch internet-facing hosts first, then restart PHP-FPM or the web server and verify the running version , so the new interpreter actually loads.

Address end-of-life PHP – flag hosts on 8.1 or older and choose a plan: vendor backport, upgrade to a supported branch, or isolation behind a VPN or web application firewall.

Isolate what you can’t patch immediately – as CERT-EU advises, take internet-facing PHP applications offline or behind access control until a fix is in place.

Track distribution advisories (Ubuntu, Debian, Red Hat, SUSE, Alpine) for backports.

What should you hunt for?

With no technical details or indicators of compromise (IOCs) published yet, early hunting can only catch generic signs of attack:

Unusual multipart POSTs – large or malformed multipart/form-data requests to PHP endpoints, especially ones that never accept uploads, and spikes from a single source.

PHP worker crashes – segmentation faults or sudden restarts in PHP-FPM, Apache or nginx logs. Memory-corruption bugs often crash workers before an exploit works reliably.

Web servers spawning shells – php-fpm, httpd or www-data launching sh, bash, curl, wget, python or nc.

New files in webroots – fresh .php files, especially in upload, cache or tmp folders.

New outbound traffic from web servers to unknown hosts right after inbound POSTs.

Existing web shell detections – IPS hits on PHP web shell uploads and web server enforcement violations.

Repeat these checks right after the 14:00 UTC release, then again at 24 and 72 hours. If you find suspicious activity, isolate the server, preserve web server and PHP logs, and hunt for webshell, new scheduled tasks or cron jobs, and new accounts.

Check Point Research is closely monitoring the situation, including the upcoming PHP security release, researcher analysis and any signs of scanning or exploitation attempts across ThreatCloud AI . We will update this blog with affected and fixed versions, technical details, indicators of compromise and protection updates as soon as they become available.

Our technical support teams are available 24/7 to help you stay protected.