Improving future security releases and reducing dependencies on upstream builds (Post-mortem: PHP2Shell security release)

[jaydrogers]

Background

On October 21, php.net released fixes for two critical remote code execution bugs (CVE-2026-109618 and CVE-2026-109619). Our patched images went live about 4 hours and 20 minutes after php.net published the source. Our own build took 27 minutes. The rest was waiting on upstream systems.

I don't think this is the last critical PHP vulnerability. Below is what happened and my plan to cut out the wait. Please share your thoughts in the comments.

The full play-by-play is in #721.

Timeline

All times are UTC.

Time	What happened
~13:40	php.net publishes 8.5.12, 8.4.27, 8.3.36, and 8.2.35, with source tarballs
14:20	docker-library/php#1694 merges
15:17	official-images#22541 merges
15:38	First tags show up on Docker Hub, but they're empty. Docker creates the tag first and uploads images later.
~17:15	Every base image we need is on Docker Hub for amd64 and arm64
17:16	pecl.php.net goes down
17:32	v5.0.2 build starts. It fails to download pecl/redis, so I keep hitting retry.
17:59	v5.0.2 is live
21:16	v4.5.3 is live (release tags only)

Where the time went

• ~3.5 hours waiting on the official PHP images. Their pipeline has a PR, CI, a second PR with human review, then Jenkins builds each tag and architecture. We can't start until all of that finishes.
• ~40 minutes fighting PECL. Our default redis extension downloads from pecl.php.net. Everyone was rebuilding at once, and PECL couldn't keep up.
• ~3 more hours for v4. Our workflow publishes floating tags like 8.4-fpm-nginx, so a v4 build would have moved them back to v4. I had to build a release-tags-only workflow during the incident. v4.5.2 also got burned: its release was published before the build failed, and published release tags can't be reused.

The plan

Build straight from php.net and GitHub. Then we can start the moment a release is published. This will ship as v6, because it changes how PHP and extensions get into our images.

1. Compile PHP ourselves

@tomschlick started this in #725 and already opened a first version in #726.

We build our own base image, ghcr.io/serversideup/php-base. It holds compiled PHP plus the docker-php-ext-* helper scripts, which is what the official php: image gives us today.

Inside our Dockerfiles, FROM php:8.4.27-fpm-trixie becomes FROM ghcr.io/serversideup/php-base:8.4.27-fpm-trixie. Everything after that line stays the same. You keep pulling serversideup/php like you do now and never touch php-base directly.

• Copy docker-library's template and helper scripts into our repo once. They're MIT licensed. We keep their license and credit the upstream commit we copied from. Their layout stays the same, so switching from FROM php: stays easy.
• Make the version a build argument. Their Dockerfiles hard-code PHP_VERSION, PHP_URL, PHP_SHA256, and GPG_KEYS, which is why each release waits on their PR. We pass those in from php.net instead.
• Pull in their changes with a normal PR when the template changes, like for a new PHP minor or a new Alpine version. Those are rarely urgent.
• Verify every tarball against the SHA256 from php.net and the release manager's GPG signature. We keep the release managers' public keys in our repo, so a slow keyserver can't hold up a build.
• Only rebuild when something changes: a new PHP tarball or a new Debian/Alpine base image.

2. Install extensions without PECL

Of our default extensions (opcache pcntl pdo_mysql pdo_pgsql redis zip), only redis doesn't ship with PHP. We build it from a pinned phpredis release on GitHub instead of PECL.

Your own extensions need a plan too. Our docs recommend install-php-extensions, and most of you use it because it finds the system packages and cleans up after itself. It keeps working on PHP 8.5 and older. It doesn't support 8.6, and there's no date for when it will.

The best outcome is install-php-extensions supporting 8.6, so first we'll see if mlocati adds support for PIE on 8.6 and newer. Our fallback is to document one command that we own: docker-php-serversideup-install-php-extensions. It's already in our images. You pass extension names the same way:

• PHP 8.5 and older: it runs install-php-extensions, same as today
• PHP 8.6 and newer: it uses docker-php-ext-install for built-in extensions and PIE for the rest, then removes the build tools

PIE uses Packagist names, so redis is phpredis/phpredis and mongodb is mongodb/mongodb-extension. The command looks up the PIE package from its extension name, so you keep typing redis.

When install-php-extensions supports 8.6, we switch back behind the same command. Your Dockerfile doesn't change.

PIE can install system libraries on its own, but only for some extensions. Its docs don't mention Alpine either. Before we commit, we test every extension in our docs on Debian and Alpine. When a library is missing, we contribute it to PIE instead of keeping our own list.

