Kiteworks: il produttore raccomanda lo spegnimento il 26 settembre - Cosa si sa finora

Il 25 settembre 2026, Kiteworks ha invitato i propri clienti via e-mail a spegnere tutti i sistemi Kiteworks sabato 26 settembre, dalle 04:00 alle 10:00 (ora dell’Europa centrale). Secondo la comunicazione del CISO Frank Balonis, il produttore ha ricevuto indicazioni dalle autorità di contrasto secondo cui potrebbe verificarsi un attacco ai sistemi Kiteworks durante quel fine settimana. Il supporto clienti giustifica lo spegnimento con la protezione da possibili attacchi zero-day. heise online ha confermato telefonicamente con il supporto l’autenticità del messaggio.

Cronologia

Tutti gli orari sono espressi nell’ora legale dell’Europa centrale (CEST). Dove non è indicato un orario, non sono disponibili indicazioni temporali affidabili.

1. Ven, 25 settembre

   Advisory ai clienti

   Il CISO Frank Balonis informa i clienti via e-mail delle indicazioni delle autorità di contrasto su un possibile attacco nel fine settimana e raccomanda uno spegnimento di sei ore. Secondo l'advisory, tutte le vulnerabilità note sono risolte nella versione 9.5.1.

2. Ven, 25 settembre

   Primi resoconti dei media

   heise online riporta che il supporto Kiteworks ha confermato l'autenticità del messaggio e giustifica lo spegnimento con la protezione da possibili attacchi zero-day. Poco dopo seguono TechCrunch, BleepingComputer, Computer Weekly e altri.

3. Ven, 25 settembre, 17:41

   Il BKA non rilascia dichiarazioni

   heise aggiunge: il BKA rifiuta di rilasciare dichiarazioni per ragioni investigative. Il BSI non risponde, l'FBI non commenta a TechCrunch.

4. Ven, 25 settembre

   Dichiarazione e comunicato stampa

   Kiteworks definisce lo spegnimento una misura precauzionale senza compromissioni note. Il comunicato stampa cita le «federal intelligence authorities» come fonte e elenca le filiali non interessate, tra cui totemo. Le istanze ospitate da Kiteworks vengono spente direttamente dal produttore.

5. Sab, 26 settembre, dalle 04:00 alle 10:00

   Finestra di spegnimento

   La finestra è simultanea in tutto il mondo: dalle 02:00 alle 08:00 UTC, a Sydney dalle 12:00 alle 18:00, a New York da venerdì alle 22:00 a sabato alle 04:00.

6. Sab, 26 settembre, 10:00

   Fine della finestra

   Termina la finestra indicata nell'e-mail ai clienti. La revoca formale della raccomandazione segue il 27 settembre.

7. Dom, 27 settembre

   Raccomandazione revocata

   Kiteworks integra il comunicato stampa: la raccomandazione di spegnimento è revocata per tutti i clienti, i sistemi possono tornare a funzionare. Le istanze ospitate sono di nuovo in servizio. I clienti che gestiscono autonomamente Advanced Forms devono contattare il supporto.

8. Situazione a lun, 28 settembre

   Ancora irrisolto

   Nessun advisory pubblico, nessun numero CVE, nessuna nuova versione, nessun indicatore, nessuna informazione sulla vulnerabilità e nessun resoconto di un attacco riuscito o tentato.

Cosa si sa

La raccomandazione vale in tutto il mondo; l’e-mail indica la finestra per tutti i fusi orari, da AEST a PDT. Kiteworks consiglia di spegnere i sistemi già prima dell’inizio della finestra, anche se non sono raggiungibili da Internet.

Quasi tutto il resto resta finora aperto: non esiste un Security Advisory pubblico, nessun numero CVE, nessuna patch né indicazione su quali prodotti o versioni siano interessati. Il comunicato stampa cita le «federal intelligence authorities» come fonte, presumibilmente autorità federali statunitensi; non si sa quali. Al 28 settembre non vi sono voci in Security Updates né negli advisory GitHub di Kiteworks; l’ultima voce su GitHub risale al 27 maggio 2026. Sono pubbliche la dichiarazione citata sopra e il comunicato stampa del 25 settembre.

A TechCrunch, il CISO di Kiteworks Frank Balonis ha rilasciato la dichiarazione con lo stesso testo. Il BKA ha rifiutato di rilasciare dichiarazioni a heise per ragioni investigative, il BSI non ha risposto. L’FBI non ha voluto commentare a TechCrunch e un portavoce della CISA non ha voluto esprimersi pubblicamente. Secondo TechCrunch, un cliente del settore sanitario ha scollegato immediatamente il proprio server dalla rete, con limitazioni operative percepibili: i medici hanno potuto raggiungere i loro pazienti solo con ritardi temporanei. Secondo un ricercatore di sicurezza citato da TechCrunch, almeno 1000 sistemi Kiteworks sono raggiungibili da Internet; BornCity parla di oltre 1000 organizzazioni che hanno ricevuto l’avvertimento.

