Docker PHP image: rebuild and redeploy for the PHP2Shell fix

Is the official Docker PHP image fixed for PHP2Shell?

The maintainers of the Docker Official Images merged an update to 8.5.12, 8.4.27, 8.3.36 and 8.2.35. A merged update and a published image for every tag and architecture are separate steps, so check that the exact tag you use has been rebuilt before relying on it. Until we’ve confirmed the published images, the table below lists Docker Official Images as “Not verified”. Third-party images (from app vendors or other publishers) follow their own schedules.

Which Docker PHP image tag should I use?

Use a tag that pins a fixed release in your branch, for example a php:<version>-fpm or php:<version>-apache tag matching the fixed version, rather than a floating tag you haven’t checked. Floating tags such as 8.3-fpm move to new builds over time, but your host only gets them when it pulls and redeploys.

How do I update a Docker PHP container?

1. Change the base image in your Dockerfile’s FROM line (or the image: in your compose file) to a fixed tag.
2. Rebuild your own images that start FROM a PHP image. Their old builds still contain the old PHP.
3. Pull and recreate the containers through your normal deployment, for example docker compose pull followed by docker compose up for the affected services. Keep volumes and data as your deployment expects.
4. Confirm the PHP the running container serves: run php -v inside that specific container (for example with docker exec), keeping in mind that it shows the container’s command-line PHP, and check the app’s own report (such as WordPress Site Health) if it has one. Enter the result in the PHP version checker.

My app’s Docker image hasn’t been updated yet. What can I do?

An application version number doesn’t tell you which PHP it bundles. Check the image publisher’s release notes or issue tracker for a PHP2Shell update, and record the image digest you run. If no update exists, consider building your own image on a fixed PHP base, applying the official stopgaps in the meantime (PHP2Shell workaround page), which reduce exposure but are not a fix, or limiting access to the service.

I pulled the latest tag. Am I done?

Not yet. docker pull downloads an image; the old container keeps running until you recreate it. Check every replica, host and environment (staging, workers, cron containers), because each container keeps the PHP it started with.

What about FrankenPHP and other PHP-based images?

FrankenPHP is one of the setups PHP’s advisory names, and images for apps such as WordPress, Nextcloud or Zabbix embed PHP too. Each publisher rebuilds on its own schedule; we haven’t verified every image and tag. Check the publisher’s release notes or repository for a PHP2Shell update, and confirm the PHP version inside the running container rather than trusting the app’s version number.

Does the host’s PHP version matter for Docker?

No. A container’s PHP comes from its image, not from the host. Updating PHP on the host (see update PHP on Ubuntu) doesn’t patch containers, and vice versa.

What else should I check after redeploying?

Confirm the image digest, the PHP version and how PHP runs inside the serving container, then check the app’s main functions. If containers were exposed while unpatched, review the check if your website is hacked guide. Overview: PHP2Shell checker · PHP2Shell patch.

Which sources support this page?

• Docker Official Images: PHP security update
• Docker: docker compose pull
• Docker: docker compose up
• The PHP Group: security advisory
• PHP manual: php_sapi_name