Un Homard, Un Rename, et 60 000 Étoiles GitHub : Comment Faire Confiance à localhost Détruit Tout

Ou : Pourquoi votre reverse proxy pense que tout le monde est votre ami

Parfois, la fonctionnalité est la vulnérabilité

Le pitch de Clawdbot était simple : un assistant IA qui tourne sur votre machine, lit vos emails, exécute vos commandes, et gère vos fichiers. Le pitch des chercheurs en sécurité était encore plus simple : un assistant IA qui tourne sur votre machine, lit vos emails, exécute des commandes, et envoie vos clés SSH à des inconnus. C’était le même produit. C’était le point.

Il y a un vieux proverbe en sécurité informatique qui dit : “Ne jamais faire confiance à personne.” Il y a un proverbe encore plus vieux (enfin, de 1995 environ) qui dit : “Sauf localhost. Localhost, c’est toi. Tu peux te faire confiance.”

Et pendant 30 ans, ça a plutôt bien marché.

Jusqu’à ce qu’un développeur autrichien crée un assistant IA personnel qui a explosé à 60 000 étoiles GitHub en quelques semaines, que des chercheurs en sécurité découvrent qu’on pouvait voler des clés SSH en 5 minutes, et qu’Anthropic envoie une lettre de mise en demeure pour le nom. Le tout en 72 heures.

Bienvenue dans l’histoire de Clawdbot¹.

Le Concept : Localhost Trust, ou Comment Se Tirer Dans le Pied Avec Élégance

Avant de plonger dans le chaos, parlons du concept technique fondamental qui a rendu tout ce désastre possible : le localhost trust.

Imaginez que vous construisez une application web. Vous avez un serveur qui fait des trucs importants—exécuter des commandes, lire des fichiers, stocker des secrets. Vous voulez le protéger. Donc vous ajoutez de l’authentification : mots de passe, tokens, tout le tralala.

Mais attendez. Parfois, d’autres services sur la même machine doivent parler à votre application. Votre propre code. Votre propre infrastructure. C’est vous qui parlez à vous-même, techniquement. Pourquoi vous embêter avec des mots de passe ?

Donc vous faites ça :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

func authMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        remoteIP := r.RemoteAddr

        // Si c'est localhost, on fait confiance
        if strings.HasPrefix(remoteIP, "127.0.0.1") ||
           strings.HasPrefix(remoteIP, "::1") {
            next.ServeHTTP(w, r)
            return
        }

        // Sinon, vérifier l'authentification
        if !validateToken(r.Header.Get("Authorization")) {
            http.Error(w, "Unauthorized", 401)
            return
        }
        next.ServeHTTP(w, r)
    })
}

Élégant, non ? Si la requête vient de 127.0.0.1, c’est forcément moi. Pas besoin de vérifier.

Et c’est vrai ! En théorie. Sur votre laptop de développement. Quand rien d’autre ne tourne.

Le problème, c’est que personne ne déploie une application seule sur un serveur en 2026. Vous avez nginx devant. Ou Caddy. Ou Traefik. Un reverse proxy, quoi.

Et le reverse proxy, il fait quoi ? Il reçoit les requêtes de l’extérieur (disons, 47.83.212.15) et les transmet à votre application. Mais il les transmet depuis lui-même. Depuis 127.0.0.1.

Votre application voit : “Oh, une requête de localhost ! Un ami !”

L’attaquant voit : “Oh, une application qui pense que je suis son ami !”

L’Histoire : Comment un Homard a Conquis GitHub (Puis S’est Fait Écraser)

Peter Steinberger est un développeur autrichien connu dans la communauté iOS, fondateur de PSPDFKit (maintenant Nutrient). En novembre 2025, après quelques mois de “vibe-coding”, il lance Clawdbot—un assistant IA personnel qui tourne localement sur votre machine. Le concept est séduisant : au lieu de parler à ChatGPT dans leur interface, vous avez votre propre butler virtuel. Il peut lire vos messages Telegram, WhatsApp, Signal. Exécuter des commandes. Gérer vos fichiers. Contrôler votre navigateur².

Le projet existe tranquillement pendant quelques semaines. Puis, le week-end du 24-25 janvier 2026, il explose.

En 24 heures : 9 000 étoiles. En quelques jours : 60 000+ étoiles.

Andrej Karpathy tweete dessus. David Sacks aussi. MacStories appelle ça “le futur des assistants IA personnels.” Chamath Palihapitiya partage que Moltbot l’a aidé à économiser 15% sur son assurance auto en quelques minutes (ce qui, honnêtement, est le genre de témoignage qui me fait lever un sourcil, mais passons).

Et puis, tout s’effondre.

Jour 1 : Les chercheurs trouvent des trucs

La firme de sécurité blockchain SlowMist publie une alerte :

“Vulnérabilité découverte dans le gateway Clawdbot : des centaines de clés API et de conversations privées sont exposées. Plusieurs instances non-authentifiées sont accessibles publiquement. Des failles dans le code pourraient mener au vol de credentials et même à l’exécution de code à distance.”

