# Patch, spegnimento o attesa? Una guida alla decisione per la falla PHP

> Mettere offline il sito per la falla PHP? Una guida alla decisione tra patch, spegnimento e attesa, con criteri, procedura e limiti dichiarati.

Fonte: https://phpsos.de/it/blog/patchen-abschalten-abwarten/  
Stato: 25/10/2026  
Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6

**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](https://phpsos.de/it/blog/behoerden-webseiten-offline/).

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.

1. **Sul sistema gira davvero PHP ed è raggiungibile da Internet?** In caso contrario il sistema non è direttamente interessato da PHP2Shell. Documenti come lo ha accertato.
2. **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](https://phpsos.de/it/php2shell/php-version-pruefen/).
3. **L'aggiornamento si può installare nelle prossime ore?** In caso affermativo: patch, riavvio, controllo. Fino ad allora possono aiutare misure provvisorie.
4. **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](https://phpsos.de/it/php2shell/sofortmassnahmen-ohne-patch/).
5. **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.

> **Importante:**
> 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?

1. Chiariamo con Lei in breve tempo quali sistemi sono interessati e quale stato delle patch è dimostrato.
2. Forniamo alla direzione una base decisionale su una pagina: opzioni, rischi, via consigliata.
3. 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](https://phpsos.de/it/leistungen/php2shell-soforthilfe/).
4. 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.

## Fonti

- [BSI: avviso su PHP2Shell](https://www.bsi.bund.de/)
- [php.net: segnalazioni di sicurezza](https://www.php.net/)
- [hessenschau: siti web di autorità in Assia spenti](https://www.hessenschau.de/panorama/sicherheitsluecke-zahlreiche-behoerden-webseiten-in-hessen-abgeschaltet-v2,sicherheitsprobleme-hacker-webseiten-100.html)
- [ZDFheute: falla di sicurezza in PHP](https://zdfheute.de/politik/sicherheitsluecke-php-webseiten-onlinedienste-cybersicherheit-bsi-100.html)