ClawJacked : n'importe quel site web pourrait attaquer par force brute un agent OpenClaw local

ClawJacked, une vulnérabilité qu'Oasis Security a divulguée dans l'agent IA open source OpenClaw le 26 février 2026, permettait à n'importe quel site web visité par un développeur d'ouvrir une connexion vers l'agent exécuté sur sa propre machine et de deviner son mot de passe jusqu'à ce que celui-ci lui cède le contrôle. Aucun clic, aucun plugin et aucune confirmation n'étaient nécessaires. L'enjeu était la passerelle qui orchestre l'agent : un intrus parvenu à entrer pouvait parler directement à l'agent, vider sa configuration, lister tous les appareils appairés et lire ses journaux. Oasis, éditeur de logiciels de gestion des accès agentiques, a démontré la chaîne de bout en bout dans son propre laboratoire et l'a signalée en privé, et OpenClaw a publié un correctif en moins de 24 heures. Aucune source citée dans cet article ne rapporte que l'attaque ait été utilisée contre un utilisateur réel. L'archive classe l'épisode comme un incident d'infrastructure de gravité élevée, daté au jour près du 25 février 2026 et sans dommage réel enregistré, aux côtés du reste de ses entrées OpenClaw dans l'Orca AI Incident Archive.

Trois valeurs par défaut, une seule chaîne

OpenClaw est un agent personnel auto-hébergé que ses utilisateurs pilotent depuis un tableau de bord web ou un terminal, et qui se connecte à des applications de messagerie, des calendriers et des outils de développement pour agir en leur sein. En son centre se trouve une passerelle, un serveur WebSocket local qu’Oasis décrit comme « le cerveau de l’opération » : elle gère l’authentification, stocke la configuration, gère les sessions de chat et distribue les commandes aux nœuds tels qu’une application compagnon macOS ou un iPhone. L’authentification se fait par jeton ou par mot de passe, et la passerelle se lie à localhost par défaut, selon le postulat explicite que l’accès local est intrinsèquement digne de confiance (Oasis Security, 26 février 2026).

Trois conséquences de cette hypothèse, enchaînées. Premièrement, les navigateurs n'appliquent pas les règles inter-origines aux connexions WebSocket comme ils le font pour les requêtes HTTP ordinaires, de sorte que le JavaScript de toute page visitée par l'utilisateur peut ouvrir une socket vers le port de la passerelle locale sans que rien ne soit visible à l'écran. Deuxièmement, le limiteur de débit de la passerelle exemptait entièrement les connexions de bouclage, de sorte que les tentatives de mot de passe échouées depuis 127.0.0.1 n'étaient ni comptées, ni limitées, ni consignées. Troisièmement, la passerelle approuvait automatiquement les appairages d'appareils provenant de localhost, de sorte qu'un script authentifié pouvait s'enregistrer comme appareil de confiance sans l'invite de confirmation qu'un appareil distant déclencherait.

Oasis a mesuré le taux de devinettes dans son propre laboratoire et l’a rapporté dans la divulgation : « Dans nos tests en laboratoire, nous avons atteint un rythme soutenu de centaines de tentatives de devinette de mot de passe par seconde à partir du seul JavaScript du navigateur. À cette vitesse, une liste de mots de passe courants est épuisée en moins d’une seconde, et un grand dictionnaire ne prendrait que quelques minutes. Un mot de passe choisi par un humain n’a aucune chance. » BleepingComputer, qui a couvert la divulgation le 1er mars 2026, décrit les mêmes trois étapes et le même ordre.

Ce qu'un attaquant obtient, et ce qu'Oasis a réellement montré

Une fois authentifié, le script disposait d’une session opérateur avec des autorisations de niveau administrateur. Oasis énumère quatre choses qu’il peut alors faire directement : envoyer des messages à l’agent IA et lire ses réponses, extraire la configuration de la passerelle, ce qui révèle les fournisseurs d’IA, les modèles et les canaux de messagerie utilisés, énumérer chaque nœud connecté avec sa plateforme et son adresse IP, et lire les journaux de l’application. À partir de là, Oasis décrit, plutôt qu’il ne démontre, l’escalade : demander à l’agent de rechercher des clés API dans l’historique Slack du développeur, lire des messages privés, exfiltrer des fichiers depuis des appareils appairés, ou exécuter des commandes shell arbitraires sur n’importe quel nœud appairé. La synthèse de l’entreprise sur le résultat est que, pour un développeur disposant d’intégrations OpenClaw typiques, cela équivaut à une « compromission complète du poste de travail, initiée depuis un onglet de navigateur ».

La démonstration publiée par Oasis, avec une preuve de concept vidéo, est plus étroite que cette description : un navigateur sur un site sans rapport a deviné le mot de passe de la passerelle, s'est connecté avec des autorisations complètes et a interagi avec succès avec l'agent de l'utilisateur, sans qu'aucune indication ne soit affichée à l'utilisateur. L'exfiltration de fichiers et l'exécution de shell sont décrites comme ce que l'accès rend possible, et non comme des étapes que la preuve de concept a réalisées. Cette distinction compte lorsque le compte rendu est lu comme un incident réellement survenu plutôt que comme un incident démontré.

