PHP2Shell in Docker, FrankenPHP and PaaS

Patching the host does nothing for PHP inside a container. The image carries its own PHP, and a running container keeps the image it started from, even after a fixed one lands on Docker Hub.⁠¹ The fix is a new image, a recreated container and a check of the runtime that actually serves requests. The complete PHP2Shell guide covers both flaws; this page covers containers, FrankenPHP and platforms that build images for you.

How you'd notice

You won't see it from the host. docker ps lists each running container and its image, and many apps bundle PHP without PHP in the name.⁠¹

docker compose exec <service> php -v is a first check, not proof. It reports the command-line binary, which can differ from the process answering web requests, and a vendor package can carry the fix under an older number.⁠³ Verify two more things:

• The package release, if PHP came from packages. On Debian-based images run docker exec <container> dpkg -l | grep php, on Alpine docker exec <container> apk info -v | grep php, then match the result to your distribution's advisory.⁠¹
• The serving runtime. Check the PHP-FPM binary, the PHP module Apache loads, or FrankenPHP itself. Render's advisory says to confirm the PHP handling web requests, and to check PHP-FPM too.⁠³

For FPM, php-fpm -v prints the version of the binary you ran. The name varies: Debian and Ubuntu packages ship it as php-fpm8.3 and similar. It doesn't prove which executable a running worker loaded, because a container can hold more than one PHP binary. To tie the check to the running process, find the master process's executable (for example with readlink /proc/<pid>/exe) and ask that binary for its version.

You want 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a vendor build that documents the fix. A tag ending in RC1 is a release candidate that came before the release, not the fix.⁠¹

For a stopped container or an image you haven't started, docker inspect can show a PHP_VERSION environment variable on some images. Treat it as an inventory clue only. It depends on the image, may be absent, and can be stale. To see what an image really contains, start a throwaway container with the entrypoint overridden, for example docker run --rm --entrypoint php <image> -v, then run the package query inside it. For a server where PHP runs outside containers, how to check your PHP version safely has the steps.

Rebuild, redeploy, verify

Plain Docker and Compose

--pull asks Docker to look for newer versions of the base images in your FROM lines. It doesn't guarantee that every Dockerfile layer is rebuilt: a cached layer, such as an earlier apt or apk install, can be reused. It also can't produce a fixed package your distribution hasn't published. Add --no-cache when a layer installs PHP packages, then confirm the installed release.⁠⁵

A pulled or rebuilt image that nothing restarted still runs the old PHP. Recreate every container, then verify each one as above.

FrankenPHP

Reported FrankenPHP 1.13.2, released 21 October, is a security release: its Docker images are built with PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, and its static binaries with PHP 8.5.12.⁠⁶ It also fixes four vulnerabilities in FrankenPHP itself.⁠⁶ Pull a 1.13.2 or later tag, replace the containers, and verify the PHP inside. Treat an image built before 1.13.2 as unpatched until you've read the PHP version it carries.

Managed platforms

Reported Render's advisory, dated 22 October, says all PHP services on Render use Docker, so you update PHP inside your image, redeploy every affected service and confirm php --version in the service shell.⁠³ It covers three cases: a base image (change the FROM line), distribution packages (install the fixed packages, noting backports may keep the old number) and a prebuilt registry image (obtain an updated image, push it, update the tag or digest).⁠³ That is Render only. We checked no other platform's advisory, so read your platform's own before assuming it patches PHP for you.

Third-party images

An upstream image is only as patched as its maintainer's last rebuild, and an application image built on a PHP base inherits that PHP until its own maintainer rebuilds. Check each tag's push date and verify the PHP inside before you trust it, including the official WordPress, Drupal and Joomla images. Opinion If the Dockerfile is public and sits on a php base, rebuild it yourself on a patched base rather than wait. If you can't, limit who can reach that service and press the maintainer.

What a rebuild doesn't cover

CVE-2026-115560 is a separate flaw. PHP disclosed it on 23 October, the 21 October releases don't fix it, and the full advisory and fix come with the next regular release.⁠² PHP says it needs an unusual combination: an application sets session.serialize_handler to php_binary or php_serialize, switches it to php at runtime with ini_set() before session_start(), and session upload progress is still enabled. Applications that never change the handler at runtime can keep the feature on.⁠² PHP still suggests session.upload_progress.enabled=0 until the next bugfix release, to fully protect against it.⁠²

So not every container carries the same exposure or the same cost. Search your code for runtime handler switches and for anything that reads upload progress, test upload-dependent features in staging, then set it in the image's php.ini or FPM pool config and recreate the container. PHP advises against relying on ini_set() or .user.ini.⁠²

PHP 8.1 and older are the other gap. The project published no releases for them, only source backports for 7.4, 8.0 and 8.1.⁠² PHP 8.2 itself reaches end of life on 31 December 2026.⁠²

Do this

Do today

1. List every image and container that runs PHP, including application images built on a PHP base (WordPress, Drupal, Joomla, Laravel stacks and third-party images).
2. Pull registry images, rebuild local ones with --pull, edit any pinned tag or digest to a patched release, and recreate every container.
3. Verify inside each running container: the package release where PHP came from packages, the serving runtime (PHP-FPM, Apache module or FrankenPHP) and php -v. Teammates running PHP on plain servers need the same fix on a plain Linux server.
4. Check your code for runtime session.serialize_handler switches and upload-progress use, test in staging, then set session.upload_progress.enabled=0 in image configuration where it fits.

Do this week

5. Add a scheduled rebuild or image-scanning step so a base-image fix doesn't depend on someone remembering.
6. Move off PHP 8.1 and older images, and plan 8.2 images onto 8.3 or newer before 31 December.
7. Record each third-party image's tag date and whether its maintainer has rebuilt.

Can wait

8. Tune image size or switch between Debian and Alpine bases.
9. Move to a different runtime.