Durcissement Sécurité OpenClaw & Réponse Vulnérabilité 2026 : Cas CVE-2026-25253, Firewall, Déploiement Minimal

Retour sur CVE-2026-25253 : pourquoi 135 000 instances ont été exposées

Mi-janvier 2026, l'équipe sécurité d'OpenClaw a publié CVE-2026-25253 : si Gateway s'exécute avec la configuration par défaut (écoute sur 0.0.0.0 sans authentification), un attaquant peut obtenir une exécution de code distant via un handshake WebSocket forgé. Le scan Shodan a révélé plus de 135 000 instances accessibles sans authentification — des développeurs personnels aux petites équipes, en passant par des tunnels d'entreprise mal configurés.

La cause racine n'était pas un bogue de code mais des défauts trop permissifs par défaut:

• L'adresse bind par défaut de Gateway est 0.0.0.0; sans pare-feu ou auth de reverse-proxy, le port de gestion est exposé à tout Internet.
• Les premiers installeurs n'imposaient ni OPENCLAW_GATEWAY_TOKEN ni TLS, laissant les canaux en clair vulnérables aux MITM.
• Beaucoup d'utilisateurs lancent openclaw onboard sur un VPS et considèrent le déploiement terminé, négligeant le resserrement de gateway.bind et les règles ufw.

L'incident a poussé le changement depuis v2026.2.0 : l'adresse bind par défaut passe à 127.0.0.1, et l'installeur inclut désormais des vérifications de sécurité obligatoires. Toutefois, les instances existantes nécessitent encore une correction manuelle — cet article fournit la checklist exécutable.

Trois principes de sécurité fondamentaux (non négociables)

Quel que soit le type de déploiement, les trois conditions suivantes doivent simultanément être remplies :

1. Ne jamais exposer Gateway directement sur Internet public : ne binder que sur loopback (127.0.0.1) ou IP privée. L'accès doit obligatoirement passer par un reverse proxy (Nginx/Caddy) ou un tunnel (Cloudflare Tunnel) avec authentification obligatoire à l'edge.
2. Authentification forte imposée : toute requête vers Gateway doit porter un OPENCLAW_GATEWAY_TOKEN valide (≥32 caractères, rotation tous les 90 jours).
3. Surface d'attaque minimale : l'hôte n'ouvre que les ports essentiels (SSH 22, HTTPS 443). Le port interne Gateway (défaut 18789) ne doit jamais écouter sur 0.0.0.0.

Checklist de sécurisation Docker

Si vous exécutez OpenClaw via Docker / Docker Compose, auditez chaque item ci-dessous :

Après modification, vérifiez avec docker exec <container> netstat -tlnp que Gateway n'écoute que sur 127.0.0.1:18789 (ou le port de votre reverse proxy).

Checklist de durcissement systemd / VPS (Ubuntu 24.04)

Lorsque OpenClaw est exécuté comme service systemd sur un VPS, les contrôles pare-feu et système suivants doivent être appliqués :

4.1 Règles de pare-feu (ufw)

1. Refuser incoming par défaut, n'autoriser que les ports nécessaires :

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp      # SSH
sudo ufw allow 443/tcp     # HTTPS (si reverse proxy)
sudo ufw allow 80/tcp      # HTTP (optionnel, redirection vers HTTPS)
sudo ufw enable

2. Vérifier que le port Gateway (18789) n'est pas ouvert au public :

sudo ufw status numbered
# Aucune règle allow pour 18789/tcp ne doit apparaître

4.2 Renforcement sshd

• Désactiver l'authentification par mot de passe, autoriser uniquement les clés : PasswordAuthentication no
• Changer le port par défaut (pas 22) ou restreindre les IP sources au pare-feu
• Installer fail2ban pour limiter les tentatives de force brute (recommandé)

4.3 Rotation des logs

Les logs OpenClaw sont par défaut dans /tmp/openclaw/openclaw-YYYY-MM-DD.log. Configurer logrotate pour éviter l'épuisement disque :

# /etc/logrotate.d/openclaw
/tmp/openclaw/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    copytruncate
}

4.4 Exemple de service systemd (avec options de sécurité)

[Unit]
Description=OpenClaw Gateway
After=network.target

[Service]
Type=simple
User=node
Group=node
ExecStart=/usr/bin/openclaw gateway start
ExecStop=/usr/bin/openclaw gateway stop
Restart=on-failure
RestartSec=5
# Durcissement sécurité
PrivateTmp=yes
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
ReadWritePaths=/home/node/.openclaw /var/log/openclaw
Environment="OPENCLAW_GATEWAY_TOKEN=${OPENCLAW_GATEWAY_TOKEN}"
# Limites ressources (optionnel)
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

