# Łatanie PHP w kontenerach Docker

> Aktualizacja obrazu PHP Docker przeciw PHP2Shell: sprawdź wersję w kontenerze, zbuduj obraz od nowa, utwórz kontenery na nowo i prawidłowo ustaw wartości przejściowe.

Źródło: https://phpsos.de/pl/php2shell/docker-container-patchen/  
Stan: 25.10.2026  
Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6

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

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

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:

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

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

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

```bash
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](https://phpsos.de/pl/server/kubernetes/). Dla obrazów FrankenPHP obowiązuje to samo postępowanie; wskazówki o trybie pracy znajdą Państwo na stronie [Zabezpieczanie FrankenPHP](https://phpsos.de/pl/server/frankenphp/).

> **Ważne:**
> Proszę nie zapomnieć o kontenerach pobocznych: workery cron i kolejek, narzędzia administracyjne lub środowiska stagingowe często używają tego samego obrazu PHP, ale działają we własnych kontenerach. Każdy z nich musi zostać utworzony na nowo.

## Ś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`:

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

```bash
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](https://phpsos.de/pl/php2shell/php-fpm-neustart/).

## 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](https://phpsos.de/pl/leistungen/php-patch-service/) 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](https://phpsos.de/pl/leistungen/security-monitoring/) mamy na oku stany obrazów i podejrzane zachowanie kontenerów.


## Częste pytania

**Czy docker restart po aktualizacji wystarczy?**  
Nie. docker restart uruchamia kontener ponownie z tym samym, starym obrazem. Muszą Państwo zbudować lub pobrać nowy obraz i utworzyć z niego kontener na nowo, na przykład poleceniem docker compose up -d --force-recreate.

**Czy oficjalny obraz PHP zawiera już naprawioną wersję?**  
Najlepiej sprawdzić to bezpośrednio: pobrać obraz na nowo i uruchomić w nim php -v. Oczekiwane są 8.5.12, 8.4.27, 8.3.36 lub 8.2.35. Jeśli obraz pokazuje starszy numer, nie jest jeszcze zaktualizowany lub pochodzi z pamięci podręcznej.

**Czy PHP w kontenerze jest mniej zagrożone niż na hoście?**  
Sama luka działa w kontenerze tak samo. Dobrze zbudowany kontener może ograniczyć skutki włamania, na przykład przez użytkownika bez uprawnień root i system plików chroniony przed zapisem. Poprawki to jednak nie zastępuje.

## Źródła

- [php.net: komunikaty o bezpieczeństwie](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)