Panneaux de contrôle exposés d'OpenClaw : 15 200 hôtes signalés pour exécution de code à distance

L'équipe de renseignement sur les menaces STRIKE de SecurityScorecard a passé une journée à scanner l'internet public à la recherche de panneaux de contrôle OpenClaw au début de février 2026 et a rapporté le 9 février qu'elle avait trouvé 42 900 adresses IP uniques répondant dans 82 pays, dont 15 200 semblaient vulnérables à l'exécution de code à distance. Cyber Security News a relayé les conclusions le 10 février 2026, la date indiquée dans l'enregistrement. Les panneaux sont la console de passerelle d'un agent IA auto-hébergé qui s'exécute avec l'accès aux fichiers de son propriétaire, de sorte que la même recherche indique qu'une instance compromise livre les clés SSH, les identifiants cloud et les sessions de navigateur actives. Aucune victime nommée ni prise de contrôle massive confirmée n'apparaît dans les sources consultées pour cet article. L'enregistrement complet, avec ses niveaux de gravité et de confiance, figure dans le Orca AI Incident Archive, aux côtés des autres entrées OpenClaw du même mois.

Ce qui rend le chiffre digne d’une lecture attentive, c’est qu’il ne s’agit pas de celui du titre. Le chiffre de 15 200 correspond au sous-ensemble que STRIKE a jugé exploitable, et non à la population qu’il a trouvée exposée. La même équipe a estimé le total à 42 900 adresses IP uniques, et son propre tableau de bord en direct, declawed.io, continuait de compter.

Ce que le scan a compté, et pourquoi ses chiffres ne concordent pas

La méthode de STRIKE reposait sur la prise d’empreinte plutôt que sur des tentatives de connexion. L’équipe a mis en correspondance les fichiers favicon servis par OpenClaw au cours de ses trois ères de marque, a recoupé les noms communs des certificats TLS, le DNS inverse et les journaux de transparence des certificats, et a intégré les données propres de SecurityScorecard sur les violations et les acteurs de menace. Sa progression publiée est une mesure utile de la vitesse à laquelle la situation a évolué : une recherche basée sur le titre a trouvé 24 034 instances, la prise d’empreinte des favicons en a confirmé 40 214, et 23 505 d’entre elles présentaient une interface de panneau de contrôle active (SecurityScorecard, 9 février 2026).

Les chiffres clés sont ceux que donne le résumé exécutif du rapport : 42,9 K adresses IP uniques dans 82 pays, 15,2 K instances signalées comme vulnérables à l’exécution de code à distance (RCE), ce que le rapport exprime comme 35,4 % des déploiements observés, plus de 24 K instances associées à des CVE connues, et 53,3 K instances dont il est affirmé qu’elles sont corrélées à une activité de violation antérieure. Ce dernier chiffre est supérieur au total de 42,9 K dans lequel il est censé s’inscrire, et SecurityScorecard n’explique pas cet écart dans l’article. Le rapport indique aussi que les comptages sont actualisés toutes les 15 minutes, ce qui signifie que tout instantané donné est une cible mouvante.

Une seconde lecture indépendante de la même recherche est parue le même jour et ne concorde pas. Infosecurity Magazine a rapporté 40 214 instances exposées associées à 28 663 adresses IP uniques, 12 812 exploitables via RCE, ce qu’il chiffrait à 63 % des déploiements observés, 549 instances corrélées à une activité de compromission antérieure, et 1 493 présentant des vulnérabilités connues (Phil Muncaster, 9 février 2026). Les deux comptes rendus divergent d’un facteur de près de cent sur la corrélation avec des compromissions, et leurs estimations du nombre d’hôtes réellement exploitables diffèrent de près du double. Ils ne peuvent pas tous deux décrire la même population avec le même dénominateur, et aucune des deux sources n’indique quel dénominateur elle a utilisé. Le chiffre de l’archive elle-même, 15 200, provient du premier de ces comptes rendus.

Le panneau de contrôle d’un agent n’est pas une page web

