# Popravljanje PHP v containerjih Docker

> Posodobitev slike PHP Docker proti PHP2Shell: preverite različico v containerju, znova zgradite sliko in ustvarite container iz nje. Zagon ne zadošča.

Vir: https://phpsos.de/sl/php2shell/docker-container-patchen/  
Stanje: 25.10.2026  
Ponudnik: PHP SOS, Nujna pomoč za PHP in varnost strežnikov. Takojšnja pomoč po WhatsAppu: https://wa.me/491736494914?text=Pozdravljeni%2C%20PHP%20SOS%2C%20potrebujemo%20pomo%C4%8D%20z%20na%C5%A1im%20stre%C5%BEnikom%20PHP.%20Podjetje%3A%20%E2%80%A6%20Spletna%20stran%3A%20%E2%80%A6

**Na kratko:** Posodobitev slike PHP Docker je proti PHP2Shell obvezna in se ne zgodi sama od sebe. Sliko z odpravljeno različico PHP morate znova zgraditi ali prenesti, vsak container iz nje ustvariti znova in preveriti, da v tekočem containerju teče 8.5.12, 8.4.27, 8.3.36 ali 8.2.35. Preprost ponovni zagon containerja ne zadošča.

## Zakaj containerji niso samodejno varni

Slika Docker je zamrznjen posnetek. PHP v njej ostane na stanju, ki ga je imel ob gradnji, tudi če so na gostitelju že zdavnaj nameščene posodobitve. Posodobitev paketov na gostiteljskem sistemu PHP v containerju ne spremeni.

Dodajo se tipične pasti: slike, zgrajene pred meseci in od takrat nedotaknjene, osnovne slike s fiksno oznako, kot je `php:8.3.35-fpm`, lokalni predpomnilniki, ki ob gradnji znova uporabijo staro osnovno sliko, in containerji, ki so bili sicer znova zagnani, a nikoli ustvarjeni znova. Prizadeti so vsi načini delovanja, ki so običajni v containerjih: PHP-FPM, Apache z mod_php in FrankenPHP.

Doda se še vprašanje odgovornosti. V številnih podjetjih je agencija ali razvijalec sliko enkrat zgradil, upravlja pa jo notranja IT ali ponudnik gostovanja. Takrat se nihče ne čuti odgovornega za stanje PHP v sliki. Zato najprej razjasnite, kdo sliko gradi, kje leži Dockerfile in kdo sme nameščati nove slike.

## Preverjanje različice PHP v containerju

Preverite tekoči container, ne samo Dockerfile. Ukazi so izključno bralni.

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

Če slika uporablja pakete distribucije namesto uradnih gradenj PHP, preverite stanje paketa v containerju. Imena paketov se po osnovni distribuciji razlikujejo:

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

