L’essentiel
Kiteworks a demandé à ses clients d’éteindre leurs serveurs de transfert de fichiers auto-hébergés le temps d’un week-end, car les forces de l’ordre ont signalé une possible attaque, vraisemblablement via une faille inconnue. Aucune compromission n’est confirmée et la version 9.5.1 corrige tous les bogues connus. Il reste rare qu’un éditeur demande à ses clients de tout débrancher. C’est l’occasion de lancer un audit de sécurité de vos systèmes exposés sur Internet, en commençant par ceux qui stockent les fichiers de vos partenaires.
La leçon plus large : un serveur de transfert de fichiers en bordure de réseau est une cible de grande valeur, et il faut savoir fonctionner une journée sans lui.
Qu’a annoncé Kiteworks ?
Le vendredi 25 septembre 2026, Kiteworks a informé ses clients par e-mail avoir reçu des renseignements crédibles des forces de l’ordre indiquant qu’un acteur malveillant pourrait tenter de cibler les systèmes Kiteworks. Le média allemand heise online a été le premier à révéler cet e-mail. Kiteworks a ensuite publié un avis public et confirmé les détails à TechCrunch et BleepingComputer.
La consigne était sans ambiguïté : éteindre les systèmes. Les clients qui exploitent eux-mêmes Kiteworks, sur site ou dans leurs propres comptes AWS ou Azure, devaient couper leurs serveurs pendant une fenêtre définie. Kiteworks a annoncé faire de même pour les clients hébergés. Les informations divergent sur la durée : BleepingComputer évoque une fenêtre de six heures à partir de 02h00 UTC le samedi 26 septembre, tandis que l’avis public de l’éditeur parle de neuf heures dans le fuseau horaire local de chaque client.
Le RSSI, Frank Balonis, affirme que Kiteworks n’a aucun indice de compromission de ses systèmes ou de ceux de ses clients et parle d’une mesure préventive. L’éditeur assure que la version 9.5.1 corrige toutes les vulnérabilités actuellement connues. Au dimanche 27 septembre, aucune CVE, aucun nouveau build ni aucun indicateur de compromission n’avait été publié. Le FBI n’a pas souhaité commenter auprès de TechCrunch et la CISA n’a pas fait de déclaration officielle. Selon Kiteworks, ses filiales, dont Zivver, DRACOON, totemo et ownCloud, ne sont pas concernées.
Pourquoi les serveurs de transfert de fichiers sont-ils si ciblés ?
Les solutions de transfert de fichiers managé (MFT) sont placées en bordure du réseau et contiennent exactement ce que recherchent les attaquants : contrats, dossiers patients, fichiers de paie et données échangées avec les fournisseurs et les banques. Kiteworks compte parmi ses clients des organisations de la santé, de l’éducation, de l’industrie automobile, de la tech et du secteur public. Selon TechCrunch, un client du secteur de la santé a indiqué que l’arrêt avait perturbé les échanges entre médecins et patients.
L’historique explique cette prudence. En 2021, le groupe Clop a exploité des failles zero-day d’Accellion FTA, le produit dont est issu Kiteworks, pour voler les données de centaines d’organisations et les faire chanter. Le même mode opératoire a ensuite visé MOVEit Transfer, GoAnywhere MFT et Cleo. À chaque fois, une seule faille dans un seul produit s’est transformée en vol de données massif, généralement pendant un jour férié ou un week-end, quand la vigilance est moindre.
Ce que cela change pour les équipes logicielles aux États-Unis et en Europe
D’abord, sachez quels systèmes de transfert de fichiers vous exploitez réellement. Les serveurs MFT arrivent souvent par un seul service ou une société rachetée et n’apparaissent jamais dans l’inventaire principal. Si vous ne connaissez pas la version, le responsable et l’exposition Internet de chacun d’eux, ce week-end a montré pourquoi il le faut.
Ensuite, préparez-vous à une indisponibilité que vous n’avez pas choisie. Un arrêt préventif bloque les échanges avec les partenaires, les dossiers de sinistres et les dépôts de fichiers clients. Les équipes qui disposaient d’une solution de repli, comme un second canal sécurisé ou une file d’attente conservant les transferts jusqu’au retour du serveur, ont perdu quelques heures. Les autres ont perdu des processus métier. Construisez ce repli avant d’en avoir besoin.
Enfin, les obligations de notification ne démarrent qu’en cas de fuite, mais vous devez pouvoir prouver qu’il n’y en a pas eu. Si un serveur MFT contenant des données personnelles est compromis, le RGPD vous laisse 72 heures pour notifier l’autorité de contrôle. Les entités NIS2 doivent une alerte précoce sous 24 heures, et les organisations américaines soumises à HIPAA ont leurs propres règles. Des journaux d’accès et d’activité conservés hors du serveur sont ce qui vous permet d’affirmer que « rien n’a été exfiltré ».
Qu’est-ce que cela signifie pour les entreprises françaises ?
En France, les plateformes d’échange de fichiers sécurisé sont omniprésentes dans la santé, l’assurance, la banque et les collectivités, souvent installées pour un projet précis puis oubliées. Le premier réflexe est de suivre les bulletins du CERT-FR, qui relaie ce type d’alerte dès qu’une CVE ou des indicateurs sont publiés. En cas de compromission touchant des données personnelles, la notification à la CNIL doit intervenir sous 72 heures (article 33 du RGPD) ; les établissements de santé ont en outre leurs propres circuits de déclaration des incidents. Documenter l’arrêt préventif, la version installée et des journaux conservés hors du serveur vous donne de quoi répondre sereinement à un contrôle comme à vos clients.
Que faire maintenant ?
- Suivre les consignes de l’éditeur. Si vous exploitez Kiteworks, vérifiez que vous avez bien reçu et appliqué l’avis d’arrêt, et ne redémarrez pas avant le feu vert de Kiteworks via ses canaux de support.
- Passer en 9.5.1. Selon Kiteworks, cette version corrige toutes les vulnérabilités connues. Contrôlez chaque instance, y compris les serveurs de test et de reprise d’activité.
- Réduire l’exposition à Internet. Placez les interfaces d’administration derrière un VPN ou un accès zero trust, limitez le trafic entrant aux plages IP des partenaires quand c’est possible et supprimez les serveurs inutilisés.
- Sortir les journaux du serveur. Envoyez les journaux d’accès et d’activité sur les fichiers vers un SIEM central, pour pouvoir les analyser même si le serveur est compromis.
- Chercher, puis surveiller. Recherchez des comptes administrateurs inconnus, des téléchargements volumineux inhabituels et de nouveaux fichiers dans les répertoires web. Surveillez dans les prochains jours la publication d’une CVE ou d’indicateurs de compromission par Kiteworks, la CISA, le CERT-FR ou d’autres CERT nationaux.
Questions fréquentes
Qu'a demandé Kiteworks à ses clients ?
Le 25 septembre 2026, Kiteworks a demandé aux clients qui exploitent eux-mêmes sa plateforme de transfert de fichiers sécurisé, sur site ou dans leurs propres comptes AWS ou Azure, d'éteindre leurs systèmes pendant une fenêtre préventive le week-end du 26 septembre. Kiteworks a indiqué qu'il éteindrait lui-même les instances hébergées.
Kiteworks a-t-il été piraté ?
Selon Kiteworks, non. Son RSSI, Frank Balonis, affirme n'avoir aucun indice d'une compromission des systèmes de Kiteworks ou de ses clients et qualifie l'avis de préventif. Il fait suite à des renseignements crédibles des forces de l'ordre selon lesquels un acteur malveillant pourrait cibler les systèmes Kiteworks.
Existe-t-il une CVE ou un correctif ?
Au 27 septembre 2026, aucune CVE, aucun nouveau build ni aucun indicateur de compromission n'avait été publié. Kiteworks indique que la version 9.5.1 corrige toutes les vulnérabilités connues à ce jour et recommande de l'utiliser. La crainte porte sur une possible faille zero-day, c'est-à-dire une vulnérabilité que l'éditeur ne connaît pas encore.
Quels produits Kiteworks sont concernés ?
L'avis concerne la plateforme Kiteworks. Selon l'éditeur, ses filiales, dont Zivver, DRACOON, totemo, ownCloud, WAMNET, Maytech, Bonfy.ai et 123FormBuilder, ne sont pas concernées.
Pourquoi un serveur de transfert de fichiers est-il si sensible ?
Les solutions de transfert de fichiers managé (MFT) sont exposées en bordure d'Internet et stockent les fichiers échangés avec les partenaires : contrats, données de santé, données financières. Le groupe Clop a exploité en masse des failles zero-day d'Accellion FTA, le prédécesseur de Kiteworks, en 2021, puis de MOVEit Transfer, GoAnywhere et Cleo, dérobant chaque fois les données de centaines d'organisations.
Sources
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