Kurz gesagt: Das offizielle PHP-Image auf Docker Hub gibt es in vielen Tags, die Version, Variante (etwa cli, fpm, apache) und Basissystem kombinieren. Ein Tag ist ein Zeiger, der nach Neubauten auf neue Stände wandert; nur der Digest bezeichnet genau einen Stand. Gegen PHP2Shell brauchen Sie ein Image mit PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, geprüft mit php -v, und einen Neubau Ihrer eigenen Images darauf.
Warum der Tag allein wenig verrät
Viele Teams schreiben in ihr Dockerfile eine Zeile wie FROM php:8.3-fpm und vergessen sie dann. Das funktioniert, solange niemand fragt, welche PHP-Version eigentlich läuft. Seit PHP2Shell fragt jeder.
Die Antwort steht nicht im Dockerfile. Ein Tag wie 8.3-fpm zeigt zum Zeitpunkt des Ziehens auf den neuesten Stand dieses Zweigs. Wurde das Image vor dem 21. Oktober gezogen und seitdem nicht erneuert, enthält es eine verwundbare Version, obwohl der Tag heute auf einen behobenen Stand zeigt. Laut den Richtlinien der Docker Official Images werden die Images aktiv neu gebaut, auch bei Sicherheitskorrekturen. Ihr lokaler Stand wird davon aber nicht berührt.
Den kompletten Ablauf vom Neubau bis zum neu erstellten Container beschreibt PHP in Docker-Containern patchen. Hier geht es um die Vorfrage: Welches Image ist das richtige, und wie belegen Sie seinen Stand?
PHP-Docker-Image-Tags: So sind sie aufgebaut
Die Tags setzen sich aus bis zu drei Teilen zusammen. Docker Hub zeigt Beispiele wie php:8.2-cli, php:8.2-fpm-alpine oder php:8.4.27-zts-alpine3.24.
| Bestandteil | Beispiel | Bedeutung |
|---|---|---|
| Versionsangabe | 8.4.27 oder 8.4 |
volle Version bleibt bei diesem Stand, Zweig-Angabe wandert mit neuen Patches |
| Variante | cli, fpm, apache, zts |
Betriebsart von PHP im Container |
| Basissystem | alpine3.24, bookworm, trixie |
zugrunde liegende Alpine- oder Debian-Version |
Die Varianten sind für PHP2Shell nicht gleichwertig. fpm betreibt PHP-FPM, apache betreibt PHP als Apache-Modul, also mod_php. Diese Betriebsart stuft das PHP-Team am höchsten ein, weil dort ein Exploit gezeigt wurde, bevor überhaupt Anwendungscode läuft. Mehr dazu unter Warum mod_php besonders gefährdet ist. Die Variante cli ist für Kommandozeilenaufgaben gedacht.
Auch das Basissystem hat Folgen. Alpine-Images sind klein, nutzen aber eine andere C-Bibliothek als Debian-Images; manche Erweiterungen oder vorkompilierte Bibliotheken verhalten sich dort anders. Wechseln Sie das Basissystem deshalb nicht nebenbei mit dem Sicherheitsupdate, sondern bleiben Sie zunächst bei dem, was Ihre Anwendung kennt.
Wichtig für das Verständnis: Im offiziellen Image stammt PHP nicht aus den Paketen der Basis-Distribution. Docker Hub beschreibt, dass die PHP-Quellen im Image liegen und Erweiterungen über Hilfsskripte wie docker-php-ext-install eingebaut werden. Ein Paketupdate des Basissystems im eigenen Dockerfile ändert an der PHP-Version deshalb nichts. Maßgeblich ist allein, auf welchem Stand des offiziellen Images Sie aufbauen.
Tag oder Digest: Was sich wann ändert
Ein Digest ist eine Prüfsumme über den Inhalt eines Images, geschrieben als sha256: mit einer langen Zeichenfolge. Er ändert sich mit jedem Neubau. Dadurch eignet er sich als Nachweis: Wer den Digest kennt, weiß genau, welcher Stand läuft.
Für die Praxis bewährt sich eine Arbeitsteilung:
- Im Dockerfile den Zweig-Tag verwenden, etwa
php:8.4-fpm, damit ein Neubau automatisch den neuesten Patch dieses Zweigs bekommt. - Im Rollout den Digest des fertig gebauten eigenen Images verwenden, damit eindeutig ist, was ausgeliefert wird.
- In der Dokumentation beides festhalten: Tag, Digest und die mit
php -vgeprüfte Version.
Wer stattdessen einen vollen Versions-Tag wie 8.3.35-fpm festschreibt, bekommt nie automatisch einen Patch. Das kann gewollt sein, verlangt aber einen Prozess, der den Tag bei jeder Sicherheitsmeldung anhebt.
PHP2Shell: Ein Image vor dem Einsatz prüfen
Die folgenden Befehle ziehen ein Image und lesen Informationen aus. Sie verändern keine laufenden Container.
# Aktuellen Stand des Zweig-Tags ziehen
docker pull php:8.4-fpm
# Welche PHP-Version steckt im Image?
docker run --rm php:8.4-fpm php -v
# Digest des gezogenen Images anzeigen
docker image inspect php:8.4-fpm --format '{{index .RepoDigests 0}}'
# Digest und Plattformen direkt in der Registry abfragen
docker buildx imagetools inspect php:8.4-fpm
Die Abfrage mit imagetools zeigt bei Multi-Plattform-Images einen übergeordneten Digest und darunter je Plattform, etwa linux/amd64 oder linux/arm64, einen eigenen. Dokumentieren Sie den Digest, den Ihre Server tatsächlich ziehen, und beachten Sie, dass Entwicklerrechner mit anderer Architektur einen anderen Plattform-Digest bekommen.
Zeigt php -v nicht mindestens die behobene Version des Zweigs, ist das Image veraltet oder kommt aus einem Zwischenspeicher. Prüfen Sie dann, ob Ihre Umgebung einen Registry-Spiegel nutzt, der alte Stände ausliefert.
Für PHP 8.1 und älter liefert das PHP-Projekt keine offiziellen Releases mehr. Ein offizielles Image dieser Zweige kann deshalb keine reguläre behobene Version enthalten. Tags, die nicht mehr gepflegt werden, bleiben laut den Docker-Richtlinien abrufbar, werden aber nicht mehr aktualisiert.
Das Image bringt laut Docker Hub php.ini-development und php.ini-production mit und empfiehlt für den Produktivbetrieb dringend die Produktionsfassung. Eigene Einstellungen legen Sie als Datei in $PHP_INI_DIR/conf.d/ ab, auch die Übergangswerte von php.net.
Typische Fehler bei der Image-Wahl
- Variante aus Gewohnheit: Die apache-Variante wird gewählt, weil sie einfach startet, obwohl fpm mit separatem Webserver möglich wäre.
- Kein Neubau der eigenen Images: Das Basis-Image ist aktuell, das daraus gebaute Anwendungs-Image nicht.
- Mehrstufige Builds übersehen: In einem Dockerfile mit mehreren
FROM-Zeilen wird nur eine angepasst. - Nebenimages vergessen: Worker, Cron-Container und Admin-Werkzeuge nutzen eigene Tags.
- Nur auf
latestsetzen: Der Tag sagt nichts über Zweig und Variante und kann bei einem neuen Hauptzweig unerwartet springen.
Wie Sie Neubauten automatisieren, damit ein veraltetes Image gar nicht erst lange läuft, beschreibt CI/CD: PHP-Images automatisch neu bauen. Grundlagen zu PHP in Containern erklärt PHP in Containern.
Wie hilft PHP SOS konkret?
- Bestand prüfen: Wir lesen aus, welche Tags, Digests und PHP-Versionen in Ihren Images und laufenden Containern stecken.
- Variante bewerten: Wir prüfen, ob mod_php nötig ist oder ob fpm mit separatem Webserver das Risiko senkt.
- Neu bauen und belegen: Mit dem PHP-Patch-Service bauen wir Images auf behobener Basis neu und dokumentieren Tag, Digest und Version.
- Prozess verankern: Wir richten Dockerfiles und Rollouts so ein, dass der nächste Patch planbar ankommt.
Häufige Fragen
Was ist der Unterschied zwischen Tag und Digest?
Ein Tag wie php:8.4-fpm ist ein Name, der nach jedem Neubau auf einen neuen Stand zeigen kann. Ein Digest ist eine Prüfsumme, die genau einen unveränderlichen Stand bezeichnet. Für Nachweise und reproduzierbare Rollouts ist der Digest die verlässlichere Angabe.
Welcher Tag enthält die PHP2Shell-Korrektur?
Behoben sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Ein Tag mit voller Versionsnummer zeigt den Stand direkt an. Bei kürzeren Tags wie 8.4-fpm prüfen Sie nach dem Ziehen mit php -v, welche Version tatsächlich enthalten ist.
Gibt es ein gepatchtes offizielles Image für PHP 8.1?
Das PHP-Projekt liefert für 8.1 und älter keine offiziellen Releases mehr. Ein offizielles Image dieser Zweige kann deshalb keine reguläre behobene Version enthalten. Planen Sie den Wechsel auf einen unterstützten Zweig.
Ist die apache-Variante riskanter als fpm?
Die apache-Variante betreibt PHP als Apache-Modul, also mod_php. Diese Betriebsart stuft das PHP-Team bei PHP2Shell am höchsten ein. Beide Varianten brauchen das Update; bei mod_php ist Eile besonders geboten.