Stručně: Aktualizace image PHP v Dockeru je proti PHP2Shell povinná a neděje se sama. Musíte image s opravenou verzí PHP znovu sestavit nebo stáhnout, každý kontejner z něj vytvořit znovu a ověřit, že v běžícím kontejneru běží 8.5.12, 8.4.27, 8.3.36 nebo 8.2.35. Obyčejný restart kontejneru nestačí.
Proč kontejnery nejsou automaticky bezpečné
Image Dockeru je zmrazená momentka. PHP v něm zůstává ve stavu, v jakém bylo při sestavení, i když jsou na hostiteli už dávno nasazeny aktualizace. Aktualizace balíčku na hostitelském systému na PHP v kontejneru nic nemění.
K tomu přistupují typická úskalí: image sestavené před měsíci a od té doby nedotčené, základní image s pevným tagem jako php:8.3.35-fpm, lokální cache, které při sestavení znovu použijí starý základní image, a kontejnery, které byly sice restartovány, ale nikdy znovu vytvořeny. Postiženy jsou všechny provozní režimy obvyklé v kontejnerech: PHP-FPM, Apache s mod_php a FrankenPHP.
Přidává se otázka odpovědnosti. V mnoha firmách image jednou sestavila agentura nebo vývojář, provozuje ho ale interní IT nebo poskytovatel hostingu. Pak se nikdo necítí odpovědný za stav PHP v image. Ujasněte proto nejdřív, kdo image sestavuje, kde leží Dockerfile a kdo smí nasazovat nové image.
Ověření verze PHP v kontejneru
Kontrolujte běžící kontejner, ne jen Dockerfile. Příkazy jsou čistě čtecí.
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}}"
Pokud image používá balíčky distribuce místo oficiálních sestavení PHP, zkontrolujte stav balíčku v kontejneru. Názvy balíčků se liší podle základní distribuce:
docker exec <container> sh -c "apt policy php8.3-fpm 2>/dev/null || apk info -v 2>/dev/null | grep php"
U balíčků distribucí může být backport nasazen, přestože zůstává staré číslo verze. Pak rozhoduje changelog balíčku. Oficiální image PHP naproti tomu většinou přinášejí PHP vlastní kompilace; tam je rozhodující číslo verze z php -v. Jak backporty poznat, popisuje stránka Jak správně ověřit verzi PHP a stav záplaty.
Aktualizace image PHP v Dockeru: znovu sestavit a nasadit
Vlastní image na základě image PHP: základní image znovu stáhnout a sestavit bez cache.
docker build --pull --no-cache -t meine-app:2026-10-25 .
docker run --rm meine-app:2026-10-25 php -v # před nasazením zkontrolovat verzi
S Docker Compose: image stáhnout, resp. sestavit a kontejnery vytvořit znovu.
docker compose pull
docker compose build --pull --no-cache
docker compose up -d --force-recreate
Poté znovu zkontrolujte pomocí docker exec <container> php -v, zda běží nová verze. Pokud má kontejner v Dockerfile pevný tag verze, například FROM php:8.3.35-fpm, musíte tag zvýšit. Tag na větev, například php:8.3-fpm, dostává nové stavy záplat, ale jen pokud image stáhnete znovu.
Mějte předchozí image připravený, dokud není nová verze otestována. Při chybě se tak můžete vrátit, aniž by aplikace dlouho zůstala offline. Starý image ale obsahuje opět zranitelné PHP; cesta zpět je proto obhajitelná jen krátce a s přechodnými opatřeními.
Kdo používá Kubernetes, nasazuje nový image přes Deployment. Podrobnosti najdete na stránce Záplatování PHP v Kubernetes. Pro image FrankenPHP platí stejný postup; poznámky k provoznímu režimu najdete na stránce Zabezpečení FrankenPHP.
Nezapomeňte na vedlejší kontejnery: cron a queue workery, administrátorské nástroje nebo staging prostředí často používají stejný image PHP, ale běží ve vlastních kontejnerech. Každý z nich je nutné vytvořit znovu.
Přechodná opatření v kontejneru
Pokud aktualizace zatím nejde, platí přechodná opatření z php.net i v kontejneru. Nejsou úplnou ochranou. Limit paměti patří přitom ke kontejneru, protože php.net ho doporučuje přes kontejner nebo cgroup, ne přes RLIMIT_AS nebo RLIMIT_DATA:
; např. jako soubor v 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 ... # nebo v Compose: deploy.resources.limits.memory
Hodnotu přizpůsobte své aplikaci. Dbejte na to, aby aplikace nemohla memory_limit sama přepsat; u PHP-FPM k tomu nastavte hodnoty v poolu pomocí php_admin_value. Nová konfigurace se uplatní až po vytvoření nebo restartu kontejneru; souvislosti k restartu najdete na stránce Restart PHP-FPM a všech workerů.
Aby to příště šlo rychleji
- Image znovu sestavovat pravidelně a automaticky, ne jen při změnách kódu.
- Používat základní image s tagem větve a sestavený stav verzovat datem nebo digestem.
- Nechat image před nasazením zkontrolovat na známé zranitelnosti a provozovat kontejnery bez práv root.
- Vést inventář, které kontejnery používají který image.
Jak konkrétně pomáhá PHP SOS?
- Zjistit stav: Zkontrolujeme všechny běžící kontejnery, jejich image a verze PHP, i vedlejší kontejnery a staging.
- Znovu sestavit a nasadit: Prostřednictvím služby záplatování PHP sestavíme image s opravenou verzí a kontejnery kontrolovaně vytvoříme znovu.
- Zabezpečit přechod, kde aktualizace závisí na aplikaci: hodnoty z php.net, limit paměti na kontejneru.
- Trvale sledovat: Pomocí bezpečnostního monitoringu máme na očích stavy image a nápadné chování kontejnerů.
Časté dotazy
Stačí docker restart po aktualizaci?
Ne. docker restart spustí kontejner znovu se stejným, starým image. Musíte nový image sestavit nebo stáhnout a kontejner z něj vytvořit znovu, například pomocí docker compose up -d --force-recreate.
Obsahuje oficiální image PHP už opravenou verzi?
Nejlépe to ověřte přímo: stáhněte image znovu a spusťte v něm php -v. Očekávají se 8.5.12, 8.4.27, 8.3.36 nebo 8.2.35. Pokud image ukazuje starší číslo, ještě není aktualizován nebo pochází z cache.
Je PHP v kontejneru méně ohroženo než na hostiteli?
Samotná zranitelnost působí v kontejneru stejně. Dobře sestavený kontejner může důsledky průniku omezit, například uživatelem bez práv root a souborovým systémem chráněným proti zápisu. Záplatu to nenahrazuje.