Jamieson O’Reilly, fondateur de Dvuln (une entreprise de red-teaming), documente le problème en détail. En utilisant Shodan (le moteur de recherche pour les serveurs exposés sur Internet), il trouve des centaines d’installations Clawdbot grand ouvertes³. Sur les instances qu’il examine manuellement, huit sont complètement ouvertes, sans aucune authentification, exposant un accès total pour exécuter des commandes et voir les données de configuration.

Jour 2 : La démo qui fait mal

Matvey Kukuy, CEO d’Archestra AI, décide de prouver le point. Il envoie un email malveillant à une instance Clawdbot vulnérable. L’email contient une injection de prompt—du texte qui ressemble à des instructions légitimes.

Le bot lit l’email. Croit que c’est une vraie demande. Et extrait une clé privée OpenSSH du système compromis, qu’il envoie gentiment à Kukuy.

Temps total : 5 minutes.

Il a tweeté la démo avec le commentaire : “That’s why we build non-probabilistic agentic security.”

Jour 3 : Anthropic entre en scène

Comme si les vulnérabilités ne suffisaient pas, Anthropic (créateurs de Claude, le LLM que beaucoup d’utilisateurs avaient configuré comme “cerveau” de leur Clawdbot) envoie une demande de changement de nom. “Clawd” ressemble trop à “Claude”, apparemment.

Steinberger annonce le rebrand :

“Anthropic nous a demandé de changer le nom (trucs de trademark), et honnêtement ? ‘Molt’ colle parfaitement — c’est ce que font les homards pour grandir.”

Le projet devient Moltbot. “Same lobster soul, new shell.”

Jours 4-5 : Le chaos total

Le changement de nom crée une opportunité pour les scammers :

• Des comptes X (Twitter) se font hacker et se font passer pour le projet officiel
• Des tokens crypto frauduleux “CLAWD” et “MOLT” apparaissent
• Des campagnes d’impersonation ciblent les utilisateurs confus

Pendant ce temps, O’Reilly publie une deuxième recherche : une attaque supply chain sur ClawdHub, la bibliothèque de “skills” du projet. Il uploade un skill bénin, gonfle artificiellement le compteur de téléchargements à 4000+, et regarde des développeurs de 7 pays différents le télécharger.

Il aurait pu exécuter du code arbitraire sur leurs machines.

Le Code Qui Fait Tout Planter

Regardons le problème concrètement. Voici une configuration nginx typique pour un déploiement Clawdbot (reconstituée d’après les descriptions des chercheurs) :

1
2
3
4
5
6
7
8
9

server {
    listen 80;
    server_name clawdbot.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        # Oups, on a oublié quelques trucs...
    }
}

Le problème ? Nginx reçoit une requête de 47.83.212.15, mais la transmet à l’application depuis 127.0.0.1. L’application voit localhost. L’application fait confiance.

Une configuration correcte ressemblerait à ça :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

server {
    listen 80;
    server_name clawdbot.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
    }
}

Et côté application, il faudrait vérifier les headers X-Real-IP ou X-Forwarded-For au lieu de RemoteAddr:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

func getRealIP(r *http.Request) string {
    // D'abord, vérifier X-Real-IP
    if ip := r.Header.Get("X-Real-IP"); ip != "" {
        return ip
    }
    // Ensuite, X-Forwarded-For (prendre la première IP)
    if xff := r.Header.Get("X-Forwarded-For"); xff != "" {
        parts := strings.Split(xff, ",")
        return strings.TrimSpace(parts[0])
    }
    // Fallback sur RemoteAddr
    return r.RemoteAddr
}

Mais attention ! Maintenant vous avez un autre problème : n’importe qui peut envoyer un header X-Real-IP: 127.0.0.1 et prétendre être localhost. Donc vous devez aussi vérifier que la requête vient bien de votre reverse proxy de confiance.

C’est le genre de truc qui semble simple en théorie et devient un cauchemar en pratique. Ce qui nous amène à…

Le Contexte Plus Large : MCP et la Surface d’Attaque

Clawdbot n’existe pas dans le vide. Il fait partie d’un écosystème plus large autour du Model Context Protocol (MCP), et cet écosystème a ses propres problèmes de sécurité. Des CVEs critiques ont été découvertes dans des outils connexes—MCP Inspector (CVE-2025-49596, CVSS 9.4), mcp-remote (CVE-2025-6514, CVSS 9.6), et les extensions Claude Code pour VS Code (CVE-2025-52882, CVSS 8.8)⁴.

Ce n’est pas que Clawdbot soit unique dans ses failles. C’est que tout l’écosystème des agents IA est en train de découvrir, en temps réel, que donner des privilèges système à du code qui parle à Internet est… compliqué.

Dialogue Hypothétique : Le Moment de la Réalisation