Built-in extensions like gd and intl need system libraries too. docker-php-ext-install won't install them. We keep that short list ourselves.

3. Start the build automatically

Our get-php-versions.sh already reads php.net/releases/active.php. A scheduled workflow checks it every 15 minutes and starts a build when a new version shows up. I still approve the publish.

4. Test PHP before we ship it

docker-library's Dockerfile ends with php --version. Their CI runs four small PHP tests. Our test-image.sh already checks more than that. We add:

• Their four tests (php-hello-world, php-ext-install, php-argon2, php-fpm-hello-web), with credit
• A parity check against the official image. Compare php -m, the configure flags, and the ini files. Add serversideup/php-base: PHP compiled from source, a drop-in for the official images #726 already includes this as test-base-image.sh. In an emergency, we compare against the last patch they shipped.
• PHP's own test suite, weekly. It's too slow to hold up a security release.

5. Let CI publish the GitHub release

Today I publish a release in GitHub, which creates the tag and starts the build. If the build fails, the tag is already locked.

The new order:

1. I write the release notes as a draft release. Drafts don't create the tag or lock anything.
2. I run a "Release" workflow with the version number. It tags the commit, then builds, tests, and publishes the images.
3. Once every image is live, CI publishes the draft.

If the build fails, nothing was published. We delete the tag, fix the problem, and run it again with the same version.

6. Make backports safe by default

Floating tags (8.4-fpm-nginx, latest) only go out when the version we're building is the highest stable version tag in the repo. Anything older, like a v5 backport after v6 ships, only gets its release tags (8.4-fpm-nginx-v5.0.3). CI publishes its release with --latest=false.

The check uses git tags, not GitHub's "Latest" label, because the release doesn't exist yet while we build. The weekly rebuild uses the same check. Backports then run through the same Release workflow from their branch, with no special workflow.

What it costs

The v5.0.2 build used about 290 job-minutes on Depot. php-base adds 57 images to compile. That only happens when PHP or the OS changes. Every other build reuses them. We'll measure the real compile time with #726 and share it with Depot before we switch.

Rollout

