Les violations MFT persistent : les failles des architectures héritées révélées

L’histoire des failles de transfert sécurisé de fichiers (MFT) dans les années 2020 ne se résume pas à un seul éditeur malchanceux. Elle illustre un schéma architectural à l’échelle d’une catégorie, générant des échecs prévisibles. La divulgation du 30 avril 2026 de la CVE-2026-4670, une faille d’authentification contournée (CVSS 9,8) dans MOVEit Automation, et de la CVE-2026-5174, une élévation de privilèges en chaîne, rendent ce schéma impossible à attribuer à la malchance.

Résumé des points clés

1. La divulgation de 2026 marque la troisième vague critique en trois ans. Le 30 avril, Progress a révélé deux vulnérabilités MOVEit Automation, dont une notée CVSS 9,8. Aucun correctif temporaire n’existe.
2. Ce n’est pas un problème lié à un seul éditeur. Cleo en décembre 2024, CrushFTP en mars 2025, Wing FTP en juillet 2025, puis MOVEit à nouveau en avril 2026 : quatre failles critiques MFT en dix-huit mois, chez quatre éditeurs différents.
3. La plupart des incidents MFT ne sont pas des zero-days. Cinquante-neuf pour cent des organisations ont subi un incident lié au MFT l’an dernier, et les failles se concentrent autour de données non chiffrées au repos, absence d’intégration SIEM et systèmes fragmentés.
4. L’ampleur des dégâts dépend de l’architecture, pas de la rapidité du patch. Lorsqu’une même classe de vulnérabilité touche une appliance durcie à locataire unique avec défense en profondeur, l’impact réel chute de plusieurs ordres de grandeur — le CVSS 10 de Log4Shell a été contenu à CVSS 4 dans un tel environnement.
5. Le prochain patch n’est pas la solution. Le vrai choix architectural consiste à savoir si la sécurité repose sur la configuration client d’une application web exposée à Internet, ou sur une fonction produit d’une appliance durcie avec un moteur de règles unique et un seul journal d’audit.

Trois ans. Onze CVE révélées sur les gammes MOVEit. Cinq notées CVSS 9,0 ou plus. À chaque vague, les mêmes conditions architecturales : application web exposée à Internet, système d’exploitation géré par le client, base de données accessible directement par l’application, et stockage de fichiers sur la même frontière de confiance que le reste.

La vague de 2023 a fait la une. Le 27 mai, le groupe Cl0p a lancé une exploitation massive de la CVE-2023-34362, une faille d’injection SQL (CVSS 9,8) dans MOVEit Transfer. Progress a publié un patch quatre jours plus tard. Mandiant a indiqué que le délai moyen entre la compromission initiale et l’exfiltration des données était d’environ cinq minutes. À la fin de l’année, plus de 2 700 organisations avaient été compromises, exposant les données personnelles d’environ 93 millions de personnes. CISA a estimé que plus de 8 000 entités dans le monde étaient concernées en tenant compte de l’exposition en cascade.

La vague de 2024 a concerné deux contournements d’authentification — CVE-2024-5805 et CVE-2024-5806, toutes deux notées CVSS 9,1. La Shadowserver Foundation a observé des tentatives d’exploitation dans les heures suivant la divulgation. WatchTowr Labs a publié un code de preuve de concept fonctionnel le jour même. La divulgation de 2025 (CVE-2025-2324) a touché le module SFTP Shared Accounts. Et l’avis de 2026 boucle la boucle : un contournement d’authentification CVSS 9,8 et une élévation de privilèges en chaîne dans MOVEit Automation, avec Shodan identifiant plus de 1 440 instances exposées à Internet, dont 16 reliées à des administrations américaines locales ou d’État.

Un éditeur peut avoir du mauvais code de temps en temps. Une catégorie souffre d’une mauvaise architecture à chaque fois.

Le schéma inter-éditeurs qui prouve l’origine architecturale

Si MOVEit était le seul exemple, le dossier serait circonstanciel. Ce n’est pas le cas. Sur les dix-huit mois de décembre 2024 à avril 2026, quatre plateformes de transfert sécurisé de fichiers ont publié des vulnérabilités critiques, chacune exploitée rapidement après divulgation publique.

Cleo, décembre 2024. Cl0p a exploité en masse une chaîne de vulnérabilités dans les produits Harmony, VLTrader et LexiCom de Cleo. Plus de 300 organisations victimes dans les secteurs du transport, de l’industrie et de la chaîne alimentaire.

