# Applicare la patch a PHP nei container Docker > Aggiornare l'immagine Docker PHP contro PHP2Shell: verificare la versione nel container, ricostruire l'immagine, ricreare i container e impostare i valori transitori. Fonte: https://phpsos.de/it/php2shell/docker-container-patchen/ Stato: 25/10/2026 Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6 **In breve:** un aggiornamento dell'immagine Docker PHP è obbligatorio contro PHP2Shell e non avviene da solo. Deve ricostruire o scaricare l'immagine con una versione di PHP corretta, ricreare da essa ogni container e verificare che nel container in esecuzione giri 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Un semplice riavvio del container non basta. ## Perché i container non sono sicuri automaticamente Un'immagine Docker è un'istantanea congelata. Il PHP al suo interno resta allo stato che aveva al momento della costruzione, anche se sull'host gli aggiornamenti sono stati installati da tempo. Un aggiornamento di pacchetti sul sistema host non cambia nulla del PHP nel container. A ciò si aggiungono le trappole tipiche: immagini costruite mesi fa e da allora mai toccate, immagini di base con tag fisso come `php:8.3.35-fpm`, cache locali che durante la costruzione riutilizzano la vecchia immagine di base e container che sono stati riavviati ma mai ricreati. Sono interessate tutte le modalità di esecuzione usuali nei container: PHP-FPM, Apache con mod_php e FrankenPHP. Si aggiunge una questione di responsabilità. In molte imprese un'agenzia o uno sviluppatore ha costruito l'immagine una volta, ma la gestisce l'IT interna o un hoster. Allora nessuno si sente responsabile dello stato di PHP nell'immagine. Chiarisca quindi per prima cosa chi costruisce l'immagine, dove si trova il Dockerfile e chi può distribuire nuove immagini. ## Verificare la versione di PHP nel container Verifichi il container in esecuzione, non solo il Dockerfile. I comandi sono di sola lettura. ```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}}" ``` Se l'immagine usa pacchetti di distribuzione anziché le build ufficiali di PHP, verifichi lo stato dei pacchetti nel container. I nomi dei pacchetti variano a seconda della distribuzione di base: ```bash docker exec sh -c "apt policy php8.3-fpm 2>/dev/null || apk info -v 2>/dev/null | grep php" ``` Con i pacchetti di distribuzione può essere stato applicato un backport anche se il numero di versione resta vecchio. In tal caso conta il changelog del pacchetto. Le immagini PHP ufficiali, invece, portano di norma PHP compilato da sé; lì il numero di versione di `php -v` è il valore determinante. Come riconoscere i backport è descritto alla pagina [Verificare correttamente versione e stato delle patch di PHP](https://phpsos.de/it/php2shell/php-version-pruefen/). ## Aggiornare l'immagine Docker PHP: ricostruire e distribuire **Immagine propria basata su un'immagine PHP:** scaricare di nuovo l'immagine di base e costruire senza cache. ```bash docker build --pull --no-cache -t meine-app:2026-10-25 . docker run --rm meine-app:2026-10-25 php -v # verificare la versione prima del rilascio ``` **Con Docker Compose:** scaricare o costruire le immagini e ricreare i container. ```bash docker compose pull docker compose build --pull --no-cache docker compose up -d --force-recreate ``` Poi verifichi di nuovo con `docker exec php -v` se giri la nuova versione. Se il container ha nel Dockerfile un tag di versione fisso, ad esempio `FROM php:8.3.35-fpm`, deve alzare il tag. Un tag sul ramo come `php:8.3-fpm` riceve i nuovi stati di patch, ma solo se scarica di nuovo. Tenga a disposizione l'immagine precedente finché la nuova versione non è stata testata. In caso di errore può così tornare indietro senza lasciare a lungo l'applicazione offline. La vecchia immagine contiene però di nuovo il PHP vulnerabile; un ritorno è quindi giustificabile solo per breve tempo e con le misure provvisorie. Chi usa Kubernetes distribuisce la nuova immagine tramite il Deployment. Dettagli alla pagina [Applicare la patch a PHP in Kubernetes](https://phpsos.de/it/server/kubernetes/). Per le immagini FrankenPHP vale la stessa procedura; indicazioni sulla modalità di esecuzione si trovano alla pagina [Mettere in sicurezza FrankenPHP](https://phpsos.de/it/server/frankenphp/). > **Importante:** > Non dimentichi i container accessori: worker di cron e di coda, strumenti di amministrazione o ambienti di staging usano spesso la stessa immagine PHP, ma girano in container propri. Ciascuno di essi va ricreato. ## Misure provvisorie nel container Se l'aggiornamento non è ancora possibile, le misure provvisorie di php.net valgono anche nel container. Non sono una protezione completa. Il limite di memoria va posto al container, perché php.net lo raccomanda tramite container o cgroup, non tramite `RLIMIT_AS` o `RLIMIT_DATA`: ```ini ; ad es. come file nell'immagine: /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 ... # oppure in Compose: deploy.resources.limits.memory ``` Il valore lo adatti alla Sua applicazione. Faccia attenzione che l'applicazione non possa sovrascrivere da sé `memory_limit`; con PHP-FPM imposti a tal fine i valori nel pool con `php_admin_value`. La nuova configurazione ha effetto solo quando il container è stato ricreato o riavviato; i retroscena sul riavvio sono alla pagina [Riavviare PHP-FPM e tutti i worker](https://phpsos.de/it/php2shell/php-fpm-neustart/). ## Perché la prossima volta sia più rapido - Ricostruire le immagini regolarmente e in automatico, non solo in caso di modifiche al codice. - Usare immagini di base con tag di ramo e versionare lo stato costruito con data o digest. - Far controllare le immagini alla ricerca di vulnerabilità note prima della distribuzione e gestire i container senza privilegi di root. - Tenere un inventario di quale container usi quale immagine. ## Come aiuta concretamente PHP SOS? - **Rilevare lo stato:** verifichiamo tutti i container in esecuzione, le loro immagini e le versioni di PHP, anche i container accessori e lo staging. - **Ricostruire e distribuire:** con il [servizio di patch PHP](https://phpsos.de/it/leistungen/php-patch-service/) costruiamo le immagini con la versione corretta e ricreiamo i container in modo controllato. - **Mettere in sicurezza la fase transitoria,** dove l'aggiornamento dipende dall'applicazione: valori di php.net, limite di memoria sul container. - **Sorvegliare in modo continuativo:** con il [security monitoring](https://phpsos.de/it/leistungen/security-monitoring/) teniamo d'occhio gli stati delle immagini e i comportamenti anomali dei container. ## Domande frequenti **Basta docker restart dopo l'aggiornamento?** No. docker restart riavvia il container con la stessa vecchia immagine. Deve costruire o scaricare la nuova immagine e ricreare da essa il container, ad esempio con docker compose up -d --force-recreate. **L'immagine PHP ufficiale contiene già la versione corretta?** Meglio verificarlo direttamente: scarichi di nuovo l'immagine e vi esegua php -v. Ci si aspetta 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Se l'immagine mostra un numero più vecchio, non è ancora aggiornata oppure proviene da una cache. **PHP nel container è meno esposto che sull'host?** La vulnerabilità in sé agisce nel container allo stesso modo. Un container ben costruito può limitare le conseguenze di un'intrusione, ad esempio con un utente senza privilegi di root e un file system protetto in scrittura. Non sostituisce la patch. ## Fonti - [php.net: bollettini di sicurezza](https://www.php.net/) - [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php) - [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)