Imaginons la conversation dans un Slack de startup tech quelque part :

DevOps Dave : Hey, j’ai configuré Clawdbot sur le serveur. C’est trop cool, il peut gérer mes emails !

Security Sarah : Cool ! T’as mis ça derrière le VPN ?

DevOps Dave : Non, j’ai besoin d’y accéder depuis mon téléphone. Mais t’inquiète, j’ai mis nginx devant.

Security Sarah : Avec les headers forwarded ?

DevOps Dave : Les quoi ?

Security Sarah : commence à transpirer

DevOps Dave : En plus regarde, c’est protégé. Quand j’essaie d’y accéder depuis Internet, ça demande un login.

Security Sarah : Montre ?

DevOps Dave : partage écran Tu vois ? Unauthorized.

Security Sarah : Attends, laisse-moi essayer un truc.

1

curl -H "X-Forwarded-For: 127.0.0.1" http://clawdbot.example.com/api/secrets

DevOps Dave : Oh non.

Security Sarah : Oh oui.

Ce Que J’Aurais Fait Différemment (Si J’Avais Construit Clawdbot)

Regardons les choses en face : Steinberger a construit un projet incroyablement populaire en très peu de temps. Le succès apporte son lot de problèmes que vous n’aviez pas anticipés quand vous codiez dans votre salon.

Mais si j’avais été impliqué, voici ce que j’aurais fait différemment :

1. Auth obligatoire, toujours

Pas de localhost trust. Jamais. Même si c’est plus pénible à configurer.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Ne JAMAIS faire ça
if isLocalhost(r.RemoteAddr) {
    // skip auth
}

// Toujours faire ça
if !validateAuth(r) {
    http.Error(w, "Unauthorized", 401)
    return
}

2. Warnings agressifs dans la documentation

En majuscules. En rouge. Avec des sirènes si possible.

1
2
3
4
5
6
7
8

# ⚠️ ATTENTION - SÉCURITÉ CRITIQUE ⚠️

Si vous exposez Clawdbot sur Internet sans configuration
appropriée, VOS SECRETS SERONT VOLÉS. Ce n'est pas une
exagération. Des gens ont déjà perdu des clés SSH, des
tokens API, et des conversations privées.

Voir SECURITY.md avant TOUT déploiement.

3. Secure by default, pas secure by option

Le projet aurait dû refuser de démarrer sans authentification configurée, ou au minimum, ne bind que sur localhost par défaut avec des warnings très visibles si quelqu’un change ça.

4. Rate limiting et logging dès le début

Si quelqu’un essaie 500 requêtes en 10 secondes sur votre endpoint de secrets, vous voulez le savoir.

Le Take : Pourquoi C’est Fascinant (Et Terrifying)

L’histoire de Clawdbot, c’est l’histoire de l’écosystème IA en 2026 condensée en 72 heures.

C’est fascinant parce que :

Le projet répond à un vrai besoin. Les gens veulent des assistants IA qui tournent localement, qu’ils contrôlent, qui ne dépendent pas de Big Tech. Clawdbot/Moltbot, c’est exactement ça. L’idée est bonne⁵.

C’est terrifying parce que :

Un agent IA avec accès à votre système, c’est fondamentalement incompatible avec les modèles de sécurité traditionnels. La FAQ du projet le reconnaît elle-même :

“Il n’y a pas de configuration parfaitement sécurisée quand on opère un agent IA avec accès shell.”

Et c’est… vrai ? Un assistant utile doit pouvoir lire vos messages, stocker vos credentials, exécuter des commandes, maintenir un état persistant. Chacune de ces capacités est un vecteur d’attaque.

Le modèle de menace inclut :

• Des acteurs malveillants qui essaient d’induire l’IA à faire des actions nuisibles
• Du social engineering pour accéder aux données
• De l’espionnage d’infrastructure

C’est le genre de threat model qui vous fait réaliser que peut-être, peut-être, donner un accès shell à une IA qui lit vos emails n’est pas une idée qui scale bien.

La Chronologie Complète

Pour ceux qui aiment les timelines :

Conclusion : Same Lobster Soul, Third Shell

Plot twist de dernière minute : alors que je terminais cet article, Steinberger a annoncé un troisième rebrand. Moltbot devient OpenClaw. “The lobster has molted into its final form,” dit le communiqué.

Le projet a maintenant dépassé les 100 000 étoiles GitHub et attiré 2 millions de visiteurs en une semaine. Les vulnérabilités sont en cours de correction—34 commits liés à la sécurité selon Steinberger. La communauté travaille sur des guides de hardening.

Mais l’épisode révèle quelque chose de profond sur l’état actuel de l’IA : on construit des outils incroyablement puissants, on les rend viraux avant qu’ils soient sécurisés, et on découvre les problèmes en production—sur les machines de vrais utilisateurs, avec leurs vrais secrets⁶.

Trois noms en cinq jours. Le homard a mué deux fois. Espérons que cette carapace soit la bonne.