CrushFTP, mars 2025. Un contournement d’authentification sur les serveurs CrushFTP a été suivi d’une divulgation en juillet 2025 permettant une prise de contrôle complète du serveur.

Wing FTP, juillet 2025. Une exécution de code à distance non authentifiée via injection Lua a permis d’obtenir des privilèges root et SYSTEM.

MOVEit, avril 2026. L’avis actuel. Aucun correctif temporaire. Mise à jour complète requise.

Le Rapport Dragos 2026 OT/ICS Cybersecurity replace ce schéma dans le contexte opérationnel. En 2025, les affiliés ransomware ont ciblé de plus en plus les sociétés d’ingénierie, fournisseurs de services OT et éditeurs ICS — soit le cœur de clientèle des plateformes MFT historiques. L’exploitation par Cl0p de Cleo MFT, CrushFTP, puis Oracle E-Business Suite, a montré comment une seule faille dans un logiciel de transfert de fichiers largement déployé peut exposer des documents opérationnels, des données d’ingénierie et des intégrations client-fournisseur dans des centaines d’organisations industrielles — même sans toucher directement au réseau OT.

Voilà à quoi ressemble le risque architectural à l’échelle d’une catégorie. Le nom de l’éditeur change. Le mode d’échec reste identique.

Ce que 59 % des organisations savent déjà par expérience

Le constat le plus frappant du rapport Kiteworks Data Security and Compliance Risk : enquête MFT 2025 est que le problème des incidents MFT n’est ni ponctuel, ni principalement lié aux zero-days. Cinquante-neuf pour cent des organisations ont subi un incident de sécurité lié au MFT l’an dernier. Seules 39 % y ont échappé.

La ventilation selon le niveau d’automatisation est encore plus révélatrice. Les organisations ayant automatisé moins de 50 % de leurs transferts via MFT affichent un taux d’incident de 71 %. Celles entre 50 et 69 % d’automatisation signalent 61 %. Entre 70 et 89 %, le taux tombe à 52 %. Et les 13 % d’organisations ayant atteint 90 à 100 % d’automatisation de bout en bout ne rapportent que 29 % d’incidents.

Le rapport 2025 présente trois failles structurelles. La première concerne le chiffrement : 76 % des organisations chiffrent les données MFT en transit, mais seules 42 % chiffrent les données au repos avec AES-256. Les agences gouvernementales ne chiffrent que 8 % des données MFT stockées. Le secteur santé, 11 %. Les données en stockage — celles accessibles en cas de faille MFT — sont les moins protégées.

La seconde faille est la visibilité. Soixante-trois pour cent des organisations n’ont aucune intégration SIEM ou SOC avec leur environnement MFT. Leurs SOC surveillent le réseau et les endpoints, mais les transferts de fichiers — souvent les plus sensibles — restent dans l’ombre.

La troisième est la complexité. Soixante-deux pour cent des organisations gèrent des architectures fragmentées entre MFT, messagerie, partage de fichiers et formulaires web. Chaque outil a ses propres règles, son propre journal d’audit, sa propre configuration. Chaque écart entre eux est un point où la preuve disparaît.

Ce ne sont pas des failles exotiques. Ce sont des contrôles fondamentaux qui auraient dû être la norme il y a dix ans.

Pourquoi l’architecture MFT échoue toujours de la même façon

Quatre propriétés architecturales définissent la catégorie MFT historique, chacune correspondant à un mode d’échec documenté dans les CVE.

Surface applicative web exposée à Internet. Toute plateforme MFT historique impose une interface web publique pour les partenaires. C’est par cette surface que toutes les injections SQL, contournements d’authentification et failles de validation d’entrée ont atteint la plateforme. Impossible de la supprimer sans casser la fonction principale du produit.

Infrastructure gérée par le client. Les plateformes MFT historiques tournent sur des environnements Windows Server, IIS, SQL Server durcis par le client, avec des contrôles réseau configurés par le client. La sécurité dépend du durcissement correct de chaque composant par le client. Toute mauvaise configuration devient une CVE potentielle. Chaque cycle de patch est à la charge du client.

Aucune isolation une fois à l’intérieur. Une fois l’exécution de code à distance obtenue dans un environnement MFT historique, rien n’isole l’application de la base de données, du stockage de fichiers ou des identifiants de stockage cloud. L’ampleur des dégâts, c’est la plateforme. La chaîne d’attaque Cl0p 2023 l’a illustré : injection SQL sur la couche web, exposition des jetons sysadmin, faille de désérialisation convertissant le jeton en exécution de code à distance, et un web shell ASP.NET nommé LEMURLOOT servant d’intermédiaire pour l’exfiltration via des en-têtes HTTP personnalisés. Aucun maillon de la chaîne n’a opposé de résistance significative entre les couches.

