Menaces OpenClaw : évaluation des risques et gestion du Shadow AI

Tout le monde a probablement entendu parler d’OpenClaw, anciennement connu sous le nom de « Clawdbot » ou « Moltbot », l’assistant d’IA à code source ouvert que l’on peut installer localement sur une machine. Il se connecte à des plateformes de chat populaires telles que WhatsApp, Telegram, Signal, Discord et Slack, ce qui lui permet de recevoir des commandes de son propriétaire et d’agir librement sur le système de fichiers local. Il a accès au calendrier, à la messagerie électronique et au navigateur du propriétaire, et peut même exécuter des commandes du système d’exploitation via le shell.

D’un point de vue sécuritaire, rien que cette description devrait suffire à rendre n’importe qui nerveux. Cependant, lorsque cette technologie est déployée dans un environnement professionnel, l’inquiétude se transforme rapidement en crainte d’un chaos imminent. Certains experts ont déjà qualifié OpenClaw de plus grande menace interne de 2026. Les problèmes liés à OpenClaw couvrent l’ensemble des risques mis en évidence dans le récent classement OWASP Top 10 for Agentic Applications.

OpenClaw permet de connecter n’importe quel modèle LLM local ou basé sur le cloud, et d’utiliser un large éventail d’intégrations avec des services supplémentaires. Au cœur du système se trouve une passerelle qui accepte les commandes via des applications de chat ou une interface utilisateur Web, et les achemine vers les agents d’IA appropriés. La première version, baptisée Clawdbot, est sortie en novembre 2025. En janvier 2026, elle était déjà devenue virale, entraînant avec elle une multitude de problèmes de sécurité. En une seule semaine, plusieurs vulnérabilités de sécurité critiques ont été révélées, des compétences malveillantes ont fait leur apparition dans le répertoire des compétences (skills) et des secrets ont été divulgués par Moltbook (essentiellement le « Reddit des bots »). Pour couronner le tout, l’entreprise Anthropic a exigé que le projet soit renommé afin d’éviter toute violation de la marque « Claude », et le nom du compte X du projet a été piraté pour promouvoir des escroqueries aux cryptomonnaies.

Problèmes connus liés à OpenClaw

Bien que le développeur du projet semble reconnaître l’importance de la sécurité, comme il s’agit d’un projet amateur, aucune ressource n’est consacrée à la gestion des vulnérabilités ni à d’autres aspects essentiels de la sécurité du produit.

Vulnérabilités OpenClaw

Parmi les vulnérabilités connues dans OpenClaw, la plus dangereuse est CVE-2026-25253 (CVSS 8.8). L’exploitation de cette faille entraîne une compromission totale de la passerelle, permettant à un pirate d’exécuter des commandes arbitraires. Pour aggraver les choses, cette attaque est extrêmement facile à réaliser : il suffit que l’agent visite le site d’un pirate ou que l’utilisateur clique sur un lien malveillant pour que le jeton d’authentification principal soit divulgué. Grâce à ce jeton, le pirate informatique dispose d’un contrôle administratif total sur la passerelle. Cette vulnérabilité a été corrigée dans la version 2026.1.29.

Deux vulnérabilités dangereuses liées à l’injection de commandes (CVE-2026-24763 et CVE-2026-25157) ont également été découvertes.

Fonctionnalités et paramètres par défaut non sécurisés

Grâce à divers paramètres prédéfinis et à certaines particularités de mise en œuvre, il est très facile d’attaquer la passerelle :

• L’authentification est désactivée par défaut, ce qui rend la passerelle accessible depuis Internet.
• Le serveur accepte les connexions WebSocket sans vérifier leur origine.
• Les connexions localhost sont implicitement considérées comme fiables, ce qui peut s’avérer catastrophique si l’hôte exécute un proxy inverse.
• Plusieurs outils, dont certains dangereux, sont accessibles en mode Invité.
• Les paramètres de configuration critiques sont divulgués sur le réseau local à travers des messages de diffusion mDNS.