La raison pour laquelle un port mal lié compte ici, c’est ce qui se trouve derrière. Une passerelle OpenClaw détient les identifiants dont l’agent se sert pour agir : le répertoire d’identifiants ~/.openclaw/credentials, les clés SSH dans ~/.ssh, les profils de navigateur avec des sessions actives, et les comptes de messagerie par lesquels l’agent s’exprime. La liste de SecurityScorecard se poursuit avec les tâches cron et les hooks de heartbeat qu’un attaquant pourrait utiliser pour persister, ainsi qu’avec ce qu’elle appelle le contexte mémoire de l’agent, tout ce que l’agent sait de son propriétaire.

Cet héritage est le véritable constat, et le rapport l’énonce sans fioritures : « L’IA agentique ne crée pas de nouvelles classes de vulnérabilité. Elle hérite des anciennes et amplifie leur impact. » L’agent n’est pas la vulnérabilité. C’est le privilège qu’un panneau d’administration ordinaire exposé porte désormais.

La thèse de la liaison par défaut, et en quoi elle est plus étroite qu’elle n’y paraît

L'affirmation causale de SecurityScorecard est sans détour : « Par défaut, OpenClaw se lie à 0.0.0.0:18789, ce qui signifie qu'il écoute sur toutes les interfaces réseau, y compris l'internet public. Pour un outil aussi puissant, la valeur par défaut devrait être 127.0.0.1 (localhost uniquement). Ce n'est pas le cas. »

Cela est vrai pour un chemin de déploiement et pas pour un autre, et la différence compte pour quiconque cherche à savoir s'il est concerné. Dans le fichier docker-compose.yml du projet au tag v2026.1.29, le conteneur de passerelle est démarré avec l'option --bind ${OPENCLAW_GATEWAY_BIND:-lan}, qui prend par défaut l'adresse du réseau local, et le même fichier publie le port 18789 sur l'hôte sans préfixe d'adresse, ce qui le lie à toutes les interfaces de l'hôte. La passerelle native en ligne de commande est différente : dans src/cli/gateway-cli/run.ts au même tag, la valeur de bind revient à « loopback » lorsque ni option ni paramètre de configuration n'est présent, et le processus refuse de démarrer sur une adresse non loopback sans secret partagé. Une revue de code communautaire publiée dans le dépôt explain-openclaw fait la même distinction, en soutenant que la formulation « out of the box » confond la valeur par défaut de compose avec celle de la CLI native.

Cela ne réduit pas l’exposition détectée par le scan. Un conteneur déployé à partir du fichier compose du projet lui-même sur un hôte cloud correspond précisément au type de déploiement qu’un scan de favicon mettrait en évidence, et les anciennes versions antérieures au renommage que le rapport compte comme majoritaires ont bien pu être plus permissives que l’un ou l’autre des paramètres par défaut actuels. Cela signifie que la question pratique pour un opérateur est de savoir laquelle de ces deux voies il a utilisée, et non si OpenClaw est intrinsèquement exposé publiquement.

Trois CVE, une seule version corrective, et un score qui dépend de qui compte

Les trois vulnérabilités citées par STRIKE ont toutes été corrigées dans la version 2026.1.29, dont la publication GitHub est horodatée à 05:26 UTC le 30 janvier 2026. CVE-2026-25253 est l’exécution de code à distance en un clic via un paramètre gatewayUrl, notée 8,8 dans la fiche NVD, une note fournie par MITRE. CVE-2026-24763 est l’évasion du bac à sable Docker via la manipulation de PATH, également notée 8,8 par l’avis GitHub. CVE-2026-25157 est l’injection de commandes SSH dans l’application macOS.

Le troisième score est là où les chiffres qui circulent divergent. L'article de SecurityScorecard et le rapport de Cyber Security News l'indiquent tous deux à 7,8. Consulté le 5 novembre 2026, l'enregistrement du NVD affiche 7,7 provenant de l'avis GitHub qui fait office de CNA pour le problème, et 7,5 provenant du NIST en tant qu'évaluateur principal. Les scores sont proches, mais ce n'est pas le même nombre, et le 7,8 qui accompagne la couverture de la presse spécialisée n'est celui d'aucune des deux entrées NVD actuelles.

