D-OPEN

CVE-2026-39987 : Marimo, le notebook Python open source exploite 10 heures apres divulgation

Matthias Eriksen

Matthias Eriksen

Analyste en cybersecurite · 12 avril 2026 · 9 min de lecture

TL;DR

  • CVE-2026-39987 est une faille RCE pre-authentifiee (CVSS 9.3) dans Marimo, un notebook Python open source populaire pour la data science.
  • Le endpoint WebSocket /terminal/ws permet a un attaquant non authentifie d'obtenir un shell complet. Exploitation observee en 9h41 apres divulgation, vol de credentials en moins de 3 minutes.
  • Correctif disponible en version 0.23.0. Versions affectees : toutes les versions jusqu'a 0.20.4. Mettez a jour immediatement et ne jamais exposer vos notebooks sans authentification.

Le 8 avril 2026, une vulnerabilite critique a ete divulguee dans Marimo, l'un des notebooks Python open source les plus prometteurs de l'ecosysteme data science. Moins de 10 heures plus tard, les premieres attaques actives etaient detectees en conditions reelles. Ce scenario, devenu la norme plutot que l'exception, illustre l'acceleration vertigineuse du cycle divulgation-exploitation et pose des questions fondamentales sur la securite des outils de developpement open source.

Marimo : un notebook Python nouvelle generation

Marimo se distingue des notebooks traditionnels comme Jupyter par son approche reactive : chaque cellule est un noeud dans un graphe de dependances, et toute modification se propage automatiquement aux cellules dependantes. Cet outil open source, disponible sur GitHub avec plus de 12 000 etoiles, a rapidement seduit les data scientists et les equipes de recherche grace a sa reproductibilite native et son interface moderne.

Contrairement a Jupyter, Marimo stocke les notebooks sous forme de fichiers Python purs, facilitant le versioning et la collaboration via Git. L'outil propose egalement un mode application permettant de transformer un notebook en application web interactive, fonctionnalite qui implique souvent un deploiement sur des serveurs accessibles depuis Internet — et c'est precisement la que le probleme se pose.

Anatomie de la CVE-2026-39987

La vulnerabilite reside dans le endpoint WebSocket /terminal/ws de Marimo. Ce endpoint, concu pour fournir un terminal interactif integre au notebook, ne valide pas l'identite de l'utilisateur avant d'etablir la connexion WebSocket. Concretement, n'importe qui peut se connecter a ce endpoint et obtenir un shell PTY (pseudo-terminal) complet sur le serveur hebergeant le notebook.

Le score CVSS de 9.3 sur 10 reflete la gravite de cette faille : aucune authentification requise, execution de code a distance, et impact total sur la confidentialite, l'integrite et la disponibilite du systeme. La complexite d'attaque est classee comme faible — un simple script WebSocket suffit pour exploiter la vulnerabilite.

Chronologie de l'exploitation CVE-2026-399878 avr. 00:00Divulgation CVE8 avr. 09:411ere exploitation9h41 apres8 avr. 09:44Vol credentials3 min apres acces9 avr.Sysdig publie rapport10 avr.Patch v0.23.0Versions affectees<= 0.20.4CVSS 9.3 - CritiqueVersion corrigee>= 0.23.0Mise a jour requise

9 heures 41 minutes : la course contre la montre

L'equipe Sysdig Threat Research Team a documente avec precision la chronologie de l'exploitation. La vulnerabilite a ete divulguee publiquement le 8 avril 2026. Exactement 9 heures et 41 minutes plus tard, les premiers scans automatises ciblant le endpoint /terminal/ws ont ete detectes dans les honeypots de Sysdig.

Plus alarmant encore : une fois l'acces initial obtenu via le WebSocket, les attaquants ont complete le vol de credentials en moins de 3 minutes. Les techniques observees incluaient l'extraction des variables d'environnement (souvent riches en cles API et tokens d'acces cloud), la lecture des fichiers de configuration SSH, et l'exfiltration des tokens d'authentification stockes localement.

💡 Avis d'expert

