# Cum actualizați PHP în containere Docker > Actualizarea imaginii Docker PHP împotriva PHP2Shell: verificați versiunea din container, reconstruiți imaginea și recreați containerul. Sursa: https://phpsos.de/ro/php2shell/docker-container-patchen/ Stadiu: 25.10.2026 Furnizor: PHP SOS, Asistență de urgență PHP și securitatea serverelor. Ajutor imediat pe WhatsApp: https://wa.me/491736494914?text=Bun%C4%83%20ziua%2C%20PHP%20SOS%2C%20avem%20nevoie%20de%20ajutor%20cu%20serverul%20nostru%20PHP.%20Firma%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6 **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. ```bash docker ps --format "table {{.Names}}\t{{.Image}}\t{{.CreatedAt}}" docker exec php -v docker exec php -i | grep -E "^PHP Version|Server API" docker image inspect --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ă: ```bash docker exec 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](https://phpsos.de/ro/php2shell/php-version-pruefen/). ## 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. ```bash 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. ```bash docker compose pull docker compose build --pull --no-cache docker compose up -d --force-recreate ``` Verificați apoi din nou cu `docker exec 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](https://phpsos.de/ro/server/kubernetes/). Pentru imaginile FrankenPHP se aplică aceeași procedură; indicații despre modul de operare găsiți la [Cum securizați FrankenPHP](https://phpsos.de/ro/server/frankenphp/). > **Important:** > 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`: ```ini ; 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 ``` ```bash 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](https://phpsos.de/ro/php2shell/php-fpm-neustart/). ## 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](https://phpsos.de/ro/leistungen/php-patch-service/) 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](https://phpsos.de/ro/leistungen/security-monitoring/) 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. ## Surse - [php.net: anunțuri de securitate](https://www.php.net/) - [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php) - [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)