Plus de 135 000 instances OpenClaw sont exposées sur Internet. Une vulnérabilité critique permet l’exécution de code à distance en un seul clic depuis n’importe quel navigateur. Des chercheurs ont découvert plus de 1 100 skills malveillants distribuant Atomic Stealer sur ClawHub. Microsoft a publié un article intitulé « Running OpenClaw Safely » qui commence par noter que « pour la plupart des environnements, la décision appropriée pourrait être de ne pas le déployer. » Le centre national de cybersécurité de la Belgique a émis un avis gouvernemental. Cisco a qualifié les agents IA personnels comme OpenClaw de « cauchemar sécuritaire ».

Ce n’est pas de l’alarmisme. Ce sont des faits provenant de chercheurs en sécurité indépendants, de fournisseurs d’entreprise et d’agences gouvernementales. Si vous utilisez une instance OpenClaw, cela vous concerne.

Ce qui a mal tourné

OpenClaw a été conçu pour localhost. Vous l’installez sur votre machine, vous communiquez via une interface web locale, et il agit en votre nom. Le modèle de sécurité supposait que la personne accédant à l’interface était celle assise devant le clavier.

Puis OpenClaw est passé de 9 000 à plus de 200 000 étoiles GitHub en quelques semaines. Les utilisateurs l’ont déployé sur des serveurs VPS, l’ont exposé à Internet et l’ont connecté à leurs canaux de messagerie. L’hypothèse du localhost s’est effondrée à grande échelle. (Nous avons couvert l’ensemble des options de déploiement et leurs compromis de sécurité dans un guide séparé.)

CVE-2026-25253 : exécution de code à distance en un clic

La vulnérabilité la plus grave est CVE-2026-25253, notée CVSS 8.8. OpenClaw ne validait pas les en-têtes d’origine WebSocket. Voici comment l’attaque fonctionne :

  1. La victime visite une page web malveillante (ou une page avec une publicité malveillante).
  2. Le JavaScript de cette page ouvre une connexion WebSocket vers localhost:18789, le port par défaut d’OpenClaw.
  3. Comme le navigateur se trouve sur la même machine, la connexion contourne toute règle de pare-feu.
  4. L’attaquant exfiltre le token d’authentification de la passerelle via le WebSocket.
  5. Avec le token, l’attaquant a un contrôle total : accès au shell, lecture/écriture de fichiers et exécution de commandes.

Se lier à localhost ne sert à rien. L’attaque passe par le propre navigateur de la victime. L’analyse de SOCRadar détaille la chaîne complète.

Skills malveillants et attaques sur la chaîne d’approvisionnement

Des chercheurs ont trouvé 341 skills malveillants sur ClawHub début février. Ce nombre a depuis atteint plus de 1 100. La campagne ClawHavoc distribue Atomic Stealer via des skills qui semblent légitimes mais contiennent des étapes d’exécution de commandes cachées. Les skills sont des fichiers Markdown. Une instruction cachée disant « exécute cette commande shell » est facile à intégrer et difficile à repérer.

Le 17 février, l’attaque sur la chaîne d’approvisionnement de Cline est allée encore plus loin. Un token npm compromis a été utilisé pour publier une version du CLI Cline qui installait silencieusement OpenClaw sur les machines des développeurs. L’attaque ciblait le pipeline de build lui-même.

Des chercheurs ont maintenant divulgué six vulnérabilités supplémentaires dans le noyau d’OpenClaw, y compris CVE-2026-27001. Le Top 10 OWASP pour les Applications Agentiques liste désormais bon nombre de ces schémas comme risques majeurs. Comme le formule l’analyse de Conscia, il s’agit d’une crise de sécurité à part entière.

Pourquoi un token de passerelle ne suffit pas

L’authentification intégrée d’OpenClaw repose sur un token statique. Vous le définissez une fois, et chaque requête doit l’inclure. C’est mieux que rien. Mais cela présente des limitations fondamentales.

Les tokens statiques n’expirent pas. Si un token fuite (via CVE-2026-25253, via les logs, via un skill malveillant lisant les variables d’environnement), l’attaquant dispose d’un accès permanent jusqu’à ce que vous le remarquiez et procédiez à une rotation manuelle.

Les tokens statiques ne peuvent pas être limités en portée. Le token de passerelle accorde un accès complet. Il n’existe aucun moyen de donner un accès en lecture seule ou de limiter ce qu’une session authentifiée peut faire.

Les tokens statiques ne peuvent pas être liés à un utilisateur. Si trois personnes partagent un token, il n’y a aucune piste d’audit permettant de savoir qui a fait quoi.

La plupart des guides de déploiement VPS recommandent de placer OpenClaw derrière nginx avec une authentification basique. C’est mieux, mais cela reste un identifiant statique. Si quelqu’un le capture (écoute réseau sur une connexion non chiffrée, configuration de reverse proxy compromise, fichier .htpasswd divulgué), il a accès.

Le problème fondamental est plus profond : l’authentification se fait à l’intérieur de l’application. Si l’application a une vulnérabilité, l’authentification peut être contournée. CVE-2026-25253 l’a démontré exactement. Le token de passerelle existait. La vulnérabilité l’a extrait avant même que l’application ait eu la chance de le vérifier.

