PHP2Shell flaws demand urgent updates to web-facing PHP

Organisations operating public-facing PHP should treat PHP2Shell as an urgent runtime-patching incident. The flaws can allow unauthenticated remote code execution, while WAF rules and configuration changes can only reduce exposure in limited circumstances; services that cannot be safely mitigated may need to be taken offline.

The immediate question is who owns the runtime. PHP sits beneath WordPress, Drupal, Magento and many bespoke sites; updating the application, theme or plugin does not replace a vulnerable PHP interpreter. In a managed hosting arrangement, that may be the provider’s job. In a self-hosted or containerised estate, it is probably yours. Either way, establish which PHP version is serving requests now.

The PHP project published fixed versions on 21 October 2026. For supported release branches, the first safe versions are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Its position is clear: configuration changes can reduce exposure to particular routes, but updating is the only complete remedy.

The exposure path: why this is more than an application bug

Both vulnerabilities concern PHP’s handling of request memory. CVE-2026-109618 involves an out-of-memory condition during request processing. PHP can be interrupted while internal request data is only partly initialised and, during clean-up, may treat invalid memory as valid. CVE-2026-109619 involves request-specific state surviving after its backing memory has been freed, allowing a later request handled by the same worker process to touch stale state.

The operational consequence matters more than the implementation detail. An attacker doesn’t need to log in and, in demonstrated cases, doesn’t need to reach the site’s application code before triggering the fault. The PHP advisory says every installation serving web requests is in scope, including PHP FastCGI Process Manager (PHP-FPM), Apache with mod_php, CGI (Common Gateway Interface), LiteSpeed and FrankenPHP. The project considers Apache mod_php the highest-risk arrangement because a demonstrated exploit can trigger before application code runs.

Don’t treat PHP-FPM as safe by comparison. Its process model changes some conditions and may reduce exposure for particular attack paths, but validated exploitation paths exist. Multiple workers, worker recycling and a front-end proxy may complicate an attack; they aren’t a patch.

So, does this affect WordPress? Potentially, because the site runs on vulnerable PHP — not because WordPress contains the flaw. The same applies to Drupal, Joomla, Magento and custom PHP applications. Updating the CMS may still be sensible for other reasons, but it does not cure PHP2Shell. Cloudflare has reported attack traffic aimed at these vulnerabilities after details leaked ahead of disclosure. That is not public confirmation of successful compromise at a known scale.

Which PHP versions need attention

Investigate every web-serving PHP installation. For currently supported upstream branches, the version check is straightforward:

PHP 8.1 and older no longer receive normal releases from the PHP project. They are not irrelevant; they are the awkward part of the incident. Some operating-system and long-term-support vendors may ship a backported package, meaning a security correction adapted to an older version, and PHP has supplied minimal source backports for PHP 7.4, 8.0 and 8.1. A source patch is not a comfortable operational answer for most organisations. If you are using an end-of-life branch, use the vendor’s explicitly documented fix if one exists, then plan a move to a supported PHP version. Don’t let the exception become permanent.

Don’t judge a Linux package by an upstream-looking version number alone. Ubuntu, Debian, Red Hat-derived distributions and commercial support providers often backport security corrections while retaining the original major/minor package version. Read the vendor changelog or advisory for the installed package build. Equally, don’t assume a host that updated system PHP has refreshed every customer container, virtual host, appliance or bundled runtime.

Detection starts with finding PHP you did not know you had

The NCSC’s first recommendation is inventory, starting with internet-facing systems. That sounds routine, but PHP estates are often less tidy than asset registers suggest. The command-line interface (CLI) interpreter shown by php -v may not be the one processing a website. One server can run several PHP versions, separate FPM pools, an old Apache module and application containers at the same time.

Start from public services and work inwards. Identify virtual hosts and load-balancer targets; map them to Apache, nginx, LiteSpeed or other web services; then identify the SAPI — the Server API, such as FPM or mod_php — and its installed package or image digest. Inspect container definitions and registries, not just running hosts. A current-looking application image can still rest on an older php:fpm parent image.

