php2shell: quanto in fretta gli hoster hanno chiuso la falla critica di PHP

Il 20 ottobre il progetto PHP ha annunciato per il giorno dopo una release di sicurezza critica, alle 14:00 UTC. Il 21 ottobre alle 16:00 (ora tedesca) erano disponibili PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Quello che succede dopo, per la maggior parte dei gestori di siti, non è più nelle proprie mani: chi usa uno shared hosting o un WordPress gestito resta attaccabile finché l'hoster non porta l'aggiornamento sui suoi server.

Gestiamo una serie di siti e applicazioni presso hoster diversi, nostri e di clienti. Per 27 di questi, quella sera abbiamo annotato quando è arrivata la nuova versione. Il risultato non è un test degli hoster, ma uno sguardo onesto su quanto la velocità possa variare.

Che cos'è php2shell

Secondo l'avviso di sicurezza del progetto PHP, dietro il nome ci sono due errori nella gestione della memoria tra una richiesta e l'altra. Con CVE-2026-109618, un'interruzione per memoria esaurita può lasciare dati in uno stato a metà, che PHP considera validi quando fa pulizia. Con CVE-2026-109619, lo stato interno di una richiesta resta in giro dopo che la sua memoria è già stata liberata, e la richiesta successiva nello stesso processo vi accede. Entrambe sono valutate CVSS 9.2 e, nel caso peggiore, permettono di eseguire codice proprio sul server.

È interessata ogni installazione di PHP che risponde a richieste web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Il rischio è massimo con mod_php. All'attaccante non serve alcun accesso, e l'attacco agisce prima ancora che WordPress o un plugin eseguano codice. Un plugin di sicurezza quindi non se ne accorge.

Quanto siano già in corso gli attacchi, le fonti lo valutano in modo diverso. Il Cyber Centre canadese ha segnalato il 21 e il 23 ottobre un proof of concept pubblico, ma nessuno sfruttamento accertato (bollettino AL26-026). Secondo Help Net Security, Amazon ha visto un tentativo di sfruttamento già il 17 ottobre, quattro giorni prima della pubblicazione.

La nostra misurazione: 27 sistemi, sette hoster e un server proprio

Abbiamo misurato dall'esterno e in sola lettura. La maggior parte degli hoster indica la versione di PHP nell'intestazione di risposta X-Powered-By. Su Hostinger e STRATO l'abbiamo interrogata ogni cinque minuti, su wp-login.php, perché quella pagina non viene mai dalla cache e PHP gira di sicuro. Su Raidboxes la versione era nel rapporto di sistema di WooCommerce. All-Inkl nasconde l'intestazione di risposta: lì un file di verifica di una sola riga ha mostrato la versione ed è stato cancellato subito dopo. Su united-domains e CheckDomain la versione non era leggibile dall'esterno.

Vanno fatte due precisazioni. Abbiamo misurato i nostri account, non un campione di tutti i server di un hoster. I grandi hoster spesso distribuiscono gli aggiornamenti server per server, quindi altri clienti possono essere stati serviti prima o dopo. E tra il 22 e il 26 ottobre su Hostinger non abbiamo misurato: per questo non sappiamo quando sia arrivata esattamente la 8.3.36.

Che cosa ne ricaviamo

La forbice è ampia e non si vede

Tra l'hoster più veloce e il più lento della nostra misurazione passano almeno 13 ore, un'intera notte. Dall'esterno non si capisce se il server di un sito sia già stato aggiornato. Chi non controlla di persona, non lo sa.

Un server proprio è veloce quanto il suo passaggio più lento

Sul nostro server gira un'applicazione in Docker, costruita sull'immagine PHP ufficiale. L'immagine con il numero 8.4.27 è uscita alle 17:45, la versione per i normali server Intel e AMD solo alle 18:47. La nostra ricostruzione è partita alle 18:51. Perché scaricasse davvero la nuova immagine di base e non riprendesse quella vecchia dalla cache, abbiamo dovuto modificare le istruzioni di build. Da allora ogni build prende l'immagine aggiornata.

