Organisations should urgently patch affected runtimes, verify deployments, apply interim protections, and investigate possible compromise while updates are tested

Two critical PHP vulnerabilities disclosed this week pose an urgent security and business continuity risk for organizations that depend on websites, customer portals, and other web applications. Collectively known as PHP2Shell, these flaws may let an unauthenticated attacker execute code on an affected server, potentially exposing sensitive information and disrupting services.

PHP2Shell’s impact is extremely broad, spanning industries, including products in the cybersecurity sector. For organizations running PHP applications, remediation requires coordination across security, application, and infrastructure teams.

Updating the underlying software may require compatibility testing, maintenance windows, and service restarts, which can delay patch application. CISOs should apply PHP security updates as soon as possible, using interim controls during deployment.

Aamir Lakhani, Global Director of Threat Intelligence and Adversarial AI Research, Fortinet

Understanding the vulnerabilities

PHP2Shell affects the PHP runtime — the software that executes application code. Updating only a content management system or plugin does not fix the underlying flaws. The vulnerabilities are tracked as CVE-2026-109618 and CVE-2026-109619, and both are rated critical, with a CVSS 4.0 score of 9.2.

CVE-2026-109618 involves memory corruption during out-of-memory error handling, when cleanup uses partially initialized request data. CVE-2026-109619 involves stale global state, where a PHP worker accesses references to memory released after a previous request. Both issues can lead to remote code execution (RCE), allowing an attacker to run malicious commands or programs on the affected server, potentially compromising applications, exposing sensitive data, or disrupting services.

Public internet scanning illustrates the scale of potential exposure. In its 22 October 2026 snapshot, Censys’ PHP2Shell dashboard had identified approximately 36.7m internet-facing services reporting potentially affected PHP versions. These are service counts, not unique servers or organizations, and version-based estimates may include installations already patched through vendor backports. Organizations should use this information to inform a response while confirming the actual exposure and patch status of their own deployments.

The PHP project identifies all PHP installations that serve web requests as being at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. It identifies mod_php as the highest risk because researchers demonstrated an attack that runs before application code. Application authentication may therefore not prevent exploitation. Successful code execution runs with the affected process’s privileges and could expose application secrets, credentials, or connected resources.

Reducing exposure while patching

The PHP project released security updates on 21 October, 2026. Fixed upstream releases are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Organizations using distribution or application-vendor packages should confirm which package contains the fix, as vendors may backport security changes without adopting the upstream version number.

PHP 8.1 and earlier no longer receive standard security releases from the PHP project. Organizations using these branches should check whether vendors provide supported backports or offer an upgrade to a supported version. The PHP project has also provided limited source backports for select older branches, which require suitable build and deployment expertise.

The time required for remediation will vary based on application dependencies and provider readiness. You should assign an owner and a remediation timeline to each affected service and keep interim controls active until verification. Security and application teams should coordinate the following actions:

1. Identify affected deployments

  • Use external attack surface management to help discover internet-facing assets. Include those missing from existing inventories, and prioritize potentially exposed PHP services
  • Confirm and record each deployment’s active PHP version, deployment model, application owner, and patch status
  • Include containers, managed hosting, and third-party applications that bundle PHP
  • Confirm remediation plans with the providers responsible for those environments

2. Test and deploy the update

  • Test the PHP update against critical application workflows and dependencies
  • Deploy the appropriate patched PHP runtime or vendor-provided package
  • Restart or replace affected PHP workers and containers as needed
  • Verify that the running web service uses the patched runtime and that older worker processes have stopped (a completed package update alone does not confirm that the fix is active)

3. Apply interim controls

While preparing and deploying the PHP update:

  • Enable relevant virtual patching, intrusion prevention system protections, and web application firewall protections
  • Review the PHP advisory for temporary configuration measures appropriate to your deployment
  • Place systems that do not need to be internet-facing behind a VPN or SASE to reduce exposure
  • Restrict access to affected services where practical
  • Consider temporarily isolating the affected service until it can be patched (if these measures cannot adequately control exposure)

4. Investigate potential compromise

  • Review suspicious web requests, unexpected PHP worker crashes, unexplained process execution, modified application files, and unusual outbound connections
  • Preserve evidence and investigate persistence mechanisms and exposed credentials if compromise is suspected. Note: installing the fix will not remove an attacker who has already gained access
  • Note that temporary configuration changes address only specific attack paths. For example, disabling session upload progress may reduce exposure to confirmed session-related paths for CVE-2026-109619, but it does not cover all variants. The PHP project states that updating is the complete solution. Follow its current advisory rather than treating a single setting or traffic rule as a comprehensive fix
  • One technique called virtual patching may be used where available, where network inspection identifies and blocks known exploitation techniques before they reach a vulnerable system. It reduces exposure without changing application code, giving teams time to test the PHP update and complete the necessary operational work

Addressing PHP2Shell requires a coordinated response to mitigate immediate exposure while accounting for the operational demands of updating business-critical applications. Organisations should identify affected runtimes, install appropriate security updates, and verify that patched code is running across all affected services.