Agent LLM en post-exploitation : Marimo et CVE-2026-39987

Quand un agent IA pilote une cyberattaque de A à Z

La frontière entre outillage offensif classique et intelligence artificielle weaponisée vient de franchir un cap documenté. Le 29 mai 2026, les chercheurs de Sysdig ont publié une analyse technique détaillant une attaque inédite dans laquelle un acteur malveillant a déployé un agent à base de grand modèle de langage (LLM) pour orchestrer la phase de post-exploitation après avoir obtenu un accès initial via CVE-2026-39987, une vulnérabilité d'exécution de code à distance (RCE) préauthentifiée dans l'outil de notebook Python Marimo. Il s'agit de l'un des premiers cas publiquement documentés d'un LLM agent utilisé non pas en support d'un opérateur humain, mais en pilote autonome d'une chaîne d'attaque complète.

Pour comprendre la portée de cet incident, il faut d'abord rappeler le contexte de CVE-2026-39987. Marimo est un framework Python de notebooks réactifs, populaire dans les équipes de data science et d'IA pour sa capacité à exécuter du code interactivement dans le navigateur. La vulnérabilité, divulguée le 8 avril 2026, affecte toutes les versions antérieures ou égales à 0.20.4 et permet à un attaquant non authentifié d'exécuter des commandes système arbitraires sur le serveur hébergeant le notebook. Elle avait déjà été exploitée dans les dix heures suivant sa divulgation publique, une vitesse d'armement qui reflète l'intérêt des attaquants pour les outils du pipeline IA/ML comme vecteurs d'intrusion dans des environnements cloud souvent richement dotés en credentials et permissions.

L'attaque documentée par Sysdig présente une architecture en plusieurs étapes d'une efficacité redoutable. Après avoir compromis un notebook Marimo exposé sur Internet via CVE-2026-39987, l'agent a extrait deux jeux de credentials cloud stockés sur l'hôte compromis. Ces credentials ont été rejoués via un pool d'adresses IP de sortie distribuées — une technique classique de contournement des contrôles géographiques et des listes de blocage IP — pour interroger AWS Secrets Manager et récupérer une clé SSH privée. Cette clé a ensuite été utilisée pour établir huit sessions SSH successives contre un serveur bastion interne. La phase finale, menée depuis le bastion, a permis d'exfiltrer à la fois le schéma et le contenu intégral d'une base de données PostgreSQL interne en moins de deux minutes.

La vitesse d'exécution — moins de deux minutes pour passer de l'accès au bastion à l'exfiltration complète d'une base de données — est caractéristique d'une orchestration automatisée. Aucun opérateur humain ne pourrait enchaîner avec cette fluidité la découverte du schéma d'une base inconnue, la rédaction des requêtes d'extraction adaptées et le transfert des données. C'est précisément ce point qui a alerté les analystes de Sysdig : l'attaquant semblait «improviser» en temps réel face à des structures de données qu'il n'avait jamais vues, une capacité jusqu'ici réservée aux humains expérimentés.

Sysdig a identifié quatre indicateurs comportementaux permettant d'attribuer l'activité à un agent LLM plutôt qu'à un opérateur humain ou à un script préétabli. Premièrement, la capacité à construire des requêtes SQL de dump sans connaissance préalable du schéma de la base cible — une forme d'adaptation dynamique qui traduit un raisonnement en temps réel plutôt que l'exécution d'un playbook fixe. Deuxièmement, un commentaire de planification en chinois simplifié — «看还能做什么», soit «Voyons ce qu'on peut encore faire» — qui a «fuité» directement dans le flux de commandes lors d'une étape de recherche de credentials supplémentaires. Ce type de fuite est caractéristique des LLM dont la pensée interne («chain-of-thought» ou commentaires de planification) n'est pas correctement dissociée de la sortie exécutable.

Troisièmement, chaque commande émise était structurée pour une consommation machine : séparées par des délimiteurs «---», les commandes utilisaient systématiquement des captures de sortie bornées (head, limit), désactivaient la pagination interactive (commande less), et redirigeaient le flux d'erreur standard vers /dev/null. Ce niveau de rigueur de formatage dépasse ce qu'un opérateur humain maintiendrait naturellement sous la pression d'une attaque active. Quatrièmement, l'absence totale de commandes exploratoires «humaines» — pas de ls -la suivi d'hésitation, pas de tentatives infructueuses réessayées manuellement, pas de typo corrigée interactivement. Chaque commande semblait précédée d'un plan préétabli, puis exécutée une seule fois avec précision.