Cycle de patch sans solution temporaire. Chaque CVE MOVEit révélée a nécessité une mise à jour complète. L’exploitation a été observée dans les heures suivant la divulgation, à plusieurs reprises. Le cycle s’accélère : plus la plateforme reste en production, plus les CVE s’accumulent, plus il devient difficile de justifier son maintien en exploitation.

Le rapport Kiteworks Data Security and Compliance Risk : Prévisions 2026 résume ainsi le problème : les infrastructures historiques ne peuvent plus répondre aux exigences actuelles de gouvernance des données. Le partage de fichiers fragmenté et les solutions MFT vieillissantes n’offrent pas les fonctions de sécurité nécessaires pour garantir la maîtrise, la traçabilité ou la souveraineté des données. Le rapport 2026 montre que seules 39 % des organisations disposent d’un échange de données unifié avec contrôle, 34 % ont une couverture partielle, 16 % n’utilisent que des solutions spécifiques à chaque canal, 11 % n’ont quasiment aucune gouvernance.

Soixante et un pour cent des organisations tentent de bâtir des journaux d’audit probants sur une infrastructure fragmentée. Cette infrastructure ne permet pas de répondre aux attentes réglementaires actuelles.

Ce que font les régulateurs face à ce schéma

Chaque faille MFT crée une trace réglementaire. Et les régulateurs savent de mieux en mieux les lire.

La SEC a ouvert une enquête officielle sur Progress Software le 2 octobre 2023, après la campagne Cl0p MOVEit. Selon le SEC Item 1.05, les sociétés cotées doivent déclarer tout incident cyber majeur sur le formulaire 8-K dans les quatre jours ouvrés. Ce délai commence dès que l’incident est jugé significatif — et depuis Cl0p, la SEC a clairement indiqué que les retards d’évaluation de matérialité sont eux-mêmes surveillés.

Dans la santé, les Centers for Medicare and Medicaid Services ont signalé la faille MOVEit ayant touché 3,1 millions de personnes au HHS Office for Civil Rights. Le standard « reasonable safeguards » de la règle de sécurité HIPAA (45 CFR §164.308) s’applique, et les pénalités OCR peuvent atteindre 2,1 millions de dollars par an et par niveau de violation.

Dans l’UE, l’article 32 du RGPD impose des mesures techniques et organisationnelles adaptées au risque, et la directive NIS 2, en vigueur depuis octobre 2024, ajoute une obligation d’alerte précoce sous 24 h et de notification d’incident sous 72 h. L’amende de 14 millions de livres infligée par l’ICO britannique à Capita en octobre 2025 cite directement l’article 32.

En Australie, le Privacy Amendment Act 2024 a porté les sanctions civiles maximales à 50 millions AUD ou 30 % du chiffre d’affaires ajusté pour toute atteinte grave ou répétée à la vie privée. Les signalements de violations notifiables auprès de l’Office of the Australian Information Commissioner ont augmenté de 25 % en 2024.

Après trois vagues critiques MFT en trois ans, la question du régulateur n’est plus de savoir si la faille était prévisible. C’est de savoir si continuer à exploiter une plateforme avec un tel historique de divulgations constitue encore une mesure raisonnable de protection.

L’alternative architecturale

Remplacer un produit MFT historique par un autre ne fait que relancer le cycle des patchs sans changer le modèle sous-jacent. La réponse architecturale, c’est un modèle différent.

Kiteworks centralise les échanges de données — messagerie, partage de fichiers, SFTP, MFT, formulaires web, API, intégrations IA — sur une appliance virtuelle durcie unique avec un moteur de règles et un journal d’audit. L’appliance intègre un pare-feu réseau, un pare-feu applicatif web, un système de détection d’intrusion et un système d’exploitation allégé maintenu par Kiteworks. Les clients ne configurent pas l’OS, ne gèrent pas la base de données, ne patchent pas la pile sous-jacente séparément. Les mises à jour complètes en un clic couvrent l’ensemble de l’appliance — application, runtime, OS, bibliothèques — en une seule opération coordonnée.

Dans cette appliance, une architecture en couches isole la couche web de la base de données et du stockage de fichiers. Une couche applicative compromise ne peut interroger directement la base ni obtenir les clés de fichiers. Les fichiers au repos sont protégés par deux couches de chiffrement indépendantes — au niveau fichier et au niveau disque — avec des modules cryptographiques validés FIPS 140-3. TLS 1.3 protège les données en transit. Une gestion des clés contrôlée par le client est disponible pour les besoins de souveraineté.

