Conectas una bandeja de entrada a Hermes con una lista de permitidos que contiene exactamente una dirección —la tuya— y das el asunto por zanjado. Y un día el bot responde a un mensaje de un dominio que nunca habías visto, firmado con tu nombre. La lista de permitidos no estaba mal configurada. El problema es que la cadena que pusiste en ella y el «remitente» de ese mensaje nunca fueron el mismo tipo de cosa.

Dos parches de seguridad fusionados el 2026-09-27 corrigen ese mismo error en dos sitios: la pasarela de correo electrónico y la pasarela SimpleX incluida autorizaban a los remitentes usando un campo que el propio remitente escribe sobre sí mismo. Ambos son P1 y ambos están hoy en main.

Un nombre visible es texto libre: así se saltó la lista de permitidos de SimpleX

SimpleX está pensado para la privacidad: no hay identificadores de usuario persistentes. Cada contacto recibe un ID interno opaco (contactId) generado en el momento de la conexión; esa es la identidad. El nombre visible es lo que la otra parte haya escrito en su propio cliente.

Antes de la corrección, la regla de autorización de la pasarela era «permitir si el contactId o el nombre visible del remitente coincide con la lista de permitidos». Los nombres visibles se repiten y se pueden cambiar en cualquier momento, así que cualquier contacto podía ponerse un nombre que ya estuviera en tu lista y empezar a manejar tu bot. El agujero se reportó el 2026-06-12 (#44729) y lo cerró el PR #125034 el 27 de septiembre.

Qué ocurre ahora:

• SIMPLEX_ALLOWED_USERS coincide solo con contactId numéricos; los nombres visibles se ignoran.
• Al conectar, el adaptador registra un aviso que lista las entradas de la lista de permitidos que no parecen IDs de contacto, porque esas entradas ya no sirven para nada. Lo más probable es que tengas que reemplazarlas.
• La documentación, plugin.yaml y el prompt de hermes gateway setup ahora piden todos IDs de contacto.

Para encontrar el tuyo: arranca el demonio simplex-chat, abre la conversación con tu contacto del agente y lee el ID numérico en los registros de sesión, o ejecuta /contacts en el demonio.

El correo es más sutil: la segunda dirección dentro de From

El correo es peor, porque la RFC 5322 permite que From sea «nombre visible más dirección», y el nombre visible puede contener casi cualquier cosa. El analizador antiguo tomaba la primera dirección entre ángulos que encontraba:

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

El remitente real aquí es [email protected], pero el código antiguo resolvía [email protected], la dirección que está en tu lista de permitidos.

El mismo parche cierra dos formas más:

Forma del ataque	Antes	Después
Una segunda dirección en From (listas de correo, grupos, una dirección dentro de la parte visible)	Se resolvía y autorizaba una identidad «legítima»	El From se resuelve vacío y el mensaje se descarta antes de la autenticación o del despacho
Un From enorme o muy anidado (más de 2048 caracteres, o más de 64 paréntesis de comentario)	El análisis en Python puro tardaba segundos con entradas hostiles, reteniendo el GIL	Los límites de tamaño y anidamiento lo descartan de entrada: un valor de 200 KB en unos 2 ms
Texto que controla el remitente dentro de la cabecera Authentication-Results del servidor receptor (partes locales entrecomilladas, comentarios)	Se podía leer un veredicto dmarc=pass / spf=pass falsificado	Las cláusulas se dividen respetando cadenas entrecomilladas y comentarios anidados; una comilla o un paréntesis descompensado falla en cerrado, y cada veredicto se lee solo desde su propio method=result

Otro criterio más cambió: dmarc=pass ya no se acepta por sí solo. Solo cuenta cuando el header.from del veredicto se alinea con el dominio de From que se analizó (iguales, o uno es sufijo de punto del otro); de lo contrario, a un atacante le basta con un dominio que controle para pasar DMARC y luego avalar cualquier From. Esta es la corrección GHSA-rxqh-5572-8m77.

Qué hace ahora tu instalación

En el lado del correo, «el remitente debe estar autenticado» viene activado por defecto:

# ~/.hermes/config.yaml
platforms:
  email:
    require_authenticated_sender: true   # true por defecto
    authserv_id: "your-mx.example.com"   # opcional: fija Authentication-Results a tu propio servidor

La variable de entorno es EMAIL_AUTHSERV_ID. Si tu servidor de correo no estampa esa cabecera en absoluto, la válvula de escape documentada es require_authenticated_sender: false (o EMAIL_TRUST_FROM_HEADER=true): eso restaura el comportamiento anterior, y la documentación dice claramente que implica aceptar el riesgo. La configuración completa de la plataforma de correo (variables IMAP/SMTP, códigos de emparejamiento, EMAIL_ALLOWED_USERS) está en la documentación de correo.

Para las operaciones diarias de la pasarela, consulta nuestra referencia del comando hermes gateway. Si te interesa la idea simétrica —autenticidad de salida en lugar de entrada—, el artículo sobre webhooks explica cómo Hermes firma sus propios eventos con HMAC para que los receptores puedan verificar el origen.

Hay algo que no se volvió más estricto: el tráfico de salida. hermes send --to simplex:alice "hello" sigue funcionando por nombre visible, porque ahí eres tú quien elige el destino. Lo que se endureció es solo quién puede dar órdenes a tu agente.

Estado de la versión

Ambos parches se fusionaron el 2026-09-27, después de la etiqueta de publicación v0.21.5 (v2026.9.24), así que ahora mismo solo están en main: hermes update los recoge, o espera a la siguiente etiqueta.

La conclusión

Una cadena en una lista de permitidos nunca fue una identidad: es una línea que escribió otro para que tú la leas. Estas correcciones vuelven a anclar «quién me está hablando» a algo que el remitente no puede decidir: el contactId generado en el momento de la conexión en SimpleX, y un veredicto estampado por tu propio servidor receptor en el correo, además de una comprobación de que el veredicto cubre de verdad el dominio de From. Si tú mismo operas un bot, vale la pena adoptar dos hábitos: sustituir las entradas de la lista de permitidos por IDs de contacto reales, y hacer que tu servidor de correo estampe las cabeceras de autenticación en lugar de desactivar esa confianza.