EN
en direct

Kiteworks ordonne à ses clients d’éteindre leurs serveurs six heures face à un possible zero-day

Le 25 septembre 2026, le CISO de Kiteworks a demandé à tous ses clients d’éteindre leurs serveurs pendant six heures le samedi, après un renseignement des autorités fédérales américaines évoquant une attaque imminente. Si vous exploitez une appliance de transfert de fichiers gérée, traitez cette alerte comme un signal : les appliances MFT restent la cible favorite des gangs d’extorsion.

Une rangée de baies serveurs dans une allée sombre de datacenter, tous les voyants éteints sauf un unique indicateur d’alimentation ambre qui reste allumé.

25 septembre 2026. Le CISO de Kiteworks, Frank Balonis, envoie un e-mail à l’ensemble de ses clients pour leur demander d’éteindre leurs serveurs pendant six heures. Samedi 26 septembre 2026. La fenêtre d’arrêt court de 04 h 00 à 10 h 00 en Europe centrale, et de 22 h 00 vendredi à 04 h 00 samedi à New York. 25 septembre 2026. La société confirme avoir reçu un renseignement crédible des autorités fédérales américaines. Pourquoi c’est important : quand un éditeur demande à toute sa base de couper la production, ce n’est jamais une intuition. C’est le signe que la menace est réelle, chiffrée, et que l’éditeur préfère une interruption planifiée à une compromission subie.

Une consigne inédite pour une appliance de transfert

Kiteworks est une plateforme de transfert de fichiers sécurisé utilisée par des administrations, des institutions financières et des entreprises pour échanger des documents sensibles. Demander à des clients d’éteindre une telle appliance n’est pas une recommandation banale : c’est une rupture de service que l’éditeur assume devant ses clients, ce qui situe le niveau de confiance dans le renseignement reçu.

La consigne est précise. Selon le média allemand Heise, qui a révélé l’e-mail, la fenêtre s’applique à l’échelle mondiale, du fuseau AEST australien au fuseau PDT américain. En Europe centrale, les serveurs doivent être arrêtés entre 04 h 00 et 10 h 00 le samedi 26 septembre. La société recommande de couper les systèmes avant la fenêtre, y compris ceux qui ne sont pas directement exposés à Internet.

Le chercheur Jake Knott, de watchTowr, résume l’anomalie : « Il n’existe aucun CVE connu, aucun correctif, aucun détail technique disponible — mais personne ne demande à l’ensemble de sa base de débrancher des systèmes de production un week-end sur une intuition. » Le ton est celui de l’alerte crédible, pas de la routine.

Ce que Kiteworks sait, et ce qu’il ne dit pas

La formulation officielle est volontairement étroite. Interrogée par BleepingComputer, la société confirme avoir reçu « un renseignement crédible de la part des autorités fédérales de renseignement, indiquant qu’un acteur malveillant pourrait tenter de cibler certains systèmes Kiteworks de clients ». Frank Balonis ajoute : « Par excès de prudence, nous avons notifié nos clients directement et recommandé une fenêtre d’arrêt préventif, le temps que nos partenaires des forces de l’ordre et nous-mêmes traitions le sujet. »

Deux phrases bornent l’information. D’abord, l’éditeur affirme n’avoir connaissance d’aucune compromission : « Cette recommandation est préventive, pas une réponse à une brèche confirmée. » Ensuite, il précise que toutes les vulnérabilités connues sont corrigées dans la version 9.5.1, la version courante.

Le mot zero-day n’apparaît que du côté du support. Contacté par Heise pour vérifier l’alerte, le support client de Kiteworks aurait justifié la consigne ainsi : « La raison pour laquelle nous vous demandons d’éteindre les serveurs est de vous protéger contre d’éventuelles attaques zero-day. » Ni le communiqué officiel, ni l’e-mail cité par Heise ne confirment qu’une faille inconnue a été découverte ou exploitée. Le FBI a refusé de commenter, et la CISA n’a pas répondu aux sollicitations de la presse.

Accellion, Clop et la généalogie d’une cible

Pour comprendre pourquoi cette alerte résonne, il faut remonter au nom précédent de l’entreprise : Kiteworks s’appelait Accellion. En décembre 2020, le gang Clop a exploité une faille zero-day dans Accellion FTA, l’ancien produit de transfert de fichiers, pour voler des données chez des dizaines d’organisations de premier plan : l’Université du Colorado, le Washington State Auditor, la banque Flagstar, l’avionneur Bombardier ou encore la chaîne de distribution Kroger.

Clop n’a jamais cessé de cibler cette famille de produits. Le groupe a enchaîné les compromissions de plateformes de transfert : Accellion FTA, GoAnywhere MFT, SolarWinds Serv-U, Cleo et MOVEit Transfer. À chaque fois, le scénario est identique : une faille sur une appliance de transfert, une exfiltration massive de documents, puis un chantage à la publication. Le département d’État américain offre désormais 10 millions de dollars pour toute information reliant les attaques de ce gang à un gouvernement étranger.

« Des années ont passé et le nom a changé, mais l’appétit des attaquants pour les appliances de transfert de fichiers n’a pas diminué, et rien ne laisse penser que cette fois sera différente », prévient Jake Knott. Le territoire est familier, mais pas du genre rassurant.

Pourquoi les appliances MFT restent la proie préférée

