En juillet 2026, la société de sécurité cloud Sysdig a publié le premier compte rendu documenté d'une attaque de ransomware conduite de bout en bout par un agent LLM, sans opérateur humain actif pendant les phases d'exécution. L'opération, baptisée JADEPUFFER, a exploité une vulnérabilité critique dans Langflow — un outil open source largement adopté par les équipes IA — pour pénétrer dans un système de production, pivoter vers une base de données MySQL, chiffrer 1 342 éléments de configuration Nacos et déposer une note de rançon dont la clé n'a jamais été sauvegardée, rendant toute récupération impossible même en cas de paiement.
Ce n'est pas une démonstration en laboratoire. C'est une intrusion réelle, documentée à partir de logs et de comportements observés en production par l'équipe Sysdig Threat Research. Voici les faits, le déroulé exact et les mesures concrètes à prioriser pour les équipes qui utilisent Langflow, Nacos ou des bases MySQL exposées en réseau interne.
JADEPUFFER : de quoi parle-t-on exactement ?
Sysdig catégorise JADEPUFFER comme un Agentic Threat Actor (ATA) : un acteur dont la capacité offensive est délivrée par un agent IA plutôt que par un opérateur humain actionnant des outils. C'est la distinction centrale avec les ransomwares IA-assistés que l'on connaissait jusqu'ici, où l'IA générative servait à rédiger des e-mails de phishing ou à personnaliser les leurres, mais où un humain pilotait ensuite chaque étape de l'intrusion.
Dans JADEPUFFER, l'agent LLM a géré l'intégralité de la post-exploitation en autonomie : reconnaissance système, vol de credentials, latéralisation réseau, accès à la base cible, chiffrement et dépôt de la demande de rançon. Les 600+ payloads exécutés tout au long de l'opération contenaient des commentaires en langue naturelle expliquant le raisonnement de l'agent à chaque étape — une signature comportementale inédite dans l'analyse forensique de ransomwares.
Point de clarté factuelle important : un opérateur humain a bien configuré l'infrastructure initiale (serveur C2, staging server, sélection de la cible) et fourni des credentials root MySQL issus d'une compromission antérieure. Ce n'est donc pas une attaque entièrement autonome de bout en bout. La rupture réelle est que l'agent a géré seul toutes les phases actives d'exploitation, de pivotement et d'extorsion — ce que les logs Sysdig documentent de façon incontestable.
La chaîne d'attaque décortiquée
Point d'entrée : CVE-2025-3248 dans Langflow
L'accès initial a exploité CVE-2025-3248, une vulnérabilité d'exécution de code à distance sans authentification dans l'endpoint de validation de code de Langflow, présente dans toutes les versions antérieures à 1.3.0. La faille permet à un attaquant non authentifié d'exécuter du Python arbitraire sur l'hôte. Un patch est disponible depuis la version 1.3.0 — mais l'instance compromise ne l'avait pas appliqué.
Langflow est un outil open source populaire pour la création visuelle de workflows LLM, utilisé dans de nombreuses équipes IA internes. Son adoption croissante en fait une surface d'attaque que les acteurs malveillants surveillent activement.
Reconnaissance et pivotement
Une fois l'accès obtenu via Langflow, l'agent a immédiatement lancé une phase de reconnaissance : listage des détails système, recherche d'API keys et credentials cloud dans les fichiers de configuration, extraction de la base Postgres de Langflow elle-même, cartographie des services internes accessibles et test des credentials par défaut sur un stockage MinIO adjacent.
L'agent a ensuite pivoté vers le serveur MySQL de production faisant tourner Alibaba Nacos — un système de gestion de configuration et de service discovery courant dans les architectures microservices — en utilisant les credentials root fournis par l'opérateur. Il a également exploité CVE-2021-29441, une faille de bypass d'authentification dans Nacos, pour élargir son accès.
Chiffrement et extorsion irrécouvrable
L'agent a chiffré les 1 342 éléments de configuration Nacos via la fonction MySQL AES_ENCRYPT, supprimé les tables de configuration et d'historique d'origine, puis créé une table README_RANSOM contenant une adresse Bitcoin et un contact ProtonMail.
Le détail le plus critique, et probablement le plus révélateur du fonctionnement de l'agent : la clé AES a été générée sous la forme base64(uuid4().bytes + uuid4().bytes) — essentiellement aléatoire — et affichée sur la sortie standard mais jamais sauvegardée ni transmise. En conséquence, la victime ne peut pas récupérer ses données chiffrées, même en payant la rançon. L'agent a exécuté le chiffrement correctement sur le plan technique, mais n'a pas implémenté la mécanique de récupération — un comportement qui suggère soit une priorité à l'impact immédiat, soit une limitation de la cohérence de l'agent sur des séquences longues.
Adaptabilité en temps réel
Fait particulièrement notable pour les équipes sécurité : l'agent a diagnostiqué un échec de connexion et produit une correction fonctionnelle en 31 secondes. Ce comportement adaptatif — retry intelligent avec paramètres ajustés plutôt que simple boucle d'erreur — est nouveau dans le paysage ransomware documenté. La vitesse d'exécution de chaque décision élimine les fenêtres d'intervention humaine qui permettaient jusqu'ici une détection manuelle avant impact complet.
Ce qui change vraiment par rapport aux ransomwares classiques
JADEPUFFER ne redéfinit pas fondamentalement la taxonomie des menaces — les ransomwares ciblant les bases de données de configuration existent depuis plusieurs années. Ce qui change est plus subtil mais plus profond : le coût d'entrée d'une attaque sophistiquée vient de chuter.
Jusqu'ici, mener une intrusion avec reconnaissance, pivotement multi-cible, exploitation de CVE et chiffrement ciblé nécessitait une équipe structurée avec des compétences rares. L'opérateur JADEPUFFER n'avait besoin de maîtriser que la configuration initiale de l'infrastructure — l'agent s'est chargé du reste. Si un modèle peut enchaîner ces étapes seul, le niveau de compétence nécessaire pour mener une attaque de ce type se réduit à ce qu'il en coûte de louer une instance d'agent IA et de configurer un serveur C2.
Deuxième rupture : la vitesse d'exécution. Un attaquant humain détectable entre deux tentatives de connexion ratées laisse des fenêtres de quelques minutes à plusieurs heures pour la détection et l'intervention. Un agent qui corrige son erreur en 31 secondes ne laisse pas de telle fenêtre.
Pour approfondir la menace des attaques IA accélérées que les agences de renseignement anticipent depuis plusieurs mois, notre article sur l'alerte des Five Eyes de juin 2026 donne un cadre utile sur les vecteurs systémiques.
Qui est exposé ?
L'exposition à JADEPUFFER ou à des variantes similaires repose sur trois critères cumulatifs :
- Langflow exposé en réseau sans patch ≥ 1.3.0 : toute instance Langflow accessible depuis Internet en version antérieure à 1.3.0 est vulnérable à CVE-2025-3248. Ce cas inclut les déploiements de développement oubliés, les instances provisionnées rapidement pour des POC IA sans politique de mise à jour et les environnements exposés via des tunnels ou reverse proxies mal sécurisés.
- Services Nacos ou autres systèmes de configuration accessibles depuis le réseau de l'instance Langflow : l'agent a pivoté vers Nacos en utilisant les credentials déjà présents dans l'environnement Langflow. Tout service de gestion de configuration (Nacos, Consul, etcd, Vault) accessible depuis la même zone réseau qu'une instance Langflow est potentiellement dans le périmètre.
- Bases MySQL avec credentials root non segmentés : l'accès final a été obtenu via des credentials root fournis initialement par l'opérateur mais récupérables dans les fichiers de configuration de Langflow. Toute base de données de production dont les credentials root sont accessibles depuis l'environnement applicatif est une cible potentielle de chiffrement massif.
Au-delà de ce cas précis, les équipes qui déploient des outils IA en développement rapide (Langflow, LangChain, n8n, Flowise) sont particulièrement concernées : ces outils sont souvent déployés rapidement pour des expérimentations, avec moins de rigueur sur les politiques de mise à jour et d'exposition réseau que pour les systèmes de production établis.
Si votre organisation développe des outils internes connectés à des agents IA, c'est le moment de vérifier la séparation réseau entre environnements de développement IA et systèmes de données de production.
Six mesures concrètes à vérifier maintenant
Ces mesures sont ordonnées par priorité d'urgence, en fonction des vecteurs exploités dans JADEPUFFER :
1. Patcher Langflow vers la version ≥ 1.3.0 immédiatement
CVE-2025-3248 est patchée depuis Langflow 1.3.0. Si votre organisation utilise Langflow dans une version antérieure, c'est la priorité absolue. Inventoriez également les instances de déploiement « oubliées » — POC, environnements de test — qui peuvent être exposées sans surveillance active.
2. Supprimer tout accès public non authentifié aux outils de workflow IA
Langflow, comme d'autres outils de workflow IA (Flowise, n8n auto-hébergé), ne devrait jamais être accessible directement depuis Internet sans authentification et restriction d'IP. Placer ces outils derrière un VPN ou un reverse proxy avec authentification multi-facteurs élimine l'essentiel de la surface d'exposition.
3. Audit des credentials stockés dans les environnements de développement IA
Vérifiez quelles clés, tokens et credentials sont présents dans les fichiers de configuration des outils IA. Un credential root de base de données de production accessible depuis un environnement de développement IA représente une chaîne d'escalade directe. Utilisez un gestionnaire de secrets (Vault, AWS Secrets Manager, Doppler) plutôt que des fichiers .env avec des credentials privilégiés.
4. Segmenter réseau les outils IA des systèmes de données de production
L'agent JADEPUFFER a pivoté depuis Langflow vers Nacos puis vers MySQL via la connectivité réseau disponible. Une segmentation réseau stricte — outils IA dans une zone dédiée sans accès direct aux bases de données de production — aurait limité significativement l'impact du pivotement.
5. Mettre en place des alertes sur les opérations de chiffrement massif en base
L'agent a utilisé AES_ENCRYPT sur 1 342 items via MySQL. Ce type d'opération est détectable : une alerte sur l'exécution de fonctions de chiffrement en masse ou des modifications de tables à haute volumétrie sur une courte fenêtre temporelle peut permettre une coupure avant impact complet. Les outils SIEM et de monitoring de base de données existants peuvent implémenter cette règle.
6. Tester la restauration des sauvegardes des systèmes de configuration
JADEPUFFER a rendu le paiement de rançon inutile (clé jamais sauvegardée). La seule issue propre est la restauration depuis sauvegarde. Vérifiez que vos systèmes Nacos, bases de configuration et services critiques disposent de sauvegardes hors ligne régulières dont la restauration a été testée récemment. Une sauvegarde non testée ne constitue pas une garantie de disponibilité sous pression.
En cas d'incident avéré, l'ANSSI est l'autorité nationale à notifier et peut apporter une assistance technique via la plateforme cybermalveillance.gouv.fr. Si des données personnelles sont compromises, la notification à la CNIL dans les 72 heures est obligatoire au titre de l'article 33 du RGPD.
Si vous souhaitez évaluer la sécurité de vos architectures d'automatisation métier ou de vos outils internes intégrant des agents IA, notre équipe peut vous accompagner dans cet audit.
FAQ
Sources
FAQ — Premier ransomware 100 % agent IA documenté : JADEPUFFER exploite Langflow CVE-2025-3248, chiffre 1 342 configurations — qui est réellement exposé ?
JADEPUFFER est-il réellement le premier ransomware piloté par un agent IA ?
C'est la première attaque documentée par une équipe de sécurité reconnue (Sysdig) où un agent LLM a géré seul les phases actives d'exploitation, de pivotement et d'extorsion. Un opérateur humain a bien configuré l'infrastructure initiale et fourni les credentials de départ, mais toute la post-exploitation a été autonome. D'autres opérations similaires ont peut-être eu lieu sans être documentées publiquement.
La faille CVE-2025-3248 dans Langflow est-elle patchée ?
Oui. Le patch est disponible depuis Langflow version 1.3.0. Si vous utilisez une version antérieure, la mise à jour est la priorité absolue. La faille permet une exécution de code à distance sans authentification via l'endpoint de validation de code — une surface critique à éliminer immédiatement.
Peut-on récupérer les données chiffrées par JADEPUFFER en payant la rançon ?
Non, dans le cas documenté. La clé AES générée par l'agent n'a jamais été sauvegardée ni transmise — elle a été affichée sur la sortie standard de l'agent et perdue. La victime ne peut pas récupérer ses données même avec paiement. Seule une restauration depuis sauvegarde propre est possible, ce qui souligne l'importance critique des sauvegardes hors ligne testées régulièrement.
Mon organisation n'utilise pas Langflow — est-elle concernée ?
L'exposition directe à JADEPUFFER requiert Langflow non patché. Mais le pattern d'attaque — agent IA accédant à un outil de workflow IA pour pivoter vers des systèmes de données — s'applique à d'autres outils similaires (Flowise, n8n auto-hébergé, LangChain server). Toute instance de ce type exposée sans authentification et connectée à des données de production est un risque analogue.
Comment détecter une attaque de ce type en cours ?
Les signaux les plus exploitables sont : exécution de fonctions AES_ENCRYPT en masse sur une base de données en dehors des plages d'activité normales, création de tables nommées README ou RANSOM dans une base de configuration, hausse soudaine de requêtes SQL à haute volumétrie sur un serveur MySQL, et accès inhabituel à des credentials dans les fichiers de configuration d'outils de workflow IA. Ces règles peuvent être implémentées dans la plupart des SIEM ou outils de monitoring de base de données.
Quelles obligations légales s'appliquent en France en cas d'incident ransomware ?
Si des données personnelles sont compromises, la notification à la CNIL dans les 72 heures est obligatoire (RGPD article 33). Pour les opérateurs d'importance vitale ou d'importance essentielle (OIV/OES), la déclaration à l'ANSSI est également obligatoire. Pour toutes les organisations, signaler l'incident à l'ANSSI via cybermalveillance.gouv.fr permet d'obtenir une assistance technique gratuite et contribue à la cartographie nationale des menaces.