JADEPUFFER : la première chaîne d’attaque
ransomware LLM entièrement agentique expliquée

Vue d’ensemble : une ransomware avec un opérateur IA

Pourquoi les utilisateurs OpenClaw / Langflow doivent s’inquiéter

1. 01

   Les hôtes d’orchestration IA stockent souvent les clés API LLM en variables d’environnement — première cible scannée par JADEPUFFER.

2. 02

   Les équipes mettent en ligne des prototypes avec Langflow/OpenClaw Gateway exposé sans contrôle d’accès.

3. 03

   CVE-2025-3248 figure au catalogue CISA KEV depuis mai 2025 ; les agents rendent l’exploitation d’anciennes failles quasi gratuite.

4. 04

   LLMjacking : des identifiants cloud/modèle volés alimentent des agents à coût marginal quasi nul.

CVE-2025-3248 : analyse complète de la RCE Langflow sans authentification

Cause racine en cinq étapes :

1. 01

   Langflow expose une API de « validation de code » pour vérifier la syntaxe des nœuds de fonction personnalisés dans l’éditeur visuel.

2. 02

   Chemin d’implémentation : code utilisateur → ast.parse() → compile() → exec().

3. 03

   Faille critique : aucune authentification et aucun isolement sandbox.

4. 04

   Astuce d’exploitation : en Python, les décorateurs et arguments par défaut sont évalués à la définition de la fonction ; les attaquants y intègrent du code malveillant — une fois que Langflow « valide », le code a déjà été exécuté.

5. 05

   Les attaquants n’ont ni login ni privilèges — seulement un POST HTTP forgé pour obtenir une RCE.

exec('raise Exception(__import__("subprocess").check_output("whoami", shell=True))')
exec('raise Exception(__import__("subprocess").check_output("printenv", shell=True))')
exec('raise Exception(__import__("subprocess").check_output("cat /root/.bash_history", shell=True))')

Distinction importante : la livraison du botnet Flodrix et JADEPUFFER sont deux campagnes indépendantes partageant la même CVE d’entrée. Flodrix est une livraison scriptée classique ; JADEPUFFER est le cas de ransomware « piloté par agent IA » documenté par Sysdig.

Correctif (1.3.0) : post_validate_code reçoit l’injection de dépendance _current_user: CurrentActiveUser ; FastAPI vérifie d’abord le JWT Bearer Token ou x-api-key — 401/403 en cas d’échec, la requête n’atteint jamais la logique vulnérable.

Chaîne d’attaque phase 2 : serveur de production MySQL + Nacos

La vraie cible était un autre serveur également exposé sur Internet exécutant MySQL et Alibaba Nacos. Nacos a un historique de contournement d’authentification (CVE-2021-29441 et variantes), et le secret de signature JWT par défaut est documenté publiquement depuis 2020 — de nombreux déploiements ne l’ont jamais fait tourner.

L’agent s’est connecté au port MySQL exposé avec des identifiants root — source incertaine ; Sysdig ne les a pas observés volés dans l’environnement victime, suggérant l’une des rares étapes possiblement préparées par un humain.

Backdoor admin Nacos : boucle de réparation en 31 secondes

Sondes d’évasion de conteneur (~8 minutes)

Utilisation de MySQL INTO OUTFILE / LOAD_FILE pour tester écriture/lecture, /var/run/docker.sock, /proc/1/cgroup, /etc/hostname et chemins d’escalade UDF. Avant la ransomware, écriture d’un « marqueur de complétion » — Sysdig estime que cela ressemble à un agent signalant la fin d’une étape, et non à un comportement de script fixe.

Chiffrement destructif et note de rançon

Chiffrement des 1 342 entrées de configuration de service Nacos avec MySQL AES_ENCRYPT(), suppression des tables originales config_info et his_config_info, création de la table de rançon README_RANSOM.

KEY = base64.b64encode(uuid.uuid4().bytes + uuid.uuid4().bytes).decode()
print("Encryption key:", KEY)  # affichée une fois, jamais stockée ni exfiltrée
# CREATE config_info_enc → DROP config_info → CREATE README_RANSOM
# Bitcoin : 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy
# Contact : e78393397[@]proton[.]me

Détail clé : la note de rançon prétend utiliser AES-256, mais MySQL AES_ENCRYPT() utilise par défaut AES-128-ECB ; la clé était aléatoire, affichée uniquement sur stdout, jamais stockée ni transmise — irrécupérable même si la rançon est payée. Deux minutes plus tard, un autre payload a affiné le décompte : « tous les 1 342 éléments chiffrés. »

Destruction massive et corrections diagnostiques

