In breve: l'immagine PHP ufficiale su Docker Hub esiste in molti tag che combinano versione, variante (ad esempio cli, fpm, apache) e sistema di base. Un tag è un puntatore che dopo le ricostruzioni si sposta su nuovi stati; solo il digest indica esattamente uno stato. Contro PHP2Shell serve un'immagine con PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35, verificata con php -v, e una ricostruzione delle Sue immagini su quella base.
Perché il tag da solo dice poco
Molti team scrivono nel loro Dockerfile una riga come FROM php:8.3-fpm e poi la dimenticano. Funziona finché nessuno chiede quale versione di PHP giri davvero. Da PHP2Shell lo chiedono tutti.
La risposta non sta nel Dockerfile. Un tag come 8.3-fpm al momento del pull punta allo stato più recente di quel ramo. Se l'immagine è stata scaricata prima del 21 ottobre e da allora non è stata rinnovata, contiene una versione vulnerabile anche se oggi il tag punta a uno stato corretto. Secondo le linee guida delle Docker Official Images, le immagini vengono ricostruite attivamente, anche per le correzioni di sicurezza. Il Suo stato locale non ne è però toccato.
L'intera procedura, dalla ricostruzione al container ricreato, la descrive Aggiornare PHP nei container Docker. Qui si tratta della domanda preliminare: qual è l'immagine giusta e come documentarne lo stato?
Tag delle immagini Docker PHP: come sono fatti
I tag si compongono di un massimo di tre parti. Docker Hub mostra esempi come php:8.2-cli, php:8.2-fpm-alpine o php:8.4.27-zts-alpine3.24.
| Componente | Esempio | Significato |
|---|---|---|
| Indicazione di versione | 8.4.27 oppure 8.4 |
la versione completa resta a questo stato, l'indicazione del ramo si sposta con le nuove patch |
| Variante | cli, fpm, apache, zts |
modalità di esecuzione di PHP nel container |
| Sistema di base | alpine3.24, bookworm, trixie |
versione di Alpine o Debian sottostante |
Le varianti non sono equivalenti per PHP2Shell. fpm esegue PHP-FPM, apache esegue PHP come modulo Apache, cioè mod_php. Il team PHP classifica questa modalità al livello più alto, perché lì è stato dimostrato un exploit prima ancora che giri del codice dell'applicazione. Di più in Perché mod_php è particolarmente esposto. La variante cli è pensata per compiti da riga di comando.
Anche il sistema di base ha conseguenze. Le immagini Alpine sono piccole, ma usano una libreria C diversa dalle immagini Debian; alcune estensioni o librerie precompilate lì si comportano diversamente. Non cambi quindi il sistema di base di passaggio con l'aggiornamento di sicurezza, ma resti inizialmente su ciò che la Sua applicazione conosce.
Importante per la comprensione: nell'immagine ufficiale PHP non proviene dai pacchetti della distribuzione di base. Docker Hub descrive che i sorgenti PHP si trovano nell'immagine e che le estensioni vengono integrate tramite script ausiliari come docker-php-ext-install. Un aggiornamento dei pacchetti del sistema di base nel Suo Dockerfile non cambia quindi nulla alla versione di PHP. Conta solo su quale stato dell'immagine ufficiale si basa.
Tag o digest: cosa cambia e quando
Un digest è una somma di controllo sul contenuto di un'immagine, scritta come sha256: con una lunga sequenza di caratteri. Cambia a ogni ricostruzione. Per questo è adatto come prova: chi conosce il digest sa esattamente quale stato sia in esecuzione.
Nella pratica si è rivelata valida una ripartizione:
- Nel Dockerfile usare il tag del ramo, ad esempio
php:8.4-fpm, perché una ricostruzione riceva automaticamente l'ultima patch di quel ramo. - Nel rollout usare il digest dell'immagine propria già costruita, perché sia chiaro cosa viene distribuito.
- Nella documentazione annotare entrambi: tag, digest e la versione verificata con
php -v.
Chi invece fissa un tag di versione completo come 8.3.35-fpm non riceve mai una patch automaticamente. Può essere voluto, ma richiede un processo che alzi il tag a ogni segnalazione di sicurezza.
PHP2Shell: verificare un'immagine prima dell'uso
I comandi seguenti scaricano un'immagine e leggono informazioni. Non modificano alcun container in esecuzione.
# Scaricare lo stato attuale del tag del ramo
docker pull php:8.4-fpm
# Quale versione di PHP c'è nell'immagine?
docker run --rm php:8.4-fpm php -v
# Mostrare il digest dell'immagine scaricata
docker image inspect php:8.4-fpm --format '{{index .RepoDigests 0}}'
# Interrogare digest e piattaforme direttamente nel registry
docker buildx imagetools inspect php:8.4-fpm
L'interrogazione con imagetools mostra, per le immagini multipiattaforma, un digest di livello superiore e sotto di esso, per ogni piattaforma, ad esempio linux/amd64 o linux/arm64, un digest proprio. Documenti il digest che i Suoi server scaricano davvero e tenga presente che i computer degli sviluppatori con un'altra architettura ricevono un altro digest di piattaforma.
Se php -v non mostra almeno la versione corretta del ramo, l'immagine è obsoleta o proviene da una cache intermedia. Verifichi allora se il Suo ambiente usa un mirror del registry che distribuisce vecchi stati.
Per PHP 8.1 e precedenti il progetto PHP non rilascia più versioni ufficiali. Un'immagine ufficiale di questi rami non può quindi contenere una regolare versione corretta. I tag non più curati restano, secondo le linee guida di Docker, scaricabili, ma non vengono più aggiornati.
Secondo Docker Hub l'immagine include php.ini-development e php.ini-production e raccomanda con forza la versione di produzione per l'esercizio produttivo. Le impostazioni proprie le metta come file in $PHP_INI_DIR/conf.d/, compresi i valori transitori di php.net.
Errori tipici nella scelta dell'immagine
- Variante per abitudine: si sceglie la variante apache perché parte facilmente, anche se sarebbe possibile fpm con un server web separato.
- Nessuna ricostruzione delle immagini proprie: l'immagine di base è aggiornata, l'immagine applicativa costruita su di essa no.
- Build multistadio trascurate: in un Dockerfile con più righe
FROMne viene adattata solo una. - Immagini secondarie dimenticate: worker, container cron e strumenti di amministrazione usano tag propri.
- Puntare solo su
latest: il tag non dice nulla su ramo e variante e può saltare in modo inatteso con un nuovo ramo principale.
Come automatizzare le ricostruzioni perché un'immagine obsoleta non giri a lungo lo descrive CI/CD: ricostruire automaticamente le immagini PHP. Le basi su PHP nei container le spiega PHP nei container.
Come aiuta concretamente PHP SOS?
- Verificare l'esistente: leggiamo quali tag, digest e versioni di PHP si trovano nelle Sue immagini e nei container in esecuzione.
- Valutare la variante: verifichiamo se mod_php sia necessario o se fpm con un server web separato riduca il rischio.
- Ricostruire e documentare: con il servizio di patch PHP ricostruiamo le immagini su una base corretta e documentiamo tag, digest e versione.
- Radicare il processo: configuriamo Dockerfile e rollout in modo che la prossima patch arrivi in modo pianificabile.
Domande frequenti
Qual è la differenza tra tag e digest?
Un tag come php:8.4-fpm è un nome che dopo ogni ricostruzione può puntare a un nuovo stato. Un digest è una somma di controllo che indica esattamente uno stato immutabile. Per le prove documentali e i rollout riproducibili il digest è l'indicazione più affidabile.
Quale tag contiene la correzione di PHP2Shell?
Sono corrette PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Un tag con il numero di versione completo mostra direttamente lo stato. Con tag più brevi come 8.4-fpm, dopo il pull verifichi con php -v quale versione sia effettivamente contenuta.
Esiste un'immagine ufficiale aggiornata per PHP 8.1?
Il progetto PHP per la 8.1 e precedenti non rilascia più versioni ufficiali. Un'immagine ufficiale di questi rami non può quindi contenere una regolare versione corretta. Pianifichi il passaggio a un ramo supportato.
La variante apache è più rischiosa di fpm?
La variante apache esegue PHP come modulo Apache, cioè mod_php. Il team PHP classifica questa modalità al livello più alto per PHP2Shell. Entrambe le varianti richiedono l'aggiornamento; con mod_php occorre particolare urgenza.