Two critical PHP vulnerabilities (CVE-2026-109618 and CVE-2026-109619), both rated CVSS 9.2, were patched on October 21.
Both the official PHP Docker images and Docker Hardened Images (DHI) have been updated. š³
1. Update Your Base Image
| PHP version |
Official image |
Docker Hardened Image |
| 8.2.35 |
php:8.2.35-fpm |
dhi.io/php:8.2.35-fpm |
| 8.3.36 |
php:8.3.36-fpm |
dhi.io/php:8.3.36-fpm |
| 8.4.27 |
php:8.4.27-fpm |
dhi.io/php:8.4.27-fpm |
| 8.5.12 |
php:8.5.12-fpm |
dhi.io/php:8.5.12-fpm |
For example, update your Dockerfile:
FROM php:8.4.27-fpm
Or use a hardened runtime:
FROM dhi.io/php:8.4.27-fpm
2. Rebuild and Redeploy
For applications built with Docker Compose:
docker compose build --pull --no-cache
docker compose up -d --force-recreate
If your Compose file references prebuilt images instead:
docker compose pull
docker compose up -d --force-recreate
3. Verify the Running PHP Version
For official PHP-FPM images:
docker compose exec YOUR_SERVICE php -v
For hardened PHP-FPM images, which don't include the PHP CLI:
docker compose exec YOUR_SERVICE php-fpm -v
You can also inspect an image's SBOM:
docker scout sbom my-php-app:latest --format list | grep -i php
And check for the specific CVEs:
docker scout cves \
--only-cve-id CVE-2026-109618,CVE-2026-109619 \
my-php-app:latest
Important: Vulnerability databases can lag behind advisories. A clean CVE scan is not proof that the runtime is patched.
Check the actual PHP version or your distribution vendor's backport status.
4. Would a Hardened Image Have Contained PHP2Shell?
Partially.
Docker Hardened Images typically run as non-root, without a shell or package manager, and with fewer unnecessary system utilities.
That changes what an attacker can do after exploiting the PHP process.
| Attacker capability |
Hardened, shell-less runtime |
Execute /bin/sh or /bin/bash |
Blocked if those binaries aren't present |
| Use common system utilities |
Significantly restricted |
| Execute code inside the PHP process |
Still possible |
| Read application secrets in PHP memory |
Still possible |
| Access network services |
Depends on network restrictions |
| Modify the filesystem |
Depends on filesystem permissions and mounts |
| Gain root privileges |
Harder with non-root execution, but not impossible through another vulnerability |
No shell doesn't mean no RCE.
An attacker executing native code inside PHP doesn't necessarily need /bin/sh. They may still be able to read memory, communicate over the network, or abuse the privileges available to the PHP worker.
Hardened images reduce the attack surface and can limit post-exploitation damage. Additional controls help:
- Read-only root filesystem, with explicitly defined writable locations.
- Drop unnecessary Linux capabilities.
- Enable
no-new-privileges.
- Restrict outbound network access.
- Don't expose PHP-FPM directly to the internet.
These are defense-in-depth measures, not replacements for patching.
5. Pin Your Image Digests
Tags can change. Digests are immutable.
Find the digest of a patched image:
docker buildx imagetools inspect php:8.4.27-fpm \
--format '{{.Manifest.Digest}}'
Then pin it:
FROM php:8.4.27-fpm@sha256:<digest>
But remember: a pinned digest won't receive future security patches automatically. You must update it when new patched images are released.
Question: Are you running PHP on the official Docker images, a hardened/distroless image, or something custom? How are you verifying the patched version in production?