Blog · Sicurezza informatica · AI

La settimana nera della sicurezza e il tempo per decidere

26 ottobre 2026 · di Interlogica

Mercoledì 21 ottobre, in poche ore, enti pubblici e università di Olanda, Finlandia e Austria hanno spento i propri siti prima ancora che fosse disponibile la correzione di cui avevano bisogno. Non erano stati violati: avevano letto l’indicazione dell’NSA statunitense, secondo cui chi usa PHP doveva aggiornare subito oppure mettere offline i sistemi finché non fosse stato possibile farlo, e avevano scelto la seconda strada.

È stata una settimana che diversi osservatori hanno già ribattezzato “Black October”, e la tentazione è raccontarla come un elenco di vulnerabilità. Ci sembra più utile guardarla da un’altra parte, perché la cosa che è cambiata davvero non riguarda il codice ma il tempo che un’organizzazione ha a disposizione per decidere cosa fare.

Cosa è successo, in breve

Il caso principale si chiama PHP2Shell: due vulnerabilità critiche (CVE-2026-109618 e CVE-2026-109619, punteggio 9.2 su 10) nel motore di PHP, presenti dalla versione 5.4 alla 8.5, che permettono a un attaccante non autenticato di eseguire codice sul server. L’esistenza delle falle è stata annunciata il 20 ottobre e il giorno dopo sono uscite le versioni corrette (8.5.12, 8.4.27, 8.3.36 e 8.2.35); il peso della notizia dipende dal fatto che, secondo alcune stime, PHP sta dietro a circa il 70% dei siti web, compresi WordPress, Drupal e Magento.

Attorno a PHP2Shell si è accumulato altro. Tra il 17 e il 19 ottobre qualcuno ha violato l’infrastruttura di TeamUpdraft, che sviluppa UpdraftPlus, un plugin di backup per WordPress con oltre quattro milioni di installazioni, e ha usato le chiavi di gestione remota sottratte per installare almeno 99 plugin con backdoor sui siti collegati. Il 21 ottobre la versione 1.107.0 di LiteLLM, una libreria molto usata per collegare le applicazioni ai modelli di intelligenza artificiale, è stata pubblicata con un malware che ruba credenziali, dopo che gli attaccanti avevano usato token rubati a tre sviluppatori. Nello stesso giorno Node.js ha corretto quattro vulnerabilità gravi, mentre browser e sistemi operativi bloccavano otto certificati intermedi dell’autorità indiana eMudhra, le cui chiavi private erano così deboli da poter essere ricostruite in pochi istanti.

Sul fronte degli smartphone la notizia non è stata una singola falla ma una tendenza: i ricercatori di iVerify e Report URI hanno descritto campagne che usano la pubblicità online per installare spyware sugli iPhone, con obiettivi che non sono più giornalisti o politici ma credenziali e portafogli di criptovalute di persone comuni.

Il tempo si è accorciato

La parte più istruttiva sta nella cronologia. Amazon ha rilevato un primo tentativo di sfruttamento di PHP2Shell il 17 ottobre, quattro giorni prima della divulgazione ufficiale, e dopo l’annuncio Cloudflare ha visto i tentativi di attacco passare da migliaia a milioni nel giro di poche ore; nello stesso momento la CISA dichiarava di non aver ancora osservato sfruttamenti, a conferma di quanto sia difficile, anche per chi lo fa di mestiere, sapere con certezza come stanno le cose mentre accadono.

Le falle di PHP sono state individuate con l’aiuto di modelli di intelligenza artificiale, e tra chi le ha segnalate compare anche OpenAI. In un’intervista alla CNBC, Chris Krebs, ex direttore della CISA, ha offerto una misura del momento:

Circa il 3% di tutte le vulnerabilità critiche mai scoperte è emerso nell’ultimo mese.

Non sappiamo ancora se sia un picco o il nuovo normale, ma il senso è chiaro: la stessa tecnologia che aiuta a trovare i difetti accorcia anche la distanza tra la scoperta di una falla e il momento in cui qualcuno prova a usarla.

Per anni la gestione delle vulnerabilità ha funzionato con tempi da calendario, fatti di finestre di manutenzione, cicli di rilascio e riunioni settimanali. Una settimana come questa mostra che quei tempi non reggono più, e che il collo di bottiglia, molto spesso, non è tecnico.

Il problema vero è decidere

Applicare una patch di PHP è un’operazione nota. Decidere di spegnere il sito con cui vendi, il portale dei clienti o il gestionale che usano cento persone, magari di notte e con informazioni incomplete, è un’altra cosa: è una scelta di business che ha un costo certo e immediato, contro un rischio probabile ma non dimostrato.

Per spegnere un sito pubblico in poche ore, come hanno fatto gli enti olandesi e finlandesi, serve che qualcuno abbia l’autorità per farlo e abbastanza contesto per farlo bene. In molte organizzazioni, invece, la persona che vede l’allarme non ha il potere di decidere, e la persona che ha il potere non ha gli elementi per valutare; nel tempo che serve a far parlare le due, la finestra si chiude.

È lo stesso tema che incontriamo ogni volta che parliamo di autonomia e delega.

Delegare non significa distribuire compiti, significa distribuire capacità decisionale.

E una capacità decisionale distribuita funziona solo se è preparata prima: chi può decidere cosa, con quali criteri, entro quali limiti e con quale responsabilità. Quando arriva l’emergenza è tardi per stabilirlo.

C’è anche un secondo aspetto, meno evidente. Il caso UpdraftCentral e quello di LiteLLM raccontano di componenti a cui abbiamo dato fiducia senza guardarli davvero: una chiave di gestione remota attivata di default, una libreria che concentra in un solo punto le chiavi di accesso a molti servizi di intelligenza artificiale. Non si può ispezionare tutto, ma si può almeno sapere cosa si sta usando, perché è impossibile decidere in fretta su qualcosa di cui non si conosce l’esistenza.

Cosa fare adesso

Se gestisci siti o sistemi, alcune verifiche concrete valgono più di qualsiasi riflessione:

  • controlla quali versioni di PHP girano sui tuoi server, compresi quelli dimenticati, e aggiorna alle versioni corrette;
  • se usi UpdraftPlus collegato a UpdraftCentral, aggiorna il plugin e cancella manualmente le chiavi di connessione, perché l’aggiornamento da solo non rimuove una backdoor già installata;
  • se nei tuoi ambienti è stata installata LiteLLM 1.107.0, considera compromesse quelle macchine e ruota le credenziali;
  • aggiorna browser, sistemi operativi e smartphone all’ultima versione disponibile.

Poi, a emergenza rientrata, conviene farsi una domanda organizzativa più che tecnica: la prossima volta, chi nella tua organizzazione può decidere in un’ora di spegnere un sistema, e sa di poterlo fare?

Fonti

Torna all’elenco