# Zakrpa za PHP u Docker kontejnerima

> Ažuriranje PHP Docker image-a protiv PHP2Shella: provjerite verziju u kontejneru, iznova izgradite image, stvorite kontejnere i ispravno postavite prijelazne vrijednosti.

Izvor: https://phpsos.de/hr/php2shell/docker-container-patchen/  
Stanje: 25.10.2026  
Pružatelj: PHP SOS, PHP hitna pomoć i sigurnost poslužitelja. Hitna pomoć putem WhatsAppa: https://wa.me/491736494914?text=Pozdrav%20PHP%20SOS%2C%20trebamo%20pomo%C4%87%20s%20na%C5%A1im%20PHP%20poslu%C5%BEiteljem.%20Tvrtka%3A%20%E2%80%A6%20Web-stranica%3A%20%E2%80%A6

**Ukratko:** Ažuriranje PHP Docker image-a protiv PHP2Shella je obveza i ne događa se samo od sebe. Morate iznova izgraditi ili povući image s ispravljenom verzijom PHP-a, iz njega iznova stvoriti svaki kontejner i provjeriti da u pokrenutom kontejneru radi 8.5.12, 8.4.27, 8.3.36 ili 8.2.35. Jednostavno ponovno pokretanje kontejnera nije dovoljno.

## Zašto kontejneri nisu automatski sigurni

Docker image je zamrznuti presjek stanja. PHP u njemu ostaje na stanju koje je imao pri izgradnji, čak i ako su na hostu odavno instalirana ažuriranja. Ažuriranje paketa na host sustavu ne mijenja ništa na PHP-u u kontejneru.

Tome se pridodaju tipične zamke: image-i izgrađeni prije mjeseci i od tada nedirnuti, osnovni image-i s fiksnom oznakom poput `php:8.3.35-fpm`, lokalne predmemorije koje pri izgradnji ponovno koriste stari osnovni image i kontejneri koji su doduše ponovno pokrenuti, ali nikad iznova stvoreni. Pogođeni su svi načini rada uobičajeni u kontejnerima: PHP-FPM, Apache s mod_php i FrankenPHP.

Tome se pridodaje i pitanje odgovornosti. U mnogim tvrtkama agencija ili programer jednom je izgradio image, a njime upravlja interni IT ili pružatelj hostinga. Tada se nitko ne osjeća odgovornim za stanje PHP-a u image-u. Zato prvo razjasnite tko gradi image, gdje se nalazi Dockerfile i tko smije postavljati nove image-e.

## Provjera verzije PHP-a u kontejneru

Provjerite pokrenuti kontejner, a ne samo Dockerfile. Naredbe su isključivo čitajuće.

```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}}"
```

Ako image koristi pakete distribucije umjesto službenih PHP izgradnji, provjerite stanje paketa u kontejneru. Nazivi paketa razlikuju se po osnovnoj distribuciji:

```bash
docker exec <container> sh -c "apt policy php8.3-fpm 2>/dev/null || apk info -v 2>/dev/null | grep php"
```

