La corsa al patch su PHP prova che non si può più correggere a velocità umana

Che cosa dice dello stato della sicurezza di Internet il fatto che la mossa responsabile sia spegnere il proprio sito? È il consiglio che agenzie di tutto il mondo hanno dato questa settimana, e molte organizzazioni lo hanno seguito.

La settimana in cui la scelta più sicura era spegnere tutto

Due falle critiche in PHP, il linguaggio su cui si regge una gran parte del web, sono state trovate con strumenti di IA. Secondo la BBC, mercoledì la PHP Foundation ha rilasciato una correzione, e agenzie tra cui l’NCSC britannico hanno detto che le organizzazioni incapaci di intervenire subito dovrebbero valutare di mettere i sistemi offline. La Finlandia ha chiuso temporaneamente i servizi web pubblici del governo, l’agenzia cyber olandese ha spento il proprio sito e alcune parti di Wikipedia sono diventate irraggiungibili. La NSA ha avvertito che questi bug spesso offrono un accesso diretto al file system o al database di un server.

Le falle erano rimaste inosservate per più di dieci anni. Alcuni dettagli sono trapelati sui social media prima della divulgazione prevista, costringendo a un annuncio affrettato. Il CTO di Cloudflare ha detto di vedere già i primi attacchi.

Il bug non è la notizia; lo è il tempo

Bug vecchi e profondi esistono in ogni grande codebase. Ciò che è cambiato è chi li trova e con quale rapidità. Wiz ha dichiarato che i modelli di frontiera hanno permesso ai suoi ricercatori di sviluppare in poche ore exploit funzionanti su più applicazioni. OpenAI, che afferma che i suoi strumenti hanno aiutato a trovare le falle, ha scritto che le stesse capacità «possono anche aiutare gli attaccanti a sviluppare rapidamente strumenti offensivi ed exploit».

Ora confrontalo con il lato di chi difende. The Record riferisce che uno dei bug risale a un audit del 2024 e poi è rimasto fermo per mesi, mentre un piccolo team di sviluppatori principali faticava con compromessi di compatibilità. Non li biasimiamo. Il loro ragionamento sembra sensato per un mondo in cui nessuno poteva usare il bug come arma in tempi brevi. Quel mondo non esiste più.

A nostro avviso, questo è lo squilibrio centrale: la scoperta ora richiede settimane o ore, mentre correggere per consenso, impacchettare e poi distribuire in migliaia di organizzazioni richiede mesi. Chi si trova in quel divario è esposto.

Spegnere i siti è un sintomo, non una strategia

Portare un sito offline funziona, e crediamo che le agenzie abbiano fatto bene a dirlo. Ma è un freno di emergenza, non un piano. Don Smith di Sophos ha individuato il vero problema: prima di applicare la patch bisogna trovare ogni posto in cui gira PHP, anche dentro sistemi di gestione dei contenuti, piattaforme di hosting e prodotti di terze parti, a volte senza che l’organizzazione lo sappia.

È un problema di inventario, e non si risolve il giorno in cui esce l’avviso. Sospettiamo che le organizzazioni che sapevano cosa stavano eseguendo abbiano potuto correggere o isolare in poche ore, mentre le altre hanno dovuto tirare a indovinare, ed è così che si arriva al blackout.

C’è anche un gruppo più difficile: i sistemi legacy. The Record afferma che le patch coprono solo PHP 8.2 e successivi, e cita stime di Cisco Talos secondo cui circa il 50% dei sistemi PHP vulnerabili potrebbe non ricevere alcuna patch. Questi gestori non possono automatizzare la via d’uscita da una versione non supportata. Per loro la finestra di esposizione non si chiude; resta lì. È la parte sottovalutata di questa storia.

I difensori dovrebbero trattare inventario e velocità come controlli

Primo, tratta l’inventario come un controllo di sicurezza. Conosci ogni istanza di PHP, comprese quelle incluse dai fornitori, e chiedi direttamente a loro.

Secondo, automatizza la parte noiosa: rilasci graduali, rollback testati e percorsi di emergenza pre-approvati, perché un aggiornamento critico non debba aspettare un comitato. I maintainer hanno bisogno della stessa cosa; la PHP Foundation dice di stare cambiando la propria struttura interna perché i bug gravi arrivino prima ai vertici.

Terzo, ritira le versioni non supportate prima del prossimo avviso, non durante.

C’è una controargomentazione legittima. OpenAI osserva che, a sua conoscenza, un’IA di frontiera ha trovato queste falle prima degli attaccanti, dando ai difensori un vantaggio, e si è impegnata a mettere a disposizione 1 miliardo di dollari in accesso sovvenzionato per organizzazioni con risorse di sicurezza limitate. È incoraggiante, anche se è la lettura dell’azienda stessa, e la fuga di notizie e i primi attacchi mostrano quanto in fretta un vantaggio svanisca. Il CEO di Chainguard ha detto che il settore deve «capire come affrontarle più in fretta, in modo più coordinato e migliore», e siamo d’accordo. OpenAI dice anche di aspettarsi un forte aumento di scoperte simili nei prossimi mesi. Prendila come una previsione, ma plausibile.

Il verdetto: questa settimana è stata una prova generale. Le organizzazioni che riescono a correggere in poche ore tratteranno la prossima come un martedì qualunque. Tutte le altre proveranno di nuovo il blackout.