Sysdig a documenté une opération d’extorsion dans laquelle un agent basé sur un modèle de langage aurait automatisé presque l’ensemble de l’attaque sans intervention humaine continue. La campagne, nommée JadePuffer, a débuté en exploitant une instance vulnérable de Langflow et s’est terminée par le chiffrement et la suppression de bases de données de production. Ce cas est particulièrement pertinent car l’intelligence artificielle n’a pas développé de nouvelles techniques : elle a enchaîné des failles connues, des identifiants valides et des configurations à risque à une vitesse difficile à égaler par un opérateur humain.

Les clés techniques de JadePuffer en 20 secondes

• Vecteur initial : exploitation de CVE-2025-3248 sur une instance de Langflow exposée à Internet.
• Gravité de la vulnérabilité : exécution à distance de code Python sans authentification sur des versions antérieures à Langflow 1.3.0.
• Comportement de l’agent : le système analysait les erreurs, modifiait ses scripts, et tentait à nouveau sans attendre de nouvelles instructions.
• Chercheur de secrets : il traçait des clés de fournisseurs d’IA, des identifiants cloud, des accès à des bases de données et des portefeuilles de cryptomonnaies.
• Persistence : il ajouta une tâche à crontab pour communiquer avec l’infrastructure de l’attaquant toutes les 30 minutes.
• Progression vers la production : il accéda à un serveur avec MySQL et Nacos via des identifiants d’administrateur.
• Impact : il chiffré 1 342 configurations Nacos et effaça complètement des tables et schémas.
• Impossible à déchiffrer : la clé n’a pas été conservée ni transmise à l’attaquant, rendant une demande de rançon ineffectuelle pour récupérer les données.

JadePuffer n’était pas une intelligence artificielle cherchant des victimes de sa propre initiative. Une préparation humaine préalable avait eu lieu : quelqu’un avait sélectionné l’infrastructure, créé l’environnement de contrôle et fourni une partie des accès nécessaires. À partir de là, l’agent a assumé une grande partie de l’exécution, allant de la reconnaissance à la destruction de l’information.

Ce nuance ne diminue pas l’importance du cas. Jusqu’à présent, une grande partie de l’usage criminel de l’IA se concentrait sur la rédaction de phishing, la génération de variantes de malwares ou l’aide à des opérateurs peu expérimentés. Ici, le modèle a agi comme un exécutant persistant, capable d’observer le résultat de chaque ordre, de corriger ses erreurs et de choisir la prochaine étape.

Langflow a été la porte d’entrée

L’accès initial s’est produit via CVE-2025-3248, une vulnérabilité critique de Langflow permettant à un attaquant distant d’exécuter du code Python sans authentification.

Langflow est une plateforme visuelle pour construire des applications et des flux avec des modèles de langage. Étant souvent déployée près de clés sensibles : API d’OpenAI, Anthropic, Google, DeepSeek ou autres fournisseurs, tokens cloud, connexions à des bases de données et secrets utilisés par des applications internes.

La vulnérabilité concernait un endpoint lié à la validation de code. Un attaquant pouvait soumettre une requête manipulée et forcer le serveur à exécuter du Python. La faille a été corrigée dans Langflow 1.3.0, mais l’instance analysée par Sysdig restait exposée et non mise à jour.

Après avoir obtenu l’exécution à distance, JadePuffer a commencé à recueillir des informations système. Il a listé les processus, inspecté les variables d’environnement, examiné les fichiers de configuration et recherché des modèles liés à des identifiants.

La recherche a inclus des fournisseurs occidentaux et asiatiques. En plus d’AWS, Azure et Google Cloud, l’agent a traqué l’accès de Alibaba, Aliyun, Tencent et Huawei. Il a également recherché des clés pour des services IA, des identifiants de bases de données et des portefeuilles de cryptomonnaies potentiels.

L’agent a vidé la base PostgreSQL utilisée par Langflow, analysé son contenu, puis supprimé certains fichiers temporaires. Ensuite, il a commencé à reconnaître le réseau interne et tenté d’identifier le stockage, les services de configuration et d’autres systèmes accessibles.

Pour maintenir l’accès, il a ajouté une entrée dans crontab exécutée toutes les 30 minutes, connectant l’infrastructure externe contrôlée par l’attaquant.

Ce type de persistance est peu sophistiqué, détectable par des contrôles simples de modifications des tâches planifiées. Sa valeur pour JadePuffer était la rapidité : il n’avait pas besoin de concevoir un mécanisme innovant si un moyen classique suffisait.

L’agent ne suivait pas un script rigide

La partie la plus intéressante de l’enquête ne réside pas dans les outils utilisés, mais dans la façon dont le système réagissait face à l’échec.

Sysdig a observé plus de 600 charges différentes durant l’opération. Beaucoup incluaient des commentaires et explications en langage naturel sur l’objectif du code, la valeur d’une base de données ou la raison de choisir une certaine voie.