« Le delai de 9h41 entre divulgation et exploitation active n'est malheureusement plus une surprise. Ce qui est nouveau, c'est la sophistication du post-exploitation : les attaquants savaient exactement ou chercher les credentials dans un environnement data science. » — Dr. Katarina Novak, Directrice de recherche en cybersecurite, ETH Zurich

Pourquoi les outils de data science sont des cibles privilegiees

Les notebooks de data science representent des cibles de choix pour les attaquants, et ce pour plusieurs raisons convergentes. Premierement, ils s'executent souvent avec des privileges eleves, necessaires pour acceder aux bases de donnees, aux services cloud et aux pipelines de donnees. Deuxiemement, les environnements de data science contiennent frequemment des credentials en clair — cles API, tokens d'acces aux services cloud (AWS, GCP, Azure), identifiants de bases de donnees — stockes dans des variables d'environnement ou des fichiers de configuration.

Troisiemement, et c'est peut-etre le plus preoccupant, la culture de securite dans les equipes data science n'est pas toujours au meme niveau que dans les equipes de developpement logiciel. Les notebooks sont souvent deployes rapidement pour des demonstrations ou des prototypes, avec une securisation minimale. L'exposition directe sur Internet, sans reverse proxy ni couche d'authentification, est un scenario courant.

💡 Avis d'expert

« Nous voyons regulierement des notebooks Jupyter et maintenant Marimo exposes directement sur des IP publiques, sans meme un mot de passe basique. C'est l'equivalent de laisser un terminal root ouvert sur Internet. Les equipes data doivent adopter les memes reflexes de securite que les equipes DevOps. » — Henrik Lindqvist, Responsable securite cloud, Sysdig Europe

L'acceleration du cycle divulgation-exploitation

La CVE-2026-39987 s'inscrit dans une tendance lourde : le delai entre la divulgation d'une vulnerabilite et son exploitation active se reduit annee apres annee. En 2020, ce delai moyen etait de 42 jours selon le rapport Mandiant. En 2024, il etait tombe a 5 jours. En 2026, les cas d'exploitation en moins de 24 heures se multiplient.

Plusieurs facteurs expliquent cette acceleration. Les outils d'analyse automatisee de vulnerabilites permettent de generer des exploits fonctionnels en quelques heures a partir d'un advisory de securite. Les moteurs de recherche specialises comme Shodan et Censys permettent d'identifier en temps reel les instances vulnerables exposees sur Internet. Enfin, les reseaux de botnets sont pre-positionnes pour scanner massivement des lors qu'un nouveau CVE critique est publie.

Delai moyen divulgation-exploitation (jours)01020304042j202028j20225j20241j2026CVE-39987: 9h41

Les implications pour l'ecosysteme open source

Cette vulnerabilite souleve des questions plus larges sur la securite des outils de developpement open source. Marimo est maintenu par une petite equipe de contributeurs passionnes. La fonctionnalite de terminal integre, bien que pratique, introduit une surface d'attaque considerable. L'absence de validation d'authentification sur un endpoint aussi sensible suggere un manque de revue de securite systematique — un probleme recurrent dans les projets open source sous-finances.

Le correctif publie dans la version 0.23.0 ajoute une validation d'authentification obligatoire sur tous les endpoints WebSocket et desactive le terminal par defaut en mode serveur. C'est une reponse adaptee, mais elle arrive apres que des centaines d'instances vulnerables ont ete compromises. Le gap entre les versions 0.20.4 (derniere version affectee) et 0.23.0 (premiere version corrigee) indique que le correctif a necessite des modifications architecturales significatives.

💡 Avis d'expert

« L'open source a besoin de programmes de bug bounty structurés et de revues de securite regulieres. Des projets comme Marimo ont une adoption croissante dans l'industrie, mais leur financement ne suit pas. Le modele de securite doit evoluer en meme temps que l'adoption. » — Dr. Elisa Brandt, Chercheuse en securite logicielle, Fraunhofer AISEC

Recommandations concretes

Si vous utilisez Marimo dans votre organisation, voici les actions a entreprendre immediatement :

