Marimo CVE-2026-39987 : exploitée en moins de 10 heures

La fenêtre de neuf heures

Le 8 avril 2026, Marimo — un notebook Python open-source populaire utilisé par les data scientists et ingénieurs ML — a publié un avis de sécurité pour CVE-2026-39987 : une faille d’exécution de code à distance non authentifiée dans l’endpoint WebSocket terminal du notebook.

Moins d’une demi-journée plus tard, les attaquants étaient déjà à l’intérieur.

L’équipe Threat Research de Sysdig, qui exploite des honeypots ensemencés d’instances Marimo exposées, a enregistré la première tentative d’exploitation à l’état sauvage 9 heures et 41 minutes après la publication de l’avis. En environ trois minutes après le shell initial, l’attaquant avait moissonné les identifiants de l’environnement compromis.

Il n’y avait pas de preuve de concept publique. Il n’y avait pas de module Metasploit. Il n’y avait que l’avis — et apparemment, c’était suffisant.

Comment fonctionne la faille

La vulnérabilité se trouve dans la fonctionnalité terminal de Marimo, qui permet aux utilisateurs du notebook d’ouvrir un shell à l’intérieur de leur environnement Python en cours d’exécution. En coulisses, Marimo expose cela via un endpoint WebSocket à `/terminal/ws`.

La faille est d’une simplicité embarrassante : tous les autres endpoints WebSocket sensibles de Marimo appellent `validate_auth()` avant d’accepter les connexions. L’endpoint `/terminal/ws` l’a sauté. Il vérifiait uniquement le mode d’exécution et la plateforme, puis remettait à tout client connecté un shell PTY (pseudo-terminal) complet s’exécutant en tant que l’utilisateur ayant lancé Marimo.

En pratique, cela signifiait :

• Toute instance Marimo accessible sur le réseau (courante dans les environnements de développement, les postes de travail cloud, les plateformes de type Jupyter partagées et les homelabs exposés) pouvait être compromise sans authentification préalable.
• L’attaquant obtenait un shell interactif, pas seulement une primitive de commande unique — idéal pour la reconnaissance manuelle, le mouvement latéral et l’exfiltration de données.
• Comme les notebooks contiennent fréquemment des clés API, des identifiants cloud, des chaînes de connexion à des bases de données et des données d’entraînement, un shell dans ce contexte est souvent une compromission immédiate de tout l’environnement.

CVE-2026-39987 porte un score CVSS 9.3 et affecte toutes les versions de Marimo jusqu’à 0.20.4 incluse. Elle est corrigée dans 0.23.0.

La séquence d’attaque

La télémétrie de Sysdig dresse un tableau clinique de ce à quoi ressemble en 2026 un exploit zero-day frais, basé sur un avis :

1. T+0h — Marimo publie l’avis de sécurité GitHub nommant l’endpoint vulnérable.
2. T+~9h 41m — L’attaquant se connecte à l’endpoint `/terminal/ws` non authentifié sur un honeypot exposé et obtient un shell.
3. T+9h 44m (~3 minutes après le shell) — L’attaquant lit `.env`, `.aws/credentials`, `.bash_history` et fichiers similaires. Moisson d’identifiants terminée.
4. T+9h 44m à +11h 15m — L’attaquant se reconnecte quatre fois sur environ 90 minutes, chaque session courte et délibérée, conforme à un opérateur humain travaillant sur une liste de cibles.

L’attaquant n’a pas pivoté agressivement ni déployé de rançongiciel dans cette observation spécifique. Ce qui compte, c’est la vitesse et la méthode : un humain a lu l’avis, écrit l’exploit, scanné les cibles et était à l’intérieur d’un environnement compromis avant que la plupart des défenseurs n’aient même classé le CVE dans leur outil de suivi.

Pourquoi les outils développeur sont le ventre mou

Marimo n’est pas un cas isolé. Il s’inscrit dans un schéma de 2026 :