Le correctif a été intégré dans la version 2026.2.25, pas dans la 2026.2.26

Oasis a demandé aux lecteurs de mettre à jour vers la version 2026.2.25 ou ultérieure, et l'avis publié par OpenClaw lui-même abonde dans ce sens. L'avis GitHub, GHSA-jmmg-jqc7-5qf4, indique que les versions affectées sont 2026.2.24 et antérieures, que les versions corrigées sont 2026.2.25 et ultérieures, et attribue le rapport à @luz-oasis, le responsable de recherche d'Oasis, Elad Luz. L'horodatage du registre npm pour 2026.2.25 est 04:16 UTC le 26 février 2026, et les notes de version du projet pour cette version décrivent le correctif en des termes qui correspondent exactement aux trois paramètres par défaut : « Sécurité/Authentification WebSocket de la passerelle : appliquer des vérifications d'origine pour les clients WebSocket de navigateur directs au-delà de Control UI/Webchat, appliquer une limitation des échecs d'authentification par mot de passe aux tentatives loopback d'origine navigateur (y compris localhost), et bloquer l'appairage automatique silencieux pour les clients de navigateur hors Control UI. »

Deux des articles de presse indiquent un numéro différent. BleepingComputer indique que le correctif a été « publié dans la version 2026.2.26 le 26 février », et SecurityAffairs répète que 2026.2.26 était la version qui corrigeait le problème, tandis que son propre paragraphe de conseils invite les lecteurs à mettre à jour vers 2026.2.25 ou une version ultérieure. Infosecurity Magazine, qui couvre la divulgation du 2 mars 2026, cite 2026.2.25. La version 2026.2.26 existe bien, mais npm l’enregistre à 23 h 59 UTC le 26 février, soit environ vingt heures après 2026.2.25, et ses notes constituent un lot distinct de durcissement. Le correctif que le lecteur doit rechercher est celui de la version 2026.2.25.

L’identifiant a été attribué plus tard. L’avis GitHub a été publié le 3 mars 2026 sous CVE-2026-32025, et l’entrée NVD correspondante a été publiée le 19 mars 2026 avec un score de base CVSS 3.1 de 7,5, noté élevé par NVD en tant qu’évaluateur principal et par VulnCheck en tant qu’évaluateur secondaire. L’avis lui-même est plus prudent que le score : son propre champ de gravité indique modéré, et son texte qualifie le bug de « grave, mais conditionnel », en précisant quatre conditions préalables — la passerelle joignable sur loopback, l’authentification par mot de passe utilisée, l’ouverture par la victime d’un contenu web contrôlé par l’attaquant, et un mot de passe devinable dans un nombre d’essais réalisable. Il indique aussi clairement ce que le bug n’est pas : « Ce n’est pas en soi un problème de type RCE exposé à Internet et non authentifié ; il s’agit d’une lacune de durcissement de l’authentification, d’origine navigateur locale, ayant un impact significatif dans les conditions ci-dessus. »

D'où vient le 42 665, et pourquoi ce n'est pas un nombre ClawJacked

Le résumé de l’archive indique que 42 665 instances étaient exposées au moment de la divulgation, et note que SecurityScorecard donne un chiffre différent de 40 214, dont 35,4 % étaient vulnérables. Aucune des trois sources citées pour cette entrée ne contient ni l’un ni l’autre de ces chiffres — Oasis, BleepingComputer et SecurityAffairs décrivent toutes la vulnérabilité sans fournir de chiffre sur la base installée. Les deux chiffres proviennent d’ailleurs, et tous deux ont été publiés avant que ClawJacked n’existe.

Le chiffre de 42 665 provient d’un scan indépendant. Maor Dayan, chercheur en sécurité qui a publié ses conclusions sur Medium, a développé un scanner appelé ClawdHunter v3.0 et l’a exécuté sur des données Shodan et Censys collectées entre le 28 et le 31 janvier 2026, signalant « au moins 42 665 instances » d’OpenClaw exposées publiquement sur Internet, dont 5 194 ont été activement vérifiées comme vulnérables et 93,4 % de celles vérifiées présentaient un contournement d’authentification. Le chiffre de 40 214 est celui de l’équipe STRIKE de SecurityScorecard, dans des recherches publiées le 9 février 2026, qui a compté les instances OpenClaw exposées à Internet et signalé 15,2 K comme vulnérables à l’exécution de code à distance, avec « 35,4 % des déploiements observés signalés comme vulnérables ». Les puces de synthèse de SecurityScorecard elles-mêmes indiquent 42,9 K adresses IP uniques hébergeant des panneaux de contrôle exposés, parallèlement aux 40 214 instances confirmées dans le corps de son texte — deux mesures différentes au sein d’un même rapport.