Une appliance de transfert de fichiers géré concentre tout ce qu’un gang d’extorsion recherche : des documents sensibles, centralisés, accessibles depuis un point unique exposé à Internet. Contrairement à un poste de travail, elle ne bénéficie pas d’un EDR grand public et ne fait pas l’objet d’une surveillance quotidienne aussi fine. Elle est souvent déployée puis oubliée, avec des mises à jour appliquées en retard.

La valeur se lit dans le modèle économique de l’attaque. Clop et ses imitateurs ne chiffrent pas toujours les fichiers : ils les volent, puis menacent de les publier. Le data-theft extortion ne demande pas de déployer un rançongiciel sur chaque machine, seulement de lire un système de fichiers bien fourni. C’est exactement ce qu’offre une appliance de transfert : le point d’entrée unique vers les échanges les plus confidentiels d’une organisation.

Le corollaire est que la confiance dans l’éditeur devient un enjeu de sécurité à part entière. Kiteworks a choisi la transparence plutôt que le silence : prévenir, même sans CVE, même sans correctif, plutôt que laisser ses clients exposés. C’est une posture rare, et elle mérite d’être saluée autant que d’être suivie.

Ce qu’il faut faire concrètement

Si vous êtes client Kiteworks, appliquez la consigne à la lettre : éteignez l’appliance avant le début de la fenêtre, même si elle n’est pas directement joignable depuis Internet, et laissez-la hors tension pendant toute la durée recommandée. Si vous n’êtes pas certain de votre version, vérifiez que vous êtes sur la 9.5.1 ou une version plus récente, et planifiez la mise à jour.

bash
# Depuis un poste d’administration, vérifier que l’appliance n’est plus joignable
# après la coupure réseau — les deux commandes doivent échouer.
ping -c 4 <ip-appliance>
curl -m 5 -I https://<fqdn-appliance>

Si vous ne pouvez pas éteindre physiquement, isolez l’appliance du réseau : retirez la règle qui l’expose, fermez les flux entrants et sortants, et conservez un accès de console hors bande pour la réactiver. Si vous gérez un parc plus large, profitez de l’alerte pour recenser vos appliances de transfert — y compris les anciennes instances Accellion encore en service — et vérifier qu’elles sont à jour, segmentées et surveillées. Une appliance de transfert ne doit jamais être le seul maillon qui protège des documents sensibles.

Un nouveau type d’alerte

L’alerte Kiteworks inaugure une catégorie que les équipes de sécurité devront apprendre à traiter : l’arrêt préventif sur renseignement, distinct du cycle CVE-correctif. Dans le cycle classique, une faille est identifiée, notée, corrigée, puis déployée. Ici, l’ordre est inversé : le renseignement précède toute faille publique, et la réponse est une coupure, pas un patch.

Pour un CISO, cela change la règle de décision. Une notification d’éditeur n’est plus seulement un élément de veille à classer : elle peut devenir un ordre opérationnel à exécuter dans la journée. La métrique à suivre n’est plus seulement le temps de correction, mais le temps de réaction à une alerte crédible — et la capacité à arrêter un service sensible sans improviser, en s’appuyant sur un runbook écrit à froid. Les organisations qui en ont un réagiront en minutes ; les autres découvriront, un samedi, qu’éteindre une appliance n’est pas une évidence.

Verdict

Si vous êtes client Kiteworks, éteignez. Une interruption de six heures un samedi coûte infiniment moins cher qu’une exfiltration de documents clients, et la crédibilité du renseignement justifie la rupture de service. Si vous exploitez n’importe quelle appliance de transfert de fichiers, traitez cette alerte comme un signal pour tout le segment : les gangs d’extorsion continuent de cibler ces produits parce qu’ils y trouvent un retour sur effort imbattable, et Kiteworks ne sera pas le dernier éditeur à demander un arrêt préventif. La leçon n’est pas « méfiez-vous de Kiteworks », mais « méfiez-vous de ce que vous laissez derrière une appliance de transfert ».

Références

Le brief cyber, chaque mardi

Les failles qui comptent, les correctifs à appliquer, en dix minutes de lecture.

Pas de spam. Désinscription en un clic.
à lire ensuite

Sur le même sujet

CVE-2026-65660 transforme le spoofing SharePoint de Microsoft en exécution de code à distance

Microsoft présentait CVE-2026-65660 comme un spoofing à CVSS 6,5 ; le chercheur Dinh Ho Anh Khoa démontre qu’il s’agit d’une injection de code (CWE-94) aboutissant à une exécution de code à distance authentifiée, et la CISA l’a ajoutée au KEV le 25 septembre 2026 après des attaques observées. Appliquez le correctif du 11 août et auditez vos serveurs SharePoint 2016, 2019 et Subscription Edition.

La CISA ajoute au KEV deux failles WSO2 et Adobe Commerce activement exploitées

Le 24 septembre 2026, la CISA a inscrit au catalogue KEV la faille de traversal de chemin CVE-2026-5430 chez WSO2 et l’autorisation défaillante CVE-2026-71362 chez Adobe Commerce et Magento, toutes deux exploitées en conditions réelles. Les agences fédérales américaines doivent corriger avant le 27 septembre, et toute organisation qui expose ces produits doit faire de même sans attendre.

← Retour au fil

Tapez au moins deux caractères.

↑ ↓ naviguer ↵ ouvrir esc fermer