Un opérateur humain exploite la RCE de Marimo et atteint un bastion SSH en huit secondes

Un attaquant humain a exploité une faille critique d’authentification dans la plateforme de notebooks Python Marimo, extrait des identifiants cloud, récupéré une clé SSH privée et accédé à un hôte bastion en huit secondes.

Sysdig a observé plus de 850 commandes interactives au cours d’une intrusion d’environ neuf heures. Plutôt que de déployer un framework d’exploitation connu ou un agent d’IA, l’opérateur a écrit et débogué des scripts Python personnalisés au sein de l’environnement compromis.

La faille d’accès initial, CVE-2026-39987, affecte les versions de CoreWeave Marimo antérieures à 0.23.0. Elle figure déjà dans le catalogue des vulnérabilités exploitées connues de la Cybersecurity and Infrastructure Security Agency (CISA) des États-Unis, ce qui confirme que son exploitation dépasse le stade de la preuve de concept théorique.

Un WebSocket non authentifié ouvrait un shell complet

Marimo est une application de notebooks Python réactive. Dans les versions vulnérables, son endpoint WebSocket /terminal/ws peut fournir à un utilisateur distant non authentifié un shell pseudo-terminal complet.

Le problème sous-jacent est l’absence d’authentification, classée sous CWE-306. L’endpoint vérifie le mode de fonctionnement de Marimo et la prise en charge par la plateforme de la fonctionnalité de terminal demandée, mais il n’applique pas le contrôle d’authentification utilisé par d’autres routes WebSocket, notamment /ws.

Par conséquent, une instance exposée sur Internet peut permettre à un attaquant d’exécuter des commandes arbitraires du système d’exploitation sans identifiants ni interaction de l’utilisateur.

L’opérateur observé s’est connecté à /terminal/ws depuis 172.236.12[.]17. L’activité s’est poursuivie de 12 h 52 à 21 h 50, bien que la date calendaire de l’intrusion n’ait pas été divulguée.

La NVD attribue à la vulnérabilité un score CVSS v3.1 de 9,8, avec le vecteur suivant :

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Cette évaluation décrit une vulnérabilité accessible sur le réseau, de faible complexité d’exploitation, ne nécessitant aucun privilège ni interaction de l’utilisateur et pouvant avoir de graves conséquences sur la confidentialité, l’intégrité et la disponibilité. Un autre rapport attribue à la faille un score de 9,3, mais la définition des versions affectées par la NVD est plus précise : les versions de CoreWeave Marimo antérieures à 0.23.0.

Marimo 0.23.0 corrige cette vulnérabilité.

De l’accès au notebook au bastion en quelques secondes

L’attaquant n’a pas exécuté immédiatement une charge utile parfaitement aboutie. Au cours de l’intrusion, l’opérateur a écrit, testé et corrigé son code Python à plusieurs reprises, avant de réduire finalement le processus à une seule commande python3 exécutée en arrière-plan.

Cette commande automatisait un pivot en cinq étapes :

1. Lire les identifiants disponibles dans l’environnement Marimo compromis.
2. Utiliser les identifiants AWS récupérés pour interroger AWS Secrets Manager.
3. Récupérer une clé SSH privée stockée.
4. Enregistrer la clé dans le système de fichiers local.
5. S’authentifier auprès d’un hôte bastion SSH.

La séquence décisive n’a duré que huit secondes. À 18 h 57 min 22 s, l’attaquant a établi une nouvelle connexion WebSocket. À 18 h 57 min 26 s, une requête a renvoyé la clé AWS stockée par l’application. L’authentification SSH auprès du bastion a suivi à 18 h 57 min 30 s.

Ce délai revêt une importance opérationnelle. Les défenseurs qui s’appuieraient sur une analyse manuelle ou sur un traitement par lots lent n’auraient pratiquement aucune possibilité d’interrompre la transition après le premier événement WebSocket visible. La prévention, l’isolation des identifiants et le confinement automatisé sont donc plus fiables que l’espoir de voir un analyste réagir pendant le pivot.

L’opérateur a également expérimenté une configuration d’écoute de type asyncssh impliquant un serveur privé virtuel contrôlé par l’attaquant. Aucun outil offensif public identifiable n’a été détecté dans l’historique des commandes.

Une automatisation rapide, sans agent d’IA

L’intrusion ressemble à une activité agentique en raison de sa rapidité, mais les éléments observés indiquent qu’un humain pilotait une automatisation personnalisée.

Plus de 850 commandes interactives, ainsi que le développement et le débogage visibles des scripts, indiquent qu’un opérateur affinait activement l’attaque. Une fois les différentes étapes opérationnelles, l’attaquant les a combinées dans un processus Python compact capable d’exécuter la chaîne identifiants-SSH à la vitesse d’une machine.

Sysdig avait également observé des opérateurs automatisés ou agentiques ciblant la même vulnérabilité. Ces opérateurs se sont heurtés à un piège défensif qui a interrompu ou perturbé leur processus ; l’attaquant humain l’a évité.