1. Build php-base and compare it to the official image (in progress in Add serversideup/php-base: PHP compiled from source, a drop-in for the official images #726)
2. Build the full php-base matrix in CI
3. Add the remaining tests
4. Switch our images to php-base on v6 beta tags
5. Add the scheduled check
6. Add the Release workflow and the floating tag check
7. Release v6 with the new workflow

Open questions

1. If you build FROM serversideup/php, what do you rely on from the official image that we must keep?
2. Which extensions do you install on top of our images? We'll test the new command against your list.

Thanks again to everyone who helped in #721. And thank you to the PHP security team, who are mostly volunteers.

[twiesing]

Thanks for the write-up. We run 32 WordPress sites on ghcr.io/serversideup/php:8.5-fpm-apache (v5, arm64, rebuilt with Buildah and rolled out with podman auto-update). Our own build on top takes about 3 minutes, so your wait was ours too. Answers to the open questions:

1. What we rely on from the official image

• The config layout: we add zz-*.ini to /usr/local/etc/php/conf.d/, a pool override to /usr/local/etc/php-fpm.d/, and mount a per-site zzzz-site.ini into conf.d at runtime. We rely on the scan dir and on load order by file name.
• docker-php-ext-* and docker-php-source, which install-php-extensions uses.
• Debian trixie with apt: we install ghostscript, jpegtran/optipng/pngquant/gifsicle/cwebp, msmtp-mta and less.
• php on the PATH: the wp-cli phar starts with #!/usr/bin/env php.

2. Extensions on top

install-php-extensions gd exif intl bcmath gmp imagick. imagick comes from PECL today, so it has the same problem as redis.

[Jamesking56]

The PHP team has released backported source fixes for versions older than PHP 8.2 but I can see you have only published new docker images for 8.2+

Do you have any plans to patch older than PHP 8.2?

[Wiejeben]

Definitely agreed on getting PHP installed directly into the image instead of using the official PHP Docker image. It removes the liability and as long as the source is validated the outcome is basically the same, definitely a unique selling point if that would make your releases literally hours faster.

[kohenkatz]

Like everyone else said, thank you for everything you have done here!

1.If you build FROM serversideup/php, what do you rely on from the official image that we must keep?
2. Which extensions do you install on top of our images? We'll test the new command against your list.

We are just starting to use the FrankenPHP image with Laravel Octane (instead of our own previous custom builds of FrankenPHP images).

We use a handful of the ENV-based configuration options, and add the following extensions on top of the default included list:

• gd for image processing
• gmp recommended for performance by phpseclib, ramsey/uuid, and others
• intl for non-English text processing

Here is our complete Dockerfile:

ARG SERVERSIDEUP_VERSION=v5.0.2
ARG PHP_VERSION=8.5.12
ARG DEBIAN_VERSION=trixie

FROM serversideup/php:${PHP_VERSION}-frankenphp-${DEBIAN_VERSION}-${SERVERSIDEUP_VERSION}

USER root

RUN install-php-extensions gd gmp intl

USER www-data

# Default to auto-sizing, but let us adjust
ENV CADDY_SERVER_WORKER_COUNT=''

ENV PHP_MEMORY_LIMIT="512M"

ENV PHP_OPCACHE_ENABLE=1
# We need the setting below because we run `artisan optimize` after the new images are pulled
ENV PHP_OPCACHE_VALIDATE_TIMESTAMPS=1

# Traefik handles our SSL, so no need to add another layer here
ENV SSL_MODE="off"

# As of 2026-09 this is the default, but it doesn't hurt to be explicit
ENV TRUSTED_PROXY=cloudflare

COPY --chown=${USER}:${USER} . /var/www/html/.

We use it with a Docker Compose setup that looks something like this:

x-base-options: &base_options
  restart: unless-stopped

x-myproject-defaults: &myproject_defaults
  << : *base_options
  image: registry.example.com/mygroup/myproject/myproject:latest
  env_file: ./apps/myproject.env

services:
  myproject:
    << : *myproject_defaults
    hostname: myproject
    command: ["php", "artisan", "octane:start", "--server=frankenphp", "--port=8000", "--caddyfile=/etc/frankenphp/Caddyfile"]
    labels:
      - traefik.enable=true
      - traefik.http.routers.central.entrypoints=https
      - traefik.http.routers.central.rule=Host(`myproject.example.com`)
      - traefik.http.routers.central.tls=true
      - traefik.http.routers.central.tls.certresolver=letsencrypt
      - traefik.http.services.central.loadbalancer.server.port=8000

  myproject-cron:
    << : *myproject_defaults
    command: ["php", "artisan", "schedule:work"]

  # General queues ...
  myproject-queues-notifications:
    << : *myproject_defaults
    command: ["php", "artisan", "horizon"]

  # ... and/or specific queues
  myproject-queues-sync-in:
    << : *myproject_defaults
    command: ["php", "artisan", "horizon"]
    environment:
      APP_ENV: dedicated-sync-in

[hktang]

We add gd zip imagick.

Yesterday when we deploy a mitigation by adding custom php.ini, we were also blocked by pecl's unavailability. We switched to adding a pinned version number @3.8.1 then the installer pulls it from Github. Should have shared this with you earlier!

[Andrewpk]

I use the frankenphp build with pdo_mysql, redis, pcntl, and zip.
I add intl ourselves using the bundled install-php-extensions tool.
I also rely on your included composer, as well as some of your sane php.ini defaults and ENV vars like PHP_OPCACHE_*, AUTORUN_ENABLED, AUTORUN_LARAVEL_MIGRATION, and other small items.

I had my own build running but it used to take ages basically just to add this and some image manipulation libraries so I stopped using my homegrown containers based off Debian and started building my containers based off of your images. This also kind of forced me to re-think my entire CI/CD process and everything is much smoother now thanks to the nudge by wanting to use your php images.

[mbrodala]

First of all thank you very much for all the work you put into these images! ❤️

One small request I'd like to make is to separate PHP updates from image updates.

For example we were on 8.2.34-fpm-apache-v5.0.1 and I would have expected a 8.2.35-fpm-apache-v5.0.1. But instead there is only 8.2.35-fpm-apache-v5.0.2 right now. So to get the PHP update we also need to pull the image update.

I'm sure you put a lot of care into not introducing breaking changes or similar but still the risk of affecting downstream projects would be lower if only the PHP version changed without any functional changes in the images.

Of course, this would considerably blow up the range of tags as 8.2.35-fpm-apache-v5.0.1 and 8.2.35-fpm-apache-v5.0.2 would need to be published in case a PHP update and a image update should happen at the same time.

[lnikoI]

This timeline reminds of Chernobyl ^^'

[joriswvanrijn]

Thanks for taking the time and effort in improving build times. Already not looking forward to the next time this will inevitably happen..

Similar use case here, using the fpm-nginx images as our Wordpress bases:

• Few extensions mysqli intl gd exif imagick
• An addtional entrypoint 99-entrypoint.sh
• nginx config overrides
• Added zzz-custom-php.ini

[sertxudev]

Are we all installing almost the same extensions?

I use intl bcmath exif gd and a custom 50-laravel-automations.sh for a multi-database, multi-tenant app.