Il comunicato stampa differisce dall’e-mail ai clienti su un punto: parla di una finestra di spegnimento di nove ore, mentre l’advisory ai clienti di sei ore. Secondo il comunicato stampa, la raccomandazione riguarda solo installazioni gestite autonomamente (On-Premises, AWS, Azure). Secondo il produttore, non sono interessate le filiali Zivver, DRACOON, totemo, ownCloud, WAMNET, Maytech, Bonfy.ai e 123FormBuilder.

L’advisory ai clienti

L’e-mail ai clienti del 25 settembre contiene, oltre all’avvertimento, un calendario per fuso orario e istruzioni per i cluster. Convertendo gli orari in UTC, tutte le regioni hanno la stessa finestra dalle 02:00 alle 08:00 UTC.

Per i cluster con più server, Kiteworks prescrive un ordine preciso:

1. Attivare la modalità manutenzione in System Setup > Maintenance Mode, affinché nessun utente possa più accedere.

2. Creare un backup: uno snapshot di ogni nodo oppure un backup del database Kiteworks (System Setup > Cluster Configuration > System Configuration). Viene mantenuto un solo backup del database; ogni nuovo backup sostituisce il precedente.

3. Registrare i ruoli: in System Setup > Locations, la colonna Assigned Roles mostra quali nodi hanno il ruolo Application; il nodo Application primario è contrassegnato da un asterisco. Annotare i nodi e i relativi indirizzi IP, poiché serviranno per il riavvio.

4. Spegnere in questo ordine: prima tutti i nodi senza ruolo Application, poi gli altri nodi Application e infine il nodo Application primario. È possibile farlo tramite la scheda Shut Down del rispettivo nodo oppure tramite la console dell’hypervisor (ad esempio VMware o AWS), se l’interfaccia Kiteworks non è più raggiungibile.

5. Riavviare nell’ordine inverso tramite l’hypervisor, poiché la console di amministrazione è raggiungibile solo quando sono in esecuzione nodi sufficienti (Appendice E della Administrator Guide): prima il nodo Application primario, poi gli altri nodi Application uno alla volta e solo dopo che il precedente è completamente operativo, affinché i server di database possano formare un quorum. Quindi i server Storage, poi gli altri ruoli (Repositories Gateway, Search, SFTP, Antivirus) e infine i server Web.

6. Disattivare la modalità manutenzione non appena tutti i nodi nel Cluster Health Dashboard della pagina di stato della console di amministrazione sono verdi.

Su richiesta, il supporto Kiteworks ha inoltre confermato che nessuna delle filiali di Kiteworks è interessata.

Possibili cause: teorie

Finché Kiteworks non pubblicherà dettagli, la causa resta aperta. Le spiegazioni seguenti sono ipotesi deducibili dagli elementi noti; alcune sono discusse anche nei commenti all’articolo di heise. Nessuna è confermata.

Tre elementi delimitano lo scenario. Primo, l’avvertimento indica una finestra temporale fissa invece di uno spegnimento a tempo indeterminato fino alla patch. Secondo, devono essere scollegati anche i sistemi non raggiungibili da Internet. Terzo, la finestra è collocata alla stessa ora in tutto il mondo (dalle 02:00 alle 08:00 UTC), anziché durante la notte locale. Una classica vulnerabilità sfruttabile via Internet non spiegherebbe i primi due punti: basterebbe scollegare il sistema da Internet fino alla disponibilità della patch.

1. Le autorità conoscono un momento pianificato

Le autorità di contrasto talvolta vengono a conoscenza in anticipo del momento di una campagna pianificata, ad esempio tramite comunicazioni monitorate di un gruppo criminale o infrastrutture sequestrate. Gli sfruttamenti di massa di prodotti per lo scambio di file avvengono tipicamente in una finestra breve e coordinata, spesso durante fine settimana o festività, quando è presente meno personale. Kiteworks è il successore di Accellion, la cui File Transfer Appliance è stata attaccata proprio in questo modo nel 2020 e nel 2021, allora attribuito al gruppo Clop: i dati venivano sottratti tramite diverse vulnerabilità e le organizzazioni colpite venivano poi ricattate.

A favore depone la finestra ristretta nel fine settimana. Contro vi è l’obiezione sollevata da diversi commentatori su heise: l’avvertimento è stato inviato a tutti i clienti, quindi gli aggressori probabilmente ne sono al corrente e possono semplicemente rinviare l’attacco. Un rinvio darebbe però al produttore tempo per una patch.

