Non era un errore in un sito. Era un errore nel motore che fa girare milioni di siti. E per sfruttarlo bastava una sola richiesta, senza password.
Il 21 ottobre 2026 il progetto PHP ha pubblicato in fretta e furia gli aggiornamenti per due vulnerabilità critiche, ribattezzate PHP2Shell: CVE-2026-109618 e CVE-2026-109619, entrambe con un punteggio di gravità di 9,2 su 10. Nel giro di poche ore sono arrivati i primi tentativi di attacco, e alcune organizzazioni hanno spento i loro servizi per precauzione finché non hanno aggiornato.
Perché è così grave
PHP è il linguaggio lato server più diffuso del web: ci girano WordPress, molti gestionali, i siti di scuole ed enti pubblici. Di solito una vulnerabilità sta nel codice di un'applicazione: un programmatore dimentica di controllare un dato e quel sito diventa attaccabile.
Qui invece il problema era nel runtime, cioè nell'interprete PHP stesso, quello che legge ed esegue i file .php. Quindi era esposto anche un sito scritto benissimo. In alcune configurazioni (soprattutto Apache con mod_php) bastava una sola richiesta HTTP, senza autenticazione, per far partire l'attacco prima ancora che venisse eseguito il codice del sito.
Che cos'è una RCE. Remote Code Execution, esecuzione di codice da remoto: l'attaccante riesce a far eseguire al server istruzioni scelte da lui. È il tipo di falla più pericoloso, perché da lì può leggere il database, rubare password e chiavi, modificare le pagine o usare il server per attaccarne altri. Il nome PHP2Shell dice proprio questo: da PHP a una shell, cioè a un terminale sul server.
Le due falle riguardano la gestione della memoria: una si attiva quando PHP esaurisce la memoria disponibile e la corrompe, l'altra sfrutta uno stato globale rimasto «sporco» tra una richiesta e l'altra. Secondo i ricercatori, un attaccante poteva anche leggere pezzi di memoria dei processi PHP, dove possono trovarsi password e token di altri utenti.
Trovata (e sfruttata) con l'aiuto dell'IA
Le falle sono state scoperte da ricercatori di Wiz e Calif, che raccontano di aver usato modelli di intelligenza artificiale sia per individuarle sia per trasformarle in un attacco funzionante. È il lato nuovo di questa storia: l'IA accorcia moltissimo il tempo tra «c'è un bug» e «ecco come sfruttarlo». Vale per chi difende, ma anche per chi attacca.
E infatti la corsa è stata strettissima:
- il 20 ottobre la notizia è trapelata in anticipo e un video dimostrativo è stato pubblicato per errore;
- Amazon ha registrato un tentativo di attacco già il 17 ottobre, quattro giorni prima dell'annuncio ufficiale, su un server-trappola (un honeypot);
- il 21 ottobre, giorno degli aggiornamenti, Cloudflare ha attivato regole di emergenza nel suo firewall e ha visto gli attaccanti cambiare i loro tentativi per aggirarle; secondo il suo amministratore delegato, i tentativi sono passati da decine di migliaia a milioni in poche ore;
- il 23 ottobre il CERT dell'Unione europea ha aggiunto all'allerta una terza falla collegata, CVE-2026-115560.
Che cosa bisognava fare
L'unica soluzione completa è aggiornare PHP alle versioni corrette: 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Le versioni 8.1 e precedenti non sono più supportate dal progetto PHP: per loro ci sono solo correzioni minime in codice sorgente, da compilare.
Chi ha un sito su un hosting condiviso (come la maggior parte dei siti scolastici e personali) dipende dal fornitore, che aggiorna PHP per tutti i suoi clienti. Chi gestisce un server proprio deve farlo da sé: con i pacchetti della distribuzione Linux, che spesso hanno ricevuto la correzione in anticipo, oppure compilando la nuova versione.
Che cosa insegna a chi programma
- La sicurezza non è solo il tuo codice. Puoi usare le query preparate, controllare ogni input e scrivere un'applicazione perfetta, ma se il software sotto di te ha una falla, sei esposto lo stesso. Per questo i server vanno aggiornati con regolarità.
- Le versioni vecchie sono un rischio. Un PHP non più supportato non riceve correzioni: la prossima falla resterà aperta per sempre.
- Non tenere segreti dove non serve. Password e chiavi in chiaro nella memoria o nei file sono il bottino di un attacco come questo. Meno ce ne sono, meno danni.
- Il tempo conta. Tra l'annuncio di una falla e i primi attacchi ormai passano ore, non settimane. Sapere quali versioni usano i propri server è il primo passo per difenderli.
Se stai studiando PHP e MySQL, questa storia è un buon promemoria: scrivere codice sicuro è necessario, ma la sicurezza di un sito è una catena, e conta anche l'anello più in basso.
Fonti: CERT-EU, avviso 2026-018; Help Net Security; The Hacker News; Fanpage.