Emergency runtime update — October 21, 2026. A website can have current plugins and still be exposed through the interpreter underneath them. PHP2Shell is a reminder to patch that foundation: PHP has released 8.2.35, 8.3.36, 8.4.27 and 8.5.12 for two critical flaws that can enable unauthenticated remote code execution. The PHP release announcement calls for immediate updates across web-serving installations, including FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed, with the highest demonstrated risk assigned to mod_php.

Two flaws, different failure paths

CVE-2026-109618 concerns out-of-memory corruption. An allocation failure can interrupt work while internal request data is only partly initialized. Cleanup may subsequently use that invalid data. The advisory describes a demonstrated mod_php path that runs before application code, making application-level authentication an inadequate boundary for that path.

CVE-2026-109619 concerns stale request state. A worker can retain references after the request's underlying memory has been freed. Another request reaching that worker may consume those references before initialization clears them, creating a use-after-free. The advisory documents confirmed RCE against mod_php and a validated session-lifecycle RCE path against FPM that requires a suitable application operation. Deployment details affect exploitability; they do not justify treating every non-Apache installation as safe.

What is observed, and what is not established

Wiz reports research demonstrations of unauthenticated RCE against WordPress, Drupal and Joomla deployments, plus disclosure of sensitive worker memory. These are representative test targets, not proof that those projects' application code caused the underlying defects, and not a count of compromised customer sites.

Cloudflare separately reports attack traffic targeting customers and changes to payloads intended to evade its protections. It describes deployed WAF defenses and recommends patching PHP regardless. That is evidence of hostile activity, not a verified census of successful intrusions. This article makes no claim about the number of breached websites.

The PHP Foundation's disclosure account says the coordinated release was advanced from October 22 to October 21 after information began circulating. Use October 21 as the emergency-release date rather than inferring otherwise from a changelog label.

Remediation priorities: close the runtime gap

The following is Bulwark Black's operational assessment: the hardest part of this response is proving which interpreter actually serves each application, then proving that the old workers are gone.

  1. Map exposure to an owner. Start with internet-facing sites, hosting panels, APIs and upload endpoints. Identify each serving integration, package source, container image and responsible team. A patched command-line binary does not establish that an FPM pool or Apache module uses the same installation.
  2. Deploy the fix where requests execute. Update supported branches to the fixed versions above, or obtain explicit confirmation that the installed vendor package contains both fixes. Rebuild container images from patched bases and redeploy them; updating an image tag in a registry does not replace running containers.
  3. Restart or replace workers, then verify service. Check the runtime associated with every active pool, instance and deployment replica through trusted management access. Validate health checks, uploads and representative transactions. Record package revisions or image digests and restart evidence so closure is auditable.
  4. Resolve legacy hosting explicitly. PHP says 8.1 and older remain unsupported by the project, even though minimal emergency source backports exist for selected old branches. A backport's existence is not evidence that a host installed it. Get written vendor package status or move to a supported runtime; do not mistake an old upstream version string alone for a complete patch assessment.
  5. Keep edge protection, but retain the patch deadline. A CMS or plugin update does not repair core PHP. Verify that WAF policies cover the relevant traffic and that alternate origin access cannot bypass the intended boundary. Treat filtering as defense in depth, not a substitute for the runtime fix.

Investigate without turning references into IOCs

Wiz highlights unusual multipart traffic, memory-limit errors, repeated HTTP 500 responses, abnormal PHPSESSID cookies and unexplained worker churn as investigation leads. Correlate those signals with process execution, new files and outbound connections; none alone proves exploitation. Preserve relevant proxy and runtime logs before rotation, and escalate suspicious combinations through incident response.

If patching must briefly wait, consult PHP's official temporary mitigations and their limitations. Do not apply a blanket memory-limit change without its availability controls and residual-risk caveats. CVE identifiers are vulnerability references—not malicious network IOCs. Research domains and patch commit identifiers likewise do not belong in attacker blocklists merely because they appear in these reports.

Bottom line: prioritize the runtime inventory, replace vulnerable workers, and verify the serving fleet. A green CMS dashboard is not evidence that PHP2Shell has been remediated.