Configuration sécurité pour installation npm globale

Pour les installations locales (développement ou ops manuel), le bind Gateway doit obligatoirement être restreint :

# Forcer Gateway à écouter sur 127.0.0.1 uniquement
openclaw config set gateway.bind 127.0.0.1

# Vérification
openclaw config get gateway.bind
# Doit afficher 127.0.0.1

Si un accès externe est requis, combiner avec un reverse proxy (Nginx/Caddy) utilisant basic-auth ou OAuth :

location /openclaw/ {
    proxy_pass http://127.0.0.1:18789/;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    # Basic auth (exemple)
    auth_basic "OpenClaw Admin";
    auth_basic_user_file /etc/nginx/.htpasswd;
    # Ou intégration oauth2proxy

Playbook de réponse à vulnérabilité : 5 étapes (Détecter → surveiller 72h)

1. Étape 1 — Détection & évaluation impact :
   • Vérifier la version : openclaw --version. Si < 2026.2.0 et Gateway exposé sur internet, marquer haut risque immédiatement.
   • Scanner l'exposition : nmap -p 18789 <your-public-ip> pour vérifier l'accessibilité du port.
2. Étape 2 — Sauvegarde config & données :
   • Backup complet ~/.openclaw/ : tar -czf openclaw-backup-$(date +%F).tar.gz ~/.openclaw
   • Exporter l'état Gateway (paires, canaux, tokens) : openclaw gateway export > gateway-state.json
3. Étape 3 — Mise à niveau & durcissement :
   • Mettre à jour CLI : npm update -g openclaw ou docker pull openclaw/openclaw:latest
   • Réinitialiser gateway.bind à 127.0.0.1 ; si reverse proxy, vérifier TLS+auth activés.
   • Rotation du token : openclaw gateway token rotate ; mettre à jour toutes les instances CLI et variables d'environnement CI.
4. Étape 4 — Vérification connectivité :
   • Redémarrer Gateway : openclaw gateway restart
   • Health local : openclaw gateway status doit indiquer "healthy".
   • Test accès externe : depuis une autre machine, la connexion doit être bloquée par le proxy ou renvoyer 401/403.
5. Étape 5 — Surveillance 72 heures :
   • Surveiller les logs : openclaw logs --follow | grep -i error
   • Vérifier que tous les canaux (Telegram/Slack) fonctionnent normalement, aucune perte de pairing.
   • Après 72h sans incident, documenter les étapes de durcissement dans le runbook et planifier la prochaine rotation de token.

Checklist d'auto-contrôle de baseline sécurité (Ports / Auth / Logs / Updates / Backups)

Exécuter ces 5 points mensuellement pour garantir qu'OpenClaw ne se réexpose pas à cause d'une dérive de configuration ou d'une version obsolète :

Références techniques

• Avis de sécurité CVE-2026-25253 : GHSA-2026-25253 (Versions affectées : <2026.2.0, CVSS 9.8 Critique).
• Port par défaut OpenClaw Gateway : 18789 (Control UI sur même port, localhost uniquement).
• Depuis v2026.2.0, bind par défaut passe à 127.0.0.1 (localhost + Docker bridge toujours accessibles, public non).
• Tags officiels Docker : openclaw/openclaw:latest, :2026.3.13, :stable.

Pourquoi "ça marche" ne suffit pas en production

Beaucoup d'équipes adoptent une mentalité "juste le faire fonctionner" pendant les PoC ou déploiements temporaires, en sautant config pare-feu, rotation de token et logrotation. Cela peut économiser 15 minutes sur une machine de dev, mais introduit trois risques fatals en production :

• Exposition de la surface d'attaque : Un Gateway accessible depuis l'Internet public est une porte grande ouverte. CVE-2026-25253 n'est que la vulnérabilité connue ; les zero-days ou futurs bugs exploiteront le même chemin.
• Non-conformité réglementaire : Les audits d'entreprise exigent que tous les services externes passent par une revue d'authentification et de moindre privilège. Les instances nues échouent aux audits SOC2 / ISO27001.
• Dégât运维 irréversible : Une fois qu'une backdoor est installée ou des données altérées, un durcissement post-mortem ne peut garantir la propreté du système. La seule option sûre est de détruire et reconstruire.

Le durcissement sécurité est l'étape 1, pas un correctif après coup. Pour des charges de travail OpenClaw de production nécessitant stabilité et longévité, l'offre managée de MACCOME inclut toutes les baselines out-of-the-box (rotation automatique des tokens, whitelisting firewall, surveillance d'intrusion 24/7) — utilisable sans les tracas du self-hosting. Si vous choisissez le self-hosting, auditez chaque item de cette checklist et consignez les résultats dans le manuel ops de votre équipe.