Secrets en texte clair

La configuration, la « mémoire » et les historiques de chat d’OpenClaw stockent les clés API, les mots de passe et autres identifiants pour les modèles LLM et les services d’intégration en texte clair. Il s’agit d’une menace critique, d’autant plus que certaines versions des voleurs d’informations RedLine et Lumma incluent déjà des chemins d’accès aux fichiers OpenClaw dans leurs listes de données à dérober. Le voleur d’informations Vidar a également été surpris en train de voler des informations confidentielles à OpenClaw.

Compétences malveillantes

Les fonctionnalités d’OpenClaw peuvent être élargies grâce aux « skills » (compétences) disponibles dans le référentiel ClawHub. Comme tout le monde peut mettre en ligne une compétence, il n’a pas fallu longtemps pour que des acteurs malveillants commencent à « intégrer » le voleur d’informations AMOS pour macOS dans leurs contributions. En peu de temps, le nombre de compétences malveillantes a atteint plusieurs centaines. Les développeurs ont alors rapidement conclu un accord avec le service VirusTotal afin de s’assurer que toutes les compétences chargées sont non seulement vérifiées par rapport aux bases de données de programmes malveillants, mais également soumises à une analyse du code et du contenu au moyen de modèles LLM. Cela dit, les auteurs sont très clairs : ce n’est pas une solution miracle.

Défauts structurels de l’agent d’IA OpenClaw

Les vulnérabilités peuvent être corrigées et les paramètres renforcés, mais certains problèmes d’OpenClaw sont inhérents à sa conception. Le produit réunit plusieurs fonctionnalités critiques qui, lorsqu’elles sont réunies, sont particulièrement dangereuses :

• OpenClaw dispose d’un accès privilégié aux données confidentielles stockées sur la machine hôte et aux comptes personnels du propriétaire.
• L’assistant est largement exposé à des données non fiables : l’agent reçoit des messages via des applications de chat et des emails, consulte de manière autonome des pages Internet, etc.
• Il souffre de l’incapacité inhérente des modèles LLM à distinguer de manière fiable les commandes des données, ce qui l’expose au risque d’injection de prompt.
• L’agent enregistre les points clés et les artefacts résultant de ses tâches afin d’orienter ses actions futures. Cela signifie qu’une seule injection réussie peut empoisonner la mémoire de l’agent, influençant son comportement à long terme.
• OpenClaw a le pouvoir de communiquer avec le monde extérieur : il peut envoyer des emails, effectuer des appels API et utiliser d’autres méthodes pour exfiltrer des données internes.

Il convient de noter que si OpenClaw constitue un exemple particulièrement extrême, cette liste des « cinq terrifiants » est en réalité caractéristique de presque tous les agents d’IA polyvalents.

Risques liés à OpenClaw pour les organisations

Si un employé installe un agent de ce type sur un appareil d’entreprise et l’intègre à une suite de services de base (comme Slack et SharePoint), alors la combinaison de l’exécution autonome de commandes, d’un accès étendu au système de fichiers et d’autorisations OAuth excessives crée des conditions propices à une compromission profonde du réseau. En réalité, l’habitude qu’a le bot d’accumuler des secrets et des jetons non chiffrés en un seul endroit va droit au désastre, même si l’agent d’IA lui-même n’est jamais compromis.

De plus, ces configurations enfreignent les exigences réglementaires dans plusieurs pays et secteurs, ce qui peut entraîner des amendes et des écarts lors des audits. Les exigences réglementaires actuelles, comme celles de la loi européenne sur l’IA ou du cadre de gestion des risques liés à l’IA du NIST, imposent explicitement un contrôle d’accès strict pour les agents d’IA. L’approche adoptée par OpenClaw en matière de configuration est clairement loin de répondre à ces normes.