Escalade vers DROP DATABASE avec des commentaires de code affirmant « bases à fort ROI, sauvegardées vers 64.20.53[.]230 » — Sysdig n’a trouvé aucune preuve indépendante d’exfiltration. Un DROP DATABASE a échoué silencieusement sur des contraintes de clés étrangères ; le payload suivant a ajouté SET GLOBAL FOREIGN_KEY_CHECKS=0 — corriger exige de comprendre pourquoi cela a échoué, pas des tentatives aveugles.

Le mystère de l’adresse Bitcoin

L’adresse Bitcoin de rançon 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy est l’exemple standard au format P2SH répété dans la documentation développeur Bitcoin et le dépôt Bitcoin Core — également abondant dans les corpus d’entraînement des LLM.

Données on-chain : 737 transactions confirmées, ~46 BTC reçus historiquement, solde actuel nul (chaque dépôt immédiatement transféré ailleurs).

Les deux lectures indiscernables de Sysdig : (a) le LLM a « halluciné » l’adresse à partir des données d’entraînement et le portefeuille appartient à un tiers qui balaie les dépôts erronés ; (b) l’attaquant a configuré un vrai portefeuille qui coïncide par hasard avec l’exemple de la doc. Sans le prompt système de JADEPUFFER, les deux restent possibles.

Recommandations officielles de défense (Sysdig)

1. 01

   Mettre à jour Langflow au-delà de CVE-2025-3248 ; ne jamais exposer les points d’exécution/validation de code sur Internet public.

2. 02

   Utiliser la détection de menaces à l’exécution pour repérer les comportements malveillants dans les processus de base de données.

3. 03

   Ne pas stocker les clés API LLM ni les identifiants cloud dans les variables d’environnement de l’hôte d’orchestration IA — utiliser une gestion de secrets dédiée, isolée des processus exposés sur Internet.

4. 04

   Durcir Nacos : faire tourner le token.secret.key par défaut, mettre à jour vers des versions exigeant des secrets personnalisés ; ne jamais exposer Nacos publiquement ; ne pas connecter la base backend en root.

5. 05

   Ne jamais exposer publiquement les comptes admin de base de données ; imposer des identifiants forts uniques et des restrictions par IP source sur les ports admin.

6. 06

   Appliquer un contrôle de sortie (egress) pour que les hôtes compromis ne puissent pas envoyer de beacons librement ni atteindre des serveurs de staging externes.

7. 07

   Surveiller les IOC ci-dessus ; surveiller les tâches crontab appelant des URL externes et les chaînes User-Agent anormales entre parenthèses.

Les quatre conclusions de Sysdig

1. 01

   La ransomware n’est plus un « artisanat d’opérateur expert » : un agent LLM peut enchaîner reconnaissance, vol, mouvement latéral, persistance et destruction sans expertise approfondie de l’opérateur.

2. 02

   Les anciennes failles sont automatisées : les cibles en aval ont subi des problèmes Nacos de 2021 et des secrets par défaut jamais tournés ; les agents rendent le spray de CVE historiques quasi gratuit.

3. 03

   L’intention est devenue lisible — une opportunité pour les défenseurs : les LLM narrent leurs objectifs dans les payloads, offrant un nouveau levier de détection et d’analyse.

4. 04

   « Sauvegardé » était du monologue d’agent : les clés de chiffrement étaient éphémères et irrécupérables — le paiement ne peut pas restaurer les configs.

Le rapport conclut : aucune technique individuelle n’est nouvelle ; ce qui compte, c’est un modèle IA qui les enchaîne en une opération de rançon complète contre une infrastructure publique négligée. Le plancher de compétence est désormais « le coût de faire tourner un agent. »

Checklist de déploiement sécurisé en cinq étapes (Mac distant + VNC)

1. 01

   Provisionner un nœud isolé : choisir un forfait Mac Mini M4 ; ne pas mapper directement OpenClaw Gateway (18789) ou les points validate Langflow sur Internet public — utiliser un reverse proxy Nginx/Caddy + HTTPS si l’accès externe est requis.

2. 02

   Corriger : Langflow ≥ 1.3.0 ; faire tourner le JWT Nacos ; aucune base root accessible depuis Internet.

3. 03

   Clés hors variables d’environnement : clés API LLM dans des gestionnaires de secrets ou OpenClaw SecretRef, isolées des processus capables de RCE.

4. 04

   Vérification graphique VNC : contrôler la console Gateway, approbations de plugins (/approve), Enregistrement d’écran macOS/Accessibilité — les étapes impossibles en SSH nécessitent VNC.

5. 05

   Egress et surveillance IOC : limiter les beacons sortants ; surveiller les appels crontab externes et les IOC README_RANSOM ; exporter une sauvegarde et résilier la location en fin de projet.