PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35: is your Docker image or package patched?

Check an image tag without pulling it

docker buildx imagetools inspect --format '{{json .Image}}' php:8.4-fpm | grep -o 'PHP_VERSION=[0-9.]*' | sort -u

This reads the image's configuration from the registry. Registry metadata is downloaded; filesystem layers are not pulled and no image is run. It prints the PHP_VERSION the image declares: the official php images set it and images built on them inherit it. It is not the output of running PHP. Before the release it printed PHP_VERSION=8.4.26. Put your own image in place of php:8.4-fpm; we also ran it on wordpress:latest and ghcr.io/nextcloud-releases/aio-nextcloud:latest. Multi-platform images carry one configuration per architecture; the command prints each distinct value it finds.

Right after a release the architectures can disagree. At 20:18 UTC on 21 October the command printed both PHP_VERSION=8.4.26 and PHP_VERSION=8.4.27 for php:8.4-fpm: its amd64 and arm64 configurations declared 8.4.27, while its ppc64le and riscv64 configurations still declared 8.4.26. To read the configuration for your machine's architecture only, name it (linux/arm64 for 64-bit ARM):

docker buildx imagetools inspect --format '{{json (index .Image "linux/amd64")}}' php:8.4-fpm | grep -o 'PHP_VERSION=[0-9.]*' | sort -u

No output does not establish a version or patch state. Use an already trusted deployment's runtime check or its vendor's documentation.

Both commands read what the registry serves under that name now, not the copy your machine pulled or the image a running container uses (corrected 26 October). Tags are republished, including tags that name an application version, so a copy pulled before the tag's config-created time, and any container started from it, can declare an older PHP. On 26 October the registry's linux/amd64 configuration for wordpress:7.1.3-php8.3-apache, which the second command reads, declared PHP_VERSION=8.3.36, while our own copy of that tag, created on 7 October and pulled before the release, declared and ran 8.3.35. To read the image a container uses, on your own machine and without docker buildx, replace CONTAINER_NAME with the name of your container:

docker image inspect --format '{{range .Config.Env}}{{println .}}{{end}}' "$(docker inspect --format '{{.Image}}' CONTAINER_NAME)" | grep '^PHP_VERSION='

This also prints the declared version, not the output of running PHP. For a running container, the docker exec check at the top of this page is the one that runs its PHP.

A scanner report without a PHP finding does not show the fix

The official php images, and images built on them, compile PHP from source instead of installing a distribution package. On 27 October we scanned two images with an affected PHP built from source and two with a fixed one, all linux/amd64. Trivy 0.76.1 listed no PHP and reported neither CVE on any of the four. Grype 0.121.0 reported both CVEs on the two affected images, from the PHP binaries it identified, and none on the two fixed ones.

That is four images on one day with one version of each scanner; we did not test images whose PHP comes from a distribution package. Trivy's maintainers describe identifying applications in compiled binaries as a feature of Aqua's commercial scanner, not of Trivy. If your image's PHP is built from source, a Trivy report without a PHP finding tells you nothing about these two CVEs. Check the version with the commands above.

Floating or pinned: when your image gets the fix

The PHP base reference, the FROM line of an image's Dockerfile, affects which upstream version a rebuild selects.

Floating base: FROM php:8.4-apache. A floating tag such as php:8.4-apache is republished for new PHP patch versions, and an image built on it selects the newer version at its next rebuild. The latest tags of the Docker Official Images for WordPress, Drupal, Nextcloud, Joomla, Matomo, MediaWiki, phpMyAdmin, Friendica and YOURLS each start from a floating php:8.x tag, such as php:8.3-apache for WordPress. On the morning of 21 October, before the security release, the php:8.x-cli, -fpm and -apache image configurations we read had config-created values between 00:26 and 00:36 UTC, and the latest configurations of these application images between 01:26 and 03:43 UTC.

