OpenClaw connaît son heure de gloire. L'agent IA autonome — que vous connaissez peut-être sous le nom de Clawdbot ou Moltbot, selon quand vous l'avez rencontré pour la première fois — a grimpé en flèche dans les classements GitHub ces dernières semaines, et les gens déploient des instances partout. Depuis la semaine dernière, il vit également son premier véritable moment de sécurité : CVE-2026-25253 a été publié, un RCE en 1 clic, avec un correctif arrivant seulement quelques jours plus tard. Si vous exécutez ces instances, ou si vous êtes responsable d'un réseau où quelqu'un pourrait le faire, c'est maintenant le moment de découvrir où elles se trouvent.
Contexte rapide
OpenClaw connecte des LLMs (Claude, GPT-4, les modèles de Google) à votre machine et à un vrai navigateur, et laisse un agent effectuer des tâches en votre nom — discuter sur Telegram/Slack, effectuer des tâches web, exécuter des commandes. Le composant qui intéresse ce template est le service gateway, qui se signale pour la découverte locale via le DNS multicast (mDNS) sur le port 5353/UDP.
Une note de nomenclature, parce que les matchers en dépendent : le projet s'appelle désormais OpenClaw, mais il a été publié sous le nom de Clawdbot et, auparavant, de Moltbot — même base de code, et les noms de service mDNS portent encore l'ancienne dénomination (_clawdbot-gw, _openclaw-gw). Le template reconnaît les deux pour que le changement de nom ne l'aveugle pas.
Le template
id: openclaw-exposure
info:
name: Openclaw (formerly Clawdbot / Moltbot) - Detect
author: rxerium
severity: info
description: |
Clawdbot Gateway service was detected exposing configuration information via mDNS including DNS settings, gateway details, and service configuration.
classification:
cwe-id: CWE-200
metadata:
verified: true
max-request: 1
shodan-query: product:openclaw
fofa-query: body="ClawdBot"
tags: network,openclaw,gateway,exposure,udp,mdns,js,discovery
javascript:
- pre-condition: |
isUDPPortOpen(Host,Port);
code: |
let c = require("nuclei/net");
let conn = c.Open('udp', `${Host}:${Port}`);
// mDNS query for _clawdbot-gw._tcp.local PTR record
let packet = "000000000001000000000000095f7365727669636573075f646e732d7364045f756470056c6f63616c00000c0001"
conn.SendHex(packet);
let resp = conn.RecvString(2048);
resp;
args:
Host: "{{Host}}"
Port: 5353
matchers:
- type: dsl
dsl:
- "contains(response, '_openclaw-gw') && success == true"
- "contains(response, 'clawdbot') && success == true"
condition: or
extractors:
- type: regex
part: response
name: server
group: 1
regex:
- 'displayName=([a-zA-Z0-9._-]+)'
Comment ça fonctionne
C'est un template de protocole JavaScript, pas HTTP. La plupart des templates d'exposition envoient un GET et font correspondre le corps de la réponse. Celui-ci utilise la bibliothèque nuclei/net de Nuclei pour ouvrir un socket brut et parler directement un protocole binaire — nécessaire, car mDNS n'est pas quelque chose que vous pouvez exprimer avec des matchers HTTP.
La pré-condition contrôle l'ensemble du processus. isUDPPortOpen(Host, Port) vérifie que 5353/UDP écoute réellement avant qu'un paquet soit envoyé. S'il est fermé, le template court-circuite et vous ne dépensez pas une requête — ce qui maintient les scans économiques lorsque vous pointez ceci vers une grande plage où la plupart des hôtes n'exécuteront pas de gateway.
Le code envoie une requête mDNS brute et lit la réponse. Il ouvre une connexion UDP vers Host:5353, envoie un paquet DNS encodé en hexadécimal avec SendHex, et lit jusqu'à 2048 octets en retour. La charge utile décodée est une requête DNS-SD d'énumération de services — une question PTR pour _services._dns-sd._udp.local, la méta-requête standard « lister tout ce que vous annoncez ». Un hôte exécutant le gateway répond avec ses services annoncés, et le nom de service OpenClaw/Clawdbot apparaît dans cette réponse.
Les matchers confirment que c'est un gateway. Deux vérifications DSL combinées en or : contains(response, '_openclaw-gw') ou contains(response, 'clawdbot'), chacune conditionnée à success == true pour qu'un socket à moitié ouvert ou une lecture vide ne puisse pas produire un faux positif. L'une ou l'autre des chaînes dans la réponse mDNS confirme que vous regardez un gateway OpenClaw, quelle que soit la dénomination qu'il porte.
L'extracteur récupère le nom d'affichage de l'appareil. Un regex extrait displayName=... de l'annonce et le présente comme server dans votre sortie. Ainsi, un résultat n'est pas seulement « un gateway existe » — vous obtenez le nom lisible par l'humain que l'opérateur lui a donné, ce qui est précieux pour l'inventaire et le triage.
La sévérité est info, CWE-200. C'est la classification honnête : le template détecte une exposition d'information (CWE-200, Information Exposure) — un gateway annonçant sa configuration là où il ne devrait pas — pas d'exploitation active. La fuite mDNS vers une interface accessible est le constat ; ce qu'un attaquant fait ensuite est un problème séparé.
verified: true signifie que le template a été confirmé contre une instance réelle, pas seulement écrit selon les spécifications — donc une correspondance est fiable.
Pourquoi la détection mDNS vaut la peine
La prise d'empreinte HTTP est la façon évidente de trouver ces instances, et ça fonctionne. Mais mDNS capture une tranche différente. Un gateway peut fuir de la découverte de services vers un segment réseau qu'un attaquant peut atteindre même lorsque le côté HTTP est derrière un pare-feu, un proxy, ou sur un port non standard que votre scan HTTP n'a pas couvert. C'est particulièrement pertinent pour les évaluations internes et les réseaux plats, où le multicast traverse allègrement des segments qu'il ne devrait pas et le gateway annonce effectivement « Je suis là, et voici mon nom » à tout ce qui est sur le réseau. Exécutez ceci aux côtés d'une empreinte HTTP et vous obtenez une couverture qu'aucun des deux n'a seul.
L'exécuter à grande échelle
Votre propre réseau et périmètre d'abord — autorisation la plus claire, et les découvertes mDNS sont les plus exploitables dans les réseaux que vous contrôlez.
nuclei -t openclaw-exposure.yaml -l targets.txt -o openclaw-hits.txt
Le template fixe déjà le port 5353 dans ses args, et la pré-condition isUDPPortOpen signifie que vous pouvez lui lancer une large liste d'hôtes sans rien marteler — les ports fermés sont ignorés avant qu'un paquet soit envoyé.
Pré-filtrez avec un scan UDP pour les grandes plages. Le scan UDP est plus lent que TCP, donc sur de larges périmètres, cela vaut la peine de trouver d'abord les écouteurs 5353 actifs et de les passer uniquement à Nuclei :
# naabu doesn't do UDP; use nmap for the 5353/udp sweep
nmap -sU -p 5353 --open -iL ranges.txt -oG - | awk '/Up$/{print $2}' > mdns-hosts.txt
nuclei -t openclaw-exposure.yaml -l mdns-hosts.txt -o openclaw-hits.txt
À l'échelle d'internet, appuyez-vous sur les données de scan. N'envoyez pas activement de l'UDP sur tout internet — c'est bruyant, lent, et juridiquement risqué. Utilisez les requêtes metadata intégrées dans le template (product:openclaw sur Shodan, body="ClawdBot" sur FOFA) pour énumérer les instances exposées, puis exécutez le template uniquement contre les candidats dans votre périmètre autorisé.
Exécutez-le en continu, pas une seule fois. La base d'installation d'OpenClaw grimpe de jour en jour en ce moment, ce qui signifie que de nouveaux gateways apparaissent tout le temps — un scan ponctuel devient vite obsolète. Et associez chaque résultat à deux actions : sortez le gateway de toute interface accessible, et faites tourner les identifiants qu'il détient.
Pourquoi c'est important
La fuite mDNS est le constat que produit le template, mais la raison de s'en préoccuper en ce moment est ce qui se trouve derrière un gateway exposé.
Le timing est toute l'histoire. CVE-2026-25253 a été divulgué le 26 janvier et corrigé dans OpenClaw 2026.1.29, publié en fin de semaine dernière. C'est une exécution de code à distance en 1 clic : la Control UI accepte un gatewayUrl depuis une chaîne de requête URL et ouvre automatiquement un WebSocket vers lui sans confirmation, divulguant le token d'authentification de l'instance à quiconque contrôle cette URL. Volez le token, détournez le WebSocket, exécutez des commandes. Ça ne nécessite aucune authentification préalable, c'est noté CVSS 8.8 (CWE-669, Incorrect Resource Transfer Between Spheres), et — la partie désagréable — ça fonctionne même contre des instances tournant uniquement sur localhost, parce que l'attaque pivote à travers le propre navigateur de la victime. Les chercheurs l'appellent une « chaîne d'exploitation RCE en 1 clic ». Le code de preuve de concept est déjà public, et la large couverture médiatique commence tout juste à arriver alors que j'écris ceci.
C'est le problème aigu, mais celui qui persiste, c'est l'exposition en général. OpenClaw stocke les identifiants pour les modèles cloud qu'il pilote — Claude, OpenAI, Google AI — ainsi que des tokens pour toutes les intégrations de messagerie et d'outillage que vous avez connectées. Un gateway exposé, c'est SSH ouvert sans mot de passe, sauf que le mot de passe est un tas d'identifiants IA payants et un point d'appui sur l'hôte. Et parce qu'un agent est une identité avec des accès, quiconque en prend le contrôle hérite de ses tokens et concessions OAuth, et peut lui donner des instructions qu'il exécutera sans les remettre en question. Les identifiants sont la récompense immédiate ; le point d'appui persistant à l'intérieur d'un agent privilégié est le plus durable. Un gateway diffusant son propre displayName via mDNS ne fait que se rendre plus facile à trouver. C'est là la faille que ce template comble.
Mitigation
Si vous exécutez OpenClaw, la liste des tâches de cette semaine :
- Patchez maintenant. Mettez à jour vers 2026.1.29 ou ultérieur — ça corrige CVE-2026-25253. Patcher ne défait pas l'exposition antérieure, donc traitez-le comme la première étape, pas comme l'ensemble du travail.
- Faites tourner le token du gateway et chaque identifiant stocké. Nouveau
authToken, nouvelles clés API pour Claude/OpenAI/Google AI, et vérifiez les journaux d'utilisation. S'il était accessible, assumez qu'il est compromis. - Sortez-le de toute interface accessible. Liez au loopback, ou mettez-le derrière un VPN, un bastion ou un ZTNA, et bloquez 5353/UDP aux limites de segment pour que mDNS cesse de traverser des réseaux où il n'a pas sa place. Le loopback est le plancher, pas le plafond — le RCE pivote à travers le navigateur, donc localhost seulement n'est pas un laissez-passer.
- Exécutez l'agent avec le moindre privilège. Pas de « mode dieu ». Limitez son accès au système, aux fichiers et aux clés, et surveillez-le comme tout compte avec des concessions OAuth et API permanentes.
- Guettez le schéma d'exploitation. Signalez les connexions WebSocket inattendues depuis les navigateurs vers des domaines externes, et alertez sur les changements de configuration du gateway.
La détection elle-même n'est pas exotique — une pré-condition, une requête mDNS brute, deux matchers de chaînes. La valeur, c'est le timing : elle capture des gateways s'annonçant sur le réseau même lorsque le côté HTTP est verrouillé, juste au moment où un RCE public en 1 clic rend urgent de les trouver. Exécutez-le tôt, exécutez-le souvent, faites tourner les clés sur chaque résultat. Les runtimes d'agents sont des identités avec des clés ; trouver les exposés rapidement, c'est tout le jeu.