In breve: chi vuole che la vulnerabilità PHP2Shell sia chiusa oggi stesso ha bisogno di quattro cose: l'aggiornamento giusto, il riavvio di tutti i processi PHP, la verifica di eventuale codice dannoso già introdotto e una prova. È stato colpito? Ci chiami. La aiutiamo. Ce ne occupiamo da remoto, dal primo messaggio.
Ora non cancelli nulla e non reinstalli nulla. Anche con la patch vale: prima salvare, poi modificare. Se qualcosa è già entrato, ci serve lo stato di file e log. Segnali l'emergenza: chiariremo con Lei la sequenza.
Perché la vulnerabilità non può aspettare
Le due vulnerabilità CVE-2026-109618 e CVE-2026-109619 si trovano in PHP stesso e consentono di eseguire codice dannoso da remoto senza autenticazione. Il BSI (l'Ufficio federale tedesco per la sicurezza informatica) ha dichiarato il livello di allerta 3 (arancione) e raccomanda l'aggiornamento immediato. Se non è subito possibile, i web server devono essere temporaneamente scollegati dalla rete. Secondo i media, già prima della pubblicazione delle patch il 21/10/2026 c'erano stati i primi tentativi di attacco osservati. Cloudflare ha osservato dei tentativi e ha introdotto regole di protezione, ma avverte che le regole basate sui soli dati della richiesta non bastano.
Importante per i gestori: un aggiornamento del CMS non chiude la vulnerabilità di PHP. Anche WordPress.org, secondo i resoconti, non prevede un aggiornamento al riguardo, perché la vulnerabilità si trova nell'interprete. La si chiude solo a livello di PHP, cioè in ciò che il Suo server esegue davvero.
Che cosa fare subito
- Conoscere la versione di destinazione. Sono corrette PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. PHP 8.2 raggiunge la fine del supporto il 31/12/2026: lo metta in conto.
- Censire tutti i sistemi. Anche server di test, immagini di container e vecchi sistemi raggiungibili da Internet.
- Chiarire le responsabilità. Con i pacchetti di hosting e i server gestiti interviene il fornitore. Chieda per iscritto versione e riavvio.
- Conservare i log. A partire dal 20/10/2026, secondo la stampa specializzata.
- Concordare la finestra. Un riavvio interrompe brevemente le richieste in corso. Fissi un momento in cui qualcuno possa prendere decisioni.
- Non aspettare se è esposto. Se non si può applicare subito la patch, valuti con noi l'isolamento o le misure provvisorie.
In concreto, come aiuta PHP SOS?
- Quadro della situazione: rileviamo sistemi, versioni di PHP, modalità di esecuzione, hoster e raggiungibilità e stabiliamo la sequenza: prima i sistemi più esposti.
- Salvare e chiudere: salviamo lo stato attuale, installiamo l'aggiornamento o portiamo l'hosting a uno stato dimostrabilmente aggiornato e riavviamo tutti i processi. Con i container ricostruiamo l'immagine e la distribuiamo.
- Verificare e bonificare: poiché una patch non rimuove il codice dannoso, cerchiamo segni di una precedente intrusione e, se serve, bonifichiamo.
- Rafforzare e riferire: riceve una prova scritta per ogni sistema e raccomandazioni perché il prossimo aggiornamento sia più rapido. Il perimetro del servizio è descritto nel servizio di patch PHP.
Aggiornamento, riavvio, prova: che cosa conta
L'errore più frequente è un aggiornamento senza riavvio. Finché processi vecchi restano in esecuzione nella memoria, il codice vulnerabile rimane attivo, anche se i file sono nuovi. La guida è nella pagina Riavviare PHP-FPM e tutti i worker. Il secondo errore è fidarsi di ciò che viene visualizzato: distribuzioni e hoster forniscono spesso backport, e allora il numero di versione resta lo stesso. È affidabile il changelog del pacchetto con i numeri CVE, nella famiglia Debian con apt-get changelog <paket>.
Inoltre, secondo il manuale di PHP, dalle release di sicurezza vale la nuova direttiva memory_hard_limit_percent. Se una versione di PHP non la conosce, è interessata. Il test è breve:
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
Va eseguito per ogni versione e modalità di esecuzione, perché la riga di comando può usare una versione di PHP diversa da quella del web server. Alla fine registriamo il risultato, così potrà mostrarlo al Suo hoster, assicuratore o committente.
Se l'aggiornamento non è subito possibile
Ci sono ragioni per cui un aggiornamento oggi non è fattibile: un'applicazione vecchia che non gira sulle versioni più recenti di PHP, un hoster senza autorizzazione, un'immagine di container in una pipeline fissa. Per questi casi php.net indica misure provvisorie che non sono espressamente una protezione completa: impostare memory_limit=-1 in modo che le applicazioni non possano sovrascriverlo, limitare post_max_size, session.upload_progress.enabled=0 e, su PHP 8.5, fatal_error_backtraces=0, ciascuna con riavvio. A queste si aggiungono regole di protezione al perimetro, che non sostituiscono un aggiornamento. Un consiglio che circola, bloccare tutte le richieste con PHPSESSID, viene espressamente respinto dagli autori specializzati.
Quali misure si adattino al Suo sistema e che cosa possano rompere lo discutiamo prima. Maggiori informazioni nella pagina Misure immediate se non può ancora applicare la patch e sul tema WAF e virtual patching. Per PHP 8.1 e precedenti vale una situazione a sé, descritta in PHP 8.1 e precedenti: che cosa vale ora.
Che cosa dovrebbe inviarci
- Elenco dei server e degli hoster, se disponibile
- Output di
php -vper ogni sistema e indicazione della modalità di esecuzione - Indicazione se sono in uso container, Plesk, cPanel o un'offerta gestita
- Finestra temporale desiderata e persona di riferimento per i riavvii
- Segnalazioni di anomalie dal 17/10/2026
Perché PHP SOS
Lavoriamo Made in Germany e da oltre 25 anni, con la nostra rete di partner di professionisti della cybersicurezza, ci specializziamo nella sicurezza informatica. Ha un unico interlocutore che accompagna l'aggiornamento, verifica il riavvio e fornisce la prova. Lavoriamo da remoto, senza trasferte, e documentiamo ogni passaggio. Non promettiamo miracoli: una patch chiude la vulnerabilità, ma non dimostra che prima non sia successo nulla, e glielo diciamo con chiarezza.
È stato colpito? Ci chiami. La aiutiamo.
Non lasci la vulnerabilità aperta più a lungo. Ci chiami o ci scriva su WhatsApp. Ce ne occupiamo dal primo messaggio e restiamo accanto a Lei finché l'incidente non è concluso e documentato. Segnali subito l'emergenza.
Domande frequenti
Posso chiudere da solo la vulnerabilità di PHP o mi serve aiuto?
Per un amministratore un aggiornamento è fattibile, ma soggetto a errori: deve valere per la versione che serve davvero le pagine e tutti i processi devono essere riavviati. Chi ha più server, immagini di container o un hoster con particolarità risparmia tempo ed errori con un supporto.
PHP va riavviato dopo l'aggiornamento?
Sì. I nuovi file da soli non bastano finché processi PHP vecchi restano in esecuzione nella memoria. Tutti i worker o processi vanno riavviati; con mod_php, il web server.
Che cosa fare se per la mia versione di PHP non c'è ancora un aggiornamento?
Per PHP 8.1 e precedenti il progetto PHP non rilascia più aggiornamenti ufficiali. Allora servono un backport del fornitore dimostrabilmente aggiornato, una migrazione a una versione ancora mantenuta o misure provvisorie, che però non offrono una protezione completa.
Basta impostare session.upload_progress.enabled su 0?
No. Secondo i resoconti degli esperti, l'impostazione da sola non chiude entrambe le vulnerabilità; l'aggiornamento di PHP resta obbligatorio. La imposti solo in php.ini, nel pool FPM o nella configurazione del server, non con ini_set() o .user.ini.
Come faccio a sapere che poi la vulnerabilità è davvero chiusa?
Con una prova sul sistema in funzione: versione o changelog del pacchetto, un test sulla nuova direttiva memory_hard_limit_percent e la conferma che tutti i processi sono stati riavviati dopo l'aggiornamento.