Une propriété de CVE-2026-25253 mérite sa propre phrase, car elle modifie le conseil d’atténuation : SecurityScorecard note que la chaîne de vol de jeton fonctionne « même si l’instance est liée à localhost ». Lier l’instance à 127.0.0.1 ferme la voie d’accès direct mesurée par le scan. Elle ne ferme pas celle-là.

La version corrective n'était pas seulement un ensemble de correctifs CVE. Ses notes de version consignent un changement incompatible : le mode d'authentification de la passerelle « none » est supprimé et la passerelle exige désormais un jeton ou un mot de passe, ainsi qu'un avertissement du doctor lorsque la passerelle est exposée sans authentification. Une version compilée suffisamment ancienne pour s'appeler encore Clawdbot ou Moltbot précède tout cela.

78 % est une étiquette de marque, pas une chaîne de version

L'affirmation du rapport selon laquelle les CVE sont largement non corrigées repose sur un indicateur indirect. STRIKE a réparti les 23 505 panneaux actifs selon le titre qu'ils servaient : Clawdbot Control 9 280 (39,5 %), Moltbot Control 9 048 (38,5 %) et OpenClaw Control 5 177 (22,0 %). Le rapport en conclut que 78 % des instances exposées « ont exécuté des versions plus anciennes portant des noms antérieurs aux correctifs de sécurité critiques », et ajoute le mot « suggère » dans la phrase suivante.

Il s’agit d’une inférence raisonnable, et cela reste une inférence. Le titre du panneau est une chaîne que le build écrit sur lui-même, et le rapport ne publie pas d’histogramme des versions. Un déploiement peut servir le titre actuel tout en étant en retard de plusieurs mois, ce que le rapport lui-même concède lorsqu’il dit que les 22 % sur le branding OpenClaw « peuvent encore correspondre à des builds obsolètes ». L’orientation du constat, à savoir que la plupart des déploiements exposés sont anciens, est corroborée par la forme de l’écosystème plutôt que par un recensement au niveau des correctifs.

La ligne sur l’acteur de menace, et la mise en garde qui l’accompagne

Voici la partie du compte rendu la plus susceptible d’être citée hors contexte ; il vaut donc la peine de préciser exactement ce que dit la source primaire. STRIKE écrit que certaines adresses IP d’instances sont corrélées à une infrastructure précédemment attribuée à des groupes nommés, citant Kimsuky, APT28, Salt Typhoon, Sandworm et APT41. Il définit ensuite ce que cela signifie : l’adresse IP ou son infrastructure d’hébergement a déjà été observée en lien avec les opérations de ce groupe, de sorte qu’une instance « liée à Kimsuky » est une instance dont l’hébergement a été signalé dans des flux de renseignement sur les menaces. Et il ajoute la phrase que les résumés omettent : « C’est un signal de renseignement, pas une preuve d’opération directe. »

Le pourcentage est une mesure distincte avec un dénominateur distinct. SecurityScorecard indique qu’environ 33,8 % des instances enrichies présentent une corrélation avec des violations de données, qu’il définit comme le fait que l’organisation d’hébergement soit apparue dans des registres antérieurs de violations de données. Il s’agit d’une affirmation sur l’historique de sécurité de l’hôte, et non sur un APT exploitant le panneau. Le rapport de Cyber Security News le présente comme « environ 33,8 % de l’infrastructure exposée est corrélée à une activité d’acteurs de menace connus », et le résumé de l’archive reprend une version de ce cadrage. Lu à la lumière de la source primaire, les 33,8 % correspondent à une corrélation avec des violations de données au sein d’un sous-ensemble enrichi, et la corrélation avec des acteurs de menace est une quantité plus petite et non nommée que le fournisseur refuse explicitement de considérer comme une preuve.

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