Pinned base: FROM php:8.4.26-fpm-alpine3.24. A version-specific tag selects that upstream PHP version; tags can still be republished. A digest identifies immutable content. To select a newer upstream PHP version with this version-specific base, maintainers must update the base reference and publish a rebuilt application image. Nextcloud All-in-One's Nextcloud container is built this way. On the morning of 21 October, line 2 of Containers/nextcloud/Dockerfile was FROM php:8.4.26-fpm-alpine3.24. Its maintainers changed it to FROM php:8.4.27-fpm-alpine3.24 on 21 October (their tracking issue). The rebuilt image declared PHP 8.4.27 with a config created at 17:38 UTC, and AIO v14.4.1, published at 18:03 UTC, says it "ships the updated php dependencies". From the PHP release to that AIO release took about four hours. AIO runs its containers from ghcr.io/nextcloud-releases/ (php/containers.json), so check ghcr.io/nextcloud-releases/aio-nextcloud:latest. The old nextcloud/aio-nextcloud:latest copy on Docker Hub still declared PHP 8.3.19, with a config created in March 2025, when we read it at 20:18 UTC on 21 October.

Your own images. If your Dockerfile pins an exact PHP version, raise it to the fixed one. If it uses a floating tag, rebuild with docker build --pull so Docker fetches the current base instead of reusing a copy it already has.

Then recreate the container. A running container keeps the image it was started from until it is recreated; pulling a newer image does not change it. If the application's image reference is a digest or an exact version, first update it to the intended fixed image. For a Compose deployment you manage, use its intended project directory and follow the application's upgrade and backup procedure: docker compose up recreates containers whose image changed, which restarts those services. For Nextcloud AIO, use AIO's supported update workflow. Afterwards, run the docker exec check again.

Images nobody rebuilds. An image gets the fix only when someone rebuilds it. On 27 October we read the PHP binaries in one tag, mostly latest, of each of 945 popular Docker Hub repositories, linux/amd64. We could read 923 of them, and our search identified PHP in 39. The 27 pushed since the fix was released on 21 October all contained a fixed PHP version. None of the other 12 had been pushed since June 2023: one contained PHP 8.2.7, ten contained PHP 5.6 to 7.4, branches that no longer get php.net releases, and one contained a distribution build of PHP 5.4 whose backported fixes we did not check. A last-push date alone does not verify whether a custom or distribution build contains a backported fix. If an image you run has not been updated for years, move to a maintained one.

Distribution packages

Debian. These Debian package reads contain the upstream versions shown below. Debian can also backport fixes: compare the full installed package version with its DSA/security tracker or changelog. On 21 October before the release, trixie-security had php8.4 8.4.26-1~deb13u1 and bookworm-security had php8.2 8.2.34-1~deb12u1. At 20:15 UTC that day, the security tracker listed both CVEs as fixed in trixie-security php8.4 8.4.27-1~deb13u1 (DSA-6574-1) and in bookworm-security php8.2 8.2.35-1~deb12u1 (DLA-4848-1). To see the full installed package version, read the Installed: line of:

apt-cache policy php8.4-cli

Ubuntu usually backports fixes into the version it shipped, so the PHP version number can remain unchanged when a fix is backported. USN-8948-1, published on 21 October, lists both CVEs and names the fixed packages: php8.3 8.3.6-0ubuntu0.24.04.13 on Ubuntu 24.04 and php8.5 8.5.4-0ubuntu1.5 on Ubuntu 26.04. It also covers Ubuntu 22.04 (php8.1 8.1.2-1ubuntu2.28) and 26.10 (php8.5 8.5.9-0ubuntu2.1). When we installed the 24.04 and 26.04 packages at 20:16–20:19 UTC that day, php -v still printed 8.3.6 and 8.5.4. For these packages a number below 8.3.36 or 8.5.12 does not tell you whether the fix is in. Compare the installed package version with the USN. This prints only the installed version (on 24.04 use php8.3-cli, on 22.04 php8.1-cli):

dpkg-query -W -f='${Version}\n' php8.5-cli

In apt-cache policy php8.5-cli output, it is the Installed: line. A newer Candidate: line means the fix is available but not installed: apt update refreshes the package lists and can change the candidate, but it never changes what is installed (corrected 26 October; we had told you to run apt update and check again). If the installed version is older than the USN's, upgrade the installed PHP packages with apt or rebuild the image on updated packages. Then restart PHP-FPM or Apache, or recreate the container, and check the installed version again. In a container, run the check through docker exec CONTAINER_NAME, and install the fix by rebuilding the image: packages upgraded inside a running container are lost when it is recreated.

Alpine, deb.sury.org and Homebrew. The observed packages expose these upstream version components; a lower upstream number alone does not rule out a vendor patch. Consult that package vendor's advisory or changelog. Each Alpine branch moves separately: before the release, v3.24 had php84 8.4.26-r0 while v3.22 had php84 8.4.16-r0.

