Address PHP2Shell by applying a fixed PHP release or vendor patches to the PHP runtime that handles web requests. The upstream releases published on October 21, 2026 are 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Verify the actual web runtime and running processes, rather than relying on CLI output alone. Moving to static delivery is an architectural decision that can reduce future exposure; it does not justify postponing updates to PHP that is running now.

The architecture section presents our own analysis based on the official sources.

What is PHP2Shell? CVEs and fixed versions

The PHP security announcement and IPA alert (Japanese) describe two vulnerabilities:

Identifier

Summary

CVE-2026-109618

An out-of-memory condition leaves internal data in an incomplete state that is later handled during shutdown

CVE-2026-109619

Internal state retains a pointer to memory freed after an earlier request and uses it during a subsequent request

Both can lead to unauthenticated remote code execution when the necessary conditions are met. For supported branches, the PHP CNA’s CVE record and ChangeLog identify the following versions:

Branch

Affected upstream versions

Fixed version

8.2

Before 8.2.35

8.2.35

8.3

Before 8.3.36

8.3.36

8.4

Before 8.4.27

8.4.27

8.5

Before 8.5.12

8.5.12

PHP 8.1 and earlier are outside regular upstream support. For this incident, minimal source patches were also provided exceptionally for 7.4, 8.0, and 8.1. Do not interpret an older branch as unaffected: check vendor patches and plan a move to a supported branch.

Are PHP-FPM and WordPress affected?

The PHP project identifies PHP runtimes that process web requests as at risk, including PHP-FPM, Apache’s mod_php, php-cgi, FrankenPHP, and LiteSpeed. This is not limited to CGI configurations on Windows.

An attack before application code executes has been demonstrated with mod_php. The official OOM advisory distinguishes paths by SAPI, and the PHP Foundation also reports confirmed code execution through an application using PHP-FPM. FPM alone is not grounds for treating a deployment as safe.

The stale state advisory involves state and settings when the same worker handles multiple requests. Avoid assuming that an identical attack works against every configuration, but prioritize patching regardless of the execution model.

Check PHP versions on servers and in Docker containers

In an environment you have permission to administer, first collect CLI information:

bash
php -vphp --iniphp -r 'echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;'

These commands inspect the CLI runtime. It may differ from the FPM pool, Apache module, or separate PHP executable used by the web server. Record the runtime assigned to each domain and the full revision of the distribution package.

phpinfo() can show the version, SAPI, and configuration, but also exposes environment information. Use a restricted route or an existing internal diagnostic tool rather than publishing a diagnostic page openly. Remove unnecessary diagnostic pages after checking.

For Docker, list running containers with:

bash
docker ps --format '{{.ID}}\t{{.Image}}\t{{.Names}}'

Choose the relevant ID and inspect its CLI with docker exec <container-id> php -v, replacing <container-id> with the actual value. Compare the Dockerfile’s FROM, the final image in a multistage build, and the running container. Check whether an old image is still running even if the tag is unchanged.

Choose an update method for your PHP provider

Installation method

What to check or update

Linux distribution package

The OS security notice and the revision of the patched package

Application using a Docker Official Image

Confirm the fix for the relevant tag, fetch the base image, rebuild, and redeploy

Built from source

Rebuild using official source and verification information, then test functionality including extensions

Shared hosting

The completion notice and scope for your contracted service, plus any checks required from users

A vendor backport may leave the upstream version number unchanged. ConoHa WING’s final notice (Japanese) explicitly describes that approach. Retain evidence from your provider rather than judging patch status solely by the upstream version number.

After updating, ensure the web runtime uses the changes and that no old workers remain. Include replicas, other hosts, and PHP bundled with administration tools. Test authentication, uploads, forms, and administrative functions as well as page rendering.

How effective are temporary mitigations before updating?

