OpenClaw vous promet un assistant IA omniscient mais cumule les failles critiques : l'outil permet aux attaquants d'obtenir discrètement un accès administrateur non authentifié

9 failles découvertes en 4 jours

OpenClaw vous promet un assistant IA omniscient mais cumule les failles critiques :
CVE à 9,9, exécution de code en millisecondes sans authentification, supply chain empoisonnée

Lancé fin 2025 sous le nom de Clawdbot, OpenClaw est devenu en quelques semaines l'un des projets open source à la croissance la plus fulgurante de l'histoire de GitHub. Un agent IA capable de lire vos mails, gérer votre calendrier, exécuter des commandes shell, piloter vos services connectés le tout en autonomie, vingt-quatre heures sur vingt-quatre. La promesse était séduisante. La réalité de sécurité, elle, s'est révélée catastrophique. Depuis janvier 2026, les CVE s'accumulent, les chercheurs tirent la sonnette d'alarme, et Microsoft lui-même déconseille son usage en environnement professionnel. Si vous utilisez OpenClaw, voici pourquoi vous devriez partir du principe que votre système est déjà compromis.

OpenClaw, initialement appelé Clawdbot, puis MoltBot, est rapidement devenu l'un des projets open source les plus adoptés de l'histoire du développement logiciel. Son principe est simple mais puissant : il connecte un grand modèle de langage externe (typiquement Claude d'Anthropic, GPT d'OpenAI ou DeepSeek) à un environnement d'exécution persistant doté d'un accès système étendu. L'utilisateur communique avec l'agent via des applications de messagerie, et celui-ci agit : il exécute des commandes shell, lit et modifie des fichiers, envoie des e-mails, planifie des tâches, navigue sur le Web, et gère des services connectés via OAuth. Il stocke une mémoire à long terme entre les sessions, apprenant et s'adaptant au fil du temps.

Le problème ? La croissance hyper-rapide du projet a dépassé la maturité de son architecture de sécurité. Dès janvier 2026, des chercheurs ont découvert des milliers d'instances exposées publiquement. Censys en a dénombré plus de 21 000 accessibles directement sur Internet, beaucoup sans chiffrement HTTPS.

Une architecture conçue pour tout faire... et donc pour tout exposer

Le vrai problème d'OpenClaw n'est pas une vulnérabilité isolée. C'est son modèle de conception fondamental. La philosophie de conception privilégie la capacité et la commodité : accès complet au disque, permissions terminal, tokens OAuth, tout cela est routinièrement accordé pour rendre l'agent fonctionnel. L'un des mainteneurs du projet l'a lui-même formulé sans détour dans le Discord officiel du projet : « Si vous ne comprenez pas comment exécuter une ligne de commande, ce projet est beaucoup trop dangereux pour que vous l'utilisiez en sécurité. »

Les chercheurs en sécurité parlent d'une « triade létale » : accès à des données privées, exposition à des contenus externes non fiables, et capacité de communication vers l'extérieur. Parce qu'OpenClaw fonctionne comme un démon en arrière-plan avec de larges permissions système, une seule entrée malveillante peut mener à une exfiltration catastrophique de données.

La classe CWE-269 de vulnérabilités (mauvaise gestion des privilèges) est un problème persistant en ingénierie logicielle depuis des décennies. Mais les enjeux sont bien plus élevés lorsque le système vulnérable s'est vu accorder explicitement l'accès à des dizaines d'autres services et plateformes simultanément.


CVE-2026-25253 : la vulnérabilité qui a tout changé

La faille la plus critique reste CVE-2026-25253, découverte par le chercheur Mav Levin en janvier 2026 : un bug de détournement WebSocket cross-site noté 8,8 sur l'échelle CVSS. N'importe quel site Web pouvait voler le token d'authentification de l'utilisateur et exécuter du code arbitraire sur sa machine via un simple lien malveillant.

Le vecteur d'attaque est particulièrement insidieux. Même un utilisateur ayant configuré OpenClaw sur localhost (en croyant être protégé) est vulnérable, car la requête WebSocket provient du propre navigateur de la victime, ce qui permet à l'attaquant de pivoter vers localhost sans nécessiter de port ouvert ni d'adresse IP publique.

Le scénario d'exploitation se déroule en trois étapes : d'abord, l'attaquant incite la victime à visiter une page malveillante (via une injection dans un e-mail, un lien Slack, un plugin ClawHub piégé, etc.). Ensuite, le code injecté s'échappe du périmètre d'isolation prévu. Enfin, avec le token dérobé, l'attaquant obtient un accès de niveau opérateur à l'API du gateway, lui permettant de modifier la configuration, d'invoquer des actions privilégiées et d'exécuter des commandes arbitraires sur le système hôte avec les permissions accordées à l'agent. La chaîne d'exploitation complète s'exécute en quelques millisecondes, sans aucune authentification préalable.

La faille a été corrigée dans la version 2026.1.29, mais la vitesse du patch n'efface pas la fenêtre d'exposition.

ClawHavoc, infostealers et supply chain : l'escalade

Au-delà des failles d'exécution directe, OpenClaw s'est retrouvé dans le viseur des attaquants pour une autre raison : la richesse de ce qu'il stocke. Hudson Rock a documenté le premier cas connu où un infostealer a récupéré un fichier de configuration OpenClaw complet depuis une machine infectée, un résultat bien plus grave que le simple vol d'un mot de passe. Un fichier de config OpenClaw contient les clés API et les tokens d'authentification pour chaque service auquel l'agent est connecté. L'attaquant qui s'en empare ne récupère pas seulement des identifiants : il dispose d'un agent fonctionnel qu'il peut opérer à la place de la victime.