Kod paketa distribucije može biti ugrađen backport iako broj verzije ostaje star. Tada vrijedi changelog paketa. Službeni PHP image-i, naprotiv, najčešće donose samostalno kompilirani PHP; tamo je broj verzije iz `php -v` mjerodavna vrijednost. Kako prepoznati backportove, opisuje [Ispravna provjera verzije PHP-a i stanja zakrpe](https://phpsos.de/hr/php2shell/php-version-pruefen/).

## Ažuriranje PHP Docker image-a: iznova izgraditi i postaviti

**Vlastiti image na osnovi PHP image-a:** iznova povucite osnovni image i izgradite bez predmemorije.

```bash
docker build --pull --no-cache -t meine-app:2026-10-25 .
docker run --rm meine-app:2026-10-25 php -v      # provjeriti verziju prije uvođenja
```

**S Docker Composeom:** povucite odnosno izgradite image-e i iznova stvorite kontejnere.

```bash
docker compose pull
docker compose build --pull --no-cache
docker compose up -d --force-recreate
```

Nakon toga ponovno provjerite naredbom `docker exec <container> php -v` radi li nova verzija. Ako kontejner u Dockerfileu ima fiksnu oznaku verzije, primjerice `FROM php:8.3.35-fpm`, morate podići oznaku. Oznaka na granu poput `php:8.3-fpm` dobiva nova zakrpana stanja, ali samo ako iznova povučete.

Držite prethodni image spreman dok se nova verzija ne testira. U slučaju pogreške tako se možete vratiti bez dugog ispada aplikacije. Stari image ipak ponovno sadrži ranjivi PHP; povratak je stoga opravdan samo nakratko i uz privremene mjere.

Tko koristi Kubernetes, novi image postavlja putem deploymenta. Pojedinosti su na stranici [Zakrpa za PHP u Kubernetesu](https://phpsos.de/hr/server/kubernetes/). Za FrankenPHP image-e vrijedi isti postupak; napomene o načinu rada pronaći ćete na stranici [Osiguravanje FrankenPHP-a](https://phpsos.de/hr/server/frankenphp/).

> **Važno:**
> Ne zaboravite sporedne kontejnere: cron i queue workeri, administratorski alati ili staging okruženja često koriste isti PHP image, ali rade u zasebnim kontejnerima. Svaki od njih mora se iznova stvoriti.

## Privremene mjere u kontejneru

Ako ažuriranje još nije moguće, privremene mjere php.net-a vrijede i u kontejneru. One nisu potpuna zaštita. Ograničenje memorije pritom pripada kontejneru, jer php.net preporučuje ograničenje putem kontejnera ili cgroupa, a ne putem `RLIMIT_AS` ili `RLIMIT_DATA`:

```ini
; npr. kao datoteka u image-u: /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 ...         # ili u Composeu: deploy.resources.limits.memory
```

Vrijednost prilagodite svojoj aplikaciji. Pazite da aplikacija `memory_limit` ne može sama nadjačati; kod PHP-FPM-a za to vrijednosti postavite u poolu s `php_admin_value`. Nova konfiguracija djeluje tek kad je kontejner iznova stvoren ili ponovno pokrenut; pozadinu o ponovnom pokretanju pronaći ćete na stranici [Ponovno pokretanje PHP-FPM-a i svih workera](https://phpsos.de/hr/php2shell/php-fpm-neustart/).

## Da sljedeći put ide brže

- Image-e redovito i automatski iznova graditi, a ne samo pri promjenama koda.
- Koristiti osnovne image-e s oznakom grane i izgrađeno stanje verzionirati datumom ili digestom.
- Image-e prije postavljanja dati provjeriti na poznate ranjivosti i kontejnere pokretati bez root prava.
- Voditi inventar koji kontejneri koriste koji image.

## Kako PHP SOS konkretno pomaže?

- **Zabilježiti stanje:** Provjeravamo sve pokrenute kontejnere, njihove image-e i verzije PHP-a, i sporedne kontejnere i staging.
- **Iznova izgraditi i postaviti:** Putem [usluge PHP zakrpe](https://phpsos.de/hr/leistungen/php-patch-service/) gradimo image-e s ispravljenom verzijom i kontrolirano iznova stvaramo kontejnere.
- **Osigurati prijelaz,** gdje ažuriranje ovisi o aplikaciji: vrijednosti php.net-a, ograničenje memorije na kontejneru.
- **Trajno nadzirati:** Uz [sigurnosni nadzor](https://phpsos.de/hr/leistungen/security-monitoring/) držimo na oku stanja image-a i upadljivo ponašanje kontejnera.


## Česta pitanja

**Je li docker restart dovoljan nakon ažuriranja?**  
Ne. docker restart ponovno pokreće kontejner s istim, starim image-om. Morate izgraditi ili povući novi image i iz njega iznova stvoriti kontejner, primjerice naredbom docker compose up -d --force-recreate.

**Sadrži li službeni PHP image već ispravljenu verziju?**  
To najbolje provjerite izravno: iznova povucite image i u njemu pokrenite php -v. Očekuju se 8.5.12, 8.4.27, 8.3.36 ili 8.2.35. Ako image prikazuje stariji broj, još nije ažuriran ili potječe iz predmemorije.

**Je li PHP u kontejneru manje ugrožen nego na hostu?**  
Sama ranjivost u kontejneru djeluje jednako. Dobro izgrađen kontejner može ograničiti posljedice provale, primjerice korisnikom bez root prava i datotečnim sustavom zaštićenim od pisanja. Zakrpu to ne zamjenjuje.

## Izvori

- [php.net: sigurnosne objave](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)