Ce contraste met en évidence une limite des contrôles conçus autour d’une automatisation prévisible. Les agents d’IA et les outils standardisés peuvent répéter des séquences reconnaissables, faire confiance à des réponses trompeuses ou échouer lorsque les hypothèses relatives à l’environnement changent. Un humain expérimenté peut examiner le système, repérer un comportement anormal et modifier le chemin d’exécution.

Cela ne signifie pas que les attaquants humains sont intrinsèquement plus rapides que les systèmes autonomes. Cela montre qu’un humain peut préparer et lancer une automatisation après avoir compris la cible, en combinant capacité d’adaptation et exécution quasi instantanée.

La CISA avait déjà classé la faille parmi les vulnérabilités exploitées

La CISA a ajouté CVE-2026-39987 à son catalogue des vulnérabilités exploitées connues le 23 avril 2026. La date limite de remédiation pour les agences fédérales américaines concernées était fixée au 7 mai 2026.

L’action requise consiste à appliquer les mesures d’atténuation du fournisseur, à suivre les recommandations applicables de la BOD 22-01 pour les services cloud ou à cesser d’utiliser le produit si aucune mesure d’atténuation n’est disponible.

Son statut KEV signifie que les installations vulnérables exposées ne doivent pas être considérées comme présentant un risque simplement potentiel. L’exploitation a été documentée, et l’incident récemment signalé démontre comment une compromission de notebook peut conduire à des secrets cloud sensibles et à une infrastructure SSH interne.

Aucune autre vulnérabilité récente de Marimo figurant dans le catalogue KEV n’est mentionnée dans les informations disponibles. La priorité immédiate est donc CVE-2026-39987 et l’ensemble des identifiants exposés par l’intermédiaire d’instances de notebooks vulnérables.

Ce que les opérateurs de Marimo doivent examiner

Les administrateurs doivent mettre à niveau chaque déploiement Marimo concerné vers la version 0.23.0 ou une version ultérieure. L’accès à /terminal/ws doit également être restreint au niveau du réseau ou du proxy inverse, en particulier lorsque les systèmes de notebooks n’ont pas besoin d’être accessibles publiquement.

L’application des correctifs ne suffit pas si une exploitation a déjà pu se produire. Les équipes de réponse à incident doivent partir du principe que les identifiants accessibles au processus Marimo ont pu être collectés.

Les actions recommandées sont les suivantes :

• Faire tourner les identifiants AWS stockés sur l’instance concernée ou accessibles depuis celle-ci.
• Examiner les accès à AWS Secrets Manager afin de repérer les récupérations inattendues depuis des charges de travail de notebooks.
• Révoquer et remplacer les clés SSH privées auxquelles l’environnement compromis pouvait accéder.
• Rechercher les clés privées enregistrées de manière inattendue sur le stockage local.
• Examiner les journaux du bastion afin de repérer les accès SSH survenus immédiatement après des sessions WebSocket Marimo.
• Analyser les connexions impliquant 172.236.12[.]17.
• Rechercher les processus Python exécutés en arrière-plan et les écouteurs de type asyncssh inconnus.
• Mettre en corrélation les connexions à /terminal/ws avec les appels aux API cloud, la récupération de secrets, les écritures dans le système de fichiers et les authentifications SSH.

Les équipes doivent également déterminer si les rôles d’exécution des notebooks disposent de l’autorisation de récupérer des clés SSH de production. La suppression de cet accès peut empêcher qu’une compromission de notebook ne se transforme en pivot d’identifiants à l’échelle de l’infrastructure.

Des campagnes distinctes ciblent Redis et les caméras Dahua

Le rapport décrit également deux opérations distinctes qui n’ont pas été attribuées à l’attaquant de Marimo.

Une campagne de cryptominage a compromis 3 562 serveurs Redis après avoir recherché des services exposés sur le port TCP 6379. L’opération a utilisé la commande Redis SLAVEOF pour transférer du contenu contrôlé par l’attaquant et installer le mineur XMRig.

Les victimes utilisaient des versions allant de Redis 2.8.17 à 7.2.0 et comprenaient des environnements Linux obsolètes comme récents. L’exposition commune semble avoir été l’absence d’authentification, plutôt qu’une vulnérabilité propre à une version particulière de Redis.

Les défenseurs doivent supprimer Redis de toute exposition directe sur Internet, exiger une authentification, inspecter les paramètres de réplication et rechercher toute activité SLAVEOF inattendue, toute modification de fichiers append-only, toute clé SSH et tout processus XMRig.

Une autre campagne, baptisée Operation CameraSwarm, a compromis plus de 14 000 caméras IP Dahua au moyen d’attaques par force brute, de relais pair à pair et des failles de contournement de l’authentification CVE-2021-33044 et CVE-2021-33045.

Les deux vulnérabilités Dahua ont un score CVSS de 9,8 et figurent dans le catalogue KEV de la CISA depuis le 21 août 2024. La date limite de remédiation fédérale était fixée au 11 septembre 2024. Les organisations doivent appliquer les mesures d’atténuation de Dahua ou cesser d’utiliser les appareils concernés lorsqu’aucune mesure d’atténuation n’est disponible.