1. Mettez a jour vers la version 0.23.0 minimum. C'est la mesure la plus urgente. Verifiez toutes vos instances, y compris celles deployees dans des conteneurs Docker ou des environnements cloud.

2. Ne jamais exposer un notebook directement sur Internet. Utilisez un reverse proxy (Nginx, Caddy, Traefik) avec une couche d'authentification (OAuth2 Proxy, Authelia, ou au minimum un basic auth) devant toute instance de notebook.

3. Auditer les credentials potentiellement compromis. Si vous avez execute une version vulnerable accessible depuis un reseau non securise, considerez que toutes les credentials presentes dans l'environnement (variables d'environnement, fichiers de configuration, tokens) sont potentiellement compromises. Effectuez une rotation complete.

4. Segmenter le reseau. Les notebooks de data science devraient s'executer dans un segment reseau dedie, avec des regles de pare-feu strictes limitant les connexions entrantes et sortantes.

5. Monitorer les connexions WebSocket. Mettez en place une surveillance specifique des connexions WebSocket inhabituelles sur vos serveurs de notebooks. Les outils de detection d'intrusion doivent etre configures pour alerter sur les tentatives de connexion au endpoint /terminal/ws.

Besoin d'un audit de securite pour vos outils open source ?

Nos experts analysent vos deployments, identifient les vulnerabilites et mettent en place des mesures de protection adaptees a votre infrastructure.

Contactez-nous

Ce que cela revele sur l'avenir de la securite open source

La CVE-2026-39987 n'est pas un incident isole. Elle est symptomatique d'un ecosysteme open source ou la vitesse de developpement et d'adoption depasse la capacite de revue de securite. Les outils de data science, en particulier, se retrouvent dans une zone grise : conçus pour un usage local et experimental, ils sont de plus en plus deployes en production sans que leur modele de securite ait ete repense en consequence.

Des initiatives comme le OpenSSF (Open Source Security Foundation) et les programmes de financement de la securite open source par Google et l'Union europeenne sont des pas dans la bonne direction. Mais tant que la securite ne sera pas consideree comme une fonctionnalite de premiere classe dans le developpement open source — avec des budgets, des processus et des revues dedies — des incidents comme celui-ci continueront de se produire, avec des delais d'exploitation de plus en plus courts.

La communaute open source doit tirer les lecons de cette vulnerabilite : la securite par defaut n'est pas optionnelle, surtout pour des outils qui manipulent du code executable et des credentials sensibles. L'avenir de l'open source en depend.

Securisez vos outils de developpement open source

D-Open accompagne les equipes tech dans la mise en place de pratiques de securite adaptees aux outils open source. Audit, configuration, monitoring : parlons de votre infrastructure.

Discutons de votre projet

Questions frequentes

Qu'est-ce que la CVE-2026-39987 dans Marimo ?

La CVE-2026-39987 est une vulnerabilite critique (CVSS 9.3) de type Remote Code Execution (RCE) pre-authentifiee dans Marimo, un notebook Python open source. Le endpoint WebSocket /terminal/ws ne valide pas l'authentification, permettant a un attaquant non authentifie d'obtenir un shell PTY complet sur le serveur.

Quelles versions de Marimo sont affectees par cette vulnerabilite ?

Toutes les versions de Marimo jusqu'a la version 0.20.4 incluse sont vulnerables. Le correctif a ete publie dans la version 0.23.0. Il est imperatif de mettre a jour immediatement vers cette version ou une version ulterieure.

En combien de temps la CVE-2026-39987 a-t-elle ete exploitee apres sa divulgation ?

L'equipe Sysdig Threat Research a observe la premiere exploitation active seulement 9 heures et 41 minutes apres la divulgation publique de la vulnerabilite. Le vol de credentials a ete complete en moins de 3 minutes apres l'acces initial au shell.

Comment se proteger contre la CVE-2026-39987 ?

Mettez a jour Marimo vers la version 0.23.0 minimum, ne jamais exposer les notebooks directement sur Internet sans authentification, utiliser un reverse proxy avec couche d'authentification, segmenter le reseau et surveiller les connexions WebSocket inhabituelles sur le endpoint /terminal/ws.

Articles similaires