Kurz gesagt: Ein PHP-Docker-Image update ist gegen PHP2Shell Pflicht, und es geschieht nicht von selbst. Sie müssen das Image mit einer behobenen PHP-Version neu bauen oder ziehen, jeden Container daraus neu erstellen und prüfen, dass im laufenden Container 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 läuft. Ein einfacher Neustart des Containers reicht nicht.
Warum Container nicht automatisch sicher sind
Ein Docker-Image ist eine eingefrorene Momentaufnahme. Das PHP darin bleibt auf dem Stand, den es beim Bauen hatte, auch wenn auf dem Host längst Updates eingespielt sind. Ein Paketupdate auf dem Host-System ändert am PHP im Container nichts.
Hinzu kommen typische Stolperfallen: Images, die vor Monaten gebaut und seither nicht angefasst wurden, Basis-Images mit festem Tag wie php:8.3.35-fpm, lokale Caches, die beim Bauen das alte Basis-Image wiederverwenden, und Container, die zwar neu gestartet, aber nie neu erstellt wurden. Betroffen sind alle Betriebsarten, die in Containern üblich sind: PHP-FPM, Apache mit mod_php und FrankenPHP.
Hinzu kommt eine Frage der Zuständigkeit. In vielen Unternehmen hat eine Agentur oder ein Entwickler das Image einmal gebaut, betrieben wird es aber von der internen IT oder einem Hoster. Dann fühlt sich niemand für den PHP-Stand im Image verantwortlich. Klären Sie deshalb zuerst, wer das Image baut, wo das Dockerfile liegt und wer neue Images ausrollen darf.
PHP-Version im Container prüfen
Prüfen Sie den laufenden Container, nicht nur das Dockerfile. Die Befehle sind rein lesend.
docker ps --format "table {{.Names}}\t{{.Image}}\t{{.CreatedAt}}"
docker exec <container> php -v
docker exec <container> php -i | grep -E "^PHP Version|Server API"
docker image inspect <image> --format "{{.Created}}"
Nutzt das Image Distributionspakete statt offizieller PHP-Builds, prüfen Sie den Paketstand im Container. Paketnamen weichen je Basis-Distribution ab:
docker exec <container> sh -c "apt policy php8.3-fpm 2>/dev/null || apk info -v 2>/dev/null | grep php"
Bei Distributionspaketen kann ein Backport eingespielt sein, obwohl die Versionsnummer alt bleibt. Dann zählt der Paket-Changelog. Die offiziellen PHP-Images bringen PHP dagegen meist selbst kompiliert mit; dort ist die Versionsnummer aus php -v der maßgebliche Wert. Wie Sie Backports erkennen, beschreibt PHP-Version und Patchstand richtig prüfen.
PHP-Docker-Image updaten: neu bauen und ausrollen
Eigenes Image auf Basis eines PHP-Images: Basis-Image neu ziehen und ohne Cache bauen.
docker build --pull --no-cache -t meine-app:2026-10-25 .
docker run --rm meine-app:2026-10-25 php -v # Version vor dem Ausrollen prüfen
Mit Docker Compose: Images ziehen bzw. bauen und Container neu erstellen.
docker compose pull
docker compose build --pull --no-cache
docker compose up -d --force-recreate
Prüfen Sie danach erneut mit docker exec <container> php -v, ob die neue Version läuft. Hat der Container einen festen Versions-Tag im Dockerfile, etwa FROM php:8.3.35-fpm, müssen Sie den Tag anheben. Ein Tag auf den Zweig wie php:8.3-fpm bekommt neue Patchstände, aber nur, wenn Sie neu ziehen.
Halten Sie das vorherige Image bereit, bis die neue Version getestet ist. Bei einem Fehler können Sie so zurückwechseln, ohne die Anwendung lange offline zu lassen. Das alte Image enthält allerdings wieder das verwundbare PHP; ein Rückweg ist deshalb nur kurz und mit den Übergangsmaßnahmen vertretbar.
Wer auf Kubernetes setzt, rollt das neue Image über das Deployment aus. Einzelheiten stehen unter PHP in Kubernetes patchen. Für FrankenPHP-Images gilt dasselbe Vorgehen; Hinweise zur Betriebsart finden Sie unter FrankenPHP absichern.
Vergessen Sie keine Nebencontainer: Cron- und Queue-Worker, Admin-Tools oder Staging-Umgebungen nutzen oft dasselbe PHP-Image, laufen aber in eigenen Containern. Jeder davon muss neu erstellt werden.
Übergangsmaßnahmen im Container
Geht das Update noch nicht, gelten die Übergangsmaßnahmen von php.net auch im Container. Sie sind kein vollständiger Schutz. Die Speichergrenze gehört dabei an den Container, denn php.net empfiehlt sie über Container oder cgroup, nicht über RLIMIT_AS oder RLIMIT_DATA:
; z. B. als Datei im Image: /usr/local/etc/php/conf.d/zz-uebergang.ini
memory_limit = -1
post_max_size = 8M
upload_max_filesize = 6M
session.upload_progress.enabled = 0
docker run --memory=1g ... # oder in Compose: deploy.resources.limits.memory
Den Wert passen Sie an Ihre Anwendung an. Achten Sie darauf, dass die Anwendung memory_limit nicht selbst überschreiben kann; bei PHP-FPM setzen Sie die Werte dafür im Pool mit php_admin_value. Neue Konfiguration greift erst, wenn der Container neu erstellt oder neu gestartet ist; die Hintergründe zum Neustart stehen unter PHP-FPM und alle Worker neu starten.
Damit es beim nächsten Mal schneller geht
- Images regelmäßig und automatisch neu bauen, nicht nur bei Codeänderungen.
- Basis-Images mit Zweig-Tag nutzen und den gebauten Stand mit Datum oder Digest versionieren.
- Images vor dem Ausrollen auf bekannte Lücken prüfen lassen und Container ohne Root-Rechte betreiben.
- Ein Inventar führen, welche Container welches Image nutzen.
Wie hilft PHP SOS konkret?
- Bestand aufnehmen: Wir prüfen alle laufenden Container, deren Images und PHP-Versionen, auch Nebencontainer und Staging.
- Neu bauen und ausrollen: Über den PHP-Patch-Service bauen wir die Images mit behobener Version und erstellen die Container kontrolliert neu.
- Übergang absichern, wo das Update an der Anwendung hängt: Werte von php.net, Speichergrenze am Container.
- Dauerhaft überwachen: Mit dem Security-Monitoring behalten wir Image-Stände und auffälliges Verhalten der Container im Blick.
Häufige Fragen
Reicht docker restart nach dem Update?
Nein. docker restart startet den Container mit demselben, alten Image neu. Sie müssen das neue Image bauen oder ziehen und den Container daraus neu erstellen, etwa mit docker compose up -d --force-recreate.
Enthält das offizielle PHP-Image schon die behobene Version?
Das prüfen Sie am besten direkt: Ziehen Sie das Image neu und lassen Sie php -v darin laufen. Erwartet werden 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Zeigt das Image eine ältere Nummer, ist es noch nicht aktualisiert oder stammt aus einem Cache.
Ist PHP im Container weniger gefährdet als auf dem Host?
Die Lücke selbst wirkt im Container genauso. Ein gut gebauter Container kann die Folgen eines Einbruchs begrenzen, etwa durch einen Benutzer ohne Root-Rechte und ein schreibgeschütztes Dateisystem. Den Patch ersetzt das nicht.