Summary: On October 21, 2026, the PHP project released emergency fixes for two critical vulnerabilities (CVE-2026-109618 and CVE-2026-109619, nicknamed “PHP2Shell”) that allow unauthenticated remote code execution against almost any site running PHP, including WordPress, Laravel and Drupal. We applied interim hardening to every server we manage before the fixes were published, blocked the known attack path at our Cloudflare edge, and installed the patched PHP releases on our servers the same day they became available.
What happened
Details of two flaws in the PHP interpreter itself leaked on October 20, ahead of the planned coordinated disclosure, and exploitation attempts began within hours. Both flaws sit in how PHP handles incoming requests, before any application code runs, so the usual defenses inside WordPress or a framework do not help. Early analysis pointed to PHP’s session upload-progress feature and multipart (file upload) requests as the trigger. The PHP security team shipped fixed releases on October 21 at 14:00 UTC: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Older branches such as PHP 7.4, 8.0 and 8.1 are end-of-life and receive fixes only through third-party backports.
What we did, in order
1. Interim hardening on every server (before the fix existed)
We audited every server we operate for the PHP settings the PHP project and others recommended as a stopgap and applied them fleet-wide as needed. These settings reduce exposure but did not fix the bug.
2. Blocking at the edge
Cloudflare pushed emergency detections for the known exploit patterns into its managed firewall ruleset, which is active on the sites we front with Cloudflare. For applications that do not accept file uploads at all, we went a step further and added rules that reject any multipart request outright, which closes the known attack path regardless of signature. We also reviewed each zone for servers that could be reached directly, bypassing Cloudflare, and locked those down so that web traffic can only arrive through Cloudflare’s network.
3. Patching
As soon as patched packages were published, we upgraded every PHP version on every server we manage directly, restarted the PHP services, and verified each site afterwards. All of those servers now run PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12. For sites hosted on WP Engine, PHP is managed at the platform level: WP Engine reports it is rolling the patched PHP versions out across its platform with protective rules in place in the meantime, and we are tracking that rollout.
What we found
We have seen no evidence of successful exploitation on any site we manage. Our Cloudflare logs show the new rules blocking test traffic as expected, and we are continuing to monitor.
What happens next
- If a client’s website required special consideration due to code changes or site age related to this issue, we’ve reached out to them directly.
- The interim hardening settings will stay in place. They are PHP-recommended defaults and carry no downside for our sites.
- Hosts and vendors outside our direct control have been notified where we identified exposed systems.