# PHP javítása Docker-konténerekben

> PHP Docker image frissítése a PHP2Shell ellen: a konténerben lévő verzió ellenőrzése, az image újraépítése, a konténer újralétrehozása és az átmeneti értékek beállítása.

Forrás: https://phpsos.de/hu/php2shell/docker-container-patchen/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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.

```bash
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:

```bash
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](https://phpsos.de/hu/php2shell/php-version-pruefen/) í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.

```bash
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.

```bash
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](https://phpsos.de/hu/server/kubernetes/) oldalon vannak. A FrankenPHP-image-ekre ugyanez az eljárás érvényes; az üzemmódra vonatkozó tudnivalók a [FrankenPHP biztosítása](https://phpsos.de/hu/server/frankenphp/) oldalon találhatók.

> **Fontos:**
> Ne felejtsen el mellékkonténereket: a cron- és queue-workerek, a rendszergazdai eszközök vagy a staging-környezetek gyakran ugyanazt a PHP-image-et használják, de saját konténerekben futnak. Mindegyiket újra kell létrehozni.

## Á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:

```ini
; 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
```

```bash
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](https://phpsos.de/hu/php2shell/php-fpm-neustart/) í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](https://phpsos.de/hu/leistungen/php-patch-service/) 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](https://phpsos.de/hu/leistungen/security-monitoring/) szemmel tartjuk az image-állapotokat és a konténerek feltűnő viselkedését.


## Gyakori kérdések

**Elég a docker restart a frissítés után?**  
Nem. A docker restart a konténert ugyanazzal a régi image-gel indítja újra. Az új image-et kell megépítenie vagy lehúznia, és belőle újra létrehoznia a konténert, például a docker compose up -d --force-recreate paranccsal.

**Tartalmazza a hivatalos PHP-image már a javított verziót?**  
Ezt a legjobb közvetlenül ellenőrizni: húzza le újra az image-et, és futtassa benne a php -v parancsot. A 8.5.12, 8.4.27, 8.3.36 vagy 8.2.35 az elvárt. Ha az image régebbi számot mutat, még nincs frissítve, vagy gyorsítótárból származik.

**A konténerben lévő PHP kevésbé veszélyeztetett, mint a hoszton?**  
Maga a rés a konténerben ugyanúgy hat. Egy jól épített konténer korlátozhatja egy behatolás következményeit, például root jogok nélküli felhasználóval és írásvédett fájlrendszerrel. A javítást ez nem pótolja.

## Források

- [php.net: biztonsági közlemények](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)