Mais le plus surprenant, c’est que même si les employés n’ont pas le droit d’installer ce logiciel sur leurs ordinateurs de travail, ils peuvent toujours l’installer sur leurs appareils personnels. Il en découle également des risques spécifiques pour l’organisation dans son ensemble :

• Les appareils personnels stockent souvent les informations d’accès aux systèmes professionnels, comme les configurations VPN d’entreprise ou les jetons de navigateur pour la messagerie et les outils internes. Ces appareils peuvent être piratés à des fins d’infiltration dans l’infrastructure de l’entreprise.
• La gestion de l’agent via des applications de chat signifie que non seulement l’employé devient la cible d’une manipulation psychologique, mais aussi son agent d’IA, ce qui rend possible le piratage de comptes d’IA ou l’usurpation d’identité de l’utilisateur dans les discussions avec ses collègues (parmi d’autres escroqueries). Même si les discussions personnelles ne portent que rarement sur le travail, les informations qu’elles contiennent sont faciles à exploiter.
• Si un agent d’IA installé sur un appareil personnel est connecté à des services d’entreprise (adresse email, messagerie instantanée, stockage de fichiers), les pirates peuvent manipuler l’agent pour détourner des données, et il serait extrêmement difficile pour les systèmes de surveillance de l’entreprise de détecter une telle activité.

Comment détecter OpenClaw

En fonction des capacités de surveillance et de réponse de l’équipe SOC, celle-ci peut suivre les tentatives de connexion à la passerelle OpenClaw sur les appareils personnels ou dans le cloud. De plus, une combinaison spécifique de signaux d’alerte peut indiquer la présence d’OpenClaw sur un appareil d’entreprise :

• Recherchez la présence des répertoires ~/.openclaw/, ~/clawd/ ou ~/.clawdbot sur les machines hôtes.
• Analysez le réseau à l’aide d’outils internes ou publics tels que Shodan afin d’identifier les empreintes HTML des panneaux de configuration Clawdbot.
• Surveillez le trafic WebSocket sur les ports 3000 et 18789.
• Surveillez les messages de diffusion mDNS sur le port 5353 (plus précisément openclaw-gw.tcp).
• Surveillez les tentatives d’authentification inhabituelles dans les services d’entreprise, comme de nouveaux enregistrements App ID, des événements de consentement OAuth ou des chaînes User-Agent propres à l’environnement Node.js et à d’autres agents utilisateurs non standard.
• Recherchez les schémas d’accès typiques de la collecte automatisée d’informations : lecture de volumes importants de données (récupération de tous les fichiers ou de tous les emails) ou analyse de répertoires à intervalles réguliers en dehors des heures de bureau.

Contrôle du Shadow AI

Un ensemble de pratiques de sécurité peut réduire efficacement l’empreinte du Shadow IT et du Shadow AI, rendant ainsi beaucoup plus difficile le déploiement d’OpenClaw dans une organisation :

• Utilisez une liste d’autorisation au niveau de l’hôte pour vous assurer que seules les applications et les intégrations cloud approuvées sont installées. Pour les produits qui prennent en charge la modularité (comme les extensions Chrome, les plug-ins VS Code ou les compétences OpenClaw), implémentez une liste fermée d’extensions vérifiées.
• Effectuez une évaluation complète de la sécurité de tout produit ou service, y compris les agents d’IA, avant de leur permettre d’accéder aux ressources de l’entreprise.
• Appliquez aux agents d’IA les mêmes exigences de sécurité rigoureuses que celles imposées aux serveurs publics qui traitent des données confidentielles de l’entreprise.
• Instaurez le principe du moindre privilège pour tous les utilisateurs et les autres entités.
• N’accordez pas de privilèges d’administrateur sans que cela soit strictement nécessaire pour l’entreprise. Exigez que tous les utilisateurs disposant d’autorisations élevées ne s’en servent que pour effectuer des tâches précises, plutôt que de travailler en permanence à partir de comptes avec privilèges.
• Configurez les services d’entreprise de manière à ce que les intégrations techniques (comme les applications demandant un accès OAuth) ne reçoivent que les autorisations minimales nécessaires.
• Vérifiez régulièrement les intégrations, les jetons OAuth et les autorisations accordées aux applications tierces. Passez en revue la nécessité de ces autorisations avec les responsables, révoquez de manière proactive les autorisations excessives et supprimez les intégrations obsolètes.