Un opérateur humain peut documenter ses scripts, mais il est peu fréquent qu’il ajoute des raisonnements détaillés à des centaines de charges lancées lors d’une attaque. Ce style correspond mieux à un code généré par un modèle de langage, qui explique automatiquement ce qu’il fait.

Le comportement était également adaptatif. Quand une requête à MinIO a retourné du XML au lieu du JSON attendu, JadePuffer a modifié l’analyseur et a recommencé l’opération. Il ne s’est pas contenté de relancer la même commande ou abandonné la tâche.

Dans une autre séquence, il a tenté de créer un compte administrateur dans Nacos et a échoué à cause d’un problème de génération de mot de passe. L’agent a essayé des alternatives, vérifié les identifiants par défaut, corrigé le hash et s’est connecté 31 secondes après la première tentative échouée.

Ce cycle d’exécution, d’observation et de correction est ce qui différencie un agent d’une simple suite de scripts. Un script peut contenir des conditions et des rétentions, mais doit généralement anticiper chaque erreur possible. Un modèle peut interpréter une réponse inattendue et générer une solution en temps réel.

Son avantage pour un attaquant est évident. Un seul opérateur peut déployer plusieurs agents contre différents objectifs et laisser chacun résoudre des problèmes mineurs de manière autonome, n’intervenant que lorsque le système rencontre un obstacle insurmontable.

Nacos et MySQL exposés à internet

Le serveur Langflow n’était pas l’objectif final. JadePuffer s’est dirigé vers une autre machine de production exécutant MySQL et Nacos.

Nacos est une plateforme open source créée par Alibaba pour la découverte de services et la gestion dynamique des configurations. Elle est utilisée dans des architectures de microservices pour stocker des paramètres pouvant affecter le fonctionnement multiple applications.

Le serveur MySQL acceptait des connexions externes et l’agent disposait de crédentials root. Sysdig n’a pas observé de vol de ces identifiants lors de l’intrusion, il n’a donc pas pu déterminer comment ils étaient parvenus entre les mains de l’attaquant.

Une fois à l’intérieur, JadePuffer a essayé différentes méthodes contre Nacos. Il a tenté d’exploiter des problèmes d’authentification liés à CVE-2021-29441, généré des tokens JWT avec une clé par défaut connue, et a modifié directement les tables pour ajouter un utilisateur administrateur.

L’accès à la base de données lui permettait d’altérer le système en dessous de l’application. Même si une vulnérabilité web échouait, il pouvait insérer directement des données dans le backend et créer un compte valide.

L’agent a également exploré d’éventuelles voies pour sortir du conteneur ou exécuter du code sur l’hôte via MySQL. Il a examiné les permissions, les chemins internes, les extensions et la disponibilité du socket Docker.

Il n’a pas trouvé de voie immédiate pour développer cet accès. Au lieu de rester bloqué, il a supprimé une partie des traces et passé à la phase destructrice.

Le ransomware s’est comporté comme un wiper

JadePuffer a utilisé la fonction AES_ENCRYPT() de MySQL pour chiffrer les 1 342 éléments de configuration stockés dans Nacos. Il a ensuite effacé les tables originales, leur historique et créé une nouvelle table avec la note d’extorsion.

Le message assurait que les données avaient été chiffrées avec AES-256 et fournissait une adresse Bitcoin ainsi qu’un compte Proton Mail.

Sysdig a souligné que la configuration par défaut de MySQL utilise AES-128-ECB pour cette fonction, sauf si l’administrateur a modifié le mode de chiffrement. La différence pourrait indiquer que l’agent a généré une note de rançon générique sans vérifier le comportement précis du serveur.

Le problème le plus critique pour la victime était autre : la clé a été générée aléatoirement, n’est apparue qu’une seule fois dans la sortie de l’agent, et n’a pas été stockée ni transmise à l’infrastructure de l’attaquant.

L’opérateur ne pouvait pas fournir une clé de déchiffrement car il ne la possédait pas. Même si la victime avait payé, elle ne pourrait pas restaurer ses configurations.

L’adresse Bitcoin mentionnée dans la note semble également provenir d’exemples publics souvent utilisés dans la documentation. Les chercheurs n’ont pas pu confirmer qu’elle était sous contrôle de l’attaquant.

Après le chiffrement, JadePuffer est passé à la suppression d’informations. Il est passé de la suppression de lignes et de tables à la destruction de schémas entiers de bases de données. Le code lui-même confirmait que des données avaient été exfiltrées auparavant, mais Sysdig n’a pas pu vérifier si cette copie existait réellement.

En pratique, l’attaque a fini par se comporter comme un wiper : elle a détruit les données et a ajouté une demande d’extorsion sans disposer d’un mécanisme réel pour les récupérer.

Ce manque de cohérence révèle une limite importante des agents offensifs. Ils peuvent exécuter plusieurs étapes rapidement, mais cela ne garantit pas une stratégie fiable de bout en bout. Le modèle a rempli la consigne de chiffrer et d’extorquer, mais il n’a pas protégé la clé nécessaire pour achever le processus criminel.

