Pe scurt: O actualizare a imaginii Docker PHP este obligatorie împotriva PHP2Shell și nu se întâmplă de la sine. Trebuie să reconstruiți sau să trageți imaginea cu o versiune PHP remediată, să recreați fiecare container din ea și să verificați că în containerul în execuție rulează 8.5.12, 8.4.27, 8.3.36 sau 8.2.35. O simplă repornire a containerului nu este suficientă.
De ce containerele nu sunt automat sigure
O imagine Docker este o fotografie înghețată. PHP-ul din ea rămâne la starea pe care o avea la construire, chiar dacă pe host s-au aplicat de mult actualizări. O actualizare de pachete pe sistemul host nu schimbă nimic la PHP-ul din container.
La acestea se adaugă capcane tipice: imagini construite acum luni și neatinse de atunci, imagini de bază cu tag fix, precum php:8.3.35-fpm, cache-uri locale care la construire refolosesc vechea imagine de bază și containere care au fost repornite, dar niciodată recreate. Sunt afectate toate modurile de operare uzuale în containere: PHP-FPM, Apache cu mod_php și FrankenPHP.
La acestea se adaugă o chestiune de responsabilitate. În multe companii, o agenție sau un dezvoltator a construit imaginea o singură dată, dar ea este operată de IT-ul intern sau de un furnizor de hosting. Atunci nimeni nu se simte responsabil pentru starea PHP din imagine. Clarificați, de aceea, mai întâi cine construiește imaginea, unde se află Dockerfile-ul și cine are voie să distribuie imagini noi.
Verificarea versiunii PHP din container
Verificați containerul în execuție, nu doar Dockerfile-ul. Comenzile sunt strict de citire.
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}}"
Dacă imaginea folosește pachete de distribuție în loc de build-uri PHP oficiale, verificați starea pachetelor din container. Numele pachetelor diferă în funcție de distribuția de bază:
docker exec <container> sh -c "apt policy php8.3-fpm 2>/dev/null || apk info -v 2>/dev/null | grep php"
La pachetele de distribuție poate fi aplicat un backport deși numărul versiunii rămâne vechi. Atunci contează changelogul pachetului. Imaginile PHP oficiale aduc în schimb PHP compilat de ele însele; acolo numărul versiunii din php -v este valoarea determinantă. Cum recunoașteți backporturile descrie Cum verificați corect versiunea PHP și starea patchului.
Actualizarea imaginii Docker PHP: reconstruire și distribuire
Imagine proprie bazată pe o imagine PHP: trageți din nou imaginea de bază și construiți fără cache.
docker build --pull --no-cache -t meine-app:2026-10-25 .
docker run --rm meine-app:2026-10-25 php -v # verificați versiunea înainte de distribuire
Cu Docker Compose: trageți, respectiv construiți imaginile și recreați containerele.
docker compose pull
docker compose build --pull --no-cache
docker compose up -d --force-recreate
Verificați apoi din nou cu docker exec <container> php -v dacă rulează noua versiune. Dacă containerul are în Dockerfile un tag fix de versiune, de exemplu FROM php:8.3.35-fpm, trebuie să ridicați tagul. Un tag pe ramură, precum php:8.3-fpm, primește noi stări de patch, dar numai dacă trageți din nou.
Păstrați imaginea anterioară la îndemână până când noua versiune este testată. În caz de eroare puteți reveni astfel, fără a lăsa aplicația offline mult timp. Vechea imagine conține însă din nou PHP vulnerabil; o cale de întoarcere este, de aceea, justificabilă doar pe scurt și cu măsurile provizorii.
Cine folosește Kubernetes distribuie noua imagine prin deployment. Detalii găsiți la Cum actualizați PHP în Kubernetes. Pentru imaginile FrankenPHP se aplică aceeași procedură; indicații despre modul de operare găsiți la Cum securizați FrankenPHP.
Nu uitați containerele secundare: workerii de cron și de coadă, uneltele de administrare sau mediile de staging folosesc adesea aceeași imagine PHP, dar rulează în containere proprii. Fiecare dintre ele trebuie recreat.
Măsuri provizorii în container
Dacă actualizarea nu este încă posibilă, măsurile provizorii de la php.net se aplică și în container. Ele nu sunt o protecție completă. Limita de memorie aparține aici containerului, deoarece php.net o recomandă prin container sau cgroup, nu prin RLIMIT_AS sau RLIMIT_DATA:
; de ex. ca fișier în imagine: /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 ... # sau în Compose: deploy.resources.limits.memory
Valoarea o adaptați aplicației dumneavoastră. Aveți grijă ca aplicația să nu poată suprascrie ea însăși memory_limit; la PHP-FPM setați pentru aceasta valorile în pool cu php_admin_value. Noua configurație acționează abia după ce containerul este recreat sau repornit; contextul legat de repornire îl găsiți la Cum reporniți PHP-FPM și toți workerii.
Pentru ca data viitoare să meargă mai repede
- Reconstruiți imaginile regulat și automat, nu doar la modificări de cod.
- Folosiți imagini de bază cu tag de ramură și versionați starea construită cu dată sau digest.
- Puneți imaginile la verificare pentru vulnerabilități cunoscute înainte de distribuire și operați containerele fără drepturi root.
- Țineți un inventar al containerelor care folosesc ce imagine.
Cum ajută PHP SOS concret?
- Preluarea inventarului: Verificăm toate containerele în execuție, imaginile lor și versiunile PHP, inclusiv containerele secundare și staging-ul.
- Reconstruire și distribuire: Prin serviciul de patch PHP construim imaginile cu versiunea remediată și recreăm containerele în mod controlat.
- Protejarea tranziției, acolo unde actualizarea depinde de aplicație: valorile de la php.net, limita de memorie la container.
- Supraveghere permanentă: Prin monitorizarea de securitate urmărim stările imaginilor și comportamentul neobișnuit al containerelor.
Întrebări frecvente
Este suficient docker restart după actualizare?
Nu. docker restart repornește containerul cu aceeași imagine, veche. Trebuie să construiți sau să trageți noua imagine și să recreați containerul din ea, de exemplu cu docker compose up -d --force-recreate.
Conține imaginea PHP oficială deja versiunea remediată?
Cel mai bine verificați direct: trageți din nou imaginea și rulați în ea php -v. Se așteaptă 8.5.12, 8.4.27, 8.3.36 sau 8.2.35. Dacă imaginea arată un număr mai vechi, nu este încă actualizată sau provine dintr-un cache.
Este PHP în container mai puțin expus decât pe host?
Vulnerabilitatea în sine acționează în container la fel. Un container bine construit poate limita consecințele unei intruziuni, de exemplu printr-un utilizator fără drepturi root și un sistem de fișiere protejat la scriere. Nu înlocuiește patchul.