serversideup/php is a downstream distributor. We package PHP, NGINX, Apache, Composer, the base operating system, and related tooling into production-ready Docker images. We do not maintain those upstream projects ourselves — this policy explains what belongs here and what belongs upstream.
For anything in scope below, please use GitHub's private vulnerability reporting to open a confidential report. If you can't use GitHub, email security@serversideup.net instead. Please include:
- The affected image tag and digest (e.g.
serversideup/php:8.4-fpm-nginx@sha256:…) - Steps to reproduce and the impact
- Any suggested mitigation, if you have one
Do not disclose details publicly (issues, discussions, social media) before a fix is released.
Vulnerabilities in what we author and ship:
- Entrypoint scripts, healthchecks, helper scripts, and S6 service definitions in
src/ - Default configs we ship for PHP-FPM, NGINX, Apache, and FrankenPHP
- Insecure defaults: ports, file permissions, the
www-datauser model, SSL defaults - Build pipeline integrity (GitHub Actions workflows, tag assembly, image publishing, image signing)
- Documentation that materially misleads users about a security-relevant setting
Vulnerabilities in software we package but do not maintain belong with the upstream project, not here:
| Component | Where to report |
|---|---|
| PHP itself | The PHP project |
| NGINX | NGINX security advisories |
| Apache HTTP Server | Apache HTTPD security |
| Composer | composer/composer on GitHub |
| Debian / Alpine base packages | The respective distribution security teams |
If an upstream CVE is already publicly disclosed, you don't need to file with us. Floating tags pick up upstream fixes on their own: a new PHP patch publishes within about an hour of php.net listing it, and operating system packages update on the weekly rebuild (Tuesday 08:00 UTC). See How our releases work for the full cadence and which tags receive rebuilds.
Images we publish are signed with cosign and carry an SBOM and build provenance. Images published before signing was added have provenance only. Verifying images shows how to check them.
Each production build ends with a vulnerability scan of every published image. The results are in the run summary of each production run, and Vulnerability scanning explains how to read them. Scanner findings are already disclosed upstream CVEs. Anything that is not yet public, including a problem in what we author, still goes through private reporting.
Our images bundle third-party software, each with its own support window. Before reporting an issue (or pinning to a particular version), confirm the component is still receiving security fixes from its maintainers:
| Component | Lifecycle reference |
|---|---|
| PHP | endoflife.date/php |
| Debian | endoflife.date/debian |
| Alpine Linux | endoflife.date/alpine-linux |
| NGINX | endoflife.date/nginx |
| Apache HTTP Server | endoflife.date/apache |
| Composer | endoflife.date/composer |
We publish images for end-of-life PHP versions so legacy applications have a path into containers, but only while two things remain true:
- The official docker-library/php Dockerfile for that version exists at some commit, so we can still compile it the same way the official images did.
- The operating system release underneath still receives security updates from its distribution. Debian LTS counts. Once a release passes its end of life, a rebuild cannot deliver any patches, and Debian removes the packages from its mirrors soon after, so the build fails anyway.
When either condition stops holding, we stop rebuilding that image and its existing tags freeze at their last successful build. We do not pin archived or snapshot package repositories to keep an EOL base building: that produces a fresh tag with the same unpatched packages, which is worse than an honest frozen tag. Use an EOL base as a stepping stone, not a destination. See Choosing an image — Operating Systems for the trade-off.
The following images are no longer built. Their existing tags remain pullable on Docker Hub and GitHub Packages, but they are frozen at their last successful build and will receive no further security updates — not for PHP, and not for the operating system underneath them.
| Image | Last built | Why it stopped |
|---|---|---|
| PHP 7.4 (all variations) | 2026-09-03 | Debian Bullseye and Alpine 3.16 were the only bases the official php:7.4 images ever shipped, and upstream stopped building them in November 2022. Both bases are now past end of life (see below). |
| PHP 8.0 (all variations) | 2026-09-03 | Same bases as 7.4. Upstream stopped building php:8.0 in November 2023. |
| Anything on Debian Bullseye | 2026-09-03 | Debian 11 LTS ended on 2026-08-31. The following week Debian removed the Bullseye packages from deb.debian.org and security.debian.org, so apt-get install fails inside the build. |
| Anything on Alpine 3.16 | 2026-09-03 | Alpine 3.16 reached end of life on 2024-05-23 and has received no security updates since. It was only ever used by PHP 7.4 and 8.0. |
PHP 8.1 is end of life and still built. We compile it from the last docker-library/php commit that included it. Debian Bookworm, Debian Trixie, and Alpine 3.22 still receive security updates, so a weekly rebuild delivers real operating system patches. It stops when those bases do.
If you are running one of the frozen images, treat it as a migration deadline rather than a stable base. Move to a supported PHP version and base from Choosing an image. The Upgrade Guide covers moving between our releases. If you cannot move yet and need to install packages on a frozen Bullseye tag, the upgrade guide shows how to do it in your own Dockerfile.
For the full release model, how floating vs. version-pinned tags behave, and how to apply your own patches to a pinned image, see the Upgrade Guide.
For the EOL trade-off when picking an operating system base, see Choosing an image — Operating Systems.