Quatre vulnérabilités enchaînables dans OpenClaw remettent en cause l’une des prémisses les plus dangereuses de l’ère des agents autonomes : celle selon laquelle accorder un accès étendu à un modèle de langage n’est qu’une question de productivité. Après tout, lorsque l’agent lui-même devient le vecteur d’attaque, le débat cesse d’être une question de commodité et devient une question d’architecture de confiance.
Ci-dessous, nous allons détailler ce qui s’est passé, pourquoi cela compte pour ceux qui écrivent du code et, surtout, ce qu’il faut faire avant que votre instance n’apparaisse dans les prochaines statistiques.
Le maillon le plus faible n’est plus l’humain : c’est l’agent que vous avez déployé ce vendredi
En avril 2026, Cyera a publié quatre CVE enchâinables dans OpenClaw, cadre open source d’agents autonomes largement adopté dans les environnements d’entreprise. Cette combinaison a été baptisée Claw Chain et, ensemble, les failles permettent à un attaquant d’utiliser l’agent lui-même pour compromettre le système hôte.
Pour rappeler le contexte, OpenClaw a été lancé initialement sous le nom de Clawdbot fin 2025, et connecte les LLM directement à des systèmes de fichiers, des identifiants, des applications SaaS et des environnements d’exécution. Autrement dit, il représente exactement le type de composant qui concentre des accès critiques en un seul point. De plus, selon Cyera, entre 65 000 et 180 000 instances étaient accessibles publiquement sur Internet en mai 2026.
Par conséquent, le problème n’est pas théorique. C’est un scénario qui est probablement en cours d’exécution dans une pipeline de votre entreprise à l’instant même.
Anatomie technique des quatre CVE : comprendre chaque pièce avant l’enchaînement
Pour comprendre pourquoi cette chaîne est si efficace, il faut examiner chacune des failles indépendamment. Ensuite, on voit clairement comment elles se complètent.
CVE-2026-44113 et CVE-2026-44112 : quand le sandbox accorde trop sa confiance à ce qu’il voit
Toutes deux exploitent une condition de course de type TOCTOU (time-of-check/time-of-use) dans le sandbox OpenShell. En d’autres termes, le système valide une ressource, mais l’attaquant peut la remplacer avant son exécution effective.
La CVE-2026-44113 affecte les opérations de lecture. Elle permet de remplacer un chemin validé par un lien symbolique pointant en dehors du répertoire autorisé. En revanche, la CVE-2026-44112, avec un CVSS critique de 9,6, réalise la même manipulation sur les opérations d’écriture. Résultat : l’attaquant peut modifier des configurations, planter des portes dérobées et obtenir un contrôle persistant.
Si vous avez déjà mis en place une validation de chemin en production, ce type de bug vous semble probablement familier. D’ailleurs, c’est un classique qui continue d’apparaître précisément parce que les développeurs traitent la validation et l’utilisation comme des opérations atomiques, alors qu’elles le sont rarement.
CVE-2026-44115 : la faille entre valider et exécuter
Cette vulnérabilité exploite une lacune entre la validation des commandes et leur exécution dans le shell. Plus précisément, des variables d’environnement, y compris des clés API, des jetons et des identifiants, peuvent être développées à l’intérieur de heredocs non cités pendant l’exécution. En clair, la commande passe la validation comme sûre mais divulgue des secrets au moment où elle s’exécute.
Concrètement, c’est la confirmation que la sanitisation fondée sur une correspondance de chaînes ne résiste pas à celui qui comprend le cycle de vie du shell.
CVE-2026-44118 : le problème de faire confiance aux indicateurs du client
Enfin, la CVE-2026-44118 exploite une option appelée senderIsOwner, contrôlée par le client. OpenClaw se fie à ce drapeau sans le vérifier par rapport à la session authentifiée. Ainsi, un processus local doté d’un jeton valant Bearer peut élever ses privilèges au rang de propriétaire et prendre le contrôle de la passerelle, de la planification des tâches et de la gestion de l’environnement d’exécution.
En résumé, c’est le vieux problème d’autorisation traité comme authentification, désormais appliqué aux agents autonomes.
Comment l’attaque et les failles en chaîne fonctionnent concrètement
À présent, assemblons les pièces. L’attaquant démarre par une injection de prompt, un plugin malveillant ou une entrée externe compromise afin d’obtenir l’exécution de code dans le sandbox. À partir de ce point, les autres failles opèrent en parallèle.
Ensuite, avec les CVE-2026-44113 et CVE-2026-44115, il récupère des identifiants, des jetons, des fichiers de configuration et d’autres données sensibles. Puis, la CVE-2026-44118 élève les privilèges au niveau de propriétaire de l’agent. Enfin, la CVE-2026-44112 entre en action pour planter des portes dérobées et assurer la persistance sur l’hôte.
Le détail le plus inquiétant est que chaque étape imite le comportement légitime de l’agent. Par conséquent, les mécanismes traditionnels de détection passent souvent inaperçus. Comme Cyera le résumait dans le rapport, l’enchaînement ne dépend pas d’un seul exploit critique, mais démontre comment plusieurs faiblesses mineures peuvent être exploitées en parallèle à partir d’un seul point d’entrée.
Des patches sont déjà disponibles : que faire dès aujourd’hui, même avant le goûter
Les vulnérabilités ont été signalées le 22 avril 2026 et corrigées le lendemain. Les identifiants sont GHSA-5h3g-6xhh-rg6p, GHSA-wppj-c6mr-83jj, GHSA-r6xh-pqhr-v4xh et GHSA-x3h8-jrgh-p8jx.
Toutefois, appliquer le correctif n’est que la première étape. Voici la liste de contrôle minimale :
- Mettez immédiatement à jour toutes les instances d’OpenClaw en production, en préproduction et dans les environnements de développement.
- Rotatez toutes les identités accessibles par les processus d’OpenClaw, y compris les clés API, les clés SSH et les secrets des SaaS connectés.
- Auditez l’étendue des accès de chaque agent, en appliquant réellement le principe du moindre privilège, pas seulement sur le papier.
- Placez les instances exposées à Internet derrière une authentification forte ou des contrôles de pare-feu.
- Révisez les journaux des 60 derniers jours à la recherche de motifs anormaux de lecture/écriture et d’élévation de privilèges.
Leçons qui vont au-delà des Failles d’OpenClaw : comment concevoir des agents qui ne présentent pas de porte dérobée
Bien que le cas soit spécifique, les enseignements sont larges. Tout d’abord, la validation et l’exécution doivent être traitées comme des points critiques d’une même transaction, jamais comme des étapes séparées. Autrement dit, toute fenêtre entre elles devient une opportunité.
De plus, les indicateurs fournis par le client ne doivent jamais être source de vérité pour les décisions d’autorisation. Au lieu de cela, l’autorisation doit être dérivée du contexte authentifié sur le serveur. Tout aussi important, les sandboxes qui exécutent des commandes shell doivent prendre en compte l’expansion des variables comme faisant partie de la surface d’attaque, et non comme un détail de l’implémentation.
Par ailleurs, la dimension architecturale est aussi critique que la partie code. Les agents autonomes disposant d’un accès étendu à des identifiants, à des systèmes de fichiers et à des SaaS constituent, par définition, des cibles de grande valeur. Par conséquent, segmenter les permissions par tâche, faire expirer les jetons de manière agressive et exiger une confirmation humaine pour les opérations sensibles n’est plus de la paranoïa : c’est devenu une hygiène de base.
Failles : la nouvelle frontière de la sécurité n’est plus le périmètre
L’affaire Claw Chain marque un tournant. Autrefois, nous parlions surtout d’injections SQL, XSS et CSRF comme les grandes catégories. Aujourd’hui, avec des agents opérant comme des exécutants semi-autonomes de tâches, la surface d’attaque s’est déplacée à l’intérieur même de l’agent.
Ainsi, si vous travaillez avec des intégrations de LLM, des plugins, des appels de fonctions ou des cadres tels qu’OpenClaw, LangChain, AutoGen et des systèmes similaires, il est utile de revenir aujourd’hui même sur trois questions :
- Quelles informations d’identification votre agent porte et que vous ne changeriez pas demain sans douleur ?
- Où, dans le flux, existe-t-il des validations qui se fient à des états contrôlés par le client ?
- Combien de temps faudrait-il pour repérer un agent se comportant légèrement différemment de ce qui est attendu ?
En conclusion, les agents d’IA ne sont pas de simples outils de productivité. Ils sont, avant tout, des systèmes distribués dotés de permissions étendues et d’une logique probabiliste. Par conséquent, les traiter comme une infrastructure critique dès le premier commit est ce qui sépare les équipes qui apprendront du Claw Chain de celles qui deviendront la prochaine grande manchette.
Acompagnez notre profil sur Instagram !
