Une faille critique dans Streamlit expose des dashboards boursiers aux manipulations, facilitant la prise de contrôle de comptes cloud mal configurés et déstabilisant potentiellement les marchés.

 

 

Cato Networks révèle une faille grave dans le widget st.file_uploader de Streamlit : l’absence de validation côté serveur permet d’exploiter cette vulnérabilité pour prendre le contrôle d’instances cloud mal configurées. À travers une démonstration, les chercheurs montrent comment cette faille peut être utilisée pour falsifier des tableaux de bord financiers en temps réel et déclencher des chocs artificiels sur les marchés. Bien que patchée dans la version 1.43.2, cette vulnérabilité souligne les risques liés à de mauvaises pratiques de configuration en environnement cloud. Vigilance, compartimentation et corrections rapides sont essentielles pour éviter tout scénario de manipulation malveillante.

Origine et nature de la vulnérabilité Streamlit

Streamlit, outil open source largement adopté pour la visualisation de données, intègre une fonction de téléchargement de fichiers, st.file_uploader, censée restreindre les types de fichiers acceptés. Or, cette vérification était uniquement exécutée côté client, dans le navigateur. Une faille majeure : en interceptant la requête, un attaquant pouvait facilement modifier l’extension du fichier envoyé, contournant ainsi la sécurité supposée.

L’équipe de Cato CTRL a mis en lumière cette vulnérabilité en février 2025. Elle permettait, entre autres, d’envoyer un fichier Python masqué sous une extension autorisée (ex. .txt), puis exécuté à distance. Cette négligence de validation côté serveur est d’autant plus critique qu’elle concerne un outil utilisé dans de nombreux dashboards de monitoring, y compris dans le secteur financier.

Scénario d’exploitation et conséquences financières

Imaginez une interface de trading qui affiche des données fausses en temps réel : cours erronés, signaux d’achat déclenchés artificiellement, volatilité non justifiée. C’est exactement ce que la démonstration de Cato a mis en scène.

En chargeant un fichier piégé dans une instance Streamlit exposée sans protections réseau (pare-feu, authentification, segmentation), l’attaquant peut obtenir un shell, escalader les privilèges et altérer les données affichées aux analystes financiers. Dans des conditions réelles, cela pourrait provoquer des prises de décisions erronées par des investisseurs, avec des impacts économiques significatifs, voire des déclenchements d’ordres automatiques sur les marchés.

La faille a été corrigée dans la version 1.43.2 de Streamlit en mars 2025. Pourtant, la plateforme a refusé de la qualifier de vulnérabilité de sécurité, estimant que la responsabilité de validation incombait aux développeurs d’applications, et non au framework. Cato Networks a donc tenté de faire enregistrer une CVE via MITRE – en vain jusqu’à aujourd’hui.

Cette faille met en lumière une vérité souvent négligée dans les environnements cloud : la configuration est aussi critique que le code. La vulnérabilité n’exploitait pas une faille dans l’infrastructure cloud sous-jacente (AWS, Azure, GCP), mais dans le déploiement de l’application elle-même. Dans le modèle de responsabilité partagée, c’est bien au client qu’incombe la protection de ses assets.

Il faut donc :

Isoler les instances Streamlit derrière des contrôles d’accès forts ;

Appliquer le principe du moindre privilège dans les autorisations ;

Mettre à jour systématiquement les dépendances open source ;

Effectuer des tests de sécurité sur les entrées utilisateur, y compris les fichiers.

Cato Networks recommande en outre d’utiliser des solutions capables de détecter les comportements anormaux dans les processus cloud, comme les accès non légitimes ou les modifications suspectes de fichiers backend. Ce cas rappelle que même une fonction d’apparence banale peut devenir un vecteur d’attaque dévastateur, surtout dans un contexte de finance algorithmique et de visualisation temps réel. L’ingénierie logicielle ne peut se permettre de reléguer la sécurité à un second plan.