Du bindest einen Posteingang mit einer Allowlist in Hermes ein, in der genau eine Adresse steht — deine — und hältst die Tür damit für geschlossen. Dann antwortet der Bot eines Tages auf eine Nachricht von einer Domain, von der du noch nie gehört hast, unterschrieben mit deinem Namen. Die Allowlist war nicht falsch konfiguriert. Das Problem ist, dass die Zeichenkette, die du dort eingetragen hast, und der „Absender“ in dieser Nachricht nie dieselbe Art von Ding waren.

Zwei Sicherheitspatches, die am 2026-09-27 gemergt wurden, beheben denselben Fehler an zwei Stellen: Das E-Mail-Gateway und das mitgelieferte SimpleX-Gateway autorisierten Absender jeweils anhand eines Feldes, das der Absender selbst über sich schreibt. Beide sind P1, beide sind heute auf main.

Ein Anzeigename ist Freitext: wie die SimpleX-Allowlist umgangen wurde

SimpleX ist auf Privatsphäre ausgelegt: Es gibt keine persistenten Nutzer-IDs. Jeder Kontakt bekommt eine opake interne ID (contactId), die beim Verbindungsaufbau erzeugt wird — das ist die Identität. Der Anzeigename ist das, was die Gegenseite in ihren eigenen Client getippt hat.

Vor dem Fix lautete die Autorisierungsregel des Gateways: „erlauben, wenn die contactId oder der Anzeigename des Absenders mit der Allowlist übereinstimmt.“ Anzeigenamen kollidieren und lassen sich jederzeit ändern, also konnte jeder Kontakt seinen Namen auf einen Wert setzen, der ohnehin in deiner Allowlist steht, und deinen Bot steuern. Die Lücke wurde am 2026-06-12 gemeldet (#44729) und am 27. September durch PR #125034 geschlossen.

So verhält es sich jetzt:

• SIMPLEX_ALLOWED_USERS gleicht nur numerische contactIds ab; Anzeigenamen werden ignoriert.
• Beim Verbindungsaufbau protokolliert der Adapter eine Warnung mit den Allowlist-Einträgen, die nicht wie Contact-IDs aussehen, weil diese Einträge nichts mehr bewirken. Höchstwahrscheinlich musst du sie ersetzen.
• Die Doku, plugin.yaml und der Prompt von hermes gateway setup fragen jetzt alle nach Contact-IDs.

Um deine eigene zu finden: Starte den simplex-chat-Daemon, öffne die Konversation mit deinem Agent-Kontakt und lies die numerische ID in den Session-Logs — oder führe /contacts im Daemon aus.

E-Mail ist subtiler: die zweite Adresse in From

Bei E-Mail ist es schlimmer, weil RFC 5322 erlaubt, dass From aus „Anzeigename plus Adresse“ besteht, und der Anzeigename fast alles enthalten darf. Der alte Parser nahm die erste in spitzen Klammern stehende Adresse, die er fand:

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

Der echte Absender ist hier [email protected], aber der alte Code löste [email protected] auf — die Adresse auf deiner Allowlist.

Derselbe Patch schließt zwei weitere Formen:

Angriffsform	Vorher	Nachher
Eine zweite Adresse in From (Mailinglisten, Gruppen, eine Adresse im Anzeigenteil)	Es wurde eine „legitime“ Identität aufgelöst und autorisiert	From löst leer auf, und die Nachricht wird vor Authentifizierung oder Zustellung verworfen
Ein riesiges oder tief verschachteltes From (über 2048 Zeichen oder mehr als 64 Kommentar-Klammern)	Das reine Python-Parsing brauchte bei feindlichen Eingaben Sekunden und hielt den GIL	Größen- und Verschachtelungsgrenzen verwerfen es sofort — ein 200 KB großer Wert in etwa 2 ms
Text, den der Absender im Authentication-Results-Header des empfangenden Servers steuert (quotierte Local Parts, Kommentare)	Ein gefälschtes dmarc=pass / spf=pass-Urteil konnte ausgelesen werden	Klauseln werden getrennt, wobei quotierte Strings und verschachtelte Kommentare beachtet werden; eine unbalancierte Quote oder Klammer schlägt geschlossen fehl, und jedes Urteil wird nur aus seinem eigenen method=result gelesen

Noch eine Ermessensentscheidung hat sich geändert: dmarc=pass wird nicht mehr allein akzeptiert. Es zählt nur, wenn das header.from des Urteils mit der geparsten From-Domain übereinstimmt (gleich, oder eine ist ein Punkt-Suffix der anderen) — sonst bräuchte ein Angreifer nur eine Domain, die er kontrolliert, um DMARC zu bestehen und anschließend für jede beliebige From zu bürgen. Das ist der Fix GHSA-rxqh-5572-8m77.

Was deine Installation jetzt tut

Auf der E-Mail-Seite ist „der Absender muss authentifiziert sein“ standardmäßig aktiv:

# ~/.hermes/config.yaml
platforms:
  email:
    require_authenticated_sender: true   # Standard: true
    authserv_id: "your-mx.example.com"   # optional: Authentication-Results an deinen eigenen Server binden

Die Umgebungsvariable ist EMAIL_AUTHSERV_ID. Wenn dein Mailserver diesen Header gar nicht stempelt, ist der dokumentierte Ausweg require_authenticated_sender: false (oder EMAIL_TRUST_FROM_HEADER=true) — das stellt das alte Verhalten wieder her, und die Doku sagt klar, dass das bedeutet, das Risiko zu akzeptieren. Die vollständige Einrichtung der E-Mail-Plattform (IMAP/SMTP-Variablen, Pairing-Codes, EMAIL_ALLOWED_USERS) findest du in der E-Mail-Doku.

Für den täglichen Gateway-Betrieb siehe unsere hermes gateway Befehlsreferenz. Wenn du die spiegelbildliche Idee willst — ausgehende Authentizität statt eingehender —, behandelt der Webhook-Beitrag, wie Hermes seine eigenen Events per HMAC signiert, damit Empfänger den Ursprung verifizieren können.

Eine Sache wurde nicht strenger: ausgehend. hermes send --to simplex:alice "hello" funktioniert weiterhin über den Anzeigenamen, weil du dort das Ziel selbst auswählst. Verschärft wurde nur, wer deinem Agent Befehle geben darf.

Release-Status

Beide Patches wurden am 2026-09-27 gemergt, nach dem v0.21.5-Release-Tag (v2026.9.24), existieren also derzeit nur auf main: hermes update holt sie, oder du wartest auf den nächsten Tag.

Das Fazit

Eine Zeichenkette in einer Allowlist war nie eine Identität — sie ist eine Zeile, die jemand anderes geschrieben hat, damit du sie liest. Diese Fixes verankern „wer mit mir spricht“ wieder an etwas, das der Absender nicht selbst entscheiden kann: die beim Verbindungsaufbau erzeugte contactId bei SimpleX und ein von deinem eigenen empfangenden Server gestempeltes Urteil bei E-Mail, plus eine Prüfung, dass das Urteil tatsächlich die From-Domain abdeckt. Wenn du selbst einen Bot betreibst, lohnen sich zwei Gewohnheiten: Allowlist-Einträge durch echte Contact-IDs ersetzen und deinen Mailserver Authentifizierungs-Header stempeln lassen, statt dieses Vertrauen abzuschalten.