Blog · Sicurezza informatica · AI

La settimana nera della sicurezza e il tempo per decidere

26 ottobre 2026 · di Interlogica

Mercoledì 21 ottobre, nel giro di poche ore, i governi di Paesi Bassi, Belgio, Finlandia, Francia e Germania hanno messo offline siti e servizi pubblici, in attesa della correzione di cui avevano bisogno. Negli stessi giorni l’NSA statunitense consigliava a chi usa PHP di aggiornare subito e, se non era possibile, di mettere offline i sistemi finché non lo fosse diventato.

È 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 una stima di Wiz Research, PHP sta dietro a circa il 70% dei siti web, e su PHP si basano piattaforme come WordPress, Drupal e Joomla.

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 attive, 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 le credenziali GitHub di tre sviluppatori. Lo stesso giorno Node.js ha pubblicato le correzioni per dieci vulnerabilità, quattro delle quali di gravità alta, e nella stessa settimana Mozilla, Google e Apple hanno bloccato otto certificati intermedi dell’autorità indiana eMudhra, le cui chiavi private erano così deboli da poter essere ricostruite quasi all’istante.

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 sfruttano la pubblicità online e codice caricato da siti legittimi per installare spyware su iPhone selezionati, con l’obiettivo di rubare password e portafogli di criptovalute. Strumenti nati per spiare politici e giornalisti stanno passando nelle mani di criminali 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 Cloudflare ha contato migliaia di tentativi di attacco nelle dieci ore prima dell’annuncio e milioni in quelle successive; il 21 ottobre, intanto, 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:

Il 3% di tutte le vulnerabilità critiche mai scoperte è stato trovato 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 i governi olandese e finlandese, 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, cancella manualmente le chiavi di connessione e controlla che non ci siano plugin sconosciuti, 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