In breve: in Kubernetes PHP sta nell'immagine del container, non nel cluster. Dopo PHP2Shell deve ricostruire ogni immagine PHP per Kubernetes con una versione di PHP corretta, distribuire di nuovo tutti i workload interessati e poi verificare lo stato in ogni pod in esecuzione. Un'immagine di base aggiornata nel registry da sola non cambia nulla per i pod in esecuzione.
Perché il cluster non si aggiorna da sé
Kubernetes gestisce i container, ma non si occupa del software al loro interno. Ogni pod gira con l'immagine da cui è stato avviato, finché non viene sostituito. Chi gestisce applicazioni PHP nel cluster è quindi responsabile delle immagini, anche se il cluster gira come servizio gestito presso un fornitore cloud. Il fornitore cura di norma il piano di controllo e i nodi, non le immagini dei clienti.
PHP2Shell comprende CVE-2026-109618 e CVE-2026-109619, entrambe con CVSS v4.0 9.2. Sono interessati, tra gli altri, PHP-FPM, Apache con mod_php e FrankenPHP, cioè le consuete modalità di esecuzione nelle immagini PHP. Sono corrette PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35.
Inventario: quale immagine PHP per Kubernetes gira e dove?
Cominci con un elenco di tutte le immagini nel cluster. I comandi seguenti leggono soltanto. I nomi di namespace, deployment e container sono esempi.
# Tutte le immagini di tutti i pod, raggruppate
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}'
# Digest dell'immagine effettivamente in esecuzione per ogni container
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .status.containerStatuses[*]}{.imageID}{" "}{end}{"\n"}{end}'
# Versione di PHP in un pod in esecuzione
kubectl exec -n shop deploy/web -c php -- php -v
Oltre ai deployment pensi anche a StatefulSet, DaemonSet, CronJob e init container. Nei cluster più grandi aiutano gli scanner di immagini, che cercano nelle immagini le CVE note. Per i pacchetti delle distribuzioni all'interno dell'immagine vale come ovunque: un backport può lasciare invariato il numero di versione, e in tal caso conta il changelog del pacchetto.
Ricostruire le immagini
Aggiorni per prima cosa l'immagine di base. Se usa immagini PHP ufficiali, scelga una variante con una versione di PHP corretta. Poi ricostruisca la Sua immagine, senza riprendere dalla cache il vecchio livello di base.
# Esempio: ricostruire l'immagine, scaricando di nuovo attivamente l'immagine di base
docker build --pull --no-cache -t registry.example.com/shop/web:2026-10-25 .
# Verificare la versione di PHP nella nuova immagine prima del rollout
docker run --rm registry.example.com/shop/web:2026-10-25 php -v
Non si affidi a tag come latest o alla semplice versione principale. Nel manifest referenzi possibilmente il digest della nuova immagine, in modo che sia chiaro quale stato viene distribuito. Se la distribuzione passa da GitOps o Helm, modifichi l'immagine lì, in modo che lo stato non venga reimpostato alla successiva sincronizzazione.
Rollout e controllo
Un nuovo rollout sostituisce gradualmente tutti i pod di un workload. Poi verifichi lo stato nei pod in esecuzione. Solo allora la patch è efficace, perché i nuovi file servono solo se i vecchi processi PHP non girano più.
# Rollout con la nuova immagine (nomi a titolo di esempio)
kubectl -n shop set image deploy/web php=registry.example.com/shop/web@sha256:<digest>
kubectl -n shop rollout status deploy/web
# Controllo: tutti i pod riavviati, nuovo digest attivo?
kubectl -n shop get pods -o wide
kubectl -n shop exec deploy/web -c php -- php -v
Se l'immagine è stata pubblicata di nuovo con lo stesso tag, kubectl rollout restart provoca un riavvio; i pod però scaricano di nuovo l'immagine solo se la imagePullPolicy lo prevede. Più sicuro è il passaggio a un nuovo digest.
Salvi i log prima di sostituire i pod. Con il vecchio pod scompaiono anche i suoi registri locali. Conservi i log del web server e dell'applicazione a partire dal 20/10/2026, idealmente in una piattaforma di log centralizzata.
Misure transitorie nel cluster
Se per la Sua versione di PHP non è ancora disponibile un'immagine corretta, php.net raccomanda misure transitorie senza protezione completa. Nel cluster imposti i limiti di memoria tramite i limiti di risorse dei container, che si basano sui cgroup. Ciò corrisponde alla raccomandazione di limitare la memoria tramite container o cgroup e non tramite RLIMIT_AS o RLIMIT_DATA.
; php.ini o pool FPM nell'immagine, ad es. incluso tramite ConfigMap
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
Con la funzione di upload, php.net indica post_max_size = 32M. Su PHP 8.5 si aggiunge fatal_error_backtraces=0. Dopo la modifica della configurazione serve un nuovo rollout. In aggiunta, le NetworkPolicy limitano le connessioni in uscita dei pod PHP e un ingress con regole di protezione può rendere più difficili i tentativi di attacco. Secondo Cloudflare, tuttavia, regole basate soltanto sui dati della richiesta non bastano.
Attrezzarsi meglio nel lungo periodo
Pianifichi ricostruzioni automatiche regolari di tutte le immagini PHP, un controllo delle immagini nella catena di build e policy che ammettano solo immagini firmate o verificate. Se i container PHP girano con un utente senza privilegi di root e con file system in sola lettura, il danno di un attacco riuscito diminuisce. Indicazioni per singoli container si trovano alla pagina Aggiornare PHP nei container Docker, per FrankenPHP alla pagina Mettere in sicurezza FrankenPHP.
In molti cluster le applicazioni PHP non girano da sole. Spesso ci sono container sidecar per logging o metriche, immagini di supporto per migrazioni di database e job che partono solo di notte. Anche le immagini di terzi, ad esempio per un wiki, un'interfaccia di monitoraggio o un sistema di ticket, possono contenere PHP senza che sia riconoscibile dal nome. Verifichi quindi non solo le Sue applicazioni, ma ogni immagine nel cluster. Per le immagini di terzi vale: attenda una versione aggiornata del produttore, controlli le sue indicazioni sulla versione di PHP contenuta e limiti la raggiungibilità finché non è disponibile. Se un simile sistema gira solo internamente, ciò riduce il rischio, ma non sostituisce l'aggiornamento.
Come aiuta concretamente PHP SOS?
- Rileviamo tutti i workload con PHP, le loro immagini e i digest e verifichiamo la versione di PHP nei pod in esecuzione.
- Tramite il servizio di patch PHP ricostruiamo le immagini, le distribuiamo e documentiamo lo stato di ogni workload.
- Salviamo i log prima della sostituzione e verifichiamo la presenza di tracce di un attacco.
- Con il monitoraggio della sicurezza e ricostruzioni automatizzate facciamo in modo che la prossima patch arrivi più rapidamente nel cluster.
Domande frequenti
Basta aggiornare l'immagine di base nel registry?
No. I pod in esecuzione continuano a usare l'immagine con cui sono stati avviati. Solo un nuovo rollout con l'immagine ricostruita sostituisce i pod. Poi verifichi la versione di PHP in ogni pod in esecuzione.
Perché referenziare le immagini tramite digest?
Un tag può puntare a stati diversi dell'immagine, a seconda di quando è stato scaricato. Un digest indica esattamente uno stato. Così sa con certezza quale codice gira in quale pod e i rollout diventano tracciabili.
E i CronJob e gli init container?
Anche questi possono contenere PHP e rientrano nell'inventario. I CronJob avviano a ogni esecuzione nuovi pod dal loro modello; aggiorni quindi l'immagine nel modello. Gli init container girano all'avvio di ogni pod.
Una NetworkPolicy protegge da PHP2Shell?
Non chiude la vulnerabilità, ma può limitare il danno. Chi restringe le connessioni in uscita dei pod PHP rende più difficili il caricamento di codice dannoso e i movimenti laterali nel cluster.