In breve: la vulnerabilità PHP2Shell consiste in due errori critici in PHP, la base della maggior parte dei siti web e degli shop online. Attraverso di essi gli aggressori possono eseguire codice dannoso sui server web senza password. Il BSI (l'Ufficio federale tedesco per la sicurezza informatica) avvisa con il livello arancione e consiglia: aggiornare subito, altrimenti scollegare temporaneamente dalla rete i server interessati. Per la direzione oggi significa: chiarire la responsabilità, esigere aggiornamento e prova, decidere su uno spegnimento e documentare tutto.
La situazione in tre frasi
Il 21 ottobre 2026 il progetto PHP ha pubblicato aggiornamenti per due vulnerabilità critiche, note con il nome PHP2Shell. È interessato PHP stesso, non un prodotto specifico, quindi potenzialmente ogni sito web, ogni shop e ogni portale che gira con PHP. Il BSI ha proclamato il livello di allerta 3 / arancione, le società di sicurezza riferiscono di tentativi di attacco, attacchi riusciti su larga scala confermati erano, secondo il BSI, inizialmente non noti.
Autorità come il BKA (la polizia criminale federale tedesca) e diverse città hanno spento i propri siti web in via precauzionale, secondo i rapporti dei media. È stata prudenza, non il segno di un attacco.
Che cosa significa la vulnerabilità PHP per direzione e azienda
La domanda non è se Lei usi PHP. Quasi ogni azienda lo fa da qualche parte: sito web, shop, portale candidati, area clienti, intranet, sistema di ticket, microsito di un'agenzia. La domanda è se questi sistemi siano aggiornati e chi ne sia responsabile.
Se un attacco riesce, nel peggiore dei casi l'aggressore può prendere il controllo del server. Possibili conseguenze sono fuga di dati, contenuti manipolati, reindirizzamenti a siti truffa, indisponibilità dello shop o abuso del server per altri attacchi. Se possono essere coinvolti dati personali, si aggiungono obblighi di notifica; il termine ai sensi dell'art. 33 GDPR è di norma 72 ore. I dettagli sono in Obbligo di notifica GDPR. Questa non è consulenza legale.
Quali costi si sostengono tipicamente nel caso grave lo inquadra l'articolo Voci di costo di un hack.
Dove PHP viene spesso trascurato nelle aziende
Il sito web principale ce l'hanno sott'occhio la maggior parte. Si trascurano piuttosto i sistemi ai margini: il portale candidati di un fornitore esterno, la landing page di una campagna passata, un'area partner per i rivenditori, il sistema di ticket del supporto, un cloud di file su server proprio o l'interfaccia web di un archivio di rete. Anche i sistemi di test delle agenzie sono spesso raggiungibili pubblicamente e girano sullo stesso server del vero sito.
Per la direzione la lezione è semplice: la domanda all'IT non è «Il nostro sito è aggiornato?», ma «Tutti i nostri sistemi con PHP sono aggiornati, compresi quelli dei fornitori di servizi?». La differenza tra le due domande è spesso proprio il punto in cui un attacco riesce.
Che cosa la situazione non è
Altrettanto importante è il ridimensionamento. PHP2Shell non è un motivo per un attivismo che disturbi l'attività più del necessario. Chi ha applicato la patch in modo documentato, ha riavviato tutti i processi PHP e non trova anomalie nella verifica può tornare all'esercizio ordinario. Uno spegnimento temporaneo è un'opzione per i casi non chiariti, non un obbligo per tutti.
Cinque domande al Suo IT o al Suo fornitore di servizi
Queste domande può porle oggi. Le risposte dovrebbero arrivare per iscritto.
- Quali dei nostri sistemi girano con PHP? Un elenco con indirizzo, scopo e gestore.
- Ogni sistema è aggiornato? Versione corretta 8.5.12, 8.4.27, 8.3.36 o 8.2.35, oppure un backport confermato dal fornitore.
- Sono stati riavviati tutti i processi PHP? Senza riavvio l'aggiornamento non ha effetto.
- Che ne è dei sistemi con PHP 8.1 o precedente? Per questi non esistono aggiornamenti ufficiali. Qual è il piano?
- È stato verificato se prima dell'aggiornamento sia successo qualcosa? Log conservati dal 20 ottobre, tracce cercate?
Se il Suo sito è presso un hoster, aiuta una richiesta formale. Un modello è offerto dalla guida Richiedere la conferma dell'aggiornamento PHP all'hoster.
Le decisioni che dovrebbero essere prese oggi
| Decisione | Opzioni | Base |
|---|---|---|
| Chi guida? | una persona responsabile interna, un partner esterno | la responsabilità deve essere univoca |
| Sistemi non aggiornati | aggiornare subito, misure transitorie, spegnere temporaneamente | raccomandazione del BSI, situazione dei dati, rilevanza per il fatturato |
| Verifica delle tracce | interna, esterna, solo in caso di anomalie | esigenza di protezione dei dati sul server |
| Comunicazione | informare internamente, preparare i clienti, attendere | situazione dopo la verifica |
| Sistemi obsoleti | pianificare la migrazione, isolare, spegnere | PHP 8.1 e precedenti senza aggiornamenti ufficiali |
Annoti chi ha deciso che cosa, quando e su quale base informativa. Basta una breve nota datata. A posteriori vale spesso più, verso assicuratori, clienti o organi di vigilanza, di qualsiasi spiegazione successiva.
Perché questa documentazione sia importante per la direzione lo spiega la pagina Responsabilità della direzione per le vulnerabilità IT. Queste sono informazioni generali e non consulenza legale.
Cosa non dovrebbe credere
Tre affermazioni gli amministratori le sentono spesso in questo periodo, e tutte e tre sono false:
- «Abbiamo aggiornato WordPress, quindi siamo al sicuro.» La vulnerabilità sta in PHP, non nel CMS. Un aggiornamento del CMS non la chiude.
- «Siamo troppo piccoli, nessuno ci attacca.» Gli attacchi sono automatizzati. Si cercano server vulnerabili, non nomi noti.
- «L'aggiornamento è installato, quindi la questione è chiusa.» Una patch non rimuove il software dannoso introdotto in precedenza e non dimostra che non sia successo nulla.
Come aiuta concretamente PHP SOS?
- Quadro per la direzione: redigiamo una breve panoramica dei Suoi sistemi PHP con stato e raccomandazione per ciascun sistema.
- Attuazione: applichiamo la patch, riavviamo o attiviamo misure transitorie dove un aggiornamento non è ancora possibile.
- Verifica: conserviamo i log e cerchiamo tracce di un attacco.
- Prova: riceve una documentazione che può usare internamente e verso terzi.
Lo svolgimento è descritto nel pronto intervento PHP2Shell.
Conclusione
PHP2Shell è una vulnerabilità tecnica con un compito di gestione. La tecnica la fanno gli specialisti. La direzione fa in modo che qualcuno sia responsabile, che le cinque domande trovino risposta e che le decisioni siano prese consapevolmente e documentate. Ci sta in una mattinata, se si comincia oggi.
Domande frequenti
La direzione deve occuparsi personalmente di PHP2Shell?
Non dell'attuazione tecnica, ma della guida sì. La direzione dovrebbe assicurarsi che le responsabilità siano chiare, che la raccomandazione del BSI venga attuata e che decisioni come uno spegnimento temporaneo siano prese consapevolmente e documentate.
Come spiego la vulnerabilità in una frase?
In PHP, il software su cui girano la maggior parte dei siti web e degli shop, ci sono due errori critici attraverso i quali degli estranei, senza password, possono avviare programmi sul server; un aggiornamento è disponibile e va installato.
Quanto costa non fare nulla?
Non si può quantificare in modo generico. Le possibili conseguenze di un attacco riuscito sono tempi di fermo, fuga di dati, obblighi di notifica, costi di bonifica e di analisi forense e perdita di fiducia dei clienti. Un aggiornamento con verifica è di norma molto meno oneroso.
Basta che se ne occupi l'hoster?
Nello shared hosting di norma è l'hoster a installare l'aggiornamento. Se lo faccia confermare per iscritto, compreso il riavvio dei processi PHP. La conferma non risponde alla domanda se prima dell'aggiornamento sia successo qualcosa; per questo serve una verifica del sito.