PHP in Docker-containers patchen

Kort gezegd: Een PHP Docker-image updaten is tegen PHP2Shell verplicht, en het gebeurt niet vanzelf. U moet het image met een verholpen PHP-versie opnieuw bouwen of ophalen, elke container daaruit opnieuw aanmaken en controleren dat in de draaiende container 8.5.12, 8.4.27, 8.3.36 of 8.2.35 draait. Een gewone herstart van de container volstaat niet.

Waarom containers niet automatisch veilig zijn

Een Docker-image is een bevroren momentopname. De PHP daarin blijft op de stand die ze bij het bouwen had, ook als er op de host allang updates zijn geïnstalleerd. Een pakketupdate op het hostsysteem verandert niets aan de PHP in de container.

Daar komen typische valkuilen bij: images die maanden geleden zijn gebouwd en sindsdien niet zijn aangeraakt, basisimages met een vaste tag zoals php:8.3.35-fpm, lokale caches die bij het bouwen het oude basisimage hergebruiken, en containers die weliswaar zijn herstart, maar nooit opnieuw zijn aangemaakt. Getroffen zijn alle werkwijzen die in containers gebruikelijk zijn: PHP-FPM, Apache met mod_php en FrankenPHP.

Daarbij komt een kwestie van verantwoordelijkheid. In veel bedrijven heeft een bureau of ontwikkelaar het image eenmaal gebouwd, maar wordt het beheerd door de interne IT of een hoster. Dan voelt niemand zich verantwoordelijk voor de PHP-stand in het image. Stel daarom eerst vast wie het image bouwt, waar het Dockerfile staat en wie nieuwe images mag uitrollen.

PHP-versie in de container controleren

Controleer de draaiende container, niet alleen het Dockerfile. De opdrachten zijn puur lezend.

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}}"

Gebruikt het image distributiepakketten in plaats van officiële PHP-builds, controleer dan de pakketstand in de container. Pakketnamen verschillen per basisdistributie:

docker exec <container> sh -c "apt policy php8.3-fpm 2>/dev/null || apk info -v 2>/dev/null | grep php"

Bij distributiepakketten kan een backport zijn geïnstalleerd, hoewel het versienummer oud blijft. Dan telt de pakketchangelog. De officiële PHP-images brengen PHP daarentegen meestal zelf gecompileerd mee; daar is het versienummer uit php -v de maatgevende waarde. Hoe u backports herkent, beschrijft PHP-versie en patchstand goed controleren.

PHP Docker-image updaten: opnieuw bouwen en uitrollen

Eigen image op basis van een PHP-image: basisimage opnieuw ophalen en zonder cache bouwen.

docker build --pull --no-cache -t meine-app:2026-10-25 .
docker run --rm meine-app:2026-10-25 php -v      # versie controleren vóór het uitrollen

Met Docker Compose: images ophalen of bouwen en containers opnieuw aanmaken.

docker compose pull
docker compose build --pull --no-cache
docker compose up -d --force-recreate

Controleer daarna opnieuw met docker exec <container> php -v of de nieuwe versie draait. Heeft de container een vaste versietag in het Dockerfile, bijvoorbeeld FROM php:8.3.35-fpm, dan moet u de tag verhogen. Een tag op de tak zoals php:8.3-fpm krijgt nieuwe patchstanden, maar alleen als u opnieuw ophaalt.

Houd het vorige image paraat tot de nieuwe versie is getest. Bij een fout kunt u zo terugschakelen zonder de toepassing lang offline te laten. Het oude image bevat echter weer de kwetsbare PHP; een terugweg is daarom alleen kort en met de overbruggingsmaatregelen verdedigbaar.

Wie op Kubernetes draait, rolt het nieuwe image uit via de deployment. Details staan onder PHP in Kubernetes patchen. Voor FrankenPHP-images geldt dezelfde aanpak; aanwijzingen over de werkwijze vindt u onder FrankenPHP beveiligen.

Overbruggingsmaatregelen in de container

Kan de update nog niet, dan gelden de overbruggingsmaatregelen van php.net ook in de container. Ze zijn geen volledige bescherming. De geheugengrens hoort daarbij bij de container, want php.net adviseert haar via container of cgroup, niet via RLIMIT_AS of RLIMIT_DATA:

; bijv. als bestand in het 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 ...         # of in Compose: deploy.resources.limits.memory

De waarde past u aan uw toepassing aan. Let erop dat de toepassing memory_limit niet zelf kan overschrijven; bij PHP-FPM stelt u de waarden daarvoor in de pool in met php_admin_value. Nieuwe configuratie werkt pas als de container opnieuw is aangemaakt of herstart; de achtergronden bij de herstart staan onder PHP-FPM en alle workers herstarten.

Zodat het de volgende keer sneller gaat

• Images regelmatig en automatisch opnieuw bouwen, niet alleen bij codewijzigingen.
• Basisimages met taktag gebruiken en de gebouwde stand met datum of digest van een versie voorzien.
• Images vóór het uitrollen op bekende kwetsbaarheden laten controleren en containers zonder rootrechten draaien.
• Een inventaris bijhouden van welke containers welk image gebruiken.

Hoe helpt PHP SOS concreet?

• Bestand opnemen: wij controleren alle draaiende containers, hun images en PHP-versies, ook nevencontainers en staging.
• Opnieuw bouwen en uitrollen: via de PHP-patchservice bouwen we de images met verholpen versie en maken we de containers gecontroleerd opnieuw aan.
• Overgang beveiligen, waar de update aan de toepassing hangt: waarden van php.net, geheugengrens bij de container.
• Duurzaam bewaken: met de security-monitoring houden we imagestanden en opvallend gedrag van de containers in het oog.

Veelgestelde vragen

Bronnen

• php.net: beveiligingsmeldingen
• PHP 8 ChangeLog
• OWASP Cheat Sheets