L’archive classe ce dossier comme un incident avec préjudice réel, gravité élevée et confiance A. Ce que les sources citées documentent, c’est une exposition plutôt qu’un bilan de victimes : des agents actifs joignables depuis l’internet ouvert, des identifiants se trouvant derrière un panneau non authentifié, et une large part d’hôtes dont les opérateurs apparaissent déjà dans des données de violation. Ni SecurityScorecard ni Infosecurity Magazine ne nomme de victime, de rançon, de jeu de données prélevé, ni un seul détournement confirmé remontant à un panneau exposé. Le préjudice consigné est l’opportunité permanente, mesurée à grande échelle, plus la corrélation propre au fournisseur selon laquelle un tiers des hôtes enrichis étaient déjà compromis ailleurs.

Cette distinction devrait survivre à la lecture. Un constat d’exposition de cette ampleur ne prouve pas que les expositions ont été exploitées, et les sources consultées ici ne prétendent pas qu’elles l’ont été.

Ce que les chercheurs ont dit aux opérateurs de faire

La liste de remédiation de SecurityScorecard est précise et porte principalement sur l’annulation de la configuration par défaut : appliquez le correctif v2026.2.1 ou une version ultérieure, plus récente que la version qui a corrigé les trois CVE ; définissez gateway.bind sur « 127.0.0.1 » ; accédez au panneau via Tailscale, WireGuard, Cloudflare Tunnel ou ngrok plutôt que par un port ouvert ; effectuez une rotation de chaque jeton et clé API stockés dans l’agent, en les considérant comme déjà compromis ; exécutez openclaw security audit deep ; n’exécutez jamais le framework en tant que root ; et, pour les équipes de sécurité, bloquez le port 18789 au périmètre et surveillez le trafic sortant de type commande-et-contrôle provenant des postes de travail internes.

Deux d'entre eux méritent d'être soulignés, car ils sont faciles à négliger. La rotation des identifiants n'est pas conditionnée par la preuve d'une compromission, car le panneau qui aurait exposé les clés est le même panneau qui les authentifie. Et le seuil de correctifs n'est pas 2026.1.29, même si c'est là que les trois CVE ont été corrigées, car la recommandation de STRIKE elle-même est 2026.2.1 ou ultérieure.

Les chercheurs ont également publié leur compteur. Le tableau de bord declawed sur declawed.io présente les décomptes d’expositions, le statut CVE par instance et la corrélation avec les violations, actualisés toutes les 15 minutes, ce qui est le seul moyen de lire des chiffres qui évoluaient aussi vite comme une tendance plutôt que comme un titre.

Établi, signalé, non résolu

Les éléments qui se vérifient d’une source à l’autre : la passerelle d’OpenClaw détient les identifiants avec lesquels son agent agit ; le fichier docker-compose du projet en v2026.1.29 publie le port 18789 sur toutes les interfaces de l’hôte et applique par défaut une liaison LAN ; trois CVE nommées ont été corrigées dans la v2026.1.29, publiée le 30 janvier 2026 ; et un vaste scan à l’échelle d’Internet a trouvé des dizaines de milliers de panneaux exposés, un chiffre que SecurityScorecard et Infosecurity Magazine situent tous deux à 40 000 ou plus dans une certaine unité.

Les éléments qui sont rapportés par le fournisseur et non reproduits indépendamment : les décomptes de 42,9 K et 15,2 K, la répartition sur 82 pays, le chiffre de 53,3 K pour la corrélation des violations, le taux de violations enrichies de 33,8 % et l’inférence de 78 % avant correctif. L’ensemble de chiffres différent d’Infosecurity Magazine constitue une seconde lecture de la même recherche, et non une mesure indépendante, et aucun tiers n’a relancé le scan.

Les points qui restent en suspens : quel dénominateur chaque décompte publié a utilisé, pourquoi le total de corrélation des violations dépasse le total d’IP dans le propre résumé du fournisseur, si les adresses corrélées aux APT reflètent des opérateurs utilisant OpenClaw ou une infrastructure qui l’héberge par hasard, et si l’un des panneaux exposés a effectivement été compromis. Les sources consultées pour cet article ne répondent à aucune de ces questions, et le dossier ne prétend pas qu’elles le font.