PHP javítása Docker-konténerekben

Röviden: A PHP Docker image frissítése a PHP2Shell ellen kötelező, és nem történik meg magától. Az image-et javított PHP-verzióval újra kell építenie vagy le kell húznia, minden konténert újra kell belőle létrehoznia, és ellenőriznie kell, hogy a futó konténerben 8.5.12, 8.4.27, 8.3.36 vagy 8.2.35 fut. A konténer egyszerű újraindítása nem elég.

Miért nem biztonságosak automatikusan a konténerek

Egy Docker-image egy befagyasztott pillanatfelvétel. A benne lévő PHP azon az állapoton marad, amelyen építéskor volt, még ha a hoszton már rég telepítettek frissítéseket. A hoszt-rendszeren végzett csomagfrissítés nem változtat a konténerben lévő PHP-n.

Ehhez jönnek a tipikus buktatók: hónapokkal ezelőtt épített és azóta nem érintett image-ek, rögzített taggel rendelkező alap-image-ek, mint a php:8.3.35-fpm, helyi gyorsítótárak, amelyek építéskor a régi alap-image-et használják újra, és konténerek, amelyeket újraindítottak ugyan, de soha nem hoztak létre újra. Érintett minden, a konténerekben szokásos üzemmód: a PHP-FPM, az Apache mod_php-val és a FrankenPHP.

Ehhez jön egy felelősségi kérdés. Sok vállalkozásnál egy ügynökség vagy fejlesztő egyszer megépítette az image-et, üzemelteti viszont a belső informatika vagy egy tárhelyszolgáltató. Ilyenkor senki sem érzi magát felelősnek az image PHP-állapotáért. Ezért először tisztázza, ki építi az image-et, hol van a Dockerfile, és ki gördíthet ki új image-eket.

A konténerben lévő PHP-verzió ellenőrzése

A futó konténert ellenőrizze, ne csak a Dockerfile-t. A parancsok kizárólag olvasók.

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

Ha az image disztribúciós csomagokat használ a hivatalos PHP-buildek helyett, a csomagállapotot a konténerben ellenőrizze. A csomagnevek az alap-disztribúciótól függően eltérnek:

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

Disztribúciós csomagoknál backport lehet telepítve, noha a verziószám régi marad. Ilyenkor a csomag changelogja számít. A hivatalos PHP-image-ek ezzel szemben többnyire maguk fordítva hozzák a PHP-t; ott a php -v verziószáma a mérvadó érték. Hogyan ismeri fel a backportokat, azt a PHP-verzió és javítási állapot helyes ellenőrzése írja le.

PHP Docker image frissítése: újraépítés és kigördítés

Saját image egy PHP-image alapján: húzza le újra az alap-image-et, és gyorsítótár nélkül építse.

docker build --pull --no-cache -t meine-app:2026-10-25 .
docker run --rm meine-app:2026-10-25 php -v      # a verzió ellenőrzése a kitelepítés előtt

Docker Compose-zal: húzza le, illetve építse az image-eket, és hozza létre újra a konténereket.

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

Ezután a docker exec <container> php -v paranccsal ellenőrizze újra, hogy az új verzió fut-e. Ha a konténernek rögzített verziótagje van a Dockerfile-ban, például FROM php:8.3.35-fpm, akkor a taget meg kell emelnie. Az ágra mutató tag, mint a php:8.3-fpm, új javítási állapotokat kap, de csak ha újra lehúzza.

Tartsa készenlétben az előző image-et, amíg az új verziót nem tesztelték. Hiba esetén így visszaválthat anélkül, hogy az alkalmazás sokáig offline lenne. A régi image azonban ismét a sebezhető PHP-t tartalmazza; a visszaút ezért csak rövid ideig és az átmeneti intézkedésekkel vállalható.

Aki Kubernetesre épít, a deploymenten keresztül gördíti ki az új image-et. Részletek a PHP javítása Kubernetesben oldalon vannak. A FrankenPHP-image-ekre ugyanez az eljárás érvényes; az üzemmódra vonatkozó tudnivalók a FrankenPHP biztosítása oldalon találhatók.

Átmeneti intézkedések a konténerben

Ha a frissítés még nem megy, a php.net átmeneti intézkedései a konténerben is érvényesek. Nem teljes védelem. A memóriahatár ilyenkor a konténerre tartozik, mert a php.net a konténeren vagy cgroupon keresztüli korlátozást ajánlja, nem az RLIMIT_AS vagy az RLIMIT_DATA révén:

; pl. fájlként az image-ben: /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 ...         # vagy Compose-ban: deploy.resources.limits.memory

Az értéket igazítsa az alkalmazásához. Ügyeljen rá, hogy az alkalmazás a memory_limit értékét ne írhassa felül; a PHP-FPM-nél az értékeket ehhez a poolban php_admin_value-val állítsa be. Az új konfiguráció csak akkor lép érvénybe, ha a konténert újra létrehozták vagy újraindították; az újraindítás hátterét a PHP-FPM és az összes worker újraindítása írja le.

Hogy legközelebb gyorsabban menjen

• Az image-eket rendszeresen és automatikusan építse újra, ne csak kódváltozásnál.
• Ágra mutató taggel rendelkező alap-image-eket használjon, és az épített állapotot dátummal vagy digesttel verziózza.
• Az image-eket kiadás előtt ellenőriztesse ismert résekre, és a konténereket root jogok nélkül üzemeltesse.
• Vezessen leltárt arról, mely konténer melyik image-et használja.

Hogyan segít konkrétan a PHP SOS?

• Az állomány felvétele: Ellenőrizzük az összes futó konténert, azok image-eit és PHP-verzióit, a mellékkonténereket és a stagingot is.
• Újraépítés és kigördítés: A PHP-javítási szolgáltatáson keresztül javított verzióval építjük az image-eket, és ellenőrzötten újra létrehozzuk a konténereket.
• Az átmenet biztosítása, ahol a frissítés az alkalmazáson múlik: a php.net értékei, memóriahatár a konténeren.
• Tartós felügyelet: A biztonsági monitoringgal szemmel tartjuk az image-állapotokat és a konténerek feltűnő viselkedését.

Gyakori kérdések

Források

• php.net: biztonsági közlemények
• PHP 8 ChangeLog
• OWASP Cheat Sheets