PHP2Shell: il nostro perimetro, i salvataggi per terzi e gli hosting ricostruiti
Dopo le due vulnerabilità critiche di PHP del 21 ottobre 2026 abbiamo lavorato su tre fronti: la nostra infrastruttura, i server di terzi che ci hanno chiesto aiuto e i siti già violati da ricostruire. Cosa abbiamo fatto, passo per passo.
Tre fronti
Il 20 ottobre 2026 il team di sicurezza di PHP ha annunciato due vulnerabilità critiche nel cuore del linguaggio, poi ribattezzate PHP2Shell. Il giorno dopo è uscita la patch. Da quel momento abbiamo lavorato su tre fronti.
Il primo è il nostro perimetro: l'infrastruttura su cui gira il lavoro di Cloudfactory. Il secondo sono i salvataggi per terzi: server che non gestiamo, ma che qualcuno ci ha chiesto di mettere al sicuro. Il terzo è la ricostruzione di siti e hosting di altri, che erano già stati violati.
Non facciamo nomi e non diamo dettagli utili a un attaccante. Il metodo però è riutilizzabile: se gestite un server PHP, potete seguire gli stessi passi.
Cos'è PHP2Shell
PHP2Shell è il nome dato a due vulnerabilità, CVE-2026-109618 e CVE-2026-109619, entrambe con punteggio CVSS v4.0 di 9,2. Permettono l'esecuzione remota di codice: chi le sfrutta può far girare i propri comandi sul server, senza bisogno di credenziali (Fastly).
Il difetto sta nel modo in cui PHP gestisce gli errori di memoria esaurita e gli errori fatali. In certi casi la memoria resta in uno stato non valido e le richieste successive possono usarla. Il problema riguarda versioni di PHP che risalgono fino al 2004 (Laravel Forge).
| Ramo PHP | Versione corretta |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
| 8.1 e precedenti | Nessuna patch ufficiale: rami a fine vita |
Un dettaglio conta molto per chi usa Laravel Forge: gli aggiornamenti automatici di Ubuntu non toccano PHP, che arriva da un repository separato. L'aggiornamento va fatto a mano, server per server (Laravel Forge). Le mitigazioni temporanee e le versioni da installare sono spiegate nel nostro articolo del 22 ottobre.
1. Il nostro perimetro
Prima di aiutare altri abbiamo messo in ordine casa nostra. Il primo passo è stato un inventario in sola lettura, pronto prima delle 16:00 del 21 ottobre, ora della patch.
Per ogni server abbiamo raccolto sistema operativo, versioni di PHP installate, versione usata da ogni sito e servizi esposti. Poi abbiamo diviso tutto per priorità: prima PHP 8.1 e precedenti, senza patch; poi 8.2, a fine vita a dicembre; infine 8.3, 8.4 e 8.5.
Dove il sistema era supportato abbiamo aggiornato ogni versione di PHP installata, anche quelle inutilizzate. Poi abbiamo riavviato i processi di lunga durata e controllato che ogni sito rispondesse.
Dove il sistema era a fine vita, la patch non poteva arrivare. Lì abbiamo ridotto la superficie d'attacco:
- hardening di PHP secondo le indicazioni di CERT-EU;
- traffico web accettato solo dalla rete di Cloudflare;
- accesso SSH limitato agli strumenti di gestione;
- database e cache raggiungibili solo dal server stesso;
- Ubuntu Pro attivato per le patch del sistema operativo.
Abbiamo colto l'occasione per un hardening completo: siti raggiungibili soltanto attraverso Cloudflare, regole di protezione scritte direttamente in nginx, isolamento rafforzato tra i siti, password e chiavi rinnovate. Abbiamo eliminato tutti i plugin non indispensabili e, dove possibile, li abbiamo sostituiti con codice proprietario sviluppato da noi. Meno componenti di terze parti significa meno porte da sorvegliare.
La soluzione definitiva è un server nuovo, con sistema supportato, PHP 8.4 e MySQL 8.4. I siti si spostano uno alla volta, mantenendo lo stesso indirizzo IP e senza toccare i DNS.
2. Salvataggi per terzi
Nei giorni della vulnerabilità ci hanno chiesto aiuto anche per server che non gestiamo noi. Spesso non c'era un contratto in essere. Li abbiamo messi in sicurezza lo stesso, perché lasciarli scoperti era un rischio troppo alto.
Il caso tipico era un server rimasto su una versione di Ubuntu fuori supporto. Il repository di PHP non pubblicava più aggiornamenti per quel sistema, quindi la patch non poteva arrivare. Abbiamo applicato le stesse mitigazioni del nostro perimetro e separato i gruppi di sicurezza, così che server diversi non si fidassero più l'uno dell'altro.
In questi interventi abbiamo trovato:
| Cosa abbiamo trovato | Cosa abbiamo fatto |
|---|---|
| Server dimenticati, ancora accesi ed esposti | Snapshot del disco e spegnimento |
| Vecchie installazioni rimaste online dopo una migrazione | Segnalate a chi poteva spegnerle |
| Pagine di diagnostica e monitoraggio raggiungibili da Internet | Rimosse o chiuse |
| File caricati dagli utenti nei form scaricabili conoscendo l'indirizzo | Accesso diretto bloccato |
| Server di posta con versione datata | Aggiornato, con verifica del flusso delle email |
Su ogni server abbiamo eseguito uno script di verifica in sola lettura. Cerca file PHP recenti nelle cartelle di upload, file di WordPress alterati, amministratori sconosciuti, crash anomali e accessi sospetti. La cronologia si basa sulla data di cambio di stato dei file (ctime), che un attaccante non può falsificare.
Per ogni server abbiamo lasciato ai responsabili un riepilogo chiaro: cosa abbiamo fatto, quali rischi restano aperti e cosa serve per chiuderli. Niente dettagli tecnici sensibili, perché questi documenti vengono spesso inoltrati.
3. Ricostruire siti e hosting di altri
Alcuni dei siti che ci sono arrivati erano già stati violati, prima e indipendentemente da PHP2Shell. In questi casi aggiornare non serve: bisogna ricostruire.
Il caso più complesso era un hosting attaccato più volte, partendo da un plugin di gestione file vulnerabile. Una pulizia precedente era stata incompleta. Sono rimaste porte d'accesso nascoste, un plugin malevolo travestito da plugin di cache, amministratori finti e persino un'eccezione aggiunta alla configurazione SSH.
Altri siti erano stati colpiti da uno strumento automatico che sfrutta una vulnerabilità di WordPress di luglio 2026. Crea amministratori finti e cerca le credenziali dei sistemi di pagamento.
Per ricostruire abbiamo seguito sempre gli stessi passi:
- 01
Isolare e conservare le prove
Sito offline, processi fermati, accessi disattivati, copia del database e dell'elenco dei file.
- 02
Server nuovo da zero
Sistema operativo supportato, PHP 8.4, MySQL 8.4, porte aperte solo a Cloudflare e agli strumenti di gestione.
- 03
Solo sorgenti pulite
WordPress, temi e plugin scaricati di nuovo dalle fonti ufficiali. Il codice personalizzato è stato riletto a mano prima di rientrare.
- 04
Dati in quarantena
Il database passa da un'area separata e viene ripulito prima dell'import.
- 05
Pulizia degli utenti
In un caso abbiamo rimosso oltre 1.700 account falsi, usando più criteri insieme per non toccare i clienti veri.
- 06
Tutte le chiavi nuove
Password, chiavi di WordPress, credenziali di pagamento e di invio email.
- 07
Email ricostruita
Nuove credenziali con permessi minimi e record SPF, DKIM e DMARC corretti.
Per un e-commerce attivo il passaggio avviene con un'esportazione finale e un import incrementale, così non si perde nessun ordine.
Sito violato o server fuori supporto?
Se il vostro sito è stato compromesso, o il server su cui gira non riceve più aggiornamenti, possiamo aiutarvi a capire cosa è successo e a ripartire da una base pulita. Scriveteci e vi diciamo da dove partire.
Come abbiamo scritto questo articolo
In Cloudfactory usiamo l'intelligenza artificiale anche nel lavoro editoriale: ci aiuta a cercare e incrociare le fonti, a confrontare i dati, a impostare la struttura e a rifinire la lingua. Il sistema che usiamo è configurato da noi, con istruzioni, esempi e procedure costruiti sul nostro modo di scrivere. Il nostro team ha controllato ogni fonte, corretto il testo e approvato la versione pubblicata. Le valutazioni e le scelte sono di Cloudfactory, e ne rispondiamo noi.
Domande frequenti
Il mio sito WordPress è vulnerabile a PHP2Shell?
Lo è se il server usa una versione di PHP precedente a quelle corrette: 8.5.12, 8.4.27, 8.3.36 o 8.2.35. La versione di WordPress non c'entra: il problema è nel linguaggio.
Gli aggiornamenti automatici del server bastano?
Spesso no. Su molti server PHP arriva da un repository esterno a quello del sistema operativo, che gli aggiornamenti automatici non toccano.
Uso PHP 8.1 o 7.4. Cosa devo fare?
Passare a una versione supportata, almeno la 8.3. Nell'attesa, limitare l'accesso al server e applicare le mitigazioni indicate da CERT-EU.
Aggiornare PHP è sufficiente?
No. Bisogna riavviare i processi che usano PHP e verificare che nessuno sia entrato prima della patch.
Un sito statico o headless è esposto?
Un sito statico servito da una CDN non esegue PHP alle visite, quindi espone molto meno. Il pannello o le API che lo alimentano vanno comunque protetti.