In breve: se mettere offline un sito a causa della falla PHP dipende da una domanda: PHP su quel server gira dimostrabilmente su una versione corretta e tutti i processi sono stati riavviati? In caso affermativo non serve alcuno spegnimento. Se l'aggiornamento non è possibile subito, il BSI (l'Ufficio federale tedesco per la sicurezza informatica) raccomanda di togliere temporaneamente il server web dalla rete. Attendere è giustificabile solo se il sistema non usa PHP, non è raggiungibile pubblicamente o il fornitore ha confermato per iscritto la patch.
La situazione in cui deve decidere
PHP2Shell comprende due falle in PHP stesso, CVE-2026-109618 e CVE-2026-109619, entrambe valutate con CVSS v4.0 9.2. Consentono l'esecuzione di codice dannoso da remoto senza autenticazione. Le versioni corrette sono disponibili dal 21/10/2026: 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Per PHP 8.1 e precedenti non esistono più aggiornamenti ufficiali.
Il BSI ha emesso il livello di allerta arancione e consiglia l'aggiornamento immediato, in alternativa lo spegnimento temporaneo. Secondo i media, la città di Magonza, uffici del governo regionale dell'Assia e altri enti pubblici hanno tolto i siti dalla rete in via precauzionale; la cancelleria di Stato dell'Assia non ha segnalato alcun attacco. Che cosa possano ricavarne le aziende è spiegato in Le autorità tolgono i siti dalla rete.
Per i responsabili in azienda la domanda è più pratica: che cosa facciamo oggi con il nostro shop, il nostro portale, il nostro sito aziendale?
Mettere offline il sito, applicare la patch o attendere: le tre opzioni a confronto
La tabella seguente mette le opzioni una accanto all'altra. Non sostituisce la valutazione del Suo caso singolo, ma rende visibile il bilanciamento.
| Criterio | Patch immediata | Spegnimento temporaneo | Attendere |
|---|---|---|---|
| Protezione da PHP2Shell | Alta, se patch e riavvio sono dimostrati | Alta per la durata dello spegnimento | Nessuna, finché non è aggiornato |
| Interruzione dell'attività | Breve, per aggiornamento e riavvio | Da ore a giorni | Nessuna |
| Presupposto | Versione PHP supportata, accesso, finestra di manutenzione | Decisione della direzione, pagina sostitutiva statica | Motivo provato per cui non c'è rischio |
| Impegno | Da basso a medio | Basso sul piano tecnico, alto su quello organizzativo | Basso, ma impegno di verifica per la prova |
| Caso tipico | Server con PHP da 8.2 a 8.5 | Sistema legacy con PHP 8.1 o precedente, stato poco chiaro | Sistema senza PHP o raggiungibile solo internamente |
| Rischio residuo | Un'intrusione precedente resta possibile | Un'intrusione precedente resta possibile | Pienamente sussistente |
Una riga merita attenzione: né la patch né lo spegnimento chiariscono se prima sia già successo qualcosa. Secondo i media, il primo tentativo di attacco osservato risale al 17/10/2026, quindi prima della patch. Uno sguardo alle possibili tracce fa perciò parte di ogni opzione.
In cinque domande verso la decisione
Affronti le domande in ordine. La prima risposta chiara porta di solito alla decisione.
- Sul sistema gira davvero PHP ed è raggiungibile da Internet? In caso contrario il sistema non è direttamente interessato da PHP2Shell. Documenti come lo ha accertato.
- Lo stato delle patch è dimostrato? Dimostrato significa: versione corretta o backport con numeri CVE nel changelog del pacchetto e riavvio di tutti i processi PHP. Non basta la visualizzazione della versione nel pannello. Come verificarlo è spiegato in Verificare correttamente versione PHP e livello di patch.
- L'aggiornamento si può installare nelle prossime ore? In caso affermativo: patch, riavvio, controllo. Fino ad allora possono aiutare misure provvisorie.
- Non è possibile, ad esempio a causa di PHP 8.1 o di accesso mancante? Allora secondo il BSI la via è lo spegnimento temporaneo. Le misure provvisorie secondo php.net riducono il rischio, ma non proteggono completamente; i dettagli sono in Misure immediate se non potete ancora applicare la patch.
- Ci sono segni di compromissione? Allora la questione non è più «patch o spegnimento», ma «gestire l'incidente». Spegnere, conservare le prove, non cancellare in fretta.
Se spegne: spegnere nel modo giusto
Uno spegnimento deve eliminare la superficie di attacco, non solo nascondere la home page. Una pagina di manutenzione che continua a essere generata da PHP non assolve questo scopo. Meglio una pagina HTML statica che il server web serve senza PHP, oppure un reindirizzamento verso un altro server.
Pensi a tutto ciò che dipende dallo stesso PHP: sottopagine, interfacce per app o gestionale, aree admin, callback di pagamento. Se è coinvolto uno shop, parli prima con fornitore di pagamenti e logistica. E informi collaboratori e clienti con parole chiare: il sito è offline in via precauzionale, il contatto avviene per telefono ed e-mail. È meglio del silenzio, che alimenta speculazioni.
Importante è anche la fine dello spegnimento. Stabilisca a quale condizione il sito torna online, ad esempio «PHP su versione corretta, riavvio controllato, prima verifica delle tracce senza riscontri». Così il freno d'emergenza diventa una procedura ordinata.
Spegnere non è una sconfitta. Secondo i media, diversi enti pubblici hanno fatto proprio questo, senza che vi fosse un attacco. Uno spegnimento precauzionale non significa automaticamente che un sito sia stato violato.
Quando non serve un fornitore
Non ogni decisione richiede aiuto esterno. Se il Suo sito si trova presso un hoster che conferma per iscritto stato delle patch e riavvio e non ci sono anomalie, con una breve documentazione è ben posizionato. Lo stesso vale se la Sua IT interna può applicare da sé la patch a un server con versione PHP supportata e padroneggia il controllo.
L'aiuto conviene quando girano sistemi con una vecchia versione di PHP, lo stato è poco chiaro, sono interessati più server o ci sono segni di un'intrusione.
Come aiuta concretamente PHP SOS?
- Chiariamo con Lei in breve tempo quali sistemi sono interessati e quale stato delle patch è dimostrato.
- Forniamo alla direzione una base decisionale su una pagina: opzioni, rischi, via consigliata.
- Attuiamo la via scelta, cioè patch con riavvio, misure provvisorie o uno spegnimento pulito con pagina sostitutiva statica, come parte della nostra assistenza immediata PHP2Shell.
- Verifichiamo le tracce dal 17/10/2026 e documentiamo il risultato.
Conclusione
La patch è il caso normale, lo spegnimento il giusto freno d'emergenza, l'attesa giustificabile solo con una prova. Chi risponde onestamente alle cinque domande e mette per iscritto la decisione agisce in linea con la raccomandazione del BSI e può mostrare poi perché.
Domande frequenti
Devo mettere offline il mio sito a causa di PHP2Shell?
No, se PHP gira già su una versione corretta e tutti i processi sono stati riavviati. Il BSI raccomanda lo spegnimento temporaneo per il caso in cui un aggiornamento immediato non sia possibile.
Che cosa costa di più, uno spegnimento: fatturato o rischio?
Si può rispondere solo nel caso singolo. Un fermo di alcune ore è di solito più pianificabile di un'intrusione le cui conseguenze e durata nessuno conosce. Metta per iscritto la valutazione, a prescindere da come va a finire.
Una pagina di manutenzione può girare sullo stesso server?
Sì, se viene servita come file statico senza PHP. Se la pagina di manutenzione continua a essere generata da PHP, la superficie di attacco resta.
Attendere è mai la scelta giusta?
Sì, in casi ben delimitati: quando sul sistema non gira PHP, quando non è raggiungibile da Internet o quando il fornitore ha confermato per iscritto patch e riavvio. Attendere senza tali prove non è un'opzione, ma un rischio.
Chi dovrebbe prendere la decisione?
La persona che risponde del rischio d'impresa, di regola amministratore o titolare. L'IT fornisce i fatti. Chi decide dovrebbe essere indicato in anticipo nel piano di emergenza.