Understanding PHP2Shell vulnerabilities and reducing risk while you patch

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

Two critical PHP vulnerabilities disclosed this week pose an urgent security and business continuity risk for organisations 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 incredibly broad, spanning industries, including products in the cybersecurity sector. For organisations 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. FortiGuard Labs is helping organisations reduce exposure during this process with vulnerability guidance and virtual patching protections. You should apply PHP security updates as soon as you can safely do so, using interim controls during deployment.

Understanding PHP2Shell and Its Business Impact
PHP, which has existed for over 30 years, is a server-side scripting language powering widely deployed platforms such as WordPress, Drupal, Joomla, and Magento. Organisations may depend on PHP through their commercial applications, hosting providers, or embedded components, even if they do not develop PHP applications themselves.

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

Reducing Exposure While Deploying the Fix
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 (EASM) 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 (IPS) 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.

Virtual patching uses network inspection to identify and block 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.