Pri paketih distribucij je lahko backport nameščen, čeprav številka različice ostane stara. Takrat šteje dnevnik sprememb paketa. Uradne slike PHP pa PHP večinoma prinašajo sami prevedenega; tam je merodajna vrednost številka različice iz `php -v`. Kako prepoznate backporte, opisuje stran [Pravilno preverjanje različice PHP in stanja popravkov](https://phpsos.de/sl/php2shell/php-version-pruefen/).

## Posodobitev slike PHP Docker: zgraditi in namestiti

**Lastna slika na osnovi slike PHP:** osnovno sliko znova prenesti in zgraditi brez predpomnilnika.

```bash
docker build --pull --no-cache -t meine-app:2026-10-25 .
docker run --rm meine-app:2026-10-25 php -v      # pred uvedbo preveriti različico
```

**Z Docker Compose:** slike prenesti oziroma zgraditi in container ustvariti znova.

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

Nato z `docker exec <container> php -v` znova preverite, ali teče nova različica. Če ima container v Dockerfile fiksno oznako različice, na primer `FROM php:8.3.35-fpm`, morate oznako dvigniti. Oznaka na vejo, kot je `php:8.3-fpm`, prejema nova stanja popravkov, vendar samo, če sliko znova prenesete.

Prejšnjo sliko hranite pripravljeno, dokler nova različica ni preizkušena. Ob napaki lahko tako preklopite nazaj, ne da bi aplikacija dolgo ostala brez povezave. Stara slika pa znova vsebuje ranljiv PHP; pot nazaj je zato upravičena samo kratek čas in z vmesnimi ukrepi.

Kdor uporablja Kubernetes, novo sliko namesti prek deploymenta. Podrobnosti so na strani [Popravljanje PHP v Kubernetesu](https://phpsos.de/sl/server/kubernetes/). Za slike FrankenPHP velja enak postopek; napotke o načinu delovanja najdete na strani [Zavarovanje FrankenPHP](https://phpsos.de/sl/server/frankenphp/).

> **Pomembno:**
> Ne pozabite stranskih containerjev: cron in queue workerji, skrbniška orodja ali okolja staging pogosto uporabljajo isto sliko PHP, a tečejo v lastnih containerjih. Vsakega od njih je treba ustvariti znova.

## Vmesni ukrepi v containerju

Če posodobitev še ni mogoča, vmesni ukrepi php.net veljajo tudi v containerju. Niso popolna zaščita. Omejitev pomnilnika sodi pri tem na container, saj jo php.net priporoča prek containerja ali cgroup, ne prek `RLIMIT_AS` ali `RLIMIT_DATA`:

```ini
; npr. kot datoteka v sliki: /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 ...         # ali v Compose: deploy.resources.limits.memory
```

Vrednost prilagodite svoji aplikaciji. Pazite, da aplikacija `memory_limit` ne more sama prepisati; pri PHP-FPM zato vrednosti nastavite v poolu s `php_admin_value`. Nova konfiguracija deluje šele, ko je container ustvarjen znova ali znova zagnan; ozadje o ponovnem zagonu je na strani [Ponovni zagon PHP-FPM in vseh workerjev](https://phpsos.de/sl/php2shell/php-fpm-neustart/).

## Da bo naslednjič hitreje

- Slike redno in samodejno zgraditi znova, ne samo ob spremembah kode.
- Uporabljati osnovne slike z oznako veje ter zgrajeno stanje označiti z datumom ali digestom.
- Slike pred namestitvijo dati preveriti glede znanih ranljivosti in containerje upravljati brez pravic root.
- Voditi popis, kateri container uporablja katero sliko.

## Kako konkretno pomaga PHP SOS?

- **Zabeležiti stanje:** preverimo vse tekoče containerje, njihove slike in različice PHP, tudi stranske containerje in staging.
- **Zgraditi in namestiti:** prek [storitve popravljanja PHP](https://phpsos.de/sl/leistungen/php-patch-service/) zgradimo slike z odpravljeno različico in containerje nadzorovano ustvarimo znova.
- **Zavarovati prehod,** kjer je posodobitev odvisna od aplikacije: vrednosti php.net, omejitev pomnilnika na containerju.
- **Trajno nadzirati:** z [varnostnim nadzorom](https://phpsos.de/sl/leistungen/security-monitoring/) imamo v očeh stanja slik in sumljivo vedenje containerjev.


## Pogosta vprašanja

**Ali po posodobitvi zadošča docker restart?**  
Ne. docker restart container znova zažene z isto, staro sliko. Novo sliko morate zgraditi ali prenesti in container iz nje ustvariti znova, na primer z docker compose up -d --force-recreate.

**Ali uradna slika PHP že vsebuje odpravljeno različico?**  
To najbolje preverite neposredno: sliko znova prenesite in v njej zaženite php -v. Pričakovane so 8.5.12, 8.4.27, 8.3.36 ali 8.2.35. Če slika kaže starejšo številko, še ni posodobljena ali izvira iz predpomnilnika.

**Ali je PHP v containerju manj ogrožen kot na gostitelju?**  
Sama ranljivost deluje v containerju enako. Dobro zgrajen container lahko omeji posledice vdora, na primer z uporabnikom brez pravic root in datotečnim sistemom samo za branje. Popravka to ne nadomešča.

## Viri

- [php.net: varnostna obvestila](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)