The official sources state that updating is the only complete remedy. The PHP announcement also describes settings that reduce specific attack paths:

  • For CVE-2026-109619, set session.upload_progress.enabled=0 in configuration effective before request parsing, and restart all workers. On PHP 8.5, also set fatal_error_backtraces=0. Other paths remain.

  • For CVE-2026-109618, the announcement describes enforcing memory_limit=-1 at the administrator level. This does not prevent lower-level allocation failures, and removing the limit requires availability safeguards. Design external limits, such as container limits; do not substitute RLIMIT_AS or RLIMIT_DATA.

Application-level ini_set() and FPM’s .user.ini cannot replace the early configuration required for the first mitigation. Copying settings is not enough to consider the work complete: the responsible administrator should read the official prerequisites and set a deadline for updating. If necessary, consider restricting external access or temporarily taking the service offline, following IPA’s guidance (Japanese).

In an October 23 follow-up, PHP also advised keeping session.upload_progress.enabled=0 until the next scheduled release to address a separate issue, CVE-2026-115560. That issue arises under limited conditions, such as switching session.serialize_handler at runtime (PHP’s follow-up). If you have already applied this setting, leave it in place.

How did pixiv respond while waiting for fixed releases?

According to pixiv’s incident write-up (Japanese), it put potentially affected services into maintenance mode from 19:00 on October 21 and resumed service after applying the fixes. Preparing both an official-image update path and a source-build path illustrates the value of checking update routes in advance. The write-up also reports that some endpoints lacked maintenance mode, which the team addressed by reusing an existing implementation.

The architectural question here is whether a shutdown action reaches every public route. An application’s maintenance page may still execute through PHP itself, so displaying that page alone does not establish that access has been blocked.

Lolipop’s official report (Japanese) also describes requests believed to target the vulnerabilities. However, at the time of its notice, the company had not confirmed resulting unauthorized access or data leakage. Distinguish attempted attacks from successful compromise, and assess individual sites through log analysis and other investigation.

Reduce public exposure with static delivery and a separate CMS

The following is a design option for a future architecture review. For articles or company information that change infrequently, consider fetching content at build time, generating HTML, and serving static files on the public site.

Area

Separation approach

Maintenance that remains

Public pages

Serve generated HTML

Delivery infrastructure and browser-side code

CMS administration

Separate it from the public site, with authentication and access controls

Updates to the administration infrastructure and account management

Content API

Fetch only what the build needs

API authentication, key management, and handling fetch failures

Forms and previews

Put necessary dynamic functions on separate routes

Updates to those runtimes, authentication, and input handling

genko.me is one option for fetching content through an API. Its Astro integration supports build-time fetching, but you can also read its REST API from PHP, as shown in the PHP integration guide. There is no official PHP package; use cURL or a similar method. The latter approach retains public-facing PHP, which still needs updates.

Static delivery brings rebuild and publication delays, preview requirements, scheduled publication handling, and redesign work for search or membership features. Compare the effort with the advantages of retaining existing WordPress themes, plugins, and editorial workflows. Static pages can also be affected by an outage of the same hosting infrastructure.

Start your architecture review with our WordPress and headless CMS comparison. For a non-technical contact, use the website owner’s checklist.

FAQ

Is PHP-FPM unaffected by PHP2Shell?

The PHP project includes FPM among the runtimes at risk. Attack paths vary by SAPI and application, but using FPM does not remove the need to update.

Does an old version in php -v mean PHP is vulnerable?

A vendor may have backported the fix, so the version number alone is inconclusive. Check the full package revision and the vendor’s patch notice, then separately verify the PHP runtime used by the web server.

Is pulling a Docker image enough to apply the fix?

Pulling an image does not replace running containers. Rebuild and redeploy the application, then verify that the changes have reached every running instance.

Does moving to a static site or headless CMS make the site safe?

If public pages do not execute PHP, that design reduces public-facing PHP on those routes. Administration tools, APIs, forms, and build infrastructure still require updates and access controls. Changing the CMS alone does not guarantee security.

Sources