C’est pourquoi nous avons construit OpenClaw.rocks avec une authentification au niveau du proxy. Les sections suivantes expliquent l’architecture en détail. Si vous souhaitez simplement une instance sécurisée sans tout construire vous-même, consultez nos offres.

Comment nous sécurisons la passerelle

Chez OpenClaw.rocks, l’authentification se fait au niveau du proxy, avant que la requête n’atteigne le pod OpenClaw. C’est une différence structurelle, pas simplement une différence de configuration.

Voici l’architecture en trois couches.

Couche 1 : Cookies de passerelle signés (HMAC-SHA256)

Lorsque vous accédez à votre instance OpenClaw via le tableau de bord OpenClaw.rocks, le serveur génère un cookie signé. Le format est :

{expiry}.{userId}.{instanceId}.{hmac_base64url}

Le cookie a une durée de vie de 4 heures et se renouvelle automatiquement toutes les 45 minutes. Il est limité au chemin /gw/{instanceId}, de sorte qu’un cookie ne peut pas être utilisé pour accéder à une autre instance. Il est HttpOnly (le JavaScript ne peut pas le lire), Secure (envoyé uniquement via HTTPS), et SameSite=Lax (non envoyé lors de requêtes cross-origin). Le HMAC est vérifié à l’aide d’une comparaison à temps constant pour empêcher les attaques par timing.

Même si quelqu’un intercepte la valeur du cookie, il ne peut pas en forger un nouveau sans le secret de signature. Et le cookie lui-même ne contient aucun identifiant donnant un accès direct à OpenClaw.

Couche 2 : Traefik ForwardAuth

Chaque requête vers une instance OpenClaw passe par Traefik, notre reverse proxy. Avant de transmettre la requête, Traefik appelle un point de terminaison auth-gate qui vérifie le cookie signé.

Il s’agit d’une vérification HMAC pure. Zéro appel à la base de données. Zéro requête réseau vers Supabase ou tout autre service. La décision est prise en microsecondes.

Si le cookie est invalide, expiré ou absent, la requête est rejetée au niveau du proxy. La requête n’atteint jamais OpenClaw. C’est la différence fondamentale. Dans une configuration classique, c’est OpenClaw lui-même qui doit décider d’autoriser ou de rejeter une requête. Si OpenClaw présente une vulnérabilité dans sa logique d’authentification, un attaquant peut passer. Dans notre configuration, OpenClaw ne voit jamais de trafic non authentifié.

Couche 3 : Injection du token de passerelle

Chaque instance OpenClaw dispose d’un token de passerelle intégré. C’est le même token que vous configureriez vous-même en auto-hébergement. La différence réside dans la manière dont il parvient au pod.

Dans une configuration d’auto-hébergement classique, vous collez le token dans un fichier de configuration, vous le stockez peut-être dans une variable d’environnement et vous espérez qu’il ne fuira jamais. Votre navigateur doit l’envoyer à chaque requête, ce qui est exactement le mécanisme que CVE-2026-25253 a exploité pour l’exfiltrer.

Dans notre configuration, un token aléatoire cryptographique de 32 octets est généré à la création de l’instance et stocké en tant que Kubernetes Secret. Traefik l’injecte comme en-tête Authorization à chaque requête transmise. Le navigateur ne le voit jamais. Il n’apparaît jamais dans un fichier de configuration que vous pourriez accidentellement commiter. Il ne voyage jamais via un WebSocket qu’une page malveillante pourrait détourner. Le token existe, mais il vit entièrement à l’intérieur du cluster, ne circulant qu’entre Traefik et le pod.

Pourquoi cette architecture bloque CVE-2026-25253

La chaîne d’attaque de CVE-2026-25253 exfiltre le token de passerelle via WebSocket. Voyons ce qui se passe lorsque cette attaque cible une instance OpenClaw.rocks :

  1. Le JavaScript de l’attaquant tente d’ouvrir un WebSocket vers le pod OpenClaw.
  2. La connexion atteint Traefik en premier. Traefik vérifie le cookie signé.
  3. La page malveillante se trouve sur une origine différente. Le cookie SameSite=Lax n’est pas envoyé lors de connexions WebSocket cross-origin. La requête est rejetée.
  4. Même si le cookie était en quelque sorte attaché, la page de l’attaquant ne peut pas le lire (HttpOnly). Il n’y a rien à exfiltrer.
  5. Même si le cookie fuitait, il ne contient pas le token bearer. Le token bearer est injecté par Traefik, jamais exposé au navigateur. L’attaquant ne peut pas le reconstruire.

Il n’y a rien à voler car le navigateur ne détient jamais les véritables identifiants. La surface d’attaque que CVE-2026-25253 exploite n’existe tout simplement pas.

Checklist de sécurité OpenClaw pour les auto-hébergeurs

Tout le monde ne souhaite pas un hébergement géré, et c’est parfaitement normal. Si vous utilisez votre propre instance OpenClaw, voici une checklist pratique pour 2026.