Pour la victime, la distinction est insignifiante. Un ransomware mal conçu peut causer le même dommage opérationnel qu’un ransomware prévu pour permettre le déchiffrement.

Ce que cela signifie pour les équipes de sécurité

JadePuffer n’a pas utilisé de faille inconnue, de technique avancée d’évasion ni de chaîne de vulnérabilités inédite. Son succès dépendait d’une instance de Langflow non patchée, de services exposés à Internet, de clés par défaut et de comptes administrateur.

La nouveauté réside dans la rapidité avec laquelle l’agent a combiné ces erreurs.

Les équipes de défense adoptent souvent l’idée qu’il existe un intervalle entre l’accès initial, la reconnaissance et l’action de destruction. Dans une opération automatisée, ce délai peut passer d’heures à quelques minutes.

Les alertes isolées ont également peu de valeur si personne ne les relie à temps. Une exécution Python dans Langflow, une nouvelle tâche à crontab, une exploration interne ou plusieurs tentatives contre Nacos peuvent sembler séparées. Un agent peut compléter toute la chaîne avant qu’un analyste ait fini d’examiner la première alerte.

La détection doit se concentrer sur le comportement et la séquence d’actions. Quelques indicateurs pourraient être :

• Une exécution anormale de Python depuis des services d’orchestration IA.
• Un accès massif à des variables d’environnement et à des fichiers secrets.
• Une création inattendue de tâches planifiées.
• Des requêtes de reconnaissance vers plusieurs services internes.
• La génération répétée de scripts avec de légères modifications.
• Des changements directs dans les tables d’authentification de Nacos.
• Une utilisation de fonctions de chiffrement sur de grands volumes de données.
• Une suppression rapide de tables ou schémas après une phase de lecture.

Le rythme peut également révéler une automatisation. Un intervenant humain met plus de temps à analyser une erreur, corriger un script, puis le relancer. Des dizaines de variantes générées en quelques secondes peuvent indiquer la présence d’un agent.

Ces signaux ne seront pas permanents. Les attaquants apprendront à introduire des pauses, supprimer des commentaires et réduire la verbosité du code. Néanmoins, durant cette phase initiale, ils constituent une opportunité pour définir des règles précises.

Mesures immédiates pour Langflow, Nacos et bases de données

Les organisations utilisant Langflow doivent mettre à jour au minimum vers la version 1.3.0 ou une version supérieure incluant la correction de CVE-2025-3248.

L’interface et les endpoints capables de valider ou exécuter du code ne doivent pas être accessibles directement depuis Internet. Il est préférable de les placer derrière un VPN, un proxy avec authentification ou un réseau administratif restreint.

Les clés des fournisseurs cloud et des modèles ne devraient pas être stockées comme variables permanentes dans le processus Langflow. Un gestionnaire de secrets peut fournir des identifiants temporaires et limiter chaque identité à ses opérations indispensables.

Nacos doit rester dans un réseau privé. Sa clé token.secret.key doit être remplacée par une valeur propre et aléatoire, et la plateforme doit être mise à jour vers une version rejetant des configurations par défaut non sécurisées.

Le compte utilisé par Nacos pour accéder à MySQL n’a pas besoin de privilèges d’administrateur global. Il doit être limité à son propre stockage et aux opérations utilisées par l’application.

MySQL ne devrait pas accepter de connexions root depuis Internet. Le pare-feu doit restreindre le port à des adresses spécifiques, et chaque service doit disposer de son propre compte.

Les contrôles sortants sont tout aussi essentiels. Le serveur Langflow compromis a pu communiquer périodiquement avec l’infrastructure externe et explorer d’autres systèmes. Une politique d’export limitée aurait réduit la portée de l’attaque et permis de générer des alertes plus précises.

L’arrivée d’agents offensifs ne remet pas en cause les bonnes pratiques classiques de sécurité. Elle les rend toutefois plus urgentes : lorsqu’un modèle peut vérifier, corriger et poursuivre en quelques secondes, un service oublié en ligne offre moins de temps pour réagir.

Questions fréquentes

JadePuffer était-il une attaque totalement autonome ?
Non. Il y a eu une préparation humaine, une sélection de la cible et l’apport de certains accès. L’agent a automatisé une grande partie des phases suivantes de manière autonome.

Quelle vulnérabilité a-t-il exploitée pour entrer ?
Il a exploité CVE-2025-3248 sur Langflow, qui permet d’exécuter du code Python sans authentification sur les versions vulnérables.

Les données pouvaient-elles être récupérées en payant la rançon ?
Non. La clé de chiffrement n’a pas été stockée ni envoyée à l’attaquant, et l’agent a fini par supprimer des bases entières.

Que doivent vérifier désormais les administrateurs ?
L’exposition de Langflow, Nacos et MySQL, les versions installées, les clés par défaut, les comptes à privilèges élevés, les tâches planifiées et le trafic sortant vers des destinations non autorisées.