Vous êtes-vous déjà demandé pourquoi le stockage de fichiers « privé » de votre entreprise ressemble plus à un seau percé qu’à un coffre-fort ?
Les vulnérabilités de ShareFile — plus précisément deux critiques signalées par WatchTowr — font voler en éclats cette illusion. CVE-2026-2699 et CVE-2026-2701 s’enchaînent pour une exécution de code à distance sans authentification, transformant un outil de collaboration en terrain de jeu pour les attaquants. Et le clou du spectacle : tout commence par quelque chose d’aussi sournois qu’une redirection qui déraille.
ShareFile est censé permettre un partage sécurisé de fichiers entre clouds et environnements on-prem. Mais les attaquants n’ont pas besoin de credentials. Ils ciblent un endpoint admin, déclenchent une faille Execution After Redirect (EAR). Dans un navigateur normal ? Ça redirige vers la connexion. Mais modifiez la réponse — supprimez cet en-tête Location — et hop, vous voilà sur la page de config des Storage Zones.
De là ? Le carnage. Reconfigurez les zones pour pointer vers des buckets AWS S3 contrôlés par l’attaquant. Exfiltrez les fichiers lors de la synchronisation. Ou pire, forcez les contrôleurs victimes à rejoindre des zones malveillantes, récupérez des droits admin pour vider les données n’importe où.
« Nous pouvions modifier le Storage Repository de la victime pour qu’il pointe vers un bucket AWS S3 sous notre contrôle, ce qui signifie que lors de la synchronisation ou du téléversement de fichiers vers l’instance, ils étaient envoyés vers un repository que nous contrôlions, exfiltrant ainsi des fichiers sensibles », note WatchTowr.
Comment une simple redirection tourne-t-elle à l’Armageddon des administrateurs ?
Tout se résume à des vérifications d’authentification bâclées — ou inexistantes après redirection. L’architecture de ShareFile fait trop confiance au flux. Les pages admin ? Censées être localhost only. Mais en bidouillant HTTP, on contourne ça. Les attaquants modifient les réponses en transit, capturent les configs, altèrent les passphrases. Soudain, votre Storage Zone Controller passe du bon côté à la face obscure.
Et ce n’est pas discret. Les fonctionnalités intégrées permettent de rediriger les uploads vers les webroots. Des emplacements arbitraires. Voilà CVE-2026-2701 qui attend dans l’ombre — un téléversement de fichiers sans restriction. Déposez un web shell. Exécutez du code. Partie terminée.
WatchTowr les a chainées : EAR pour l’accès, upload pour la RCE. Sans connexion. Sans authentification. Sur les instances vulnérables.
Ce n’est pas qu’un bug. C’est une pourriture architecturale dans le partage de fichiers hybride. ShareFile (propriété de Citrix) pousse les contrôleurs on-prem pour le « contrôle » — mais ils deviennent des cibles juteuses. Ça rappelle les fuites d’API Dropbox de 2012, où des misconfigs ont déversé des millions de fichiers. L’histoire se répète : promettre la sécurité, livrer des portes dérobées.
Mais pourquoi maintenant ? Les entreprises s’accrochent aux partages de fichiers on-prem au milieu de la paranoïa cloud. ShareFile vend ce rêve hybride. Pourtant ces failles hurlent : votre zone « privée » est publique si on y regarde de près.
Pourquoi cela ravage-t-il votre réseau ?
Imaginez. L’attaquant contrôle le contrôleur. Les fichiers transitent par son S3. Ou des shells surgissent dans les webroots, pivotant latéralement. CVSS 9.8 et 9.1 ? C’est niveau apocalypse.
« Des produits comme celui-ci permettent généralement de spécifier l’emplacement de stockage des fichiers. Nous pouvions simplement reconfigurer ShareFile pour stocker les fichiers téléversés dans un emplacement potentiellement dangereux, comme le répertoire webroot de l’application », explique WatchTowr.
Plus profondément : les Storage Zones de ShareFile décentralisent le contrôle — super pour l’échelle, désastreux pour la segmentation. Un maillon faible mène à l’exfiltration, la RCE, la persistance. Si vous synchronisez des docs sensibles (juridique, RH, PI), c’est votre vecteur de brèche.
Mon avis ? Le communiqué de Citrix tournera ça en « patché rapido » — signalé en février, corrigé en 5.12.4. Mais ça masque le virage : le partage de fichiers on-prem agonise. Les solutions cloud-native comme Box ou Dropbox lissent ces angles avec le zero-trust. ShareFile s’accroche au legacy, et ça se voit. Prono : 2025 verra des migrations massives post-cette affaire.
Paragraphe court pour le punch : Patch maintenant.
Le correctif — et le vrai réveil
Versions antérieures à 5.12.4 ? Vulnérables. 6.x en sécurité. Mais en fouillant le code, WatchTowr a vu la pagaille : pas de gardes d’auth sur les endpoints sensibles, upload sans contrôles. Corrigé ? Oui. Systémique ?
Non. Ça expose la ligne de faille du partage de fichiers. Les admins supposent qu’un « appliance » signifie sécurisé. Faux. L’exposition réseau invite les astuces EAR. À l’épreuve du futur ? Lâchez les silos pour du cloud API-gated.
Comparez aux galères Citrix NetScaler — même famille, même saignement. La CISA surveille du similaire. À vous : auditez les zones, segmentez, surveillez les uploads.
Et cet angle unique ? Ces failles rappellent l’RCE Apache Struts chez Equifax (2017) — tweaks de config menant à une compromission totale. ShareFile n’est pas une web app ; c’est la colonne vertébrale entreprise. Enjeux plus élevés.
🧬 Analyses connexes
- En savoir plus : Iran’s April 1 Deadline Puts Apple, Google in Crosshairs
- En savoir plus : Iran’s 27-Day Blackout Fuels Global Phishing Frenzy and Wiper Warnings
Questions fréquemment posées
Quelles sont les vulnérabilités critiques ShareFile CVE-2026-2699 et CVE-2026-2701 ?
Ce sont une faille EAR pour un accès config sans authentification et un téléversement arbitraire de fichiers pour RCE, chainables sans connexion.
Mon instance ShareFile est-elle protégée contre la RCE sans authentification ?
Passez à 5.12.4+ ou 6.x ; les versions antérieures sont à haut risque si exposées.
Comment les failles ShareFile mènent-elles à l’exfiltration de données ?
Les attaquants reconfigurent les zones vers un S3 attaquant, synchronisant les fichiers victimes vers l’extérieur.