• Les outils développeur s’exécutent avec un contexte privilégié. Ils détiennent du code source, des identifiants, des jetons cloud, des secrets de pipeline et des échantillons de données client.
• Ils sont fréquemment exposés sur Internet. Les espaces de travail cloud, les notebooks hébergés, les runners CI et les IDE collaboratifs se lient souvent à 0.0.0.0 plutôt qu’à localhost, et les défenseurs les inventorient rarement avec la même rigueur que les systèmes de production.
• L’authentification est une réflexion après coup. Les outils conçus pour un « usage local » deviennent silencieusement accessibles à distance dans les déploiements cloud, héritant de modèles d’authentification qui supposent un réseau de confiance.
• La cadence des correctifs est lente. Les data scientists et ingénieurs ML mettent à jour les notebooks bien moins fréquemment que les équipes de sécurité ne corrigent l’infrastructure de production.

La télémétrie sectorielle renforce l’urgence. Le nombre d’exploitations zero-day est passé de 63 en 2022 à environ 90 en 2025, et environ 28 % des vulnérabilités exploitées sont militarisées dans les 24 heures suivant la divulgation. Le développement d’exploits assisté par IA comprime davantage la fenêtre — les outils de fuzzing guidés par LLM accélèrent démontrablement les phases de découverte et de militarisation.

CVE-2026-39987 est une étude de cas pour cette compression. Neuf heures. Pas de PoC. RCE pré-authentification complet.

Que faire — maintenant

Si vous utilisez Marimo :

1. Mettre à jour immédiatement vers la version 0.23.0 ou ultérieure. C’est non négociable si votre instance est accessible sur le réseau.
2. Auditer les signes de compromission : connexions inhabituelles à `/terminal/ws`, shells inattendus lancés par le processus Marimo, nouvelles clés SSH, fichiers d’identifiants consultés, trafic sortant vers des IP inconnues.
3. Lier Marimo à localhost (`–host 127.0.0.1`) lorsque c’est possible ; utiliser le transfert de port SSH pour l’accès distant au lieu d’exposer le port du notebook.
4. Renouveler les identifiants accessibles depuis toute instance pré-0.23.0 exposée — clés cloud, identifiants de base de données, jetons git.

Si vous dirigez une équipe data science ou ML :

1. Inventoriez votre parc de notebooks. Marimo, Jupyter, JupyterLab, Jupyter-AI, tunnels VS Code, outils auto-hébergés à la Deepnote — sachez ce qui est déployé, où et qui en est propriétaire.
2. Traitez les serveurs de notebook comme des systèmes de production. SLA de correctifs. Authentification. Journalisation. Segmentation réseau. Le modèle mental « ce n’est qu’un outil de dev » est la voie royale aux shells gratuits pour les attaquants.
3. Abonnez-vous aux avis pour les outils que votre équipe utilise réellement. Pas seulement les CVE Windows et Linux — la longue traîne des outillages développeur Python/R/Julia/Rust compte désormais.

La leçon plus large

L’enseignement de CVE-2026-39987 n’est pas que Marimo est uniquement dangereux — les mainteneurs ont répondu de manière responsable, livré un correctif et documenté la faille de manière transparente. L’enseignement est que la divulgation publique elle-même est désormais un coup de pistolet de départ. Les attaquants lisent les avis aussi avidement que les défenseurs et écrivent souvent des exploits plus rapidement que les programmes de correctifs ne déploient les fixes.

Pour toute organisation utilisant des outils développeur open-source à grande échelle, l’hypothèse de travail en 2026 doit être simple : la fenêtre entre « CVE publié » et « activement exploité » se mesure en heures, pas en semaines. La cadence des correctifs, l’exposition réseau et l’hygiène des identifiants doivent être conçues autour de cette réalité — non autour d’une notion nostalgique de la façon dont les chronologies des zero-day fonctionnaient autrefois.

Sources et lectures complémentaires

• Marimo OSS Python Notebook RCE: From Disclosure to Exploitation in Under 10 Hours — Sysdig
• Marimo RCE Flaw CVE-2026-39987 Exploited Within 10 Hours of Disclosure — The Hacker News
• Critical flaw in Marimo Python notebook exploited within 10 hours of disclosure — InfoWorld
• Critical Marimo Flaw Exploited Hours After Public Disclosure — SecurityWeek
• CVE-2026-39987 — Tenable
• Zero-Day Exploits Surge, 30% of Flaws Attacked Before Disclosure — Infosecurity Magazine