For a production website, a short-lived, access-controlled PHP information page can confirm the runtime responding to that site. Never leave it public: a full phpinfo() page exposes configuration and environmental detail attackers can use. Package queries, FPM status tooling, container inspection and deployment records are often the cleaner route.

Then look beyond web publishing. Check vendor advisories for NAS packages, control panels, web-based appliances, monitoring systems and line-of-business products that embed PHP. The NCSC-NL PHP2Shell repository maintains an evolving list of software with a PHP dependency. Use it as a discovery aid, not as proof that an unlisted product is unaffected. The appliance vendor remains the authority for the supported update path.

Prevention: patch first, contain only when you must

The right response is an emergency but controlled runtime update. Take a backup or deployment snapshot where that is normal practice, apply the supported distribution package or rebuilt image, restart workers, confirm the active version and smoke-test the service. It isn’t glamorous, but it is the work that closes the hole.

A web application firewall (WAF) can reduce exposure while patches roll out. Keep managed WAF rules enabled if you already have them, particularly across an internet-facing estate, but don’t let them become the reason a patch slips. Cloudflare’s own guidance is to patch PHP even where its new protections are deployed. These flaws can require context across requests and responses, and no edge rule can guarantee protection from a runtime defect.

If immediate patching is impossible, PHP’s guidance offers narrowly scoped risk reductions. Administrators can set memory_limit=-1 in startup or server configuration that an application cannot override, place conservative request-size controls at the proxy or web-server layer, and avoid using operating-system address-space limits that can themselves trigger the vulnerable failure route. For the stale-state flaw, disable session.upload_progress.enabled and restart all workers; PHP 8.5 operators can also disable fatal_error_backtraces.

These are temporary containment measures, not the fix. They may change application behaviour, particularly around uploads and resource consumption, and cover demonstrated paths rather than every route corrected by the patch. If a public service cannot be patched promptly and cannot safely tolerate containment, give the NCSC’s advice to take it offline more weight than a strained effort to keep it exposed.

Recovery: patching does not prove there was no intrusion

Remote code execution normally gives an attacker the privileges of the PHP web worker, not automatically unrestricted administrative access. Proper confinement can reduce the blast radius. It is little comfort, though, if that account can write application files, read configuration containing database credentials or call cloud APIs.

On systems exposed before patching, retain web-server, WAF, PHP-FPM and operating-system logs before rotation. Look for unusual multipart POST activity, abnormally large or malformed requests, repeated 5xx server-error responses, PHP fatal errors, memory exhaustion and execution-timeout messages. The official advisory also recommends reviewing warnings, deprecations and diagnostics occurring before target scripts run or during extension and server clean-up.

There is a hard limit: clean logs do not demonstrate safety. The stale-state issue may not produce a useful log line, and a successful attacker may remove or evade obvious traces. Review web roots and writable upload areas for unexpected PHP files, scheduled tasks, altered service definitions, unfamiliar outbound connections and changed credentials. Where there is credible evidence of compromise, preserve evidence and follow an incident-response process rather than deleting a suspicious file and calling it done.

Exposed SharePoint Server remote-code-execution vulnerabilities have demanded the same discipline: close the vulnerable entry point, then investigate what may have happened before it was closed.

Practical priorities for UK and Channel Islands operators

Small organisations should ask their hosting supplier a direct question: “Which PHP runtime serves our site, is it fixed for CVE-2026-109618 and CVE-2026-109619, and when was it restarted after the update?” A useful answer contains a version or vendor package reference and a timestamp. “We keep everything up to date” isn’t an answer.

Larger organisations should avoid turning this into an endless vulnerability-management ticket chain. Give public-facing PHP services an owner, set a brief deadline for version evidence, chase suppliers and treat unverified legacy systems as exposed until shown otherwise. The difficult systems will be old vendor portals, appliance web interfaces, inherited CMS instances and workloads with rarely rebuilt container images. Those are the systems likely to remain once the obvious patching is done.