Aucun des deux chiffres ne mesure la portée de ClawJacked, car tous deux comptent des instances qui répondent sur une interface publique. La condition préalable de ClawJacked est la configuration opposée : une passerelle liée à l’interface loopback, en mode mot de passe, sur une machine dont l’utilisateur navigue vers une page hostile. Un serveur compté dans un scan à l’échelle d’Internet peut se trouver derrière sa propre authentification et ne pas être affecté par ce bug, tandis que l’ordinateur portable qui n’apparaît jamais dans un tel scan est exactement la cible décrite par Oasis. La formulation même de l’archive, « at disclosure », rattache donc un décompte de population de janvier à une vulnérabilité de février. Ces chiffres sont de véritables mesures de l’exposition d’OpenClaw ; ils ne comptabilisent pas les machines dont ClawJacked aurait pu prendre le contrôle. Cet article ne tranche pas un différend — le dossier n’est pas marqué comme contesté — mais la provenance des deux chiffres est vérifiable et n’étaye pas la présentation « at disclosure ».

Ce qui est établi, et ce qui ne l’est pas

Établi : qu'Oasis Security a découvert la chaîne et l'a démontrée en laboratoire ; que l'avis et les notes de version d'OpenClaw confirment les trois comportements — absence d'application de l'origine pour les clients WebSocket des navigateurs, absence de limitation pour les tentatives de mot de passe en boucle locale, appairage automatique silencieux — et que la version 2026.2.25 a modifié chacun d'eux ; que le correctif a été déployé dans le jour suivant le signalement ; et que trois médias extérieurs au blog du découvreur l'ont couvert. La note de confiance A de l'archive est cohérente avec ce dossier, et rien ici n'est contesté par les parties concernées.

Non établi : que quiconque l'ait utilisé. Aucune source n'est citée ici, et aucune n'a été trouvée dans la couverture entourant la divulgation, ne rapporte une compromission réelle, une victime ou des données prélevées. La démonstration d'Oasis est une démonstration en laboratoire, et l'article décrit la capacité d'un attaquant plutôt qu'une attaque observée. Cela concorde avec le fait que l'archive ne consigne aucun préjudice réel, et c'est la nuance la plus importante de cette affaire : il s'agit d'un signalement de vulnérabilité, non d'un rapport de violation.

Deux libellés en circulation sont erronés, et tous deux sont faciles à hériter. Plusieurs articles secondaires associent CVE-2026-25253 à ClawJacked. L’entrée du NVD pour cet identifiant décrit un autre bug dans le même produit : OpenClaw avant 2026.1.29 prenant un gatewayUrl depuis une chaîne de requête et s’y connectant sans demander de confirmation tout en envoyant un jeton, un vol de jeton en un clic avec un score CVSS de 8,8, publié le 1er février 2026 et corrigé le 29 janvier. Il s’agit de la vulnérabilité de janvier, avec un mécanisme différent et un correctif différent. L’identifiant de ClawJacked est CVE-2026-32025. Infosecurity Magazine, de son côté, a décrit ClawJacked comme une injection de prompt indirecte ; la chaîne documentée par Oasis n’implique ni prompt ni décision du modèle — il s’agit d’un contournement d’authentification qui se termine par une session d’opérateur.

Qu’est-ce qui a changé par la suite ?

OpenClaw a corrigé la vulnérabilité, publié l’avis et crédité la personne qui l’a signalée, et le CVE a été attribué dans la semaine suivant l’article public. Les recommandations d’Oasis aux organisations vont au-delà du correctif : recenser les agents et assistants exécutés sur les machines des développeurs, mettre à jour chaque instance, auditer les identifiants et capacités détenus par chacun et révoquer ceux qui ne sont pas utilisés, et gouverner les agents en tant qu’identités non humaines avec des contrôles d’intention, l’application des politiques, un accès juste-à-temps et une piste d’audit de l’humain à l’agent puis à l’action. L’entreprise vend des logiciels dans cette dernière catégorie, ce qu’il vaut la peine de savoir lorsqu’on met la dernière recommandation en balance avec les trois premières.

Le contexte plus large est que ClawJacked n’était qu’un avis parmi une avalanche. La base de données d’avis de sécurité de GitHub contient un grand lot d’avis OpenClaw datés du 3 mars 2026 — le jour même où celui de ClawJacked a été publié — couvrant divers bugs distincts d’authentification, d’appairage, de traversée de chemin et d’évasion de sandbox dans les versions 2026.2.19 à 2026.2.26. Le schéma que conserve la fiche ClawJacked est plus étroit que « les agents IA ne sont pas sûrs » et plus utile : la passerelle traitait l’interface loopback comme une frontière de confiance, et le navigateur a rendu cette hypothèse fausse. Tout service local qui exempte 127.0.0.1 de la limitation de débit, et tout flux d’appairage d’appareils qui approuve automatiquement les appelants locaux, hérite du même profil, qu’un modèle IA soit derrière ou non. En l’occurrence, le modèle n’a jamais été le composant vulnérable — c’était la couche d’authentification qui l’entoure.