Siamo ufficialmente senza PHP. Ecco cosa ci ha insegnato ottobre (finora)

La settimana dal 19 al 24 ottobre 2026, da lunedì a sabato, ha portato una sequenza costante di notizie di sicurezza gravi in tutto il settore. Se ve la siete persa, la nostra rassegna di quella settimana ne copre i dettagli. La versione breve: in diversi casi, gli attaccanti si sono mossi prima delle correzioni.

Una settimana così non ci rimanda al tavolo da disegno, ma rende più nitide le linee che già vi sono tracciate. Una cosa è sostenere un principio, un'altra è osservare, caso per caso, cosa succede dove quel principio manca. Perciò, invece di elencare passaggi tecnici, vogliamo spiegare i principi con cui lavoriamo, perché per voi come clienti l'approccio conta più di qualsiasi singolo aggiornamento. Uno di quei principi ha appena raggiunto il suo traguardo: ora siamo ufficialmente senza PHP.

Perché applicare le patch a posteriori è una corsa persa?

Per anni il consiglio standard è stato semplice: applicate le patch in fretta e andrà tutto bene. La tendenza remava già contro quel consiglio. Il team Mandiant di Google ha misurato il tempo medio tra il momento in cui una vulnerabilità diventa nota e il suo sfruttamento: 63 giorni nel 2018-2019, 32 giorni tra il 2021 e il 2022, e cinque giorni nel 2023, calcolati come media escludendo i valori anomali.

Cinque giorni è il dato del 2023, prima che gli strumenti di intelligenza artificiale entrassero nel lavoro quotidiano sul software. Questo mese ci ha dato una misurazione fresca della corsa, presa da tre punti di osservazione diversi attorno alla divulgazione di PHP2Shell del 21 ottobre 2026.

Il team di threat intelligence di Amazon ha osservato un tentativo di sfruttamento di PHP2Shell il 17 ottobre, quattro giorni prima della divulgazione pubblica, e afferma che, una volta scaduto l'embargo e rilasciata la patch, nuovi exploit dimostrativi sono comparsi nel giro di ore. F5 Labs ha rilevato le prime scansioni di PHP2Shell più di cinque ore prima della pubblicazione delle due CVE, e a poche ore dalla divulgazione i suoi sensori registravano migliaia di tentativi di exploit. Il CEO di Cloudflare, Matthew Prince, ha dichiarato il 22 ottobre che Cloudflare ha visto migliaia di tentativi prima dell'annuncio, decine di migliaia nei 45 minuti successivi, centinaia di migliaia entro due ore e milioni al momento del suo post. Erano tentativi, non intrusioni confermate, ma mostrano quanto in fretta venissero provate le porte: la finestra oggi si misura in minuti e ore, e per alcuni si è chiusa prima ancora che la patch esistesse.

Né lo sfruttamento prima che esista una correzione è una rarità. Nel 2023, il 70% delle vulnerabilità sfruttate monitorate da Mandiant, 97 su 138, è stato sfruttato come zero-day, cioè prima che esistesse qualunque correzione.

Se lo sfruttamento può cominciare prima che una patch sia disponibile, e arrivare in massa pochi minuti dopo la sua pubblicazione, allora le patch, per quanto disciplinate, non possono essere l'intero piano. Un difensore che si affida solo a quelle è entrato in una corsa spesso decisa prima che inizi. Perciò diamo per scontato che la corsa a volte sarà persa, e progettiamo per la sconfitta. Quell'assunto si traduce in tre domande. Finché una falla è aperta, quanta parte dei nostri sistemi può essere colpita? Se qualcosa viene colpito, quanto può essere perso? E una volta che esiste una correzione, quanto in fretta possiamo riprenderci e chiudere il varco? Ogni principio che seguiamo risponde a una di quelle domande, e tutto ciò che segue è organizzato attorno a esse.

Perché rimuoviamo il software invece di tamponarlo con le patch?

