Retour au blog
AgentsTechniqueArticle technique

Sécuriser OpenClaw en 2026 : De la faille Clawjacked à l'isolation totale

Publié 03 mars 20264 min de lectureStéphane

Résumé décisionnel

Examinez les risques OpenClaw et les mesures proposées : isolation réseau, sandbox Docker, restrictions de privilèges et audit des outils autorisés.

RAG
Sécuriser OpenClaw en 2026 : De la faille Clawjacked à l'isolation totale

Comment transformer un framework d'agent IA massivement déployé en une infrastructure locale résiliente et strictement isolée.

TL;DR : L'époque où les IA n'étaient que de simples générateurs de texte est révolue. OpenClaw opère comme un démon d'orchestration local avec des accès système réels. La récente faille "Clawjacked" a prouvé que la confiance aveugle au localhost est mortelle. Pour sécuriser votre instance : isolez-la sur un VPS dédié, utilisez Tailscale, configurez un sandboxing Docker strict et bannissez le "Elevated Mode".

En février 2026, l'écosystème de l'IA a franchi un cap avec l'adoption massive d'OpenClaw (anciennement Clawdbot). Contrairement aux LLMs hébergés dans le cloud, OpenClaw est un démon local (Gateway) qui orchestre une boucle "ReAct" (Reasoning and Acting).

L'agent est doté de "mains" numériques : il peut exécuter des scripts shell, modifier des fichiers, et communiquer sur Slack ou Discord. Mais cette intégration système profonde bouleverse notre modèle de menace. Une compromission de l'agent se traduit désormais par une compromission totale de l'hôte.


Le signal d'alarme : La faille Clawjacked (CVE-2026-25253)

La vulnérabilité Clawjacked, découverte début 2026, illustre parfaitement le danger. Par défaut, OpenClaw écoutait sur 127.0.0.1:18789. L'erreur architecturale ? Assumer que tout trafic en boucle locale est légitime.

Les politiques CORS des navigateurs ne bloquant pas les WebSockets vers le localhost, il suffisait qu'un développeur visite un site web malveillant pour qu'un script JavaScript ouvre une connexion silencieuse vers l'agent, force l'authentification en quelques millisecondes, et prenne le contrôle de la machine (RCE "en un clic").

Bien que corrigée, cette faille nous rappelle une règle d'or : ne jamais considérer l'interface locale comme une zone sécurisée.


4 Étapes pour blinder votre instance OpenClaw

Si vous hébergez OpenClaw (que ce soit pour vos projets persos sur votre homelab ou en entreprise), voici les pratiques obligatoires à mettre en place.

1. Ségrégation physique et réseau Zero-Trust

Ne faites jamais tourner un agent autonome avec des droits d'écriture sur votre machine de tous les jours.

  • Isolez : Utilisez un VPS dédié ou une VM stricte.
  • Déprivilégiez : Créez un utilisateur système standard (openclaw-user) sans aucun droit sudo.
  • Masquez l'instance : Changez le port par défaut (ex: 48921) et ne l'exposez jamais sur internet. Utilisez Tailscale (basé sur WireGuard) pour rendre votre nœud invisible publiquement.
bash
RouterLab
# Lancement de la Gateway sur un port modifié, écoutant uniquement sur l'IP Tailscale
openclaw gateway --port 48921 --bind 100.x.y.z

2. Le piège du Sandboxing Docker

La plupart des utilisateurs pensent être à l'abri en activant l'intégration Docker d'OpenClaw. C'est faux. Par défaut, le paramètre mode: "non-main" n'isole que les sessions secondaires, laissant l'agent principal s'exécuter directement sur l'hôte.

Pour une vraie sécurité, modifiez votre ~/.openclaw/openclaw.json :

json
RouterLab
{
  "sandbox": {
    "mode": "all",
    "scope": "session",
    "workspaceAccess": "none",
    "network": "none"
  }
}

Note technique : En coupant le réseau ("network": "none") et l'accès à l'espace de travail ("workspaceAccess": "none"), vous empêchez l'agent d'exfiltrer des données via des requêtes curl s'il est victime d'une injection de prompt.

3. Bannir le "Elevated Mode"

L'architecture d'OpenClaw propose une porte dérobée conceptuelle : le Elevated mode. Activé via /elevated on, il permet à l'outil exec de contourner délibérément le conteneur Docker pour s'exécuter avec les privilèges de l'hôte.

C'est une hérésie en production. L'utilisation de ce mode annule fondamentalement les bénéfices du confinement et doit être prohibée via la politique d'outils (Tool Policy).

4. Audit continu et Listes Blanches (Allowlist)

OpenClaw intègre d'excellents outils de diagnostic, utilisez-les !

Exécutez régulièrement la commande :

bash
RouterLab
openclaw security audit --deep

Cette commande scannera votre configuration à la recherche de groupes de discussion ouverts avec des privilèges élevés, ou d'interfaces de contrôle mal sécurisées. Utilisez --fix pour appliquer les recommandations.

Enfin, configurez vos canaux de communication (Slack, Discord, DMs) en mode Allowlist stricte. Rejetez silencieusement toute requête provenant d'un ID utilisateur non explicitement autorisé. L'agent ne doit jamais interagir avec des inconnus.


Conclusion

Déployer OpenClaw revient à embaucher un administrateur système numérique doué d'autonomie. Privilégier l'ergonomie (Time-to-Value) au détriment de l'isolation est insoutenable dans le domaine de l'IA agentique opérationnelle.

Avant d'octroyer à un LLM la capacité de lire ou modifier votre écosystème informatique, assurez-vous de maîtriser son rayon d'explosion avec openclaw sandbox explain.

Endpoint RouterLab

Tester l’API RouterLab

Passez d’un article à une requête réelle : créez un essai, récupérez une clé et appelez les modèles depuis une API compatible OpenAI.

https://api.routerlab.ch/v1

Mesure d’audience

Acceptez-vous Google Analytics pour mesurer les visites des pages publiques ? Votre choix est facultatif et modifiable à tout moment.