Des chercheurs de ThreatDown décrivent un botnet baptisé Carbonato, qui prend le contrôle de démons Docker exposés sur Internet sans authentification et y installe Hermes Agent, un cadre d'agents IA open source ; BleepingComputer a rapporté ces conclusions le 24 septembre 2026 [1] [2]. Hermes Agent est l'outil choisi par les attaquants, et non l'objet d'une faille signalée : l'article de BleepingComputer ne présente pas ce détournement comme une faiblesse du cadre [1].
Contexte
Hermes Agent est un cadre d'agents open source de Nous Research, capable d'exécuter des commandes dans un terminal du système d'exploitation et d'agir sur des instructions reçues par des canaux de messagerie. Sa propre documentation décrit un système d'approbation à trois modes (smart, manual et off), un mode YOLO facultatif qui supprime les demandes d'approbation, et un ensemble de commandes bloquées dans toutes les configurations [5].
Des articles publiés plus tôt en 2026 avaient déjà montré des attaquants faisant tourner Hermes Agent dans ce mode sans surveillance. Hunt.io a décrit un cas de juillet 2026 où un agent en mode YOLO, qui supprime les demandes d'approbation humaine, a exécuté des vérifications d'élévation de privilèges contre des hôtes appartenant au ministère des Finances de Thaïlande [4]. Unit 42 a rapporté le 31 juillet 2026 qu'un attaquant sinophone avait configuré Hermes en mode YOLO pour qu'il reçoive ses instructions depuis un canal Telegram, avec DeepSeek comme moteur de raisonnement [3].
Constatations
Selon BleepingComputer, Carbonato cible les hôtes Docker dont l'API est exposée sans authentification sur le port 2375. Les chercheurs ont trouvé un registre Docker sans authentification contenant près de 60 dépôts et 4,3 Go de données d'images, et l'article indique que le botnet analyse toutes les cinq minutes les réseaux rattachés à un hôte infecté pour y trouver d'autres démons exposés [1].
The Hacker News rapporte que le botnet démarre un conteneur privilégié pour exécuter des commandes sur le système sous-jacent, puis installe Hermes Agent et écrase le fichier de persona SOUL.md par défaut pour que l'agent se comporte comme « GH0ST », décrit comme un hacker senior, pentesteur et développeur d'exploits. Ce persona désigne en priorité les clés d'API d'IA et d'autres identifiants [2].
BleepingComputer précise que l'agent interprète une tâche, écrit des commandes de terminal, lit le résultat et décide de la suite, puis renvoie son rapport dans une conversation Telegram. Les données qu'il a pour instruction de collecter comprennent des clés d'API d'IA, des identifiants SSH et des jetons d'accès [1]. Les chercheurs n'ont pas pu rattacher Carbonato à un groupe de menace connu et évoquent le Costa Rica comme localisation possible de l'opérateur [1].
Conséquences pour ceux qui font tourner des agents en local
Le point d'entrée de Carbonato est un démon Docker exposé, et non une faiblesse de Hermes Agent ; les personnes exposées dans ce rapport sont donc celles qui publient une API Docker sans authentification. Les sources consultées ne disent pas si une victime était un Mac personnel, et les méthodes de persistance rapportées (tâches cron et scripts de surveillance) sont des mécanismes Linux [1] [2].
Les articles montrent bien ce que peut faire un agent doté d'un terminal dès que quelqu'un contrôle ses instructions : il collecte des identifiants et fait son rapport par un service de messagerie ordinaire. Son propriétaire légitime dispose de la même capacité, ce qui explique que la documentation du cadre traite les approbations, l'isolation par conteneur et le stockage des clés comme des choix de configuration que l'opérateur doit faire [5].
Recommandations
- Ne publiez jamais une API Docker sur le port 2375 sans authentification. Les chercheurs conseillent d'imposer l'authentification du démon Docker, de désactiver l'accès distant à l'API lorsqu'il n'est pas nécessaire et de segmenter les réseaux pour limiter les déplacements latéraux [2].
- Gardez les approbations de Hermes Agent activées. La documentation indique smart comme mode par défaut et manual comme le mode qui demande toujours confirmation pour les commandes dangereuses ; off désactive toutes les vérifications d'approbation [5].
- Exécutez l'agent dans un backend de conteneur avec les limites de ressources décrites par la documentation, et sous un utilisateur non root [5].
- Utilisez des listes d'autorisation explicites pour la passerelle de messagerie, et évitez le réglage qui autorise tout le monde [5].
- Conservez les clés d'API dans le fichier .env de l'agent, avec des permissions réservées à son propriétaire (chmod 600), comme le conseille la documentation, et renouvelez toute clé qu'un hôte d'agent a pu exposer [5].
- Gardez Hermes Agent à jour et consultez ses journaux dans le répertoire ~/.hermes/logs [5].
Pertinence pour FireAI
FireAI est un pare-feu pour un seul Mac. Il identifie une app par sa signature de code ou son chemin, montre les connexions qu'elle ouvre et leur applique des règles par app. Un Mac qui fait tourner Hermes Agent apparaît dans FireAI sous la forme de l'interpréteur qui le lance, généralement Python, de sorte qu'une règle s'applique à tout ce que cet interpréteur exécute. Une règle qui n'autorise que le domaine du fournisseur de modèle, avec un blocage pour toute autre destination, est le contrôle qui limite les endroits où un tel agent peut envoyer des données ; la page Activité montre les destinations qu'il a contactées.
FireAI ne protège pas les serveurs, ne détecte ni ne ferme un port Docker exposé, ne gère ni Docker ni aucun conteneur, et n'inspecte ni les instructions données à un agent ni le contenu des connexions chiffrées. Il ne peut pas empêcher un agent de lire ou de supprimer des fichiers locaux. Une connexion Telegram que l'utilisateur a autorisée ne serait pas remise en question.
Limites
Les constatations sur Carbonato sont celles de ThreatDown, telles que relayées par BleepingComputer et The Hacker News ; aucun des deux articles, tels que consultés, n'indique combien d'hôtes ont été compromis. Les deux articles diffèrent légèrement par ce qu'ils soulignent, et les dates d'exposition mentionnées dans les comptes rendus n'ont pas été rapprochées ici. Les cas de Hunt.io et d'Unit 42 sont des opérations distinctes menées par des acteurs différents ; ils ne sont cités que pour montrer que l'usage sans surveillance de Hermes Agent par des attaquants avait déjà été signalé plus tôt en 2026 [3] [4].
Les mesures de durcissement proviennent de la documentation propre à Hermes Agent, et non d'un audit indépendant, et cet article ne teste pas si elles empêchent le comportement décrit dans les rapports sur le botnet. La documentation précise également que l'approbation des commandes dangereuses est ignorée dans les backends isolés (sandbox), car la frontière du conteneur assure l'isolation [5].
Essayez FireAI, par HisnLabs gratuitement pendant 17 jours.