Nel fine settimana tra il 25 e il 27 settembre 2026 Kiteworks, piattaforma di trasferimento file e comunicazioni sicure usata da enti governativi, istituzioni finanziarie e grandi aziende, ha inviato ai propri clienti un avviso senza precedenti: spegnere i server Kiteworks per una finestra precauzionale, comunicata inizialmente in sei ore e poi estesa a nove.

Cosa è successo

Secondo quanto riportato, il CISO dell'azienda, Frank Balonis, ha comunicato ai clienti di aver ricevuto "informazioni di intelligence credibili da autorità federali" secondo cui un attore di minaccia potrebbe tentare di colpire i sistemi Kiteworks nel weekend. L'azienda ha precisato esplicitamente di non essere a conoscenza di alcuna compromissione effettiva: l'avviso, si legge nella comunicazione, "è preventivo e non una risposta a una violazione confermata". Ai clienti è stato inoltre raccomandato di applicare l'aggiornamento alla versione 9.5.1, lasciando intendere che la superficie di attacco temuta riguardi vulnerabilità già note piuttosto che uno zero-day inedito.

La finestra di spegnimento raccomandata copriva, per l'Europa centrale, la fascia tra le 4:00 e circa le 13:00 di sabato 27 settembre. Al momento in cui scriviamo non risultano conferme pubbliche di un attacco realmente avvenuto: si tratta a tutti gli effetti di una misura precauzionale basata su intelligence non verificabile dall'esterno.

Perché la vicenda non va liquidata come un falso allarme

Kiteworks non è un prodotto qualunque: appartiene alla categoria dei sistemi di Managed File Transfer (MFT), la stessa al centro di alcuni dei più gravi incidenti di data breach di massa degli ultimi anni, a partire dal caso MOVEit Transfer sfruttato dal gruppo di estorsione Clop (tracciato anche come UNC2546) tra il 2020 e il 2021 e poi di nuovo nel 2023, con centinaia di organizzazioni colpite attraverso un singolo fornitore compromesso. Un MFT violato non espone solo l'azienda che lo usa, ma potenzialmente tutti i dati che quell'azienda scambia con clienti, fornitori e partner attraverso la piattaforma: è un punto di concentrazione del rischio, non un sistema periferico.

In questo contesto, la scelta di Kiteworks di comunicare in modo trasparente una minaccia non confermata, chiedendo ai clienti un'azione concreta e disruptiva come lo spegnimento programmato, è un caso raro di gestione proattiva del rischio da parte di un fornitore: molte aziende, di fronte a un'intelligence non verificata, tendono a non comunicare nulla fino a quando non arriva una conferma, per timore di allarmismo o di danno reputazionale.

Cosa significa per le aziende italiane

  • Chi usa piattaforme MFT per scambiare dati con l'estero o con la pubblica amministrazione (Kiteworks, ma anche prodotti analoghi come MOVEit, GoAnywhere o Accellion) deve trattare questi sistemi come infrastrutture critiche a tutti gli effetti, anche quando non rientrano formalmente tra i "sistemi core" del proprio perimetro IT.
  • La gestione del fornitore conta quanto la gestione interna: un cliente Kiteworks che non avesse ricevuto o letto tempestivamente l'avviso del proprio fornitore avrebbe perso l'intera finestra di mitigazione. Vale la pena verificare chi, in azienda, riceve e agisce concretamente su questo tipo di comunicazioni di sicurezza dei fornitori critici.
  • Per i soggetti NIS2, un fornitore che comunica una minaccia di questo tipo rientra nella gestione del rischio della catena di fornitura prevista dal D.Lgs. 138/2024: la valutazione periodica dei fornitori critici dovrebbe includere anche la loro capacità di comunicare tempestivamente eventi di sicurezza, non solo le certificazioni possedute.
  • Anche in assenza di una violazione confermata, se un'organizzazione italiana avesse scelto di non seguire la raccomandazione del fornitore e successivamente fosse emersa una compromissione, la mancata attuazione di un'indicazione esplicita del vendor potrebbe pesare in una valutazione di adeguatezza delle misure di sicurezza ai sensi dell'art. 32 GDPR.

Cosa fare subito

  • Verificare se la propria organizzazione usa Kiteworks o altre piattaforme MFT, direttamente o tramite un fornitore terzo, e identificare chi in azienda riceve le comunicazioni di sicurezza del vendor.
  • Aggiornare Kiteworks alla versione 9.5.1 se non già fatto, indipendentemente dall'esito dell'allarme.
  • Rivedere i log di accesso del periodo 25-28 settembre 2026 alla ricerca di attività anomale, anche se lo spegnimento precauzionale non è stato effettuato.
  • Definire in anticipo una procedura di risposta a comunicazioni fornitore di questo tipo: chi decide, in quanto tempo e con quale autorità di spegnere un sistema critico su richiesta di un vendor.
  • Se si scambiano dati personali attraverso piattaforme MFT, includerle esplicitamente nel registro dei trattamenti e nella valutazione dei rischi ai sensi del GDPR, trattandole come infrastrutture ad alto impatto in caso di violazione.