Le modèle administratif est également clé. Dans le MFT historique, la console d’administration est le système d’exploitation lui-même. Les administrateurs ont accès au code serveur, au système de fichiers, et peuvent installer des applications. Un attaquant qui atteint la console d’administration accède à tout. Dans le modèle Kiteworks, les administrateurs n’ont aucun accès à l’OS, au système de fichiers, au code applicatif ou à la base de données. La console d’administration est une interface web avec contrôle strict des accès par rôles. Les fonctions d’administration agissent uniquement via des appels API spécifiques. Les administrateurs ne peuvent pas installer de logiciels sur l’appliance.

La défense en profondeur n’est pas théorique dans cette architecture. Lors de Log4Shell en décembre 2021, la faille Log4j était notée CVSS 10.0. Au sein de l’appliance Kiteworks, les contrôles en couches ont réduit l’impact réel à CVSS 4.0 avant l’arrivée du patch officiel. La prochaine CVE critique ne s’annoncera pas. Ce qui détermine l’ampleur des dégâts, c’est l’architecture en place au moment où elle survient.

Que doivent faire les organisations exploitant un MFT historique ?

Premièrement, patcher immédiatement. Si vous exploitez MOVEit Automation, mettez à jour vers 2025.1.5, 2025.0.9 ou 2024.1.8 avec l’installeur complet. Progress confirme qu’aucun correctif temporaire n’existe pour CVE-2026-4670 ou CVE-2026-5174. La même urgence s’applique à tout environnement MFT historique encore maintenu — le délai entre divulgation et exploitation se compte en heures chez plusieurs éditeurs.

Deuxièmement, auditer les écarts. Le rapport Kiteworks Data Security and Compliance Risk : enquête MFT 2025 montre que 63 % des organisations n’ont pas d’intégration SIEM avec leur MFT, 58 % ne chiffrent pas les données MFT au repos avec AES-256, et 33 % n’ont pas adopté le contrôle d’accès basé sur les attributs. Cartographiez votre environnement MFT selon ces trois critères avant que la prochaine divulgation ne vous y oblige dans l’urgence.

Troisièmement, inventorier les canaux. La plupart des organisations échangent des données sensibles via cinq à dix outils différents — messagerie sécurisée, plateformes de partage de fichiers, serveurs SFTP, MFT, formulaires web, API et de plus en plus d’intégrations IA. Les données du rapport Kiteworks Prévisions 2026 montrent que 61 % des organisations disposent d’une infrastructure d’échange de données fragmentée, ce qui empêche de bâtir des journaux d’audit probants. Recensez chaque canal par lequel des données réglementées sortent de votre périmètre, puis vérifiez lesquels partagent un moteur de règles et lesquels non.

Quatrièmement, intégrer l’architecture au cycle de planification. Migrer hors d’une plateforme MFT historique est un vrai projet, avec de vrais délais. L’objectif n’est pas de migrer en un trimestre, mais d’inscrire l’alternative architecturale au prochain budget, à la prochaine revue d’architecture ou à la prochaine fenêtre de mise à jour majeure — avant que l’historique des CVE n’impose la discussion en mode crise. Les données du rapport Kiteworks MFT 2025 montrent que les 13 % d’organisations ayant automatisé 90 à 100 % de leurs flux enregistrent moins de la moitié d’incidents par rapport à celles qui gèrent encore beaucoup de tâches manuelles. L’investissement dans la consolidation est rentabilisé en un cycle de divulgation.

Cinquièmement, mesurer ce qui compte vraiment. La rapidité de patch n’est pas le bon indicateur. C’est l’ampleur des dégâts qui compte. Deux organisations touchées par la même CVE n’auront pas le même résultat si l’une exploite une appliance durcie à locataire unique et l’autre une application web gérée par le client sur une frontière de confiance plate. Selon le rapport Black Kite 2026 sur les fuites tierces, le délai médian de divulgation d’une faille tierce est de 73 jours. L’architecture qui limite l’exposition pendant ces 73 jours détermine l’impact réglementaire et réputationnel.

L’historique MOVEit n’est pas une histoire sur Progress Software. C’est l’histoire d’une catégorie d’architecture d’échange de données arrivée au terme de sa viabilité face aux menaces actuelles. La prochaine faille critique MFT est déjà en cours de découverte. Le modèle de plateforme que vous aurez choisi avant la divulgation déterminera le titre dans lequel vous apparaîtrez.