Il 20 ottobre 2026 sono circolati online, per un leak non voluto, i dettagli tecnici di due vulnerabilità critiche nel motore di PHP, il linguaggio che fa funzionare la maggior parte dei siti web del mondo. Il team di sicurezza di PHP ha confermato il problema e ha pubblicato la correzione il giorno successivo, mercoledì 21 ottobre, anticipando di un giorno il rilascio originariamente previsto proprio a causa della fuga di notizie. Per chi gestisce siti, e-commerce o gestionali basati su PHP, la finestra per intervenire è molto stretta.
Che cosa è successo davvero
Le due vulnerabilità, identificate come CVE-2026-109618 e CVE-2026-109619, hanno ricevuto un punteggio di gravità CVSS v4.0 pari a 9.2 su 10, nella fascia critica. Non si tratta di un problema in un plugin di WordPress o in un singolo tema: il difetto riguarda il cuore stesso di PHP, il motore che interpreta il codice di qualunque sito o applicazione scritta in questo linguaggio. Secondo quanto confermato dal team di sicurezza di PHP e dalla società di ricerca watchTowr, che ha riprodotto una delle due falle, un attaccante può eseguire codice sul server da remoto senza bisogno di credenziali: basta che il sito sia raggiungibile da internet.
Il soprannome ufficioso «PHP2Shell» deriva dal nome di uno strumento di exploit comparso in alcuni screenshot circolati sui social prima della divulgazione ufficiale. Il leak è avvenuto tramite un post pubblicato e poi rimosso in fretta, ma non abbastanza da impedire che i dettagli si diffondessero. Questo ha accorciato drasticamente i tempi di preparazione: normalmente un bug di questa gravità viene gestito con settimane di preavviso riservato ai soli addetti ai lavori; qui le aziende hanno avuto poche ore.
Perché riguarda anche le piccole e medie imprese
PHP fa girare la stragrande maggioranza dei siti aziendali, dei negozi online (molti basati su piattaforme come WooCommerce, Magento o Shopware) e di numerosi gestionali web usati da uffici commerciali, studi professionali e reparti amministrativi. Molte PMI non gestiscono direttamente il server: si appoggiano a un hosting condiviso, a un provider esterno o a un'agenzia che ha realizzato il sito anni fa e non lo segue più attivamente. È proprio in questi casi — server «dimenticati», mai aggiornati dopo il collaudo iniziale — che il rischio è più concreto, perché nessuno sta monitorando attivamente la versione di PHP in uso.
Un dettaglio tecnico importante, riportato da Sansec e da altre società di sicurezza che seguono il caso, riguarda l'attribuzione: il team PHP correggerà la falla solo sui rami di versione attualmente supportati, cioè PHP 8.2, 8.3, 8.4 e 8.5. Le versioni più vecchie — PHP 7, PHP 5 e anche le serie 8.0 e 8.1, che hanno già terminato il ciclo di supporto — non riceveranno una patch ufficiale, anche se il problema le riguarda. Chi gira ancora su queste versioni resta esposto a tempo indeterminato, a meno di aggiornare l'ambiente o isolarlo.
Come capire se la tua azienda è coinvolta
Prima di qualunque intervento tecnico serve un inventario chiaro. In pratica significa rispondere a queste domande:
- Quanti siti web, e-commerce, portali o gestionali aziendali usano PHP, inclusi quelli realizzati anni fa da fornitori diversi dall'attuale?
- Dove sono ospitati: su un server gestito internamente, su hosting condiviso, su un pannello di controllo (cPanel, Plesk) o su un'appliance di terze parti che include PHP senza che sia evidente a prima vista?
- Chi ha accesso e responsabilità su ciascuno di questi ambienti, e chi può autorizzare un aggiornamento?
- Quale versione di PHP è effettivamente installata su ognuno? Spesso la risposta non è scontata: basta chiedere conferma scritta al proprio fornitore di hosting o al webmaster.
Questo censimento, da solo, spesso rivela installazioni dimenticate che nessuno ricordava più di avere online. È un esercizio utile anche al di là dell'emergenza di oggi.
Cosa fare, in ordine
Una volta fatto l'inventario, l'ordine delle priorità è il seguente:
- Aggiornare subito alla versione corretta non appena il proprio fornitore di hosting conferma di averla applicata. Diverse fonti di sicurezza indicano come versioni corrette 8.2.35, 8.3.36, 8.4.27 e 8.5.12, ma i numeri esatti vanno sempre verificati sul sito ufficiale php.net o con il proprio fornitore, perché la situazione si è evoluta rapidamente nelle ultime ore.
- Chiedere conferma scritta al fornitore di hosting, non basarsi su rassicurazioni verbali. Molti hosting condivisi aggiornano PHP in automatico, ma non tutti, e non sempre sui piani più datati: una email o un ticket con la conferma dell'aggiornamento è una prova utile anche ai fini di eventuali verifiche successive.
- Verificare le installazioni ferme a PHP 7, PHP 5 o alle serie 8.0/8.1: per queste non arriverà una patch ufficiale. Le opzioni sono due: migrare l'applicazione a una versione supportata di PHP, oppure isolare temporaneamente il servizio (restringendo l'accesso, mettendolo dietro un firewall applicativo o una VPN) finché non si pianifica l'aggiornamento.
- Non aspettare il weekend: Sansec, società specializzata nella sicurezza degli e-commerce, prevede che i tentativi di attacco su larga scala possano iniziare pochi minuti dopo la pubblicazione della patch, perché gli aggressori analizzano il codice corretto per ricostruire la falla originale.
Segnali di compromissione da controllare dopo l'aggiornamento
Aggiornare non chiude automaticamente la questione se il server era già esposto prima della patch. Huntress, società di sicurezza che segue il caso, segnala come indicatore tipico di sfruttamento la presenza di processi «figli» sospetti avviati dal processo PHP del server web: in condizioni normali PHP non dovrebbe lanciare shell di sistema o interpreti di script non previsti dall'applicazione. Vale la pena, con l'aiuto di chi gestisce il server:
- controllare i log del server web nelle ore precedenti e successive al 21 ottobre, cercando richieste POST anomale o ripetute verso pagine di upload file;
- verificare la presenza di file nuovi o modificati di recente nelle cartelle del sito, in particolare script eseguibili in cartelle di upload che normalmente dovrebbero contenere solo immagini o documenti;
- conservare i log esistenti prima di qualunque pulizia, nel caso servano in un secondo momento per ricostruire quanto accaduto;
- cambiare le credenziali di accesso al pannello di amministrazione del sito e al database, per precauzione.
Al momento sia watchTowr sia Huntress non segnalano ancora sfruttamenti attivi confermati nei propri ambienti osservati, ma la previsione condivisa dagli analisti è che la situazione possa cambiare molto rapidamente una volta pubblicato il dettaglio tecnico completo della correzione.
Come può aiutare Hi-Keep
Hi-Keep può occuparsi concretamente di questo tipo di emergenza per le PMI che non dispongono di un reparto IT interno dedicato: dal censimento di tutti i siti, e-commerce e gestionali web dell'azienda (compresi quelli su hosting esterni), alla verifica della versione di PHP effettivamente in uso, fino al coordinamento con il fornitore di hosting per ottenere conferma scritta dell'aggiornamento. Dove necessario, Hi-Keep interviene anche per isolare temporaneamente le applicazioni ferme su versioni di PHP non più supportate e per controllare i segnali di compromissione sui server coinvolti.