Patcha PHP i Docker-containrar

Kort sagt: Att uppdatera PHP-Docker-imagen är ett måste mot PHP2Shell, och det sker inte av sig självt. Ni måste bygga eller hämta imagen på nytt med en åtgärdad PHP-version, skapa varje container på nytt från den och kontrollera att 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 körs i den körande containern. En enkel omstart av containern räcker inte.

Varför containrar inte automatiskt är säkra

En Docker-image är en fryst ögonblicksbild. PHP i den förblir på det läge det hade vid bygget, även om uppdateringar för länge sedan har installerats på värden. En paketuppdatering på värdsystemet ändrar ingenting i PHP i containern.

Dessutom finns typiska fallgropar: Images som byggdes för månader sedan och sedan dess inte rörts, bas-images med fast tagg som php:8.3.35-fpm, lokala cacher som vid bygget återanvänder den gamla bas-imagen och containrar som visserligen har startats om men aldrig skapats på nytt. Berörda är alla driftlägen som är vanliga i containrar: PHP-FPM, Apache med mod_php och FrankenPHP.

Dessutom kommer en fråga om ansvar. I många företag har en byrå eller en utvecklare byggt imagen en gång, men den drivs av den interna IT-avdelningen eller ett webbhotell. Då känner sig ingen ansvarig för PHP-versionen i imagen. Klarlägg därför först vem som bygger imagen, var Dockerfile ligger och vem som får rulla ut nya images.

Kontrollera PHP-versionen i containern

Kontrollera den körande containern, inte bara Dockerfile. Kommandona är rent läsande.

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

Använder imagen distributionspaket i stället för officiella PHP-builds, kontrollera paketstatusen i containern. Paketnamn skiljer sig mellan bas-distributioner:

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

Vid distributionspaket kan en backport vara installerad fast versionsnumret förblir gammalt. Då gäller paketets changelog. De officiella PHP-imagerna levererar däremot oftast PHP självkompilerat; där är versionsnumret från php -v det avgörande värdet. Hur ni känner igen backports beskriver Kontrollera PHP-version och patchstatus rätt.

Uppdatera PHP-Docker-image: bygga om och rulla ut

Egen image baserad på en PHP-image: Hämta bas-imagen på nytt och bygg utan cache.

docker build --pull --no-cache -t meine-app:2026-10-25 .
docker run --rm meine-app:2026-10-25 php -v      # kontrollera versionen före utrullningen

Med Docker Compose: Hämta respektive bygg images och skapa containrar på nytt.

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

Kontrollera därefter igen med docker exec <container> php -v att den nya versionen körs. Har containern en fast versionstagg i Dockerfile, till exempel FROM php:8.3.35-fpm, måste ni höja taggen. En tagg på grenen som php:8.3-fpm får nya patchversioner, men bara om ni hämtar på nytt.

Håll den tidigare imagen redo tills den nya versionen är testad. Vid ett fel kan ni då växla tillbaka utan att låta applikationen vara offline länge. Den gamla imagen innehåller dock åter det sårbara PHP; en återväg är därför bara försvarbar kortvarigt och med övergångsåtgärderna.

Den som kör Kubernetes rullar ut den nya imagen via deployment. Detaljer finns under Patcha PHP i Kubernetes. För FrankenPHP-images gäller samma tillvägagångssätt; anvisningar om driftläget finns under Säkra FrankenPHP.

Övergångsåtgärder i containern

Går uppdateringen ännu inte gäller övergångsåtgärderna från php.net även i containern. De är inget fullständigt skydd. Minnesgränsen hör då till containern, eftersom php.net rekommenderar den via container eller cgroup, inte via RLIMIT_AS eller RLIMIT_DATA:

; t.ex. som fil i imagen: /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ärdet anpassar ni till er applikation. Se till att applikationen inte själv kan skriva över memory_limit; vid PHP-FPM sätter ni värdena för det i poolen med php_admin_value. Ny konfiguration verkar först när containern har skapats eller startats om på nytt; bakgrunden till omstarten står under Starta om PHP-FPM och alla workers.

Så går det snabbare nästa gång

• Bygg om images regelbundet och automatiskt, inte bara vid kodändringar.
• Använd bas-images med grentagg och versionera det byggda läget med datum eller digest.
• Låt images kontrolleras efter kända sårbarheter före utrullning och kör containrar utan root-rättigheter.
• För ett inventarium över vilka containrar som använder vilken image.

Hur hjälper PHP SOS konkret?

• Kartlägga beståndet: Vi kontrollerar alla körande containrar, deras images och PHP-versioner, även sidocontainrar och staging.
• Bygga om och rulla ut: Via PHP-patchtjänsten bygger vi imagerna med åtgärdad version och skapar containrarna på nytt på ett kontrollerat sätt.
• Skydda övergången, där uppdateringen hänger på applikationen: värden från php.net, minnesgräns vid containern.
• Övervaka varaktigt: Med säkerhetsövervakningen håller vi image-lägen och avvikande beteende hos containrarna under uppsikt.

Vanliga frågor

Källor

• php.net: säkerhetsmeddelanden
• PHP 8 ChangeLog
• OWASP Cheat Sheets