Une attaque sur la chaîne d'approvisionnement, baptisée ClawHavoc, a été découverte par Koi Security fin janvier. Des attaquants avaient uploadé plusieurs plugins d'apparence professionnelle dans ClawHub, le marketplace officiel de compétences additionnelles pour OpenClaw. La documentation de ces plugins indiquait aux utilisateurs d'installer un agent assistant pour continuer (qui installait en réalité l'infostealer Atomic Stealer, incluant des clés API OpenClaw dans les données volées). Ces clés donnent à l'attaquant le contrôle distant total sur OpenClaw et tous les services auxquels il est connecté.

L'écosystème de plugins, dès le lancement, permettait à quiconque possédant un compte GitHub vieux d'une semaine d'uploader des compétences exécutables sans aucune revue de code, une surface d'attaque supply chain catastrophique.

Neuf CVE en quatre jours : le mois de mars confirme le problème structurel

Si les premières failles auraient pu passer pour des incidents de jeunesse, mars 2026 a dissipé tout doute. Entre le 18 et le 21 mars, neuf CVE pour OpenClaw ont été publiés, dont un critique à 9,9 permettant à n'importe quel utilisateur authentifié d'obtenir les droits administrateur.

Parmi les failles notables de cette vague : lorsqu'une session sandboxée spawne un processus enfant via sessions_spawn, OpenClaw ne transmettait pas les restrictions du sandbox au processus fils qui s'exécutait donc avec sandbox.mode: off, permettant l'exécution de code arbitraire, l'accès aux données et des attaques en déni de service. Particulièrement ironique dans la mesure où NVIDIA avait justement développé NemoClaw pour renforcer l'isolation sandbox d'OpenClaw en contexte entreprise.

Plusieurs patches avaient été livrés des semaines avant la publication des CVE correspondants, une bonne pratique du projet. Mais cela ne fonctionne que si les utilisateurs mettent à jour. La plupart des auto-hébergeurs ne suivent pas les releases upstream quotidiennement. Ils attendent les publications de CVE, les advisories ou les articles de blog. Résultat : de nombreuses instances sont restées vulnérables pendant des semaines après l'existence du correctif.


Le virage OpenAI et les perspectives

Le 14 février 2026, Peter Steinberger, le développeur d'OpenClaw, a annoncé rejoindre OpenAI. Le projet est en cours de transition vers l'OpenClaw Foundation, avec le soutien financier et technique d'OpenAI. Ce mouvement est interprété par certains analystes comme une tentative de mettre de l'ordre dans l'architecture de sécurité avant que le projet ne bénéficie d'une exposition encore plus grande.
Les projets futurs, comme l'expérimental Project ClawGuard, prévoient la signature cryptographique de tous les plugins, des mémoires immuables pour prévenir les attaques par agent dormant, et une validation stricte des origines WebSocket activée par défaut.

Mais la question structurelle demeure entière. Le modèle actuel consistant à accorder à un seul agent un accès étendu sur des dizaines de systèmes est pratique mais fragile. Les outils qui parviendront à être utiles avec moins d'accès, pas plus, seront ceux en qui les entreprises auront réellement confiance.

Ce que vous devez faire maintenant

Si vous utilisez OpenClaw, la posture recommandée par l'ensemble des chercheurs est univoque : partir du principe que le système est compromis jusqu'à preuve du contraire.

Concrètement :

• Auditez ce à quoi l'outil a eu accès, faites pivoter les credentials de chaque service connecté, et traitez chaque session touchée comme potentiellement compromise. Les patches corrigent les failles spécifiques, mais ils n'annulent pas ce qui a pu se passer pendant que la vulnérabilité était active et non patchée.
• Dressez un inventaire des agents IA qui tournent sur votre parc de machines développeurs. Les instances OpenClaw, les serveurs LLM locaux et outils similaires représentent un angle mort grandissant pour les équipes de sécurité. Mettez à jour vers la dernière version disponible (la 2026.2.25 au minimum pour les correctifs les plus récents) et ne jamais exposer le port gateway directement sur Internet. Si un accès distant est nécessaire, il doit passer par un VPN ou un tunnel SSH.
• Si vous hébergez OpenClaw vous-même, vous vous engagez dans une démarche de sécurité continue, pas dans un déploiement de type « set-and-forget ». Plus de 128 advisories sont encore en attente d'assignation de numéros CVE. D'autres vulnérabilités viendront.

Sources : OpenClawAI, Oasis

Et vous ?

OpenClaw est-il simplement la prochaine instance d'un cycle bien connu, comme Log4Shell ou AutoGPT, où l'adoption virale devance inévitablement la maturité sécuritaire ? Ou y a-t-il quelque chose de fondamentalement différent dans le cas des agents IA ?

Microsoft déconseille officiellement OpenClaw en environnement professionnel. Les DSI et RSSI de votre organisation ont-ils une politique claire sur l'usage des agents IA autonomes par les développeurs ?

Le modèle de permission actuel (accès large accordé une fois pour toute) est-il compatible avec une sécurité raisonnable ? Faut-il imposer un modèle de permissions granulaires et éphémères (just-in-time) avant de déployer ce type d'outil en production ?

Le rachat de facto par OpenAI via l'OpenClaw Foundation vous inspire-t-il confiance pour la suite, ou craignez-vous que les impératifs commerciaux ne prennent le dessus sur la rigueur sécuritaire ?