In breve: la catena di fornitura di un sito web va dal progetto PHP, attraverso distribuzione e hoster, fino a CMS, plugin, agenzia e servizi integrati. Per la sicurezza IT conta ogni anello, perché una patch raggiunge il Suo sito solo quando tutti l'hanno trasmessa. Chi mette per iscritto la catena, stabilisce per ogni anello un responsabile e una prova e limita gli accessi, la rende affidabile.
Una patch e il suo lungo viaggio
Il 21/10/2026 alle 14:00 UTC il progetto PHP ha pubblicato le correzioni per PHP2Shell. Con ciò la falla non era chiusa per nessun sito. Dapprima le distribuzioni come Debian, Ubuntu o la famiglia RHEL dovevano recepire le correzioni nei propri pacchetti; secondo i resoconti i backport sono stati in parte rilasciati già lo stesso giorno. Poi hoster e amministratori dovevano installare questi pacchetti e riavviare tutti i processi PHP. Solo allora il rispettivo sito era protetto.
Ogni anello di questa catena può rallentare. E a ciascuno è legata un'altra organizzazione con le proprie priorità. Chi non sa com'è fatta la sua catena non può dire dove si trovi la patch in questo momento.
Alcune catene hanno anelli aggiuntivi che quasi nessuno conosce. Molti server Debian e Ubuntu ottengono PHP non dalla distribuzione, ma dal repository di Ondřej Surý su sury.org, una fonte di terzi molto diffusa. Secondo i resoconti ha messo a disposizione build per tutti i rami dalla 5.6 alla 8.5. È utile, ma non è l'archivio di sicurezza di Debian: chi usa questa fonte dipende da un altro anello, con un proprio ritmo e una propria responsabilità. Se un server sia configurato così lo mostra l'elenco delle fonti dei pacchetti, e proprio questa informazione appartiene alla documentazione della catena.
Gli anelli della catena di fornitura in sintesi
La tabella seguente mostra gli anelli tipici di un sito PHP e che cosa può pretendere da ciascuno.
| Anello | Rischio tipico | Che cosa stabilire |
|---|---|---|
| Progetto PHP | falla nell'interprete, fine del supporto | versione supportata in uso, piano per la fine del supporto |
| Distribuzione o fonte di terzi | backport mancante o tardivo | fonte dei pacchetti nota, segnalazioni di sicurezza sottoscritte |
| Hoster o servizio di piattaforma | aggiornamento senza riavvio, nessuna informazione | obbligo di aggiornamento, riavvio, prova e notifica |
| Produttore del CMS | falla nel core | canale di aggiornamento, persona responsabile |
| Fornitore di plugin e temi | estensioni abbandonate o insicure | solo plugin mantenuti da fonti ufficiali |
| Agenzia o sviluppatore | accessi estesi, competenza poco chiara | accessi personali, incarichi scritti |
| Script e servizi esterni | codice altrui nel browser, fuga di dati | elenco, versioni fisse, scopo verificato |
Due esempi della settimana di PHP2Shell mostrano quanto sia facile trascurare un anello. Vercel segnala che non basta aggiornare l'ambiente di sviluppo locale, il codice dell'applicazione o i plugin; conta l'ambiente di esecuzione PHP che effettivamente serve le pagine. Coolify consiglia di aggiornare singolarmente l'ambiente di esecuzione PHP di ogni applicazione, anche dietro Cloudflare. E secondo i resoconti WordPress.org non prevede un proprio aggiornamento contro PHP2Shell, perché la falla è nell'interprete. Chi aspetta il CMS aspetta invano.
Rendere visibile la catena: cinque passaggi
Ecco come mettere ordine nelle dipendenze dei Suoi siti:
- Annotare la catena per ogni sito: dall'ambiente di esecuzione PHP agli script esterni, con il nome del fornitore o della persona.
- Stabilire la competenza per ogni anello: chi installa gli aggiornamenti, chi verifica, chi informa chi?
- Concordare le prove: che cosa vale come completato? Per l'ambiente di esecuzione PHP, ad esempio, stato del pacchetto e riavvio, come descritto in Come chiedere al Suo hoster lo stato delle patch.
- Limitare gli accessi: ogni agenzia e ogni fornitore riceve solo i diritti che gli servono, con account personali.
- Pianificare vie alternative: che fare se un anello viene meno, ad esempio se un fornitore di plugin abbandona o un fornitore non è raggiungibile?
Chieda a ogni fornitore come La informa sulle falle critiche. Chi risponde solo su richiesta è, in una situazione come PHP2Shell, un rischio per i Suoi tempi. Metta per iscritto la risposta.
Plugin ed estensioni: il punto meno trasparente
In molti siti la parte maggiore della catena di fornitura è invisibile: plugin e temi aggiunti nel corso degli anni. Ciascuno proviene da un altro fornitore, con un proprio ritmo negli aggiornamenti di sicurezza. Alcuni fornitori abbandonano il prodotto senza annunciarlo. Altre estensioni vengono prese da fonti non ufficiali e non ricevono mai aggiornamenti.
Qui aiuta una regola semplice: ogni plugin ha bisogno di uno scopo, di un fornitore che lo mantenga e di una fonte ufficiale. Se ne manca uno, finisce nell'elenco da sostituire. Lo stesso vale per i servizi integrati come fornitori di pagamento, sistemi di prenotazione, finestre di chat o strumenti di analisi. Portano codice proprio sulla Sua pagina o ricevono dati dei Suoi visitatori. Annoti quali servizi sono integrati, chi li ha commissionati e se servono ancora. Uno script dimenticato di un fornitore con cui da tempo non esiste più un contratto è un anello senza responsabile.
Come mantenere aggiornati nel tempo plugin e pacchetti lo descrive Mantenere aggiornate le dipendenze: Composer, npm e plugin.
Catena di fornitura, contratti e NIS2
Per le aziende che rientrano nella NIS2, la sicurezza della catena di fornitura fa espressamente parte della gestione del rischio, quindi anche i rapporti con fornitori e prestatori. I dettagli sono in NIS2 e sicurezza dei server web. Ma anche senza obbligo di legge vale: i compiti esternalizzati restano un Suo rischio. Per questo i risultati dei cinque passaggi appartengono ai contratti con agenzia, hoster e fornitori; quali punti vadano regolati lo descrive Contratti con fornitori IT: regolare con chiarezza gli obblighi di sicurezza. Questa pagina è un'informazione generale e non costituisce consulenza legale.
Come aiuta concretamente PHP SOS?
- Tracciamo con Lei la catena di fornitura di ogni sito, dall'ambiente di esecuzione PHP agli script esterni.
- Verifichiamo plugin, temi e pacchetti quanto a stato di manutenzione e provenienza e consigliamo sostituzioni dove necessario.
- Concordiamo con hoster e agenzia chi risponde di quali anelli e quali prove vengono fornite.
- Dove un anello è scoperto, lo assumiamo in modo continuativo con un contratto di manutenzione della sicurezza.
Conclusione: la sicurezza di un sito è forte quanto l'anello più lento della sua catena di fornitura. Chi conosce la catena e collega ogni anello a un responsabile e a una prova sa, nell'emergenza, dove si trova la patch.
Domande frequenti
Che cosa significa catena di fornitura per un sito web?
Tutti i soggetti dal cui lavoro dipende la sicurezza del Suo sito: il progetto PHP, la distribuzione Linux, l'hoster o il servizio di piattaforma, il produttore del CMS, i fornitori di plugin e temi, l'agenzia e i servizi integrati come fornitori di pagamento o script esterni.
Sono responsabile se un fornitore non applica le patch?
La responsabilità per il proprio sito e per i dati che contiene resta di regola a Lei, anche se i compiti sono esternalizzati. Per questo le competenze dovrebbero essere chiare per contratto e verificate. Per la valutazione giuridica sono competenti l'avvocato e il responsabile della protezione dei dati.
Basta che l'hoster aggiorni PHP?
Per l'ambiente di esecuzione PHP presso l'hoster sì, purché riavvii anche tutti i processi e lo documenti. Se parti della Sua applicazione girano altrove, ad esempio in container, su servizi di piattaforma o su un secondo server, ogni ambiente di esecuzione deve essere aggiornato singolarmente.
Come riconosco i plugin rischiosi?
I segnali d'allarme sono la mancanza di aggiornamenti da molto tempo, un fornitore senza un contatto di sicurezza riconoscibile, l'approvvigionamento da fonti non ufficiali e funzioni che nessuno usa più. Tali plugin dovrebbero essere sostituiti o rimossi.