Déploiement sécurisé de l’IA agentique

Si une organisation autorise les agents d’IA à titre expérimental (par exemple, pour des tests de développement ou des projets pilotes d’efficacité) ou si des cas d’utilisation particuliers de l’IA ont été approuvés pour l’ensemble du personnel, des mesures robustes de surveillance, de journalisation et de contrôle d’accès doivent être mises en place :

• Déployez les agents dans un sous-réseau isolé avec des règles strictes d’entrée et de sortie, en limitant la communication aux hôtes de confiance nécessaires à la tâche.
• Utilisez des jetons d’accès à durée de vie limitée avec une portée strictement limitée des privilèges. Ne remettez jamais à un agent des jetons qui lui permettent d’accéder aux serveurs ou aux services centraux de l’entreprise. Dans l’idéal, créez des comptes de service dédiés pour chaque test.
• Isolez l’agent des outils dangereux et des ensembles de données qui ne sont pas pertinents pour sa tâche précise. En cas de déploiements expérimentaux, les bonnes pratiques consistent à tester l’agent à l’aide de données purement synthétiques qui imitent la structure des données de production réelles.
• Configurez la journalisation détaillée des actions de l’agent. Ces informations devraient inclure les journaux d’événements, les paramètres de ligne de commande et les artefacts de chaîne de pensée associés à chaque commande exécutée.
• Configurez le SIEM de manière à ce qu’il signale toute activité anormale de l’agent. Les mêmes techniques et règles utilisées pour détecter les attaques LotL sont applicables ici, mais des efforts supplémentaires sont nécessaires pour définir à quoi ressemble une activité normale pour un agent donné.
• Si des serveurs MCP et des compétences d’agent supplémentaires sont utilisés, analysez-les à l’aide des outils de sécurité émergents pour ces tâches, comme skill-scanner, mcp-scanner ou mcp-scan. En ce qui concerne plus particulièrement les tests OpenClaw, plusieurs entreprises ont déjà publié des outils open source permettant de contrôler la sécurité de ses configurations.

Politiques d’entreprise et formation des employés

Une interdiction pure et simple de tous les outils d’IA est une solution simple, mais rarement productive. Les employés trouvent généralement des solutions pour contourner le problème, ce qui le rend encore plus difficile à contrôler. Il vaut mieux trouver un équilibre raisonnable entre productivité et sécurité.

Mettez en place des politiques transparentes sur l’utilisation de l’IA agentique. Définissez les catégories de données que les services d’IA externes sont autorisés à traiter et celles qui leur sont strictement interdites. Les employés doivent comprendre pourquoi certaines choses sont interdites. Une politique du « oui, mais avec des conditions » est toujours mieux accueillie qu’un « non » catégorique.

Formez-les sur des exemples concrets. Les avertissements abstraits concernant les « risques de fuite » ont tendance à être inutiles. Il vaut mieux expliquer comment un agent ayant accès à la messagerie électronique peut transférer des messages confidentiels simplement sur demande d’un email entrant quelconque. Lorsque la menace semble réelle, la motivation à respecter les règles grandit également. Idéalement, les employés devraient suivre une mini-formation sur la sécurité de l'IA.

Proposez des alternatives sûres. Si les employés ont besoin d’un assistant d’IA, mettez à leur disposition un outil approuvé qui offre des fonctionnalités de gestion centralisée, de journalisation et de contrôle d’accès OAuth.