Il 21 ottobre 2026 sarà ricordato da chi lavora nel web come una giornata anomala. Il team di PHP, il linguaggio su cui funziona la grande maggioranza dei siti (WordPress, PrestaShop, Joomla, Drupal, MediaWiki e moltissimi gestionali), ha pubblicato in via d’urgenza la correzione per due vulnerabilità critiche, CVE-2026-109618 e CVE-2026-109619, ormai note come php2shell. I dettagli erano trapelati il giorno prima, e l’annuncio ufficiale parlava di un rischio valutato 9,2 su 10: un estraneo, senza bisogno di credenziali, può arrivare a far eseguire codice suo sul server.
La reazione è stata eloquente. Per tutto il giorno servizi noti in tutto il mondo hanno scelto di spegnersi o di ridurre le funzioni in via precauzionale, in attesa di aggiornare: secondo le cronache Wikipedia, Asana, GOG, BambooHR e diversi siti di enti pubblici in Paesi Bassi, Finlandia, Danimarca e Francia. Perfino Wordfence, uno dei servizi di sicurezza più diffusi per WordPress, ha sospeso plugin, server e pannello per alcune ore «mentre implementiamo le mitigazioni». Non perché fossero stati violati, ma perché in casi come questo spegnere costa meno che rischiare: se si ferma anche chi di sicurezza si occupa per mestiere, la misura del problema è chiara. Secondo una stima del ricercatore Silas Cutler, i server potenzialmente esposti nel mondo potrebbero essere fino a 1,3 milioni.
Le correzioni (PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12) sono arrivate nel pomeriggio. Fine della storia? Purtroppo no. È qui che comincia la parte più lunga.
La corsa che parte nel momento in cui esce la patch
Una correzione di sicurezza è anche una mappa. Appena viene pubblicata, chi attacca la confronta con la versione precedente, capisce esattamente dove stava il difetto e costruisce un attacco automatico. La società Sansec aveva previsto i primi tentativi di massa entro 15 minuti dal rilascio; già in serata diverse aziende di sicurezza segnalavano tentativi di sfruttamento, anche se sugli attacchi andati a segno le fonti non concordano ancora.
Non è pessimismo, è storia recente:
- Drupalgeddon 2 (2018). Poche ore dopo la pubblicazione del codice dimostrativo, attacchi automatici installavano su migliaia di siti Drupal backdoor e programmi per estrarre criptovalute.
- Log4Shell (2021). A due ore dalla comparsa dei dettagli su GitHub era già in corso una scansione di massa di Internet; in cinque giorni Cloudflare registrava in media 400 tentativi di attacco al secondo.
- CVE-2024-4577, sempre PHP (2024). La correzione esce il 6 giugno; il 7 giugno compaiono dimostrazione tecnica e prime scansioni; l’8 giugno il gruppo ransomware TellYouThePass sta già cifrando server. Pochi giorni dopo si contavano circa mille macchine compromesse visibili in rete.
Lo schema è sempre lo stesso: tra la pubblicazione di una correzione e il primo attacco su larga scala passano ore, a volte minuti. Chi aggiorna il giorno dopo arriva, spesso, quando qualcuno è già entrato.
Il vero rischio: ciò che non verrà mai aggiornato
Ogni grande vulnerabilità lascia una lunga coda di sistemi che non verranno aggiornati presto, o non lo saranno mai: server dimenticati, siti di prova, installazioni che nessuno segue più. In questo caso anche tutti i siti che girano su versioni di PHP non più supportate (8.1 e precedenti), che non rientrano nel ciclo di correzioni ufficiali.
Questi sistemi non restano semplicemente «vulnerabili». Nelle settimane successive vengono trovati, presi e messi al lavoro. Un server compromesso diventa una risorsa nelle mani di qualcun altro:
- Un soldato di una botnet. Migliaia di server presi insieme formano una rete capace di attacchi DDoS che mettono in ginocchio servizi interi. Il 21 ottobre 2016, esattamente dieci anni fa, la botnet Mirai, fatta di dispositivi mai aggiornati, colpì il provider DNS Dyn e rese irraggiungibili per ore Twitter, Netflix, Reddit e GitHub.
- Una fabbrica di spam e phishing. Il server compromesso invia posta per conto di altri, finisce nelle liste nere, e con lui rischiano la reputazione anche gli indirizzi e i domini vicini.
- Una base per altri attacchi. Dalla macchina presa partono scansioni, tentativi di accesso, attacchi automatici ai moduli e ai carrelli di altri siti: proprio i flussi di traffico ostile da cui, poi, tutti devono difendersi.
- Una miniera per chi la controlla: criptovalute estratte con le risorse altrui, contenuti di spam iniettati nelle pagine per manipolare i motori di ricerca, dati dei clienti sottratti e rivenduti, fino al ricatto con il ransomware.
C’è poi un aspetto che si sottovaluta spesso: aggiornare non ripulisce. Se qualcuno è entrato prima della correzione, può aver lasciato una porta di servizio che resta aperta anche dopo l’aggiornamento. Il sito torna «aggiornato», ma non torna sicuro.
Per questo le conseguenze di una vulnerabilità come php2shell non si esauriscono oggi. Si sentiranno per mesi, sotto forma di traffico malevolo, tentativi di intrusione e attacchi provenienti proprio dai sistemi rimasti indietro. Chi ha aggiornato in tempo dovrà comunque difendersi da chi non l’ha fatto.
Velocità e preparazione: due cose diverse
Da questa giornata emergono due lezioni.
La prima è la velocità. Quando una correzione critica esce, la finestra utile si misura in ore: serve sapere in anticipo dove gira cosa, avere procedure pronte e poter aggiornare tutti i sistemi insieme, non uno alla volta.
La seconda, più difficile, è la preparazione alle conseguenze. Una patch si installa in un pomeriggio; prepararsi a ciò che arriva dopo (botnet, ondate di traffico ostile, tentativi di accesso, reputazione degli indirizzi da proteggere) richiede monitoraggio continuo, filtri che si adattano, copie di sicurezza verificate e la capacità di accorgersi in fretta che qualcosa non va.
Come ci siamo mossi
Nelle ore precedenti al rilascio abbiamo seguito l’evolversi della situazione e attivato su tutti i server una protezione temporanea che bloccava il tipo di richiesta usato dall’attacco. Appena le correzioni sono state disponibili abbiamo aggiornato PHP su tutta la nostra infrastruttura, in parallelo, nel giro di poche ore, rimuovendo poi le protezioni temporanee man mano che ogni server risultava corretto.
Resta una parte che non possiamo risolvere da soli: i siti che usano ancora versioni di PHP non più supportate. Per loro non esiste una correzione ufficiale, e stiamo contattando direttamente i clienti interessati per pianificare il passaggio a una versione supportata.
Cosa può fare chi ha un sito
- Sapere chi aggiorna PHP sul proprio server. Gli aggiornamenti automatici di WordPress, o di qualunque CMS, non toccano PHP: in una giornata come questa la correzione dipende da chi gestisce il server. Sui nostri server ce ne occupiamo noi; chi ha una VPS gestita in autonomia deve farlo da sé.
- Usare una versione di PHP supportata (oggi dalla 8.2 in su) e non rimandare il passaggio quando la propria esce dal supporto. Se dopo il cambio qualcosa non funziona, trovi i passi in Il sito non funziona dopo il cambio di versione PHP: cosa fare.
- Tenere aggiornati CMS, temi e plugin, ed eliminare quelli che non si usano: ogni componente in più è una porta in più.
- Avere copie di sicurezza recenti e verificate, conservate fuori dal server.
- Non ignorare gli avvisi del proprio fornitore: in giornate come questa, rispondere in fretta fa la differenza.
- Affidarsi a chi sorveglia l’infrastruttura in modo continuo: la sicurezza non è un intervento una tantum, è un processo che non si ferma dopo la patch.
La giornata di oggi ha mostrato quanto un singolo difetto possa scuotere l’intero web in poche ore. Le conseguenze più durature, però, le vedremo nelle prossime settimane, e dipenderanno da quanti sistemi saranno rimasti indietro.
Fonti
- How-To Geek: i siti andati offline per php2shell
- SecurityWeek: il rischio di sfruttamento di massa
- The Hacker News: le patch d’emergenza e i primi tentativi
- Wordfence: pagina di stato
- Safeguard: gli enti pubblici offline il 21 ottobre
- Sansec: php2shell
- BleepingComputer: Drupal sfruttato a poche ore dalla patch
- Analisi dell’impatto di Log4Shell (arXiv)
- Help Net Security: CVE-2024-4577 e il ransomware
- Censys: le vittime di CVE-2024-4577
Cerca tra le nostre guide: molti problemi hanno già una risposta passo passo.
Oppure apri un ticket: ti risponde subito Jarvis e, se serve, un tecnico.