Marcus Chen, YuSMP Group
Marcus Chen Staff Engineer, Backend & Cloud, YuSMP Group · hardening dei server, pipeline di patching e rilascio sicuro per team negli Stati Uniti e in Europa
Corridoio buio di un data center con rack di server spenti, una saracinesca d'acciaio chiusa e una leva di alimentazione rossa abbassata, a illustrare uno spegnimento precauzionale

In breve

Kiteworks ha chiesto ai clienti di spegnere per un weekend i server di trasferimento file autogestiti, perché le forze dell’ordine hanno segnalato un possibile attacco, probabilmente tramite una falla sconosciuta. Nessuna violazione è confermata e la versione 9.5.1 corregge tutti i bug noti. Resta raro che un fornitore chieda ai clienti di staccare la spina. È un buon momento per un audit di sicurezza dei sistemi esposti su Internet, a partire da quelli che custodiscono i file dei partner.

La lezione più ampia: un server di trasferimento file sul perimetro è un bersaglio di grande valore, e serve un piano per lavorare un giorno senza.

Cosa ha annunciato Kiteworks?

Venerdì 25 settembre 2026 Kiteworks ha comunicato via e-mail ai clienti di aver ricevuto dalle forze dell’ordine informazioni credibili secondo cui un attore malevolo potrebbe tentare di colpire i sistemi Kiteworks. La testata tedesca heise online è stata la prima a riportare l’e-mail. Kiteworks ha poi pubblicato un avviso pubblico e confermato i dettagli a TechCrunch e BleepingComputer.

La richiesta era netta: spegnere i sistemi. I clienti che gestiscono Kiteworks in proprio, on-premise o nei propri account AWS o Azure, dovevano spegnere i server durante una finestra stabilita. Kiteworks ha dichiarato che avrebbe fatto lo stesso per i clienti ospitati. Le fonti divergono sulla durata: BleepingComputer cita una finestra di sei ore a partire dalle 02:00 UTC di sabato 26 settembre, mentre l’avviso pubblico dell’azienda parla di nove ore nel fuso orario locale di ciascun cliente.

Il CISO Frank Balonis ha dichiarato che Kiteworks non ha indicazioni di compromissioni dei propri sistemi o di quelli dei clienti e ha definito la misura preventiva. Secondo l’azienda la versione 9.5.1 corregge tutte le vulnerabilità attualmente note. Fino a domenica 27 settembre non erano stati pubblicati CVE, nuove build né indicatori di compromissione. L’FBI non ha voluto commentare con TechCrunch e la CISA non ha rilasciato dichiarazioni ufficiali. Le controllate di Kiteworks, tra cui Zivver, DRACOON, totemo e ownCloud, non sono coinvolte.

Perché i server di trasferimento file sono un bersaglio così ambito?

I sistemi di managed file transfer (MFT) stanno sul perimetro della rete e contengono esattamente ciò che cercano gli attaccanti: contratti, cartelle cliniche, file delle buste paga e dati scambiati con fornitori e banche. Kiteworks dichiara tra i propri clienti organizzazioni di sanità, istruzione, automotive, tecnologia e pubblica amministrazione. Secondo TechCrunch, un cliente del settore sanitario ha riferito che lo spegnimento ha interrotto le comunicazioni tra medici e pazienti.

La storia spiega la cautela. Nel 2021 il gruppo Clop ha sfruttato alcune zero-day di Accellion FTA, il prodotto da cui è nata Kiteworks, per rubare i dati di centinaia di organizzazioni e ricattarle. Lo stesso copione ha poi colpito MOVEit Transfer, GoAnywhere MFT e Cleo. Ogni volta una sola falla in un solo prodotto si è trasformata in un furto di dati di massa, di solito durante festività o weekend, quando i controlli sono più radi.

Cosa significa per i team software negli Stati Uniti e in Europa

Primo, sapere quali sistemi di trasferimento file si gestiscono davvero. I server MFT entrano spesso tramite un singolo reparto o un’azienda acquisita e non finiscono mai nell’inventario principale degli asset. Se non conoscete versione, responsabile ed esposizione su Internet di ciascuno, questo weekend ha mostrato perché dovreste.

Secondo, pianificare i fermi che non scegliete voi. Uno spegnimento precauzionale blocca gli scambi con i partner, le pratiche di sinistro e i caricamenti dei clienti. I team con un piano B, come un secondo canale sicuro o una coda che trattiene i trasferimenti finché il server non torna, hanno perso qualche ora. Quelli senza hanno perso processi di business. Costruite il piano B prima che serva.

