Patch PHP i Docker-containere

Kort sagt: En PHP Docker-image-opdatering er pligt mod PHP2Shell, og den sker ikke af sig selv. I skal bygge eller hente imaget med en rettet PHP-version påny, oprette hver container påny fra det og kontrollere, at der i den kørende container kører 8.5.12, 8.4.27, 8.3.36 eller 8.2.35. En almindelig genstart af containeren er ikke nok.

Hvorfor containere ikke automatisk er sikre

Et Docker-image er et indfrosset øjebliksbillede. PHP'en deri forbliver på den status, den havde ved bygningen, selv om der for længst er indspillet opdateringer på værten. En pakkeopdatering på værtssystemet ændrer intet ved PHP'en i containeren.

Hertil kommer typiske faldgruber: images, der blev bygget for måneder siden og siden ikke er rørt, basis-images med fast tag som php:8.3.35-fpm, lokale caches, der ved bygningen genbruger det gamle basis-image, og containere, der nok er genstartet, men aldrig oprettet påny. Berørt er alle driftsformer, der er almindelige i containere: PHP-FPM, Apache med mod_php og FrankenPHP.

Hertil kommer et spørgsmål om ansvar. I mange virksomheder har et bureau eller en udvikler bygget imaget én gang, men driften varetages af den interne it eller en hostingudbyder. Så føler ingen sig ansvarlig for PHP-status i imaget. Afklar derfor først, hvem der bygger imaget, hvor Dockerfilen ligger, og hvem der må udrulle nye images.

Kontrollér PHP-versionen i containeren

Kontrollér den kørende container, ikke kun Dockerfilen. Kommandoerne er rent læsende.

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

Bruger imaget distributionspakker i stedet for officielle PHP-builds, kontrollerer I pakkestatus i containeren. Pakkenavne afviger fra basisdistribution til basisdistribution:

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

Ved distributionspakker kan en backport være indspillet, selv om versionsnummeret forbliver gammelt. Så tæller pakkens changelog. De officielle PHP-images medbringer derimod som regel PHP selvkompileret; dér er versionsnummeret fra php -v den afgørende værdi. Hvordan I genkender backports, beskriver Kontrollér PHP-version og rettelsesstatus korrekt.

Opdatér PHP Docker-imaget: byg påny og udrul

Eget image på basis af et PHP-image: Hent basis-imaget påny og byg uden cache.

docker build --pull --no-cache -t meine-app:2026-10-25 .
docker run --rm meine-app:2026-10-25 php -v      # kontrollér versionen før udrulning

Med Docker Compose: Hent henholdsvis byg images og opret containere påny.

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

Kontrollér derefter igen med docker exec <container> php -v, om den nye version kører. Har containeren et fast versions-tag i Dockerfilen, f.eks. FROM php:8.3.35-fpm, skal I løfte tagget. Et tag på grenen som php:8.3-fpm får nye patchniveauer, men kun hvis I henter påny.

Hold det forudgående image klar, til den nye version er testet. Ved en fejl kan I så skifte tilbage, uden at applikationen længe er offline. Det gamle image indeholder dog igen den sårbare PHP; en vej tilbage er derfor kun kortvarigt og med de midlertidige foranstaltninger forsvarlig.

Den, der satser på Kubernetes, udruller det nye image via deployment. Enkeltheder står under Patch PHP i Kubernetes. For FrankenPHP-images gælder samme fremgangsmåde; henvisninger om driftsformen finder I under Sikr FrankenPHP.

Midlertidige foranstaltninger i containeren

Er opdateringen endnu ikke mulig, gælder php.nets midlertidige foranstaltninger også i containeren. De er ingen fuld beskyttelse. Hukommelsesgrænsen hører her til på containeren, for php.net anbefaler den via container eller cgroup, ikke via RLIMIT_AS eller RLIMIT_DATA:

; f.eks. som fil i imaget: /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 ...         # eller i Compose: deploy.resources.limits.memory

Værdien tilpasser I til jeres applikation. Sørg for, at applikationen ikke selv kan overskrive memory_limit; ved PHP-FPM sætter I værdierne hertil i poolen med php_admin_value. Ny konfiguration virker først, når containeren er oprettet påny eller genstartet; baggrunden for genstarten står under Genstart PHP-FPM og alle workers.

Så det går hurtigere næste gang

• Byg images regelmæssigt og automatisk påny, ikke kun ved kodeændringer.
• Brug basis-images med gren-tag, og versionér den byggede status med dato eller digest.
• Lad images kontrollere for kendte sårbarheder før udrulning, og drift containere uden root-rettigheder.
• Før en fortegnelse over, hvilke containere der bruger hvilket image.

Hvordan hjælper PHP SOS konkret?

• Optage status: Vi kontrollerer alle kørende containere, deres images og PHP-versioner, også sidecontainere og staging.
• Bygge påny og udrulle: Via PHP-patch-servicen bygger vi imagene med rettet version og opretter containerne kontrolleret påny.
• Sikre overgangen, hvor opdateringen hænger på applikationen: værdierne fra php.net, hukommelsesgrænse på containeren.
• Overvåge varigt: Med sikkerhedsovervågningen holder vi øje med image-status og påfaldende adfærd i containerne.

Ofte stillede spørgsmål

Kilder

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