Menace du Progress ShareFile Storage Zone Controller : quels risques pour le stockage de fichiers sur site
Une alerte de sécurité émise par un seul fournisseur a récemment contraint des organisations du monde entier à éteindre physiquement des serveurs de fichiers hébergeant certains de leurs contenus partagés les plus sensibles.
Le 10 juillet 2026, Progress Software a envoyé un e-mail à ses clients ShareFile pour les avertir d’une « menace de sécurité externe crédible » visant les Storage Zone Controllers, le composant serveur sur site qui permet aux entreprises de conserver physiquement leurs fichiers sur leur propre infrastructure tout en utilisant la couche de partage cloud de ShareFile, selon Help Net Security. La consigne était claire : éteignez immédiatement les serveurs Windows hébergeant les SZC et laissez-les hors ligne jusqu’à nouvel ordre.
Le 13 juillet, Progress avait désactivé l’accès général aux comptes ShareFile par précaution et n’avait trouvé aucune preuve qu’un compte ou fichier ait effectivement été consulté par un attaquant. L’entreprise a également commencé à rétablir progressivement l’accès au cloud pour les clients qui ne dépendent pas du composant de stockage sur site.
Mais la consigne principale reste inchangée : si votre organisation utilise un Storage Zone Controller, il doit rester hors ligne tant que Progress n’a pas donné d’autres instructions, et la faille sous-jacente reste non corrigée et non confirmée.
Cette combinaison — menace active, cause racine non résolue et absence de correctif disponible — rend cet incident particulièrement instructif, même pour les organisations qui n’utilisent pas ShareFile. Kiteworks n’a joué aucun rôle dans cet incident et ne gère en aucune façon les données ShareFile ; ShareFile est une plateforme concurrente, exploitée de façon indépendante.
Voici l’analyse de Kiteworks sur les faits publiquement rapportés concernant cet incident et les raisons pour lesquelles ce type d’exposition doit retenir toute l’attention des entreprises qui évaluent leur architecture de transfert et de partage de fichiers, notamment la différence entre un serveur de stockage géré par le client et un déploiement durci et géré par le fournisseur.
Résumé des points clés
1. Progress a désactivé l’accès aux Storage Zone Controllers de ShareFile après avoir détecté une menace crédible. Le fournisseur a envoyé un e-mail à ses clients le 10 juillet leur demandant d’éteindre manuellement les serveurs Windows hébergeant leurs déploiements Storage Zone Controller (SZC) sur site.
2. Aucune compromission de données confirmée à ce jour, mais l’enquête se poursuit. Progress a indiqué le 13 juillet n’avoir aucune indication d’accès non autorisé aux comptes ou données ShareFile, mais demande toujours à ses clients de maintenir leurs serveurs SZC hors ligne pendant que l’accès au cloud est progressivement rétabli.
3. Deux CVE déjà publiés auraient pu être enchaînés pour permettre une exécution de code à distance avant authentification. Les discussions en ligne évoquent CVE-2026-2699 et CVE-2026-2701 comme mécanisme probable, même si Progress n’a pas officiellement confirmé la cause racine.
4. L’exposition concerne exclusivement l’infrastructure gérée par le client, et non le cloud de Progress. Les Storage Zone Controllers sont des serveurs Windows sur site que les organisations installent, exposent à Internet et mettent à jour elles-mêmes, indépendamment du service cloud multi-locataire ShareFile. Un audit des risques qui recense chaque composant de stockage géré par le client et exposé à Internet — en fonction de son niveau de correctifs et de son exposition au pare-feu — constitue la première étape à mener face à ce type d’incident.
5. Ce schéma se répète, ce n’est pas un cas isolé. Les composants de stockage et de transfert de fichiers auto-gérés et exposés à Internet ont déjà servi de point d’entrée dans une série d’incidents majeurs, et c’est précisément ce risque qu’une architecture durcie et centralement corrigée vise à éliminer.
Quels sont les meilleurs cas d’usage de partage sécurisé de fichiers dans les différents secteurs ?
Pour en savoir plus :
Menace sur la sécurité des Storage Zone Controllers ShareFile : que s’est-il passé ?
ShareFile est une plateforme largement utilisée par les entreprises qui doivent stocker et échanger des fichiers avec des tiers — clients, partenaires, sous-traitants, auditeurs. La plupart des déploiements ShareFile fonctionnent entièrement dans le cloud de Progress. Mais une partie des clients, généralement ceux ayant des exigences de localisation des données, de conformité ou de performance, utilisent les Storage Zone Controllers : des serveurs Windows gérés par le client qui hébergent localement le stockage des fichiers, tandis que l’interface cloud de ShareFile gère le partage, les autorisations et la collaboration.
Cette architecture crée un modèle de responsabilité partagée. Progress assure la sécurité et les correctifs de son infrastructure cloud, mais le serveur SZC — système d’exploitation, binaires applicatifs, exposition réseau, rythme de mise à jour — relève du client. Lorsque Progress a envoyé sa notification du 10 juillet, il ne s’agissait pas d’attendre un correctif. Il fallait débrancher la machine, car Progress ne pouvait apparemment pas encore combler la faille.
L’actualisation du 13 juillet a quelque peu tempéré le ton. Progress a indiqué que son enquête n’avait révélé aucune indication d’accès non autorisé aux comptes ou données ShareFile, et a commencé à rétablir l’accès au cloud pour les clients n’utilisant pas de SZC.
C’est une position nettement plus favorable que celle de nombreuses divulgations à ce stade. Mais le fait que les serveurs SZC doivent rester hors ligne, plusieurs jours après l’alerte initiale et sans cause racine confirmée, en dit long : quelle que soit la faille, Progress ne se sent pas suffisamment confiant dans un correctif ou une mesure de mitigation pour autoriser la remise en ligne de ces serveurs.
Pour une plateforme sur laquelle les entreprises comptent afin d’assurer la continuité de leurs échanges de fichiers avec l’externe, « garder le serveur éteint » est l’une des consignes les plus sévères. Cela signifie que le fournisseur a jugé la faille suffisamment grave pour que le risque d’exposition l’emporte sur le coût opérationnel d’une interruption de plusieurs jours pour chaque client concerné.
Storage Zone Controllers : pourquoi le composant sur site est le maillon faible
Si cet incident se concentre sur les Storage Zone Controllers plutôt que sur le service cloud de ShareFile, c’est une question d’architecture, et le même schéma se retrouve sur l’ensemble du marché du transfert sécurisé de fichiers et du partage de fichiers en entreprise.
Les Storage Zone Controllers existent parce que certains clients refusent que leurs fichiers résident exclusivement dans le cloud multi-locataire d’un fournisseur. Cela peut se comprendre : exigences de localisation des données, réglementation sectorielle ou politique interne peuvent justifier un stockage sur site.
Mais ce choix transfère une part importante de la charge de sécurité sur les équipes IT et sécurité du client. Le serveur SZC doit être corrigé selon le calendrier du client, pas celui du fournisseur. Il doit être protégé par le pare-feu et surveillé à l’aide des contrôles d’accès et outils de détection du client.
Et s’il est exposé à Internet — ce qui est souvent le cas, car les tiers doivent pouvoir accéder aux fichiers — il devient une cible directement accessible, hors du périmètre de durcissement et de correctifs du fournisseur.
Ce constat ne vise pas spécifiquement ShareFile. C’est une caractéristique structurelle de tout produit où le fournisseur livre un composant serveur auto-géré et laisse la correction, l’exposition et la configuration à la charge du client.
Une mauvaise configuration de sécurité ou un retard de correctif sur un tel composant ne met pas seulement en danger un fichier : c’est toute la zone de contenu que le serveur était censé protéger qui est à risque, car la plateforme fait généralement confiance à ce serveur pour gérer les opérations de fichiers authentifiées en périphérie du réseau.
La classification des données appliquée au contenu stocké dans ces zones — étiquetant les fichiers contenant des données réglementées telles que des informations personnelles identifiables, des informations médicales protégées ou des informations confidentielles — permet au moins d’identifier les organisations qui devront notifier et remédier en priorité si l’accès au contenu du serveur est confirmé.
Cause racine suspectée : CVE enchaînés et exécution de code à distance avant authentification
Progress n’a pas publié de cause racine officielle à ce jour, et cette nuance est importante. Selon la communauté de la cybersécurité et les discussions en ligne, des attaquants auraient enchaîné deux vulnérabilités déjà publiées, référencées CVE-2026-2699 et CVE-2026-2701, pour obtenir une exécution de code à distance avant authentification sur les serveurs SZC exposés à Internet et non corrigés contre ces deux failles.
L’exécution de code à distance avant authentification est l’un des pires scénarios de vulnérabilité. L’attaquant n’a pas besoin d’identifiants valides, ni de session usurpée, ni d’accès préalable — il peut atteindre le service vulnérable directement sur le réseau et exécuter du code arbitraire sur le serveur.
Si cette hypothèse se confirme, et que la consigne de Progress de couper physiquement les serveurs va dans le sens d’une prise au sérieux de ce scénario, alors tout serveur SZC non corrigé et exposé à Internet devenait une cible potentielle pour quiconque le repérait via un scan Internet classique.
Voici ce qui est confirmé et ce qui ne l’est pas. Progress a confirmé la menace crédible, la suspension des comptes et l’instruction de couper les serveurs SZC. Il n’a pas confirmé que CVE-2026-2699 et CVE-2026-2701 sont en cause, ni si une exploitation a effectivement réussi dans un environnement client.
Les entreprises doivent considérer la théorie de l’enchaînement de CVE comme l’hypothèse de travail principale dans la communauté sécurité, sans la tenir pour une déclaration officielle du fournisseur, jusqu’à publication des conclusions post-incident par Progress.
Un schéma connu : les serveurs de fichiers sur site restent des portes d’entrée
Si cet incident donne une impression de déjà-vu, c’est parce que la catégorie du transfert et du partage de fichiers en entreprise a déjà connu ce scénario. Les serveurs de transfert ou de partage de fichiers auto-gérés et exposés à Internet sont régulièrement devenus le point d’accès initial de campagnes à grande échelle, précisément parce qu’ils sont conçus pour accepter des connexions externes, hébergent souvent des années de données sensibles accumulées, et ne sont pas toujours corrigés aussi rapidement que les infrastructures critiques comme la messagerie ou les systèmes d’identité.
Le point commun de ces incidents n’est pas l’erreur d’un fournisseur. C’est l’architecture : un serveur autonome, exposé à Internet par conception, corrigé selon le calendrier du client, exécutant un logiciel qui n’a pas été conçu en partant du principe que chaque déploiement serait attaqué en continu dès le premier jour.
Quand ce serveur est compromis, l’impact ne se limite pas à une boîte mail ou un lien partagé — c’est tout ce que le serveur était censé stocker et transmettre qui est concerné, ce qui, pour une infrastructure d’échange de fichiers, représente souvent les données les plus sensibles partagées avec l’extérieur : contrats, documents financiers, informations médicales protégées, et données réglementées couvertes par des cadres comme le RGPD ou HIPAA.
Une violation confirmée impliquant un serveur de stockage de fichiers auto-géré contenant des données réglementées déclenche des obligations de notification — l’exposition en matière de conformité s’ajoute à la perturbation opérationnelle.
Les équipes sécurité qui évaluent une plateforme d’échange de fichiers, ShareFile ou autre, doivent poser une question directe sur chaque composant auto-géré de l’architecture : qui applique les correctifs, à quel rythme, et que devient le contenu de ce composant si une faille zero-day apparaît avant le correctif. La réponse à cette question mesure réellement l’exposition, bien plus qu’une comparaison de fonctionnalités.
Le secteur du transfert et du partage de fichiers en entreprise a déjà connu plusieurs versions de ce scénario : appliances ou serveurs auto-gérés, exposés à Internet, exploités bien avant que les organisations concernées n’aient connaissance de la faille.
Chacun de ces incidents impliquait des logiciels installés et exploités par les clients eux-mêmes, exposés à des partenaires externes par conception, et chacun a donné lieu à une course contre la montre similaire à ce que vivent aujourd’hui les clients ShareFile SZC : consignes de patch d’urgence, arrêts forcés, et attente inconfortable pour savoir si, et dans quelle mesure, un attaquant a pu accéder aux données.
Aucun de ces précédents ne préjuge de la cause de l’incident Progress actuel. Mais ils expliquent pourquoi les équipes sécurité considèrent le « serveur de fichiers auto-géré et exposé à Internet » comme une catégorie de risque à part entière, quel que soit le nom du fournisseur.
Les programmes de gestion des risques tiers qui évaluent formellement cette catégorie de risques — pas seulement le SLA cloud du fournisseur, mais aussi les composants gérés par le client livrés avec — constituent le mécanisme de gouvernance qui transforme ce schéma récurrent en exposition documentée et maîtrisée.
Que doivent faire les entreprises exploitant ShareFile SZC dès maintenant ?
Les organisations utilisant actuellement des Storage Zone Controllers doivent suivre à la lettre les consignes de Progress, sans prendre d’initiatives indépendantes en matière de gestion des risques. Cela implique de maintenir les serveurs concernés hors tension jusqu’à confirmation explicite de Progress, de surveiller les canaux de communication officiels du fournisseur plutôt que de s’appuyer sur des résumés indirects, et d’analyser les journaux antérieurs à l’arrêt pour détecter d’éventuels signes du schéma d’exécution de code à distance avant authentification signalé par la communauté sécurité, même si Progress ne l’a pas confirmé. L’intégration de ces journaux dans une plateforme SIEM pour corrélation avec des indicateurs de menaces connues est le moyen le plus rapide de détecter si un accès anormal a précédé l’arrêt.
Au-delà de la réponse immédiate, il est pertinent pour toute organisation exploitant une infrastructure de stockage ou de transfert de fichiers auto-gérée — ShareFile SZC ou autre — de recenser chaque serveur exposé à Internet dans cette catégorie, de vérifier l’état des correctifs pour tous les CVE connus, et de s’assurer que les plans de réponse aux incidents couvrent le scénario où la consigne du fournisseur est « nous n’avons pas encore de correctif, éteignez tout ». Toutes les organisations ne disposent pas d’un plan de réponse aux incidents documenté pour ce type de vulnérabilité sans échéance de résolution, et cet incident est l’occasion de combler cette lacune.
Les équipes achats et gestion des risques fournisseurs doivent également être impliquées, pas seulement les opérations de sécurité. Une menace crédible sans cause racine confirmée ni correctif disponible est autant une question contractuelle que technique : que dit le SLA du fournisseur sur les délais de divulgation, l’organisation dispose-t-elle d’une solution de repli pour partager des fichiers avec l’externe si la plateforme principale reste hors ligne longtemps, et qui valide la reprise d’activité une fois le correctif disponible.
Développer ces réflexes en amont, avant la prochaine alerte, coûte moins cher que d’improviser sous pression. Des politiques de gouvernance des données qui précisent quelles catégories de contenu exigent une plateforme durcie et corrigée centralement — plutôt qu’un composant géré par le client — donnent aux équipes achats les critères pour évaluer ce compromis avant qu’une alerte de menace crédible n’impose le débat.
Comment l’architecture Kiteworks réduit ce type d’exposition
Kiteworks n’a joué aucun rôle dans cet incident. ShareFile est une plateforme tierce que Kiteworks n’exploite pas, ne gouverne pas et sur laquelle il n’a aucune visibilité, et rien dans ce qui précède ne doit être interprété comme un jugement sur la qualité de l’ingénierie ou la gestion d’incident de Progress, qui, selon la chronologie publique, a agi rapidement et communiqué de façon proactive.
Cet incident illustre néanmoins très clairement le profil de risque d’un serveur de stockage sur site, exploité par le client, en périphérie du réseau et dont la gestion des correctifs incombe au client. C’est précisément ce type d’exposition que le partage sécurisé de fichiers Kiteworks et le modèle d’appliance virtuelle durcie de la plateforme Kiteworks visent à éliminer. Plutôt qu’un serveur Windows généraliste exécutant un logiciel de stockage que les clients corrigent à leur rythme, Kiteworks propose une appliance durcie à locataire unique avec un système d’exploitation verrouillé, des correctifs gérés par le fournisseur et aucune surface d’attaque inutile exposée à Internet.
La gouvernance centralisée des accès complète ce dispositif. Au lieu d’un serveur de stockage autonome prenant ses propres décisions d’autorisation en périphérie du réseau, Kiteworks fait transiter les accès fichiers via une architecture Zero trust unifiée, avec contrôles d’accès basés sur les rôles et des règles centralisées, visibles via le tableau de bord RSSI, et soutenues par un journal d’audit unifié retraçant chaque accès, partage ou modification d’autorisation.
Les politiques d’accès basées sur les attributs (ABAC) évaluent le rôle utilisateur, la classification du contenu et le contexte de la demande à chaque accès — garantissant qu’une session ou un identifiant compromis ne puisse pas accéder silencieusement à du contenu hors de son périmètre autorisé. Le contenu au repos est protégé par un chiffrement validé FIPS 140-2, et les organisations qui doivent conserver leurs données dans une juridiction donnée peuvent répondre à cette exigence via les options de déploiement proposées, sans avoir à installer un serveur de stockage auto-géré et corrigé indépendamment.
Si le contenu sensible de ce scénario avait été gouverné selon ce modèle plutôt qu’avec un Storage Zone Controller ShareFile auto-géré, l’architecture de gestion des correctifs et des accès décrite ci-dessus aurait permis de réduire précisément ce type d’exposition — un serveur exploité par le client, exposé à Internet, avec son propre calendrier de correctifs.
Cette affirmation dépend de la configuration, du rythme de correctifs et des choix de déploiement de chaque organisation dans Kiteworks, et ne préjuge en rien de la cause racine que Progress confirmera pour cet incident. Aucune plateforme n’est à l’abri des vulnérabilités ; la vraie question est toujours de savoir quelle part de la gestion des correctifs et des accès incombe au fournisseur ou au client, et à quelle vitesse et à quel niveau cette charge peut être traitée lorsqu’une menace crédible apparaît.
La leçon à retenir pour les responsables sécurité et conformité
L’incident est toujours en cours, et il convient d’adopter une lecture mesurée : un fournisseur a détecté une menace crédible, a agi rapidement en désactivant l’accès et en demandant aux clients d’éteindre les serveurs concernés, et n’a pas encore trouvé de preuve de compromission. C’est une réaction adaptée à une situation incertaine, et Progress mérite d’être salué pour la rapidité de son alerte et de son suivi.
La leçon durable pour les équipes sécurité et conformité en entreprise ne concerne pas ShareFile en particulier. Elle porte sur la réflexion à mener avant de choisir un composant de stockage ou de transfert de fichiers auto-géré et exposé à Internet, plutôt qu’une plateforme durcie et centralement gouvernée par le fournisseur.
Les exigences de localisation des données et de conformité sont bien réelles et ne disparaissent pas parce qu’un serveur auto-géré comporte plus de risques de correctifs. Ce qui change, c’est la question à poser à tout fournisseur avant le déploiement : lorsque — et non si — une menace crédible vise ce composant, qui doit combler la faille, et en combien de temps.
La gestion des risques tiers et de la supply chain liée à l’infrastructure d’échange de fichiers comme celle-ci est un sujet de plus en plus central pour les équipes sécurité et conformité, et il est traité dans le rapport annuel Kiteworks 2026 sur les risques liés à la confidentialité et à la conformité des données. Des incidents comme celui-ci illustrent pourquoi cette vigilance s’intensifie.
Pour en savoir plus sur la réduction de l’exposition liée aux serveurs de stockage de fichiers auto-gérés et exposés à Internet, réservez votre démo sans attendre.
Foire aux questions
Un Storage Zone Controller est un serveur Windows géré par le client qui permet à un utilisateur ShareFile de stocker ses fichiers sur sa propre infrastructure tout en utilisant l’interface cloud de ShareFile pour le partage et la collaboration. Comme c’est le client, et non Progress, qui doit corriger et sécuriser ce serveur, il est devenu le centre de cet incident dès lors que Progress a identifié une menace crédible le visant. Ce modèle de responsabilité partagée se retrouve aussi bien sur les plateformes de partage de fichiers d’entreprise comme ShareFile que sur les produits de transfert sécurisé de fichiers, et c’est la raison pour laquelle les composants sur site présentent généralement plus d’exposition directe que l’infrastructure cloud du fournisseur. Les organisations qui s’appuient sur des composants de serveur de fichiers auto-gérés doivent étendre leur revue de gestion des risques tiers pour évaluer explicitement ces composants en plus du service cloud du fournisseur — le SLA et la posture de sécurité sont souvent différents, et cet incident montre que l’écart entre les deux peut être décisif.
Au 13 juillet, Progress a indiqué n’avoir aucune preuve d’accès non autorisé à des comptes ou données ShareFile, et son enquête se poursuit. C’est un signal positif, mais ce n’est pas une conclusion définitive — Progress continue de demander aux clients de maintenir les Storage Zone Controllers hors ligne, ce qui suggère que la faille sous-jacente reste ouverte. Les organisations doivent suivre ce point via leur propre processus de gestion des risques fournisseurs et s’informer directement auprès de Progress plutôt que de s’appuyer sur des résumés indirects. Toute organisation dont le SZC hébergeait des données réglementées — informations personnelles identifiables (PII), informations médicales protégées (PHI) ou documents confidentiels — doit consulter un conseiller juridique pour évaluer la nécessité d’une notification préventive de violation, l’enquête étant toujours en cours et le périmètre non confirmé.
Non. Ces deux CVE ont été évoqués dans la communauté cybersécurité comme une chaîne d’exploitation plausible permettant l’exécution de code à distance avant authentification contre des serveurs SZC non corrigés, mais Progress n’a pas officiellement confirmé cette cause. Les entreprises doivent la considérer comme l’hypothèse de travail principale et continuer à suivre les communications officielles de Progress pour confirmation, tout en appliquant la précaution générale de suivre les recommandations de réponse aux incidents pour tout composant présentant un profil d’exposition similaire. L’analyse des journaux d’authentification et d’accès SZC de la période précédant l’arrêt dans un SIEM permet de détecter rapidement la présence d’indicateurs d’exploitation, quel que soit le mécanisme CVE finalement confirmé.
Non. Kiteworks n’a joué aucun rôle dans cet incident, et ShareFile est une plateforme concurrente, exploitée indépendamment, que Kiteworks ne gouverne pas et à laquelle il n’a pas accès. L’intérêt pour les clients et prospects Kiteworks est architectural : cet incident met en lumière la catégorie de risques associée aux serveurs de stockage de fichiers auto-gérés et sur site, exposition que le déploiement Kiteworks de partage sécurisé de fichiers durci, corrigé par le fournisseur et à locataire unique vise à réduire. Le Réseau de données privé Kiteworks fournit la couche de gouvernance centralisée — contrôles d’accès unifiés, journalisation d’audit immuable et correctifs gérés par le fournisseur — qui élimine le fossé de responsabilité illustré par cet incident.
Commencez par un inventaire : identifiez chaque serveur de stockage ou de transfert de fichiers auto-géré et exposé à Internet dans l’environnement, vérifiez l’état des correctifs et assurez-vous que les règles de pare-feu limitent l’exposition au strict nécessaire. Évaluez ensuite si le plan de réponse aux incidents de l’organisation prévoit le scénario où un fournisseur divulgue une menace crédible sans correctif immédiat, car c’est précisément la situation des clients Progress aujourd’hui. À plus long terme, pesez la charge continue de correction et de surveillance des composants auto-gérés face à une alternative durcie et centralement gouvernée, basée sur une architecture Zero trust et des journaux d’audit unifiés. Une évaluation des risques qui modélise explicitement le scénario « le fournisseur signale une menace crédible, aucun correctif disponible » pour chaque composant serveur de fichiers géré par le client — en quantifiant l’impact selon la sensibilité des contenus stockés — donne à la direction les éléments pour prioriser la remédiation architecturale plutôt que la poursuite de l’auto-gestion.
Ressources complémentaires
- Article de blog
5 meilleures solutions de partage sécurisé de fichiers pour les entreprises - Article de blog
Comment partager des fichiers en toute sécurité - Vidéo
Kiteworks Snackable Bytes : Partage sécurisé de fichiers - Article de blog
12 exigences essentielles pour un logiciel de partage sécurisé de fichiers - Article de blog
Les options de partage sécurisé de fichiers les plus fiables pour l’entreprise et la conformité