PHP2Shell: a critical vulnerability that demands immediate attention

Two critical flaws in PHP can expose sensitive server memory or allow an unauthenticated attacker to execute code. The response is straightforward: identify affected services, patch them immediately and investigate any signs of compromise.

PHP runs a large part of the web. That reach turns two newly disclosed vulnerabilities, collectively dubbed PHP2Shell, into a serious problem. An attacker who does not have an account may be able to read sensitive server memory or execute code. The result could be stolen data, altered websites or complete control of a service.

Researchers have demonstrated successful exploitation, and watchTowr reports exploitation in the wild. Organizations therefore need to establish not only whether they are exposed, but whether vulnerable services may already have been compromised.

Inventory PHP services and patch immediately, prioritizing internet-facing systems. Temporary mitigations can reduce exposure, but they do not replace patching.

Exploitability varies by deployment, but patching is urgent for all

The bugs arise when processing a request is interrupted. PHP may carry on using memory that is incomplete or has already been freed. With the right sequence of requests, an attacker may be able to turn that mishap into a leak of information or the execution of code.

Exploitability depends on the PHP version, server configuration and application behaviour. Both Apache with mod_php and PHP-FPM require attention, and some attacks may begin before application code runs.

Calif identifies affected paths dating back to PHP 5.4.0. Broader reporting describes PHP 5.0 onward as affected, although every historical release has not been validated to the same degree. Unsupported versions should be upgraded or replaced.

The first fixed upstream releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Vendor packages may contain equivalent backported fixes.

What to do now

The first task is to establish where PHP is running. It may sit behind public websites, internal applications, containers, appliances and outsourced hosting, often with responsibility scattered across several teams or suppliers. The response has five parts.

Map the exposure. Inventory all PHP applications and runtimes, including public websites, internal applications, staging sites, containers, appliances, vendor-bundled PHP, hosting panels, outsourced hosting and parallel PHP installations. Record the service owner, actual PHP version, internet exposure and patch status. Common PHP applications include WordPress, Drupal, Joomla, MediaWiki, Magento/Adobe Commerce, Nextcloud, Roundcube and phpMyAdmin, alongside custom applications.

Patch immediately and verify completion. Update the underlying PHP runtime; updating the application alone may be insufficient. Confirm vendor patch status, including equivalent backported fixes, and obtain confirmation from hosting providers. Restart or redeploy all affected services and containers, including long-running PHP workers. Verify that the live services use the corrected runtime.

Remove or restrict access if patching is impossible. Remove internet access or temporarily shut down the affected service. Where continued operation is essential, restrict access to trusted networks pending patching.

Apply temporary controls. Follow vendor guidance: disable session upload progress and, on PHP 8.5, fatal-error backtraces; block unnecessary multipart requests and enforce request limits. These measures reduce exposure to specific attack paths but do not comprehensively remediate the vulnerabilities.

Look for evidence of exploitation. Review web-server, reverse-proxy, PHP and security logs, together with endpoint telemetry, for unusual POST requests, repeated server errors, memory-limit failures and worker crashes. Investigate unexpected processes, outbound connections and application-file changes. Correlate timestamps and request identifiers where available, preserve relevant evidence and escalate suspicious findings. Individual errors do not prove exploitation, and clean logs do not establish that compromise is absent.

Patching closes the vulnerability, but it does not remove an existing compromise. DNV Cyber can assist with exposure assessment, log analysis, incident investigation and remediation planning. We can also help organizations reduce their attack surface and develop a practical path away from ageing or unsuitable internet-facing technology where the risk justifies it.

Taking no chances

Some governments have chosen the bluntest precaution. On 21 October 2026 Yle reported that Valtori was taking Finnish government websites offline; Reuters described similar shutdowns elsewhere in Europe. Removing a service while it is patched can be perfectly sensible. It is not, by itself, evidence that the service was breached.

The same concern was reflected in official guidance across the Nordic region. Finland’s National Cyber Security Centre published a national vulnerability advisory on the two PHP flaws. Norway’s National Security Authority told all system owners to install the updates as quickly as possible and had earlier advised taking affected systems off the network until they could be upgraded. Sweden’s CERT-SE urged organizations to update immediately. Denmark’s Agency for Societal Security likewise said systems should be patched without delay—and taken offline if that could not be done quickly. The wording differed; the message did not.

The broader lesson is not confined to PHP. Attackers routinely revisit old vulnerability classes and assumptions, looking for weaknesses that have survived—or returned—as software has evolved. That is likely to keep pressure on mature technologies with a large internet-facing footprint. Patching remains essential, but organizations should also ask whether every exposed service still needs to be there, and whether some systems should be isolated, modernized or replaced over time.

PHP2Shell shows how quickly a defect in common infrastructure can become everybody’s problem. Organizations that know where PHP is running—and can join patching to investigation—will fare best. For everyone else, the advice is terse: find it, fix it, verify it and check the logs.