2. Il produttore non conosce ancora la vulnerabilità

È anche possibile che Kiteworks, oltre alla segnalazione delle autorità, non disponga di dettagli tecnici e quindi non conosca né il componente interessato né una patch o una modifica di configurazione da raccomandare. In tal caso, lo spegnimento è l’unica misura efficace senza conoscere la vulnerabilità, e la fine fissata rappresenta un compromesso che i clienti sono più propensi ad accettare. Nei commenti di heise viene avanzata l’ipotesi che il produttore possa lasciare online singoli sistemi come esca durante la finestra per osservare l’attacco. Non vi sono prove a sostegno.

A favore depone il fatto che non siano indicati né un advisory né una mitigazione. Contro vi è il fatto che, secondo le proprie dichiarazioni, Kiteworks collabora con Mandiant e in caso di avvertimento delle autorità siano di norma disponibili almeno indicatori.

3. Una backdoor già installata con attivazione temporizzata

La raccomandazione di spegnere anche i sistemi interni si adatta a uno scenario in cui l’attacco non arriva dall’esterno, ma è già predisposto sugli appliance: ad esempio una backdoor derivante da una precedente compromissione, che si attiva a un orario prestabilito o contatta un server di controllo. Un sistema spento non può eseguire nulla in quel momento.

A favore depone il fatto che, in questo scenario, la raggiungibilità da Internet non svolga alcun ruolo. Contro vi è il fatto che, in questo caso, un produttore raccomanderebbe piuttosto una verifica della compromissione e una reinstallazione anziché un riavvio dopo sei ore.

4. Compromissione lato produttore

Un’altra via che raggiunge i sistemi interni è costituita dalle connessioni stabilite dall’appliance verso il produttore, ad esempio per aggiornamenti, verifica delle licenze o assistenza remota. Se tale canale è compromesso, un firewall non protegge dal traffico in entrata. In questo scenario, lo spegnimento darebbe al produttore una finestra per ripulire la propria infrastruttura, sostituire chiavi o certificati e consentire nuovamente le connessioni solo in seguito.

A favore depone l’orario uniforme a livello mondiale, compatibile con un’azione coordinata dal lato del produttore. Contro vi è il fatto che il produttore raccomanderebbe piuttosto di bloccare le connessioni in uscita anziché spegnere completamente i sistemi.

5. Misura complementare a un’azione delle autorità

Infine, è concepibile che le autorità intervengano nello stesso periodo contro l’infrastruttura degli aggressori e vogliano evitare che questi colpiscano rapidamente in risposta. Ciò spiegherebbe la breve finestra e il ruolo delle autorità di contrasto. Il fatto che il BKA rifiuti una dichiarazione per ragioni investigative indica indagini in corso, ma non dimostra questa variante.

Critica alla comunicazione

Nei commenti di heise prevale lo scetticismo e le obiezioni sono oggettivamente comprensibili: senza informazioni sulla vulnerabilità non è possibile valutare se sarebbe bastato isolare Internet tramite firewall. Una finestra temporale senza una patch annunciata lascia aperto cosa valga dopo le 10:00. E un avvertimento inviato solo via e-mail ai clienti non raggiunge tutti gli operatori, ad esempio presso partner, fornitori di servizi o dopo cambi di personale. Indipendentemente dalla teoria corretta: chi gestisce Kiteworks dovrebbe controllare i log dopo il riavvio e monitorare i canali del produttore finché non sarà disponibile un advisory.

Dopo la finestra: cosa possono fare ora gli operatori

Kiteworks ha revocato la raccomandazione di spegnimento il 27 settembre, ma non ha pubblicato dettagli tecnici. Non è quindi possibile valutare se e come il pericolo sia stato eliminato. Durante il riavvio e successivamente, sono opportuni i seguenti passi:

1. Verificare la versione: tutti i nodi eseguono la versione 9.5.1? Secondo il produttore, tutte le vulnerabilità note sono risolte in questa versione.

2. Verificare lo stato del cluster: nel Cluster Health Dashboard tutti i nodi dovrebbero essere verdi e la modalità manutenzione disattivata.

3. Analizzare i log: esaminare accessi, azioni amministrative e download insoliti di file intorno alla finestra di spegnimento, in particolare sui sistemi che non sono stati spenti o lo sono stati solo tardi.

4. Limitare la raggiungibilità: dove possibile, bloccare l’accesso da Internet all’interfaccia di amministrazione e abilitare solo i servizi necessari.

5. Advanced Forms: chi gestisce autonomamente il modulo chiarisca il riavvio preventivamente con il supporto Kiteworks.

6. Monitorare i canali: Security Updates, advisory GitHub, Newsroom ed e-mail ai clienti di Kiteworks, finché non sarà disponibile un advisory con dettagli tecnici.