Votre token d’authentification de passerelle est-il activé ? Exécutez openclaw doctor pour vérifier. Si l’authentification de passerelle est désactivée, quiconque peut atteindre le port 18789 contrôle votre agent et tout ce à quoi il a accès.

Votre instance est-elle derrière un reverse proxy avec TLS ? Le HTTP en clair signifie que n’importe qui sur le chemin réseau peut lire votre token de passerelle en transit. Utilisez nginx, Caddy ou Traefik avec un certificat TLS valide. Let’s Encrypt est gratuit.

Êtes-vous sur la dernière version ? CVE-2026-25253 a été corrigée dans v2026.1.29. CVE-2026-27001 a été corrigée dans v2026.2.15. Si vous utilisez une version antérieure, mettez à jour maintenant. Le guide de durcissement d’Adversa AI couvre les étapes supplémentaires.

Avez-vous audité vos skills installés ? La campagne ClawHavoc ciblait spécifiquement ClawHub. Vérifiez chaque skill que vous avez installé. Si vous ne l’avez pas installé vous-même, supprimez-le et vérifiez la source.

Votre reverse proxy valide-t-il les origines WebSocket ? C’est le vecteur spécifique exploité par CVE-2026-25253. Votre reverse proxy devrait rejeter les requêtes d’upgrade WebSocket provenant d’origines inattendues. La documentation de sécurité d’OpenClaw contient des exemples de configuration.

Votre authentification se fait-elle avant ou après que la requête atteigne OpenClaw ? C’est la question la plus importante. Si OpenClaw gère sa propre authentification, une vulnérabilité dans OpenClaw peut la contourner. Si votre reverse proxy gère l’authentification, la requête n’atteint OpenClaw que si elle est déjà vérifiée.

Ce que nous ne résolvons pas

L’honnêteté est importante ici. L’authentification au niveau du proxy résout la sécurité de la passerelle. Elle ne résout pas tout.

L’injection de prompt est un problème au niveau applicatif. Un message habilement conçu peut potentiellement amener l’agent à effectuer des actions non prévues. Il s’agit d’un domaine de recherche actif dans toute l’industrie de l’IA, et aucun fournisseur d’hébergement ne peut totalement l’empêcher aujourd’hui.

Le comportement malveillant des skills s’exécute dans le contexte de l’agent. Si vous installez un skill qui exfiltre des données via un trafic HTTPS sortant autorisé, l’authentification proxy ne peut pas l’arrêter. Ce que notre infrastructure fait, c’est contenir le rayon d’explosion : chaque instance fonctionne dans son propre pod Kubernetes avec isolation réseau, capabilities réduites, seccomp et un système de fichiers racine en lecture seule. Un agent compromis ne peut pas atteindre d’autres agents ou le système hôte. L’opérateur Kubernetes applique ces paramètres par défaut pour chaque instance.

La confiance envers le fournisseur LLM dépend de votre plan. Si vous utilisez vos propres clés API (plan Light), vos conversations passent par le fournisseur que vous configurez, et sa politique de confidentialité s’applique. Avec le plan Pro, nous acheminons le trafic via notre propre passerelle AI avec des fournisseurs préconfigurés. Vous n’avez pas besoin de confier vos clés API à une instance OpenClaw ni de faire confiance à la sécurité de stockage d’une clé tierce. La passerelle gère les identifiants des fournisseurs en votre nom, et vous ne les voyez ni ne les manipulez jamais directement.

La sécurité fonctionne par couches. Nous gérons les couches d’infrastructure. Les défis au niveau applicatif sont réels et méritent d’être compris.

La sécurité est une décision architecturale

La crise de sécurité d’OpenClaw ne concerne pas un seul CVE ou un lot de skills malveillants. Il s’agit d’un outil conçu pour localhost déployé sur Internet par des centaines de milliers de personnes, avec une authentification qui se fait à l’intérieur de l’application qu’elle est censée protéger.

Déplacer l’authentification au niveau du proxy n’est pas une fonctionnalité. C’est une décision architecturale. Cela signifie que lorsque le prochain CVE d’OpenClaw sera publié (et ce sera le cas), les requêtes authentifiées seront toujours vérifiées avant de toucher l’application. La surface d’attaque est structurellement plus petite.

Nous avons pris cette décision dès le premier jour. Chaque instance OpenClaw.rocks fonctionne derrière des cookies signés, une vérification ForwardAuth et des tokens bearer par instance. Pas de tokens de passerelle dans le navigateur. Pas d’identifiants statiques à exfiltrer. Pas de logique d’authentification à l’intérieur de l’application vulnérable.

Si vous souhaitez en savoir plus sur la façon dont nous déployons OpenClaw sur Kubernetes avec un durcissement de sécurité complet, le guide de déploiement couvre le sujet en détail.

Si vous voulez simplement un agent fonctionnel qui reste sécurisé sans avoir à penser à tout cela, c’est exactement ce que nous avons construit.

Commencez sur OpenClaw.rocks ou explorez l’opérateur Kubernetes open-source si vous préférez gérer votre propre infrastructure.