Ça existe depuis des années rien de nouveau
il y a eu tellement de fuites de données accumulées ces dernières années que des acteurs cyber ont fini par tout indexer et aujourd’hui vous pouvez retrouver dans des canaux privés & des forums obscurs ce genre de moteur de recherche interne ultra-performant où un numéro de téléphone ou une adresse mail suffit désormais pour faire sortir le dossier complet de n’importe quel citoyen
Fermer la porte : 7 règles pour ne pas exposer votre agent sans le savoir.
Prévention, vérification et détection — sans rien casser et sans se mentir sur ce qui protège vraiment.
RÈGLE 0 — LE TEST EN 5 SECONDES
Avant tout le reste, mesurez votre propre exposition :
curl -sI http://:/
La réponse doit être une redirection 302 vers /login. Si vous recevez un 200, ouvrez la page et cherchez `__HERMES_AUTH_REQUIRED__` dans le corps : si la valeur est false, vous êtes exposé, maintenant.
Faites-le depuis l'extérieur de votre réseau. Depuis la machine elle-même, vous testez la loopback, c'est-à-dire précisément le chemin qui n'est pas le problème.
Cette commande devrait être la première ligne de la documentation de déploiement. C'est le seul contrôle qui ne dépend d'aucune hypothèse sur votre configuration.
RÈGLE 1 — LA BONNE RÉPONSE EST « NE PAS EXPOSER »
Un dashboard d'agent n'est pas une application web à publier. Derrière, il y a un shell, un système de fichiers et l'ensemble de vos credentials. C'est un outil d'administration locale.
Si vous devez y accéder à distance :
- VPN (WireGuard, Tailscale) est la réponse correcte et ne coûte rien ;
- tunnel SSH est la réponse correcte et ne coûte rien ;
- un proxy public est la réponse qui vous demande de faire le travail décrit en règle 2, correctement.
Deux pistes qui n'en sont pas : un port non standard, une URL non devinable. Ni l'un ni l'autre n'est un contrôle d'accès, et un moteur de scan s'en moque.
RÈGLE 2 — SI VOUS EXPOSEZ, L'AUTH SE DÉCLARE EXPLICITEMENT
Si le dashboard est derrière un proxy public, l'authentification doit être configurée comme un choix délibéré, pas héritée d'un comportement par défaut :
- déclarer l'URL publique dans la configuration : cela force l'activation du gate même sur un bind loopback, c'est le signal que le produit attend ;
- configurer un fournisseur d'authentification : soit un couple identifiant / empreinte de mot de passe côté configuration du dashboard, soit une inscription OAuth auprès de l'éditeur ;
- servir le tout en HTTPS avec un certificat valide, en-têtes de sécurité, et vérifier que le proxy ne réécrit pas l'en-tête Host de manière à contourner la validation côté application.
Le point de fond : ne jamais considérer que « le port est fermé » ou « ça écoute en local » suffit. Le jour où quelqu'un ajoute un proxy en cinq minutes pour dépanner, la protection aura disparu sans que personne n'ait touché à la sécurité.
—
RÈGLE 3 — DOCKER : PUBLIER SUR LA LOOPBACK DE L'HÔTE
Le cas le plus traître, celui qu'aucun check de bind ne peut voir :
docker run -p 9119:9119 ...
Ici le conteneur écoute en loopback à l'intérieur, mais le port est publié sur 0.0.0.0 de la machine hôte. L'application se croit locale, le monde la voit.
La forme correcte :
docker run -p 127.0.0.1:9119:9119 ...
Le port n'est plus publié que sur la loopback de l'hôte ; le proxy local reste possible, l'exposition publique disparaît. C'est une différence de onze caractères entre une instance privée et une instance indexée par les moteurs de scan.
Règle générale : tout `-p` sans adresse explicite publie sur toutes les interfaces. Vérifiez systématiquement par `docker port ` et `ss -ltnp` sur l'hôte, et lisez la sortie en cherchant 0.0.0.0 et non 127.0.0.1.
—
RÈGLE 4 — LE TOKEN DE SESSION N'EST PAS UN CONTRÔLE D'ACCÈS RÉSEAU
Le token que le dashboard injecte dans la page protège les routes de l'API contre un autre onglet du même navigateur, pas contre Internet. Tant que le gate est inactif, il est distribué avec la page.
Conséquence pratique : ne raisonnez jamais « le token est aléatoire, donc je suis protégé ». Un secret qui voyage dans une réponse anonyme n'est pas un secret, c'est un identifiant de corrélation.
⬇️⬇️⬇️⬇️⬇️⬇️
- faire tourner toutes les clés du fichier .env : fournisseurs de modèles, jetons de bots de messagerie, clés d'outils tiers. La rotation est gratuite, l'enquête ne l'est pas ;
- vérifier les journaux d'usage chez les fournisseurs : une clé volée se remarque à des appels que vous n'avez pas faits, souvent en volume ;
- vérifier vos bots de messagerie : un jeton de bot volé permet de lire et d'envoyer au nom du bot, ce qui se voit dans ses conversations ;
- changer les mots de passe de tout ce que l'agent pouvait atteindre, et vérifier les clés SSH et les jetons de déploiement présents sur la machine.
Un shell distant rend toute confiance résiduelle inutile : après un accès de ce type, on considère l'hôte compromis et on reconstruit, on ne nettoie pas.
—
RÈGLE 6 — DÉTECTION : CE QUE VOS PROPRES LOGS VONT VOUS DIRE
Bonne nouvelle : les consultations de secrets sont journalisées par le produit. Chaque appel de renvoi de variable produit une ligne d'audit, du type :
INFO hermes_cli.web_server: env/reveal: OPENAI_API_KEY
Cette ligne existe, je l'ai vérifiée sur une instance locale en déclenchant la consultation. Elle atterrit dans les journaux du foyer applicatif, `logs/agent.log` et `logs/gui.log`.
La recherche à lancer sur chaque machine qui a tourné en dashboard :
grep -h "env/reveal" ~/.hermes/logs/*.log
Ce que vous lisez :
- aucune ligne : personne n'a consulté de secret, votre rotation peut attendre une fenêtre calme ;
- une ligne que vous n'avez pas provoquée : quelqu'un était dedans. La ligne dit quelle clé a été lue, l'horodatage encadre la fenêtre d'exposition, et vous savez précisément quoi faire tourner ;
- des lignes en rafale toutes les trente secondes : la limite de débit ayant été atteinte, vous lisez le rythme d'un script qui aspirait le fichier. Ce n'est plus une hypothèse d'intrusion, c'est une extraction en cours.
Complétez avec les journaux du proxy : les requêtes sur les routes de session et sur le WebSocket du terminal sont, elles, très reconnaissables. Et surveillez les connexions en upgrade WebSocket sortant de la machine : c'est la trace la plus nette d'une prise de main interactive.
Enfin, côté poste de travail : vérifiez l'historique des sessions de votre agent. Des sessions que vous n'avez pas ouvertes, ou l'ouverture d'une session par un utilisateur inconnu, sont un signal direct.
—
RÈGLE 7 — CE QUE L'ÉDITEUR DOIT CORRIGER
Parce qu'une règle de prévention opérateur ne remplace pas un correctif de conception :
1. décider du gate sur un signal d'EXPOSITION et non de bind : présence d'en-têtes de proxy (X-Forwarded-For, X-Forwarded-Host, Forwarded), en-tête Host non-loopback, contexte de conteneur — et fermer par défaut en cas de doute ;
2. ne jamais injecter le token de session dans une réponse servie à un appelant non authentifié : servir la page de connexion dès que le token n'a pas été présenté, même en mode local ;
3. retirer l'indicateur d'absence d'authentification du HTML anonyme : cette information ne doit pas venir du serveur ;
4. protéger les routes sensibles — en particulier les mutations et l'accès aux transcripts — indépendamment du secret unique, pour que la sécurité ne repose pas sur une seule valeur distribuée ;
5. afficher un avertissement explicite au démarrage quand le serveur est joignable par un proxy tout en se croyant local, plutôt que de laisser l'opérateur découvrir la situation par un moteur de recherche.
—
CHECK-LIST À PASSER AUJOURD'HUI
1. Le test de la règle 0, depuis l'extérieur de votre réseau. 302 vers /login. Sinon, on arrête tout et on traite.
2. Aucun proxy public sans authentification déclarée.
3. Aucun port publié en Docker sans adresse explicite. `-p 127.0.0.1:...`.
4. Aucun token de session dans un journal, un ticket ou une capture.
5. Rotation de tous les secrets du fichier .env si l'exposition n'est pas datable.
6. Recherche de la ligne d'audit dans les journaux de tous vos hôtes.
⬇️⬇️⬇️⬇️⬇️⬇️⬇️
7. Les sessions de l'agent relues à la main, pour trouver ce que vous n'avez pas fait.
La leçon transposable dépasse ce produit : une frontière de sécurité qui dépend d'un choix de configuration que l'utilisateur ne sait pas qu'il fait n'est pas une frontière. Un service qui décide de sa sécurité d'après l'adresse sur laquelle il écoute suppose que personne ne mettra jamais rien devant — et quelqu'un mettra toujours quelque chose devant.
@NousResearch
THREAD :Un dashboard « local » n'est pas local.
Comment un simple reverse proxy transforme Hermes Agent en porte ouverte : clés API, historique complet de l'agent, shell.
Hermes Agent décide de son authentification en regardant l'adresse réseau sur laquelle son processus écoute ; or, dès qu'un proxy ou un mapping de port existe, « écouter sur la loopback » ne veut plus dire « joignable que par moi ».
—
L'HYPOTHÈSE DE DÉPART
Un service bindé sur 127.0.0.1 n'est joignable que depuis la machine elle-même. Pas de chemin réseau, donc rien à authentifier : c'est un raisonnement juste, et c'est une convention saine dans l'écosystème (bases de données, serveurs de dev, moteurs de modèles — presque tout se binde en loopback par défaut).
Hermes a fait de cette convention sa frontière de sécurité :
should_require_auth(host) retourne `host not in {localhost, 127.0.0.1, ::1}`
Bind loopback = pas de login. Bind non-loopback = login obligatoire.
C'est défendable sur un portable. Ça devient faux dès qu'un proxy se met devant.
—
LE PROBLÈME
Le gate d'authentification ne répond pas à la question « qui peut m'atteindre ? », mais à la question « sur quelle adresse j'écoute ? ».
Ces deux questions ont la même réponse tant que rien n'est devant. Elles n'ont plus rien à voir dès que :
- un reverse proxy (nginx, traefik, Caddy, cloudflared) relaie les requêtes vers la loopback ;
- un port est publié en Docker, parce que le conteneur écoute en loopback à l'intérieur mais que le port publié écoute sur 0.0.0.0 à l'extérieur — le check de bind ne voit strictement rien ;
- une version ancienne honore encore un flag de désactivation de la protection.
Dans ces trois cas, le processus se croit toujours « local et privé » alors qu'un chemin réseau existe vers lui. Et sur ce chemin, rien ne demande qui vous êtes.
—
LE DÉTAIL QUI TUE
Quand le serveur conclut qu'il n'a pas besoin de login, il écrit le token de session dans la page qu'il sert :
window.__HERMES_SESSION_TOKEN__="***"
window.__HERMES_AUTH_REQUIRED__=***
Ce token est la seule barrière des routes sensibles : un middleware global l'exige sur toutes les routes /api/ hors liste publique, et les handlers eux-mêmes ne portent aucune garde locale (dans le routeur des sessions, zéro appel à la vérification de token).
Autrement dit : le mot de passe est imprimé sur la porte, et la porte est publique. Ce n'est pas une métaphore, c'est la réponse HTTP.
—
LA CHAÎNE, ÉTAPE PAR ÉTAPE
1. Requête anonyme sur la racine. Réponse 200, sans aucun credential. Le token de session est lisible dans le corps de la page.
2. Avec ce token dans l'en-tête Authorization :
- POST /api/env/reveal renvoie la valeur EXACTE, non masquée, d'une variable du fichier .env
- GET /api/sessions liste les conversations de l'agent
- GET /api/sessions//messages renvoie le transcript complet
- GET /api/sessions/search fait une recherche plein texte dedans
- un upgrade WebSocket sur /api/pty accepte et ouvre un shell interactif (le dashboard embarque réellement le TUI de l'agent derrière un pseudo-terminal)
3. Le même token donne aussi accès aux routes de suppression de sessions et aux routes de contrôle du processus (redémarrage de la passerelle, mise à jour).
Aucune étape ne demande d'exploit. Il n'y a rien à casser : il suffit de lire la page, puis de demander.
—
LA PREUVE
Mesuré en local, sur une instance déployée pour l'occasion, avec un foyer de données isolé et des valeurs-leurres. Aucune instance tierce sollicitée.
GET /api/sessions sans token -> 401 (la garde existe bien)
GET / -> 200 token présent dans le HTML
GET /api/sessions + token de la page -> 200 liste des sessions, avec aperçus
GET /api/sessions//messages + token -> 200 transcript complet
GET /api/sessions/search + token -> 200 le leurre retrouvé par recherche
POST /api/env/reveal sans token -> 401
⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️
POST /api/env/reveal + token -> 200 valeur retournée
Vérification du secret par empreinte, parce que l'agent masque les chaînes de type clé dans sa propre sortie console et qu'un affichage brut donnerait l'illusion d'un échec :
longueur retournée == longueur plantée (36 == 36)
sha256(retourné) == sha256(planté) -> correspondance exacte
WS /api/pty sans token -> 403
WS /api/pty + token -> 101 Switching Protocols
Le 401 de la première ligne est important : il prouve que la protection existe et qu'elle n'est pas contournée. Elle est simplement fournie avec la page.
—
CE QUE ÇA COÛTE
- Les clés du fichier .env : fournisseurs de modèles (OpenAI, Anthropic, Gemini, OpenRouter, DeepSeek…), et les jetons de bots de messagerie qui s'y trouvent aussi. Le schéma du produit déclare quarante emplacements de clés d'API, plus les jetons de plateformes. Le renvoi est limité à cinq valeurs par tranche de trente secondes : largement assez pour vider un fichier.
- Toutes les conversations de l'agent, listables, lisibles et recherchables. C'est le point sous-estimé : un agent à qui l'on confie ses mails, ses tickets, ses dossiers clients et ses chemins internes fait de son historique un document d'entreprise. Identifier le propriétaire d'une instance, c'est lire cet historique.
- Un shell interactif sous l'utilisateur de l'agent. À partir de là, ce n'est plus une fuite de données : c'est la machine.
—
COMMENT ON EN ARRIVE LÀ SANS LE VOULOIR
Le scénario n'est pas exotique, c'est le scénario recommandé : « binde en loopback, mets un proxy devant ». Le durcissement standard devient la cause de l'incident dès lors que le proxy est le seul chemin d'exposition et que l'opérateur n'a rien déclaré.
Il existe bien un second déclencheur, une URL publique déclarée dans la configuration, qui force le gate même sur un bind loopback. Le message d'aide du produit le dit d'ailleurs explicitement : « une URL publique configurée exige une authentification même quand un reverse proxy local atteint un backend en loopback ». Tout le problème tient donc à ce que l'opérateur doit déclarer — et qu'un proxy monté sans y penser ne déclare jamais.
À l'échelle d'Internet, ce n'est pas un cas isolé : un moteur de recherche de services exposés suffit à lister des centaines d'instances de ce dashboard servies sans page de connexion, avec le token dans la réponse. Ce n'est pas une hypothèse, c'est indexé.
—
L'ERREUR DE CONCEPTION, EN UNE PHRASE
L'authentification a été rendue fonction de OÙ le processus écoute, alors qu'elle doit être fonction de COMMENT il est joignable. Ces deux choses cessent d'être identiques à partir du moment où un proxy ou un mapping de port existe.
—
PORTÉE — CE QUE CE N'EST PAS
Honnêteté intellectuelle : ce comportement est conforme au modèle de menace déclaré de l'éditeur pour un usage local, et sa documentation classe explicitement « exposer la passerelle ou l'API sur Internet public sans authentification, VPN ou pare-feu » hors du périmètre de sécurité. Le projet n'opère pas de programme de bug bounty.
Ce n'est donc pas une vulnérabilité référençable et il n'y a pas de prime à la clé. C'est un défaut de conception d'un raisonnement : le gate prend une décision locale (l'adresse d'écoute) pour une propriété globale (l'exposition). C'est aussi, et surtout, un rappel utile : une frontière de sécurité qui dépend d'un choix de configuration que l'utilisateur ne sait pas qu'il fait n'est pas une frontière.
Cybernetjournal retweeted
Introducing Muse, the personal agent that understands your goals and works 24/7 to get things done for you.
On a trouvé cette semaine 3 failles critiques impliquant des sites gouvernementaux importants. On attend que les problèmes soient réglés avant d’en parler publiquement.
Et il y a aussi une banque, mais je ne peux pas encore en parler. D’ici lundi, peut-être que oui.
Fable 5 c’est fou comment il est fort oh lala
Il a trouvé une faille dans deezer en moins de 5 minutes
Le même jour. En tout cas, grâce à eux, j’ai signalé deux failles critiques à deux sites différents.
The US government, citing national security authorities, has issued an export control directive to suspend all access to Fable 5 and Mythos 5 by any foreign national, whether inside or outside the United States, including foreign national Anthropic employees.
The net effect of this order is that we must abruptly disable Fable 5 and Mythos 5 for all our customers to ensure compliance.
Access to all other Claude models is not affected.
We apologize for this disruption to our customers. We believe this is a misunderstanding and are working to restore access as soon as possible.
Read our full statement: anthropic.com/news/fable-myt…
Cybernetjournal retweeted
Arrêter un mec qui stream des matchs sur Telegram : ✅👍🏽😁
Arrêter les mecs des réseaux pédophiles qui se partagent des photos/vidéos porno sur Telegram : ❌👎🏽😠
🇫🇷📺 FLASH | Le streamer "Hiboux", habitué des diffusions illégales de compétitions sportives sur 𝕏, Telegram et Discord, aurait été interpellé. (via @Seblatombe)
Cybernetjournal retweeted
Jamais je travaillerai avec cet exchange frauduleux qui list des memecoins frauduleux à -de 90K
Ps : 3 membres de l’imprimante ce sont plaints de leurs système de fees et des payements crypto to fiat qui prennent une éternité n’allez jamais la bas
J’offre 200 usdt dans les rt tirage au sort ce soir à 20h 🤣🤣🤣🤣
De rien pour la pub NINO 🖨️🤣
🧵Comment est‑ce possible qu’un réseau promouvant des contenus choquants, comme du porno, des violences et de la pédopornographie, fasse sa publicité sur X, en payant même des influenceurs ?👇
