php2shell (CVE-2026-109618 / 109619) can't be assessed with php -v: where version numbers diverge across FPM, Docker and distros

If the PHP that handles web requests (PHP-FPM, Apache's mod_php, php-cgi, FrankenPHP, LiteSpeed) is older than 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, it is affected by CVE-2026-109618 and CVE-2026-109619, known as php2shell. The fix is to upgrade to one of these versions (or, for distro packages, to the fixed package) and restart the processes. What you need to check is not your local php -v, but “the PHP actually serving the web” and “the installed package version.”

This article focuses on four places where judging by the version number alone leads to the wrong conclusion. All figures and status information are as of 2026-10-22, and sources for each item are listed at the end.

What is known as of 2026-10-22

The PHP advisory states that “the only complete fix is to update.” Mitigations for the period before you can update are covered later in this article.

Pitfall 1: php -v and the web-facing PHP may be different

php -v typed over SSH reports the version of the CLI PHP. Web requests are handled by PHP-FPM processes or by mod_php loaded into Apache, which are separate binaries and separate packages. If you installed a newer PHP only for the CLI, run several versions side by side, or have an FPM pool pointing to a different version, the web side can remain old even when php -v shows a fixed version.

There are several ways to see the real version on the web side.

# FPM on Debian / Ubuntu (named per version)
php-fpm8.3 -v

# FPM on RHEL-family systems
php-fpm -v

# Check whether mod_php is loaded in Apache
apachectl -M | grep -i php

The most reliable method is to have the PHP that actually runs via the web report its own version. Place a temporary file with a hard-to-guess name, and delete it as soon as you have checked.

<?php echo PHP_VERSION, ' ', PHP_SAPI;

If PHP_SAPI is fpm-fcgi, PHP is running under FPM; apache2handler means mod_php; cgi-fcgi means CGI. Avoid leaving phpinfo() exposed, as that in itself leaks information.

Restarting is another step that is easy to miss. Even after the package is replaced, php-fpm or Apache processes that are already running may keep running the old code. Some setups restart automatically on package updates; others do not. After updating, restart FPM / Apache and check the web-side version again using the methods above.

Pitfall 2: With Docker, you can't judge by the tag name

The official php image has “moving tags” such as 8.3 and 8.3-fpm, whose contents get replaced, and pinned tags such as 8.3.30, which fix the version.

• Even after a moving tag is switched to a fixed version on Docker Hub, your local copy remains the old image until you pull again. Running containers also keep using the old image until they are recreated. A Dockerfile with FROM php:8.3-fpm will still build on the old base if it remains in the build cache.
• A pinned tag stays old forever until you bump the number yourself.

You can check whether fixed-version tags have been published using the Docker Hub API.

curl -s "https://hub.docker.com/v2/repositories/library/php/tags?name=8.3.36&page_size=100"

Here are the results of querying four release lines on 2026-10-22 (times in UTC).

Checking this turned up three points where judging by numbers can mislead you.

1. “Recently updated” does not mean “fixed.” The pinned tag 8.3.35 was rebuilt during 2026-10-21, but the PHP_VERSION inside was still 8.3.35. Look at the version inside, not the update timestamp.
2. Different digests can have the same contents. 8.3 and 8.3.36 had different tag digests (the value of the multi-architecture index), but the amd64 image was identical and both had PHP_VERSION=8.3.36. Likewise, for 8.3-fpm / 8.3.36-fpm, 8.4-apache / 8.4.27-apache, latest / 8.5.12, 8.5-fpm and 8.2-fpm, the PHP_VERSION of the amd64 image was a fixed version.
3. There are no fixed official images for 8.1 and earlier. 8.1-fpm was last updated on 2025-12-31.

To check your local images and running containers:

# PHP version of a locally pulled image
docker image inspect php:8.3-fpm --format '{{range .Config.Env}}{{println .}}{{end}}' | grep PHP_VERSION

# Pull again and recreate the containers
docker compose pull
docker compose up -d

# If you build your own image, re-pull the base and then build
docker compose build --pull

# Version inside a running container
docker compose exec app php -r 'echo PHP_VERSION, PHP_EOL;'

Replace app in the last command with your own service name. Each official image is built with a single PHP_VERSION, so the CLI version inside a container matches that container's FPM / Apache version (Pitfall 1 applies when PHP is installed directly on the host).

FrankenPHP embeds PHP, so the FrankenPHP version and the embedded PHP version are different numbers. The release notes for FrankenPHP 1.13.2, released on 2026-10-21, state that the Docker images were built with PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 and the static binaries with PHP 8.5.12.

Pitfall 3: Distro packages are “fixed with old numbers”

Ubuntu and RHEL port only the fixes to older versions (backporting). The number shown by php -v stays old, so a numeric check such as “lower than 8.3.36, therefore vulnerable” will flag a fixed system as vulnerable. Conversely, you cannot rely on the number for reassurance either. Make the call based on the package version and each distro's security tracker.

Fixed packages listed in each tracker as of 2026-10-22 (the same for both CVEs):

This table shows directly why numbers alone are not enough. Ubuntu 24.04's fixed PHP is a version starting with 8.3.6, far lower than upstream's 8.3.36. RHEL 9's default PHP is fixed while remaining at 8.0.30, even though upstream no longer issues fixes for 8.0. Debian has moved to the same numbers as upstream (8.2.35 / 8.4.27).

Some packages are not fixed yet (as of 2026-10-22).

• The RHEL 9 php module 8.4 is listed as “affected, no fix.”
• Debian forky (testing) has php8.4 8.4.26-1, marked “vulnerable.” The php8.4 in sid (unstable) is 8.4.27-1 and fixed.

Example commands to check your own server:

# Debian / Ubuntu: installed version and available version
apt-cache policy php8.3-fpm libapache2-mod-php8.3

# Ubuntu: whether this CVE is fixed on this server
pro fix CVE-2026-109618
pro fix CVE-2026-109619

# RHEL family: whether an update fixing this CVE exists, and the installed version
dnf updateinfo list --cve CVE-2026-109618
rpm -q php-fpm php-cli

Adjust the package name (php8.3-fpm, etc.) to your environment. Compare the version shown with the “fixed version” in the table above or in the tracker; if it is the same or higher, the fix is in. Then complete the restart and web-side check described in Pitfall 1.

If you install PHP from a third-party repository rather than the distro's own packages, you need to follow that repository's updates. The PHP advisory notes that the volunteer-run rpms.remirepo.net would not have updates on the day of disclosure, and recommends switching to distro packages or your own builds.

Pitfall 4: On shared hosting and managed environments, you can't upgrade PHP yourself

On shared hosting and managed PHP environments, the provider replaces the PHP runtime. Here too, the number alone is not enough: if the provider builds PHP itself or backports fixes, the version number may stay old.

There are three things you can do yourself.

1. Check the web-side version. Use the temporary file from Pitfall 1 to print PHP_VERSION and PHP_SAPI, then delete it right away. If the control panel has a PHP version selector, also note which version you have selected.
2. Read the provider's notice, and ask if there is none. Ask: “For which PHP versions on my plan will the fixes for CVE-2026-109618 and CVE-2026-109619 be applied, and when (or have they been applied)?” Asking by CVE number rather than version number gets you an answer that covers backports as well.
3. If you have selected an unsupported version, upgrade. The PHP project issues no fixes for 8.1 and earlier, and support for 8.2 ends on 2026-12-31. Unless the provider has backported the fixes, switching versions is the reliable path.

Status by hosting provider (as of 2026-10-22)

On shared hosting, the provider normally updates the PHP runtime, and many providers' notices say that “no action is required from users.” Users have two things to do: check the official notice from their provider, and, if they have selected an old PHP version in the control panel, decide whether to switch to the version the notice recommends (one with a fixed release).

The table below summarizes only what is written on each provider's official pages (announcements and maintenance information), paraphrasing the wording of their notices. Notices are updated as things progress, so always confirm the actual status on the official page cited.

Where I could not find or open an official notice, the table says “could not confirm” or “could not find.” The absence of information there does not mean the provider has not responded. Check directly with your provider's announcements and support.

Mitigations while you cannot update right away

The PHP advisory lists settings that reduce the attack surface until you can update. However, the advisory itself explicitly states that they “do not make you safe.” The main ones are:

• For CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini, the FPM pool, or the server configuration, and restart all workers (ini_set() and FPM's .user.ini do not work for this). On PHP 8.5, also set fatal_error_backtraces=0.
• For CVE-2026-109618: set memory_limit=-1 in a way the application cannot override, and reduce post_max_size (8M if there are no uploads, 32M if there are). Do not use RLIMIT_AS / RLIMIT_DATA as a substitute.

The UK NCSC recommends considering taking offline any system that cannot be updated or mitigated right away, and checking for signs of compromise before updating or applying mitigations.

Sources (checked on 2026-10-22)

• php.net: Security advisory: Critical remote code execution vulnerabilities, update now (2026-10-21)
• php.net: Upcoming Critical PHP Security Release (2026-10-20)
• php.net: Release announcements for PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
• GitHub: GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GitHub: GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• Docker Hub: official php image
• FrankenPHP 1.13.2 release notes
• Debian Security Tracker: CVE-2026-109618 / CVE-2026-109619
• Ubuntu: CVE-2026-109618 / CVE-2026-109619 / USN-8948-1 / USN-8948-2
• Red Hat: CVE-2026-109618 / CVE-2026-109619 (fixed package versions from Red Hat's VEX data)
• NCSC: Critical security issue affecting PHP