What happened

On 21 October 2026, the PHP project released fixes for two critical vulnerabilities in the PHP engine: CVE-2026-109618 and CVE-2026-109619, collectively referred to as “php2shell.” Both flaws are rated Critical (CVSS v4.0 score of 9.2 out of 10), the highest severity category. Each flaw can let an attacker take control of a server running PHP, without a password or login, by sending it a single specially crafted web request.

Details of the vulnerabilities leaked on 20 October 2026, ahead of the planned coordinated release. An exploit tool, PHP2Shell, credited to the security firm Calif, which discovered the flaws alongside Wiz Research and OpenAI, is now publicly available. According to Sansec, the vulnerable code dates back to PHP 5.4, and Calif has confirmed unauthenticated code execution against widely used platforms including WordPress, Drupal, Magento and Joomla. Palo Alto Networks’ Unit 42 reports that it has observed proof-of-concept code and estimates that more than 22.6 million internet-exposed PHP instances are potentially vulnerable.

With a working exploit publicly available, widespread exploitation is expected. Cloudflare reported early attack activity at 07:43 UTC on 21 October, before the fixes were released. The Dutch NCSC had no confirmed reports of exploitation at the time of writing and expects large-scale exploitation to follow. WatchGuard Red Cell will update this post as the situation develops.

Why it matters

Both vulnerabilities sit in PHP's request handling, not in any specific application. A server running fully patched WordPress, Drupal or custom code is still exposed if the underlying PHP version is vulnerable. The PHP project notes that on Apache with mod_php, it has demonstrated exploitation before any application code runs.

In short, an attacker can deliberately make PHP fail part way through handling a request, in a way that lets them run their own code on the server.

CVE-2026-109618 is triggered when an attacker forces PHP to exhaust its memory part way through processing a request. PHP stops processing, but its cleanup routine treats the incomplete request data as valid, which an attacker can abuse to run code. CVE-2026-109619 is triggered by a fatal error. Internal state from the failed request is not fully reset and continues to reference released memory. A subsequent request handled by the same worker process can use that stale state to run code.

For MSPs and partners managing multiple environments, the exposure extends across every client environment that runs PHP. Staging sites, legacy forums and line-of-business applications are frequently outside normal patch cycles and are likely entry points.

Affected and fixed versions

According to the PHP project, every PHP installation that serves web requests is affected. This includes all the common ways PHP is connected to a web server: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed.

Managed hosting providers apply PHP updates on their own schedule. Confirm the rollout status with the provider and verify the running version once the provider reports completion.

WatchGuard Products

WatchGuard has completed its initial analysis and found none of our products are affected by the vulnerability. See https://psirt.watchguard.com/WGSA-2026-0032 for our response and future updates.

Indicators of compromise

No vendor has published confirmed indicators of compromise at the time of writing. The following are hunting leads. Treat a match as a starting point for investigation, not confirmation of compromise.

Guidance for IT teams and partners

Upgrading PHP is the only complete fix. Prioritize internet-facing systems and act on the following steps in parallel where possible.

1. Inventory PHP across all environments. Identify every system running PHP in your own environment and, for MSPs and partners, in client environments, including staging, test and pre-production sites. Confirm versions on each host with php -v and the installed package version. Vulnerability scanners may not report findings for backported or third-party PHP builds.
2. Upgrade supported branches. Install PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restart all PHP worker processes. For managed platforms, obtain written confirmation from the provider and verify the version independently.
3. Isolate end-of-life systems. Remove internet access to systems running PHP 8.1 or earlier, or restrict access to VPN and known IP addresses, until they are upgraded. Apply the same restriction to non-production environments that are not protected by a WAF.
4. Apply interim hardening. The PHP advisory lists temporary configuration changes for each CVE. These changes reduce risk but do not remediate the vulnerabilities. Apply them at the server level, in php.ini or the PHP-FPM pool configuration, and restart all workers. Test the changes on a single server before broad rollout. Enforce request size, multipart part count and field count limits at the reverse proxy or WAF.
5. Enable network protections. Enable WAF and IPS signatures for CVE-2026-109618 and CVE-2026-109619 in blocking mode. Confirm that the origin server cannot be reached directly in a way that bypasses the WAF, such as through a DNS record that points directly at the server rather than through the WAF.
6. Search logs and preserve evidence. Review logs from 20 October 2026 onward for the indicators above. If you identify suspicious activity, preserve logs and disk images before remediation and change passwords, keys and other credentials stored on (or accessible from) the affected server.

Steps 5 and 6 are most relevant for organizations without MDR coverage. If you are a WatchGuard MDR customer, we are proactively monitoring for any attempted exploits.

Sources

• PHP project security advisory
• Unit 42 threat brief
• Sansec research
• Cloudflare statement
• NCSC-NL advisory