Terzo, gli obblighi di notifica scattano solo se i dati escono, ma dovete poter dimostrare che non è successo. Se un server MFT con dati personali viene compromesso, il GDPR concede 72 ore per notificare l’autorità di controllo. I soggetti NIS2 devono un preallarme entro 24 ore e le organizzazioni statunitensi soggette a HIPAA hanno regole proprie. Log di accesso e di attività sui file conservati fuori dal server sono ciò che vi permette di dire «non è stato sottratto nulla».

Cosa significa per le aziende italiane?

In Italia le piattaforme di scambio file sicuro sono diffuse in sanità, assicurazioni, banche, PA e nelle filiere manifatturiere che condividono progetti e ordini con i fornitori. Per i soggetti che rientrano nel perimetro NIS2, recepita con il D.Lgs. 138/2024, un incidente significativo va pre-notificato al CSIRT Italia dell’Agenzia per la Cybersicurezza Nazionale (ACN) entro 24 ore; se sono coinvolti dati personali, la notifica al Garante privacy segue la scadenza di 72 ore prevista dall’art. 33 del GDPR. Conviene quindi seguire gli avvisi del CSIRT Italia e documentare lo spegnimento precauzionale, la versione installata e i log esterni: è la prova più solida, verso l’autorità e verso i clienti, che la situazione era sotto controllo.

Cosa fare adesso?

  1. Seguire le indicazioni del fornitore. Se usate Kiteworks, verificate di aver ricevuto e applicato l’avviso di spegnimento e non riavviate finché Kiteworks non dà il via libera tramite i canali di supporto.
  2. Aggiornare alla 9.5.1. Secondo Kiteworks questa versione corregge tutte le vulnerabilità note. Controllate ogni istanza, compresi i server di test e di disaster recovery.
  3. Ridurre l’esposizione su Internet. Mettete le interfacce di amministrazione dietro VPN o accesso zero trust, limitate dove possibile il traffico in ingresso agli intervalli IP dei partner ed eliminate i server inutilizzati.
  4. Portare i log fuori dal server. Inviate i log di accesso e di attività sui file a un SIEM centrale, così da poterli analizzare anche se il server viene compromesso.
  5. Cercare, poi monitorare. Cercate account amministrativi sconosciuti, download insolitamente voluminosi e nuovi file nelle directory web. Nei prossimi giorni seguite l’eventuale pubblicazione di una CVE o di indicatori di compromissione da parte di Kiteworks, CISA, CSIRT Italia o altri CERT nazionali.

Domande frequenti

Cosa ha chiesto Kiteworks ai clienti?

Il 25 settembre 2026 Kiteworks ha chiesto ai clienti che gestiscono in proprio la sua piattaforma di trasferimento file sicuro, on-premise o nei propri account AWS o Azure, di spegnere i sistemi per una finestra precauzionale nel weekend del 26 settembre. Kiteworks ha dichiarato che avrebbe spento direttamente le istanze ospitate.

Kiteworks è stata violata?

Secondo Kiteworks no. Il CISO Frank Balonis ha dichiarato che l'azienda non ha indicazioni di compromissioni dei sistemi propri o dei clienti e ha definito l'avviso preventivo. È stato originato da informazioni credibili delle forze dell'ordine secondo cui un attore malevolo potrebbe prendere di mira i sistemi Kiteworks.

Esiste una CVE o una patch?

Al 27 settembre 2026 non erano stati pubblicati CVE, nuove build né indicatori di compromissione. Kiteworks afferma che la versione 9.5.1 corregge tutte le vulnerabilità attualmente note e ne raccomanda l'uso. Il timore riguarda una possibile zero-day, cioè una falla che il fornitore non conosce ancora.

Quali prodotti Kiteworks sono coinvolti?

L'avviso riguarda la piattaforma Kiteworks. Secondo l'azienda le controllate, tra cui Zivver, DRACOON, totemo, ownCloud, WAMNET, Maytech, Bonfy.ai e 123FormBuilder, non sono coinvolte.

Perché un server di trasferimento file è così critico?

I sistemi di managed file transfer (MFT) sono esposti sul perimetro di Internet e custodiscono i file che le aziende scambiano con i partner: contratti, dati sanitari e finanziari. Nel 2021 il gruppo Clop ha sfruttato in massa alcune zero-day di Accellion FTA, il predecessore di Kiteworks, e in seguito di MOVEit Transfer, GoAnywhere e Cleo, rubando ogni volta i dati di centinaia di organizzazioni.

Fonti

Kiteworks — Precautionary Shutdown Advisory (September 25, 2026)
TechCrunch — Kiteworks urges customers to shut down their servers amid ‘imminent’ threat of cyberattack
BleepingComputer — Kiteworks urges server shutdown over potential zero-day attacks
heise online — Imminent Zero-Day Attack: KiteWorks Urges Customers to Shut Down Servers