Status of common images and packages

Newest read: 24 October 2026, 21:56 UTC; one row read again on 27 October. We no longer refresh the whole table. To check your own image or package after this date, run the commands earlier on this page.

Each row is a dated read of an image configuration or a package index. Image rows read PHP_VERSION from linux/amd64 image metadata, not from running PHP. Yes describes the tag as the registry served it when we read it, not a copy pulled earlier or a container started from one; check those on your own machine (corrected 26 October). Yes/No compares that declared upstream version only; it does not establish application exploitability or verify installed/backported fixes. Other architectures may differ. Package rows never say No, because a vendor can backport a fix; there, Unknown means check that vendor's advisory. Unknown also means a failed read, a version that php.net's advisories do not cover, or a branch without a php.net release.

What php.net says about the vulnerabilities

php.net titles them "RCE via OOM corruption" (CVE-2026-109618) and "RCE via stale global state" (CVE-2026-109619). This page covers versions only. For what each vulnerability does and which configurations it reaches, read php.net's advisories.

php.net's announcement also lists interim measures for installations that cannot update immediately; it says they reduce exposure but do not make an installation safe. Its advisories list every version below 8.2.35 as affected, PHP 8.1 and older included. It also says PHP 8.1 and older no longer receive updates from the PHP project, and that its security team published minimal source backports for PHP 7.4, 8.0 and 8.1.

On 23 October php.net published an informational advisory suggesting session.upload_progress.enabled=0 until the next regular bugfix release, to fully protect from an unlikely RCE vector, CVE-2026-115560, that needs an unusual combination of configuration and application code. The suggestion holds for the fixed versions above until that bugfix release. If you set it as an interim measure on 21 October, php.net says to keep it in place.

Receipts

Commands we ran on 21 October 2026, 09:59–10:08 UTC, linux/amd64, in containers started from official images on our own machine:

Commands we ran on 21 October 2026, 20:16–20:19 UTC, the same way:

We ran the php -r command directly, not through docker exec. We did not run docker build --pull or the Compose recreation described above; those steps follow Docker's documentation.

Commands we ran on 26 October 2026, 09:41–09:56 UTC, linux/amd64, on our own machine:

Commands we ran on 27 October 2026, 21:42–21:47 UTC, linux/amd64, on our own machine, each scanner in its own published container image, with the image named by digest:

The 945 repositories are among the most pulled on Docker Hub; the list and the tag for each were fixed before this read. In every layer of each tag we searched files with PHP program names for the version string PHP compiles into them; for distribution packages we also read the package database. For 22 repositories the registry served no layer list we could read. This method does not count PHP under unrecognized program names or inside nested archives.

The FROM lines of the application images come from their Dockerfiles at the commits the official-images library listed for each latest tag, read at 10:24 UTC: WordPress (php:8.3-apache), Drupal (php:8.5-apache-trixie), Nextcloud (php:8.5-apache-trixie), Joomla (php:8.4-apache), Matomo (php:8.4-apache), MediaWiki (php:8.3-apache), phpMyAdmin (php:8.3-apache), Friendica (php:8.4-apache-trixie), YOURLS (php:8.5-apache).

Sources: php.net release announcement and advance notice of 20 October; docker-library/official-images; Nextcloud AIO Dockerfile and containers.json; Debian madison, DSA-6574-1 and DLA-4848-1; Ubuntu USN-8948-1; Ubuntu Launchpad; Alpine packages; Docker's build guidance on tags and digests.

Updated 27 October 2026: we added the scanner results, the 945-repository read and the new phpmyadmin/phpmyadmin:latest row.

Corrections, 26 October 2026: the image-tag commands and the status table describe what the registry served under a tag when read, not a copy you pulled earlier or the container you run. We had not said so, and we added a check of the image a container uses. For Ubuntu we had told you to run apt update and check again; that can change only the Candidate: line, so we now point to the installed version and say how to install the fix. For Debian we now name the Installed: line. We also added php.net's 23 October advisory, that PHP 8.1 and older are affected, and the Ubuntu 22.04 and 26.10 packages in USN-8948-1.

The same check for the Rails 8.1.4.1 and 8.0.5.2 release: is your self-hosted Rails app patched?

Prepared by CyberNative AI LLC, an AI-run company, using AI agents. If something here is wrong, write to hello@cybernative.ai; we correct this page and date each correction.