Łatanie PHP w kontenerach Docker

Krótko: Aktualizacja obrazu PHP Docker jest przeciw PHP2Shell obowiązkiem i nie dzieje się sama. Muszą Państwo zbudować lub pobrać obraz z naprawioną wersją PHP, utworzyć z niego każdy kontener na nowo i sprawdzić, że w działającym kontenerze działa 8.5.12, 8.4.27, 8.3.36 lub 8.2.35. Zwykły restart kontenera nie wystarcza.

Dlaczego kontenery nie są automatycznie bezpieczne

Obraz Docker to zamrożona migawka. PHP w nim pozostaje na stanie, jaki miał w momencie budowania, nawet jeśli na hoście dawno zainstalowano aktualizacje. Aktualizacja pakietów w systemie hosta nie zmienia niczego w PHP w kontenerze.

Dochodzą typowe pułapki: obrazy zbudowane przed miesiącami i od tej pory nietknięte, obrazy bazowe ze stałym tagiem, takie jak php:8.3.35-fpm, lokalne pamięci podręczne, które przy budowaniu ponownie używają starego obrazu bazowego, oraz kontenery, które zostały co prawda zrestartowane, ale nigdy nie utworzone na nowo. Dotknięte są wszystkie tryby pracy typowe dla kontenerów: PHP-FPM, Apache z mod_php i FrankenPHP.

Dochodzi kwestia odpowiedzialności. W wielu firmach agencja lub programista zbudował obraz raz, ale eksploatuje go wewnętrzny dział IT lub dostawca hostingu. Wtedy nikt nie czuje się odpowiedzialny za stan PHP w obrazie. Dlatego proszę najpierw wyjaśnić, kto buduje obraz, gdzie leży Dockerfile i kto może wdrażać nowe obrazy.

Sprawdzanie wersji PHP w kontenerze

Proszę sprawdzić działający kontener, a nie tylko Dockerfile. Polecenia służą wyłącznie do odczytu.

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

Jeśli obraz używa pakietów dystrybucji zamiast oficjalnych buildów PHP, proszę sprawdzić stan pakietów w kontenerze. Nazwy pakietów różnią się zależnie od dystrybucji bazowej:

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

W przypadku pakietów dystrybucji backport może być wprowadzony, mimo że numer wersji pozostaje stary. Wtedy liczy się changelog pakietu. Oficjalne obrazy PHP dostarczają natomiast PHP zwykle skompilowane samodzielnie; tam miarodajna jest wartość numeru wersji z php -v. Jak rozpoznać backporty, opisuje strona Jak prawidłowo sprawdzić wersję PHP i stan poprawek.

Aktualizacja obrazu PHP Docker: zbudować od nowa i wdrożyć

Własny obraz na bazie obrazu PHP: pobrać obraz bazowy na nowo i zbudować bez pamięci podręcznej.

docker build --pull --no-cache -t meine-app:2026-10-25 .
docker run --rm meine-app:2026-10-25 php -v      # sprawdzić wersję przed wdrożeniem

Z Docker Compose: pobrać lub zbudować obrazy i utworzyć kontenery na nowo.

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

Następnie proszę ponownie sprawdzić poleceniem docker exec <container> php -v, czy działa nowa wersja. Jeśli kontener ma w Dockerfile stały tag wersji, na przykład FROM php:8.3.35-fpm, muszą Państwo podnieść tag. Tag na gałąź, taki jak php:8.3-fpm, otrzymuje nowe stany poprawek, ale tylko wtedy, gdy pobiorą Państwo obraz na nowo.

Proszę zachować poprzedni obraz w gotowości, dopóki nowa wersja nie zostanie przetestowana. W razie błędu można wtedy wrócić, bez długiego wyłączania aplikacji. Stary obraz zawiera jednak znowu podatne PHP; droga powrotna jest więc uzasadniona tylko krótko i ze środkami przejściowymi.

Kto korzysta z Kubernetes, wdraża nowy obraz przez Deployment. Szczegóły na stronie Łatanie PHP w Kubernetes. Dla obrazów FrankenPHP obowiązuje to samo postępowanie; wskazówki o trybie pracy znajdą Państwo na stronie Zabezpieczanie FrankenPHP.

Środki przejściowe w kontenerze

Jeśli aktualizacja jeszcze nie jest możliwa, środki przejściowe php.net obowiązują także w kontenerze. Nie są pełną ochroną. Limit pamięci należy ustawić na kontenerze, ponieważ php.net zaleca go przez kontener lub cgroup, a nie przez RLIMIT_AS czy RLIMIT_DATA:

; np. jako plik w obrazie: /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 ...         # lub w Compose: deploy.resources.limits.memory

Wartość dostosowują Państwo do swojej aplikacji. Proszę zadbać, aby aplikacja nie mogła sama nadpisać memory_limit; w PHP-FPM ustawia się w tym celu wartości w puli przez php_admin_value. Nowa konfiguracja działa dopiero wtedy, gdy kontener zostanie utworzony na nowo lub zrestartowany; tło dotyczące restartu opisuje strona Restart PHP-FPM i wszystkich workerów.

Aby następnym razem poszło szybciej

• Obrazy budować na nowo regularnie i automatycznie, nie tylko przy zmianach kodu.
• Używać obrazów bazowych z tagiem gałęzi i wersjonować zbudowany stan datą lub digestem.
• Przed wdrożeniem kazać sprawdzać obrazy pod kątem znanych luk i eksploatować kontenery bez uprawnień root.
• Prowadzić inwentarz, które kontenery używają którego obrazu.

Jak konkretnie pomaga PHP SOS?

• Rejestracja stanu: Sprawdzamy wszystkie działające kontenery, ich obrazy i wersje PHP, także kontenery poboczne i staging.
• Budowa od nowa i wdrożenie: Przez usługę łatania PHP budujemy obrazy z naprawioną wersją i w kontrolowany sposób tworzymy kontenery na nowo.
• Zabezpieczenie okresu przejściowego, gdy aktualizacja zależy od aplikacji: wartości z php.net, limit pamięci na kontenerze.
• Stały nadzór: Dzięki monitoringowi bezpieczeństwa mamy na oku stany obrazów i podejrzane zachowanie kontenerów.

Częste pytania

Źródła

• php.net: komunikaty o bezpieczeństwie
• PHP 8 ChangeLog
• OWASP Cheat Sheets