Coolify, la piattaforma con cui gestiamo questo server, ha pubblicato il suo aggiornamento con la versione di PHP corretta già dodici minuti dopo il rilascio. Da noi però è arrivato solo con l'aggiornamento automatico notturno. I produttori veloci servono a poco se l'aggiornamento resta fermo sul tuo sistema.

I rami PHP vecchi non ricevono più nulla

Un sistema girava ancora su PHP 8.1. Per 8.1 e precedenti il progetto PHP non produce più release, ci sono solo correzioni minime nel codice sorgente per chi compila PHP da sé. Su uno shared hosting lì aiuta solo il passaggio a un ramo supportato. Un altro sistema era già indietro di cinque release prima della release di sicurezza, su 8.2.29 invece di 8.2.34. La buona notizia: la release di sicurezza lo ha trascinato in avanti, alla nuova misurazione girava su 8.2.35.

Senza PHP nessuna falla PHP

Il nostro sito principale hafenstudios.com non era interessato, perché è fatto di file HTML statici. Per un sito WordPress non è un'opzione, ma mostra perché le parti che non hanno bisogno di PHP non dovrebbero nemmeno eseguirne.

Come controlli la versione di PHP in WordPress

1. Nella bacheca: Strumenti → Salute del sito, scheda Informazioni, poi apri la sezione Server. Lì trovi la versione di PHP con cui WordPress sta girando.
2. Confrontala con la tabella: il tuo ramo è corretto dal numero indicato nella colonna «Corretto da».
3. Leggi bene i suffissi: dopo il numero può esserci una sigla dell'hoster, per esempio 8.3.36-nmm1. Conta il numero che la precede.

Un'eccezione: alcune distribuzioni Linux e alcuni hoster integrano la correzione nella propria versione senza cambiare il numero. Se hai un numero più vecchio e il tuo hoster dice di aver corretto, non è una contraddizione. In quel caso vale la sua conferma scritta.

Chi gestisce molti siti, da WordPress 6.9 può controllare anche tramite l'interfaccia REST, con una password per le applicazioni e in sola lettura: /wp-json/wp-abilities/v1/abilities/core/get-environment-info/run restituisce tra l'altro la versione di PHP.

Se il tuo hoster non ha ancora aggiornato

• Chiedi. Basta una frase al supporto: quando arriva PHP 8.x.y con la correzione per CVE-2026-109618 e CVE-2026-109619? La risposta ti mostra anche quanto sul serio lo prende il tuo hoster.
• Cambia ramo. Molti hoster offrono più versioni di PHP tra cui scegliere. Se un altro ramo è già corretto, dopo un breve test puoi passare a quello. Prima un backup, poi controlla a mano home page, login e moduli.
• Un firewall come ponte. Cloudflare ha attivato regole contro le vie d'attacco note, anche nel piano gratuito. Il progetto PHP scrive però chiaramente che non esiste un rimedio completo. Il firewall non sostituisce l'aggiornamento.
• Con server propri: aggiorna i pacchetti, ricostruisci i container con un'immagine di base aggiornata e poi riavvia tutti i processi PHP. Le impostazioni con cui il progetto PHP propone di coprire il tempo fino all'aggiornamento sono nell'avviso di sicurezza.

Il 23 ottobre è arrivata un'integrazione: una terza falla, CVE-2026-115560, riguarda l'indicatore di avanzamento degli upload nelle sessioni. Agisce solo se un'applicazione cambia a runtime il formato di salvataggio delle sue sessioni PHP. WordPress stesso non usa sessioni PHP, entrerebbero in gioco al massimo plugin che lo fanno. La correzione arriva con la prossima release regolare; nel frattempo il progetto PHP consiglia session.upload_progress.enabled=0. Su uno shared hosting può impostarlo solo l'hoster.

E se stai comunque facendo ordine: gli aggiornamenti di PHP sono solo metà del lavoro. Perché i plugin obsoleti sono il problema più grande e duraturo lo spieghiamo nel nostro articolo su come aggiornare i plugin di WordPress. Quanto siano vecchi, in parte, i requisiti minimi nella directory dei plugin lo mostra la nostra analisi: 8.131 plugin indicano ancora PHP 5 (in inglese).

Domande frequenti