La question de l'attribution reste ouverte. Le commentaire en chinois est un indice mais non une preuve d'attribution nationale : les LLM modernes produisent naturellement des sorties dans la langue dans laquelle ils ont été principalement entraînés ou promptés, et un acteur non-chinois aurait pu utiliser un modèle optimisé en mandarin pour des raisons de performance. D'après The Hacker News, Sysdig n'a pas émis d'attribution formelle à un groupe connu. La sophistication de l'opération — combinant exploitation de vulnérabilité fraîche, évasion de détection via pool d'IP, et post-exploitation guidée par LLM — suggère néanmoins un acteur disposant de ressources significatives et d'une expérience avancée en opérations offensives.

Pour les équipes de défense, cet incident redéfinit les attentes en matière de vitesse d'attaque et de capacités d'adaptation des adversaires. Les playbooks de réponse à incident supposant un opérateur humain derrière chaque session malveillante devront être révisés pour intégrer des scénarios d'attaque à vitesse machine. En particulier, les délais moyens de détection et de confinement — souvent mesurés en heures ou en jours — sont structurellement incompatibles avec des attaques capables d'exfiltrer une base de données en moins de deux minutes après pivot bastion.

L'IA weaponisée entre dans une nouvelle phase opérationnelle

L'incident Marimo/LLM marque un tournant dans la réflexion sur l'IA offensive. Jusqu'ici, les usages offensifs des LLM documentés publiquement se limitaient à des tâches d'assistance : rédaction de leurres de phishing plus convaincants, génération de variantes de code malveillant pour contourner les signatures antivirales, ou traduction de documentation technique pour faciliter la compréhension d'un vecteur d'attaque. L'incident rapporté par Sysdig franchit une ligne qualitative : l'agent n'assiste plus un humain, il opère de manière autonome, prend des décisions en temps réel face à des situations imprévues et adapte ses actions aux contraintes de l'environnement cible.

Ce changement de paradigme a des implications directes pour les professionnels de la sécurité. Les modèles de menace traditionnels supposent un cycle de décision humain dans la boucle offensive : l'attaquant observe, analyse, décide, agit — avec des latences mesurables entre chaque étape. Un agent LLM autonome compresse ce cycle jusqu'à l'éliminer presque entièrement, rendant caduques les approches de détection fondées sur des seuils de temps ou des patterns comportementaux calibrés sur des opérateurs humains. Les solutions de détection et réponse aux incidents (NDR, EDR, SIEM) vont devoir incorporer des mécanismes de détection d'activité «machine-paced» spécifiquement conçus pour identifier les signatures comportementales des LLM agents en action.

L'exploitation de CVE-2026-39987 sur Marimo illustre par ailleurs un vecteur d'attaque en pleine expansion : les outils du pipeline IA/ML. Jupyter notebooks, Marimo, Streamlit, Gradio, Ray Serve — ces environnements sont de plus en plus exposés dans des contextes cloud pour faciliter la collaboration entre équipes de data science, et ils sont souvent hébergés avec des niveaux de permissions cloud élevés (accès à S3, à des secrets, à des bases de données) en raison de la nature de leurs workloads. Ils constituent donc des cibles à haute valeur ajoutée pour les attaquants cherchant à pivoter vers des ressources cloud sensibles. La supply chain IA, déjà fragilisée par des incidents comme la compromission de packages npm ciblant des projets d'IA, s'étend désormais à l'outillage de développement lui-même.

Au-delà de l'aspect technique, l'incident soulève une question de gouvernance urgente. Si des agents LLM peuvent désormais conduire des cyberattaques de manière autonome, la question de la responsabilité légale et éthique de leur création et déploiement à des fins offensives devient pressante. Plusieurs initiatives réglementaires — notamment dans le cadre de l'AI Act européen et des travaux en cours à l'OCDE — tentent d'encadrer les usages à haut risque des systèmes d'IA, mais aucune ne couvre explicitement les agents d'attaque autonomes. Cet incident devrait accélérer les travaux sur ce sujet, notamment dans les instances de normalisation de la cybersécurité comme l'ENISA et les groupes de travail ISO/IEC 27001.

Ce qu'il faut retenir

• Un agent LLM a conduit de manière autonome une chaîne post-exploitation complète sur Marimo CVE-2026-39987 : vol de credentials, pivot AWS/SSH, exfiltration PostgreSQL en moins de 2 minutes.
• Les outils du pipeline IA/ML (notebooks, serveurs d'inférence) exposés sur Internet avec des permissions cloud élevées sont des cibles prioritaires — les auditer et les isoler sans délai.
• Les équipes SOC doivent intégrer des signatures de détection d'activité «machine-paced» : vitesse d'exécution anormale, commandes structurées pour consommation machine, absence de patterns comportementaux humains.