Partiamo dalla prima domanda, quanto può essere colpito. Ogni organizzazione accumula software invecchiato male: strumenti i cui manutentori sono passati ad altro, componenti bloccati su vecchie versioni perché qualcos'altro ne dipende, codice che nessuno vuole toccare. La risposta comune è avvolgere quel software in soluzioni di ripiego e regole firewall e sperare per il meglio.

Noi la vediamo diversamente. Il software che non può essere tenuto aggiornato viene rimosso, non tamponato. Non lo teniamo in vita con correzioni temporanee, perché una correzione temporanea su codice non mantenuto è una promessa destinata prima o poi a essere infranta. O un componente può essere aggiornato per tutto il tempo in cui lo usiamo, o non viene eseguito affatto.

Perché i ripieghi falliscono? Perché un ripiego blocca solo le falle già note. Il software non mantenuto non smette di avere debolezze il giorno in cui i suoi manutentori se ne vanno. Ricercatori e attaccanti continuano a trovarne di nuove, anno dopo anno, e ormai non resta nessuno a scrivere le correzioni. Ogni scoperta impone un'altra regola, un altro filtro, un altro strato imbullonato sopra il precedente, e la pila diventa più fragile a ogni aggiunta. Prima o poi compare una falla che nessuno strato esterno può filtrare, oppure due strati interferiscono tra loro, e la protezione cede in silenzio. Un ripiego compra tempo, e sul codice abbandonato non c'è niente di utile su cui spendere quel tempo, perché il problema di fondo non verrà mai risolto.

Ripensate alla corsa di prima, ora disputata in minuti e ore. Contro software mantenuto, la corsa è brutalmente breve, ma almeno si può correre. Contro software abbandonato, non c'è corsa affatto, perché la correzione che dovrebbe concluderla non arriverà mai. Scritto così sembra ovvio. In pratica è la strada più difficile, perché rimuovere qualcosa di solito significa ricostruire ciò che vi si appoggiava. Pensiamo che quel costo valga la pena. Un attaccante non può sfruttare una debolezza in un sistema che non esiste più.

Che aspetto ha, concretamente, una superficie di attacco piccola?

La rimozione è il modo più diretto per ridurre ciò che può essere colpito. L'abitudine più ampia che vi sta dietro ha un nome tecnico: mantenere piccola la superficie di attacco. La superficie di attacco è un'idea semplice, la somma di ogni punto in cui un attaccante potrebbe provare una chiave in una serratura. Ogni servizio esposto, ogni libreria di terze parti, ogni plugin è una serratura in più da difendere. La nostra definizione di buona sicurezza comincia qui: il codice più robusto è quello che non eseguite, e i dati più al sicuro sono quelli che non avete mai conservato.

Considerate cosa sia davvero una libreria o un plugin di terze parti. Quando uno sviluppatore lo adotta, sta affidando a uno sconosciuto, spesso un volontario non pagato, il compito di mantenere quel codice sicuro per tutto il tempo in cui viene eseguito. La libreria ha bisogno dei propri aggiornamenti, delle proprie correzioni di sicurezza, di un proprio manutentore che presti attenzione. Se quel manutentore perde interesse, cambia lavoro o semplicemente smette di rispondere, il codice continua a funzionare, ma nessuno lo sorveglia più. Una falla trovata dopo quel momento resta aperta per sempre, ed è il problema dell'abbandono della sezione precedente che entra da una porta laterale. Moltiplicate tutto questo per i molti componenti da cui dipende un'applicazione tipica, e il quadro diventa chiaro. Ogni dipendenza è una piccola promessa fatta da qualcuno che non avete mai incontrato, e alcune di quelle promesse scadono in silenzio. Eseguirne di meno significa dovere la propria sicurezza a meno sconosciuti.

I sistemi a cui accedete, attraverso cui pagate e con cui dialogano le nostre app sono scritti in Go. PHP è sparito, e con lui la lunga coda di librerie, plugin e dipendenze che le applicazioni PHP tendono a trascinarsi dietro.

Abbiamo scelto Go per i nostri sistemi più critici perché risponde al problema delle dipendenze a livello di linguaggio. Go è memory safe, cioè sicuro nella gestione della memoria: il linguaggio gestisce la memoria al posto del programmatore, il che esclude un'intera classe di bug come i buffer overflow, e la CISA (l'agenzia statunitense per la cybersicurezza) elenca Go tra i linguaggi memory safe in The Case for Memory Safe Roadmaps. Quella classe è più grande di quanto sembri: il progetto Chromium rileva che circa il 70% dei suoi bug di sicurezza gravi è costituito da problemi di sicurezza della memoria. La libreria standard di Go copre gran parte di ciò che serve a un servizio web, crittografia inclusa, quindi un servizio in Go ha bisogno di meno pacchetti di terze parti, cioè di meno promesse da parte di sconosciuti. La crittografia è presa tanto sul serio che il modulo crittografico di Go è validato secondo lo standard FIPS 140-3 del governo statunitense, certificato CMVP n. 5247. E quando una falla emerge comunque nell'ecosistema più ampio, il team di sicurezza di Go cura un database delle vulnerabilità, e il suo strumento govulncheck segnala solo le vulnerabilità nel codice che un programma chiama davvero, il che mantiene gli avvisi poco rumorosi e utilizzabili.

Tutto questo conta per via di quanto siano diffuse, e quanto vecchie, le installazioni PHP. W3Techs riporta che PHP è usato dal 69,2% di tutti i siti di cui conosce il linguaggio lato server, con il 26,6% dei siti PHP ancora su PHP 7 e il 7,7% su PHP 5, misurazione del 27 ottobre 2026. Il progetto PHP stesso supporta ogni ramo di rilascio per due anni di correzioni di bug e sicurezza, poi per altri due anni di sole correzioni di sicurezza critiche. PHP 7 e PHP 5 sono oltre tutto questo. Una grossa fetta del web gira su codice che i suoi stessi creatori non proteggono più, cioè la corsa persa della prima sezione, intrapresa volontariamente.

Il nostro sito è fatto di pagine statiche costruite in anticipo, senza codice lato server che le generi quando le visitate. Una pagina che è solo un file offre pochissimo da attaccare. Alla domanda su quanto può essere colpito, questa è la nostra risposta: il meno possibile.

Quali dati conserviamo su di voi?

Una superficie piccola limita i modi in cui un attaccante potrebbe entrare. La seconda domanda chiede cosa troverebbe se, un giorno, uno di loro entrasse comunque. La nostra risposta è rendere il bottino il più noioso possibile: meno dati, conservati per meno tempo.

Chiediamo solo ciò che serve a gestire un account. La nostra informativa sulla privacy (in inglese) lo elenca chiaramente: un nome utente, un indirizzo email, una password cifrata e l'indirizzo IP usato al momento della registrazione. I pagamenti passano attraverso processori di pagamento terzi, quindi i dati della vostra carta risiedono presso specialisti il cui intero mestiere è proteggerli, non presso di noi.

Stiamo anche stringendo ciò che accade nel tempo. I vecchi account inutilizzati verranno eliminati automaticamente. I dati che non esistono non possono trapelare, non possono essere rubati e non possono essere pretesi. Un account che avete abbandonato anni fa non dovrebbe restare lì come una passività con il vostro nome sopra. Se la corsa dovesse mai essere persa dal nostro lato della barricata, il premio sul tavolo deve essere il più piccolo che possiamo rendere.

La stessa logica vale oltre noi, perché anche le altre aziende perdono delle corse. Molte delle fughe di dati che le persone subiscono avvengono presso negozi, forum e servizi a cui si erano iscritte molto tempo fa. Per questo offriamo avvisi di violazione dei dati: il nostro Data Breach Scanner controlla le fughe di dati note alla ricerca del vostro indirizzo email e vi scrive se compare, così potete cambiare le password prima che la fuga venga sfruttata.

Cosa succede se qualcosa si rompe comunque?

La terza domanda ha due metà: riprendersi e chiudere il varco. Prima la ripresa. Una buona pianificazione della sicurezza dà per scontate le giornate storte. L'hardware si guasta, i fornitori cambiano, e a volte la mossa giusta è semplicemente abbandonare un pezzo di infrastruttura.

I nostri sistemi sono costruiti in modo da poter essere ricreati o spostati altrove se necessario. Per voi, questo significa che un guasto, o una sede che non soddisfa più i nostri standard, non deve trasformarsi in una lunga interruzione, perché il sistema interessato può essere ricostruito o spostato. Se mai concludessimo che un ambiente non è più abbastanza buono, possiamo lasciarlo invece di negoziarci.

La resilienza non è una qualità spettacolare. Si manifesta per lo più nel fatto che le cose continuano a funzionare, e in questa cornice è ciò che impedisce a un round perso di diventare una stagione persa.

Quanto in fretta le correzioni raggiungono i nostri sistemi?

L'altra metà della terza domanda è la velocità. Niente di quanto sopra elimina il bisogno di applicare le patch; cambia il peso che le patch devono portare. Con una superficie piccola e software aggiornato, applicare una correzione è routine, non un progetto.

La nostra regola è semplice: gli aggiornamenti partono non appena esistono le correzioni. Le misurazioni di ottobre spiegano perché. Quando i tentativi di exploit arrivano entro minuti e ore dalla pubblicazione di una correzione, e a volte prima che ne esista una, una correzione lasciata in attesa non protegge nessuno. Trattiamo una patch rilasciata come un colpo di pistola di partenza. Il tratto tra l'esistenza di una correzione e la sua applicazione è l'unica parte della corsa che un difensore controlla pienamente, quindi è la parte che ci rifiutiamo di cedere.

E poiché il nostro stack è piccolo, c'è semplicemente meno da correggere, ed è qui che le tre domande si incontrano: meno c'è da colpire, più in fretta si chiude il varco.

Messe fianco a fianco, le domande e i principi che vi rispondono appaiono così:

Cosa significa tutto questo per voi?

Significa che le tre domande hanno risposte tangibili. Meno codice si frappone tra voi e il vostro account, quindi ci sono meno punti in cui qualcosa può andare storto. Esistono meno dati su di voi, quindi perfino il caso peggiore espone poco. E i nostri sistemi possono essere ricostruiti, quindi una giornata storta per noi non deve diventare una lunga interruzione per voi.

Saremo onesti sul limite di tutto questo. La corsa da cui siamo partiti non può essere vinta in modo affidabile, né da noi né da nessuno, perché le falle a volte vengono sfruttate prima che qualcuno sappia della loro esistenza, e nessuna architettura cambia questo fatto. Nessun fornitore può promettere rischio zero, e chiunque lo faccia vende fiducia, non sicurezza. Ciò che possiamo promettere è la forma di una perdita: poche vie d'ingresso, poco da prendere e una via rapida per tornare in piedi. Non possiamo garantire di vincere ogni round della corsa. Abbiamo costruito in modo che perderne uno vi costi il meno possibile, e pensiamo che questa promessa, mantenuta con costanza, valga più di una promessa audace che non può esserlo.

La sicurezza è anche uno sforzo condiviso. La configurazione più solida che possiamo costruire beneficia comunque di buone abitudini dalla vostra parte, quindi se volete passi pratici, cominciate dalla nostra guida su come aumentare la vostra sicurezza online (in inglese). E se state scegliendo una VPN, con noi o con chiunque altro, chiedete al fornitore come ragiona, non solo cosa vende. La risposta vi dice molto su come andranno le vostre settimane tranquille, e quelle rumorose.