Vous branchez une boîte de réception sur Hermes avec une allowlist qui contient exactement une adresse — la vôtre — et vous considérez la porte fermée. Puis un jour le bot répond à un message venu d’un domaine dont vous n’avez jamais entendu parler, signé de votre nom. L’allowlist n’était pas mal configurée. Le problème, c’est que la chaîne que vous y avez mise et l’« expéditeur » de ce message n’ont jamais été la même sorte de chose.

Deux correctifs de sécurité fusionnés le 2026-09-27 corrigent cette même erreur à deux endroits : le gateway email et le gateway SimpleX intégré autorisaient tous deux les expéditeurs à partir d’un champ que l’expéditeur écrit sur lui-même. Les deux sont P1, les deux sont sur main aujourd’hui.

Un nom d’affichage est du texte libre : comment l’allowlist de SimpleX a été contournée

SimpleX est conçu pour la confidentialité : il n’existe aucun identifiant utilisateur persistant. Chaque contact reçoit un identifiant interne opaque (contactId) généré au moment de la connexion — c’est cela, l’identité. Le nom d’affichage, lui, est ce que l’autre partie a bien voulu taper dans son propre client.

Avant le correctif, la règle d’autorisation du gateway était « autoriser si le contactId ou le nom d’affichage de l’expéditeur correspond à l’allowlist ». Les noms d’affichage entrent en collision et peuvent être modifiés à tout moment : n’importe quel contact pouvait donc se donner un nom déjà présent dans votre allowlist et se mettre à piloter votre bot. La faille a été signalée le 2026-06-12 (#44729) et fermée par la PR #125034 le 27 septembre.

Ce qui se passe désormais :

• SIMPLEX_ALLOWED_USERS ne correspond **qu’**à des contactId numériques ; les noms d’affichage sont ignorés.
• À la connexion, l’adaptateur journalise un avertissement listant les entrées de l’allowlist qui ne ressemblent pas à des identifiants de contact, car ces entrées ne servent plus à rien. Vous aurez très probablement besoin de les remplacer.
• La documentation, plugin.yaml et l’invite de hermes gateway setup demandent désormais tous des identifiants de contact.

Pour trouver le vôtre : démarrez le démon simplex-chat, ouvrez la conversation avec votre contact agent et lisez l’identifiant numérique dans les journaux de session — ou lancez /contacts dans le démon.

L’email est plus subtil : la seconde adresse à l’intérieur de From

L’email est pire, car la RFC 5322 autorise From à valoir « nom d’affichage plus adresse », et le nom d’affichage peut contenir à peu près n’importe quoi. L’ancien analyseur prenait la première adresse entre chevrons qu’il rencontrait :

From: "Victim <[email protected]>" <[email protected]>

Le véritable expéditeur, ici, est [email protected], mais l’ancien code résolvait [email protected] — l’adresse de votre allowlist.

Le même correctif ferme deux autres formes d’attaque :

Forme d’attaque	Avant	Après
Une seconde adresse dans From (listes de diffusion, groupes, une adresse à l’intérieur de la partie nom d’affichage)	Une identité « légitime » était résolue et autorisée	Le From se résout à vide et le message est rejeté avant l’authentification ou la distribution
Un From énorme ou profondément imbriqué (plus de 2048 caractères, ou plus de 64 parenthèses de commentaire)	L’analyse en Python pur prenait des secondes sur une entrée hostile, en tenant le GIL	Des plafonds de taille et d’imbrication le rejettent d’emblée — une valeur de 200 Ko en environ 2 ms
Du texte contrôlé par l’expéditeur à l’intérieur de l’en-tête Authentication-Results du serveur récepteur (parties locales entre guillemets, commentaires)	Un verdict dmarc=pass / spf=pass falsifié pouvait être lu	Les clauses sont découpées en respectant les chaînes entre guillemets et les commentaires imbriqués ; un guillemet ou une parenthèse non équilibré échoue en mode fermé, et chaque verdict n’est lu que depuis son propre method=result

Un autre jugement a changé : dmarc=pass n’est plus accepté tout seul. Il ne compte que si le header.from du verdict s’aligne sur le domaine From analysé (égaux, ou l’un étant un suffixe pointé de l’autre) — sinon un attaquant n’a besoin que d’un domaine qu’il contrôle pour passer DMARC, puis se porter garant de n’importe quel From. C’est le correctif GHSA-rxqh-5572-8m77.

Ce que votre installation fait maintenant

Du côté email, « l’expéditeur doit être authentifié » est actif par défaut :

# ~/.hermes/config.yaml
platforms:
  email:
    require_authenticated_sender: true   # true par défaut
    authserv_id: "your-mx.example.com"   # facultatif : épingler Authentication-Results à votre propre serveur

La variable d’environnement correspondante est EMAIL_AUTHSERV_ID. Si votre serveur de messagerie n’appose pas du tout cet en-tête, la porte de sortie documentée est require_authenticated_sender: false (ou EMAIL_TRUST_FROM_HEADER=true) — cela restaure l’ancien comportement, et la documentation dit clairement que cela revient à accepter le risque. La configuration complète de la plateforme email (variables IMAP/SMTP, codes d’appairage, EMAIL_ALLOWED_USERS) se trouve dans la documentation email.

Pour l’exploitation quotidienne du gateway, consultez notre référence de la commande hermes gateway. Si vous cherchez l’idée en miroir — l’authenticité sortante plutôt qu’entrante —, l’article sur les webhooks explique comment Hermes signe ses propres événements avec HMAC pour que les récepteurs puissent vérifier l’origine.

Une chose n’est pas devenue plus stricte : le trafic sortant. hermes send --to simplex:alice "hello" fonctionne toujours par nom d’affichage, car là c’est vous qui choisissez la cible. Ce qui s’est durci, c’est uniquement qui est autorisé à commander votre agent.

État de la publication

Les deux correctifs ont été fusionnés le 2026-09-27, après le tag de publication v0.21.5 (v2026.9.24) : ils ne vivent donc que sur main pour l’instant. hermes update les récupère, sinon attendez le prochain tag.

À retenir

Une chaîne dans une allowlist n’a jamais été une identité — c’est une ligne que quelqu’un d’autre a écrite pour que vous la lisiez. Ces correctifs raccrochent le « qui me parle » à quelque chose que l’expéditeur ne peut pas décider : le contactId généré au moment de la connexion pour SimpleX, et un verdict apposé par votre propre serveur récepteur pour l’email, plus une vérification que ce verdict couvre bien le domaine From. Si vous exploitez vous-même un bot, deux habitudes valent la peine d’être adoptées : remplacer les entrées d’allowlist par de véritables identifiants de contact, et faire apposer les en-têtes d’authentification par votre serveur de messagerie plutôt que de désactiver cette confiance.