Hermes Agent ha vuelto a publicar — v0.21.6. Abres la página del release y el primer párrafo lo dice: es un release de patch que consolida la ventana en un tag estable, y las notas completas y curadas llegan con la v0.22.0. Ejecutas hermes update, la terminal dice que todo ha ido bien, y te quedas con una pregunta que no puedes responder del todo: ¿qué he instalado realmente y debería darme prisa? Esta vez esa sensación incómoda es peor de lo habitual, porque lo nuevo no es solo el contenido — también ha cambiado la forma en que se produjo el release. Este artículo hace dos cosas: explica qué cambió en el proceso de publicación y te da tres comandos para confirmar tu versión por tu cuenta.

Qué hay de nuevo: el primer tag del nuevo pipeline de releases estables

El comunicado oficial lo dice sin rodeos: la v0.21.6 es el primer release cortado por el nuevo pipeline de releases estables, y su forma es «un attempt ref, una imagen Docker probada y un tag de comprobante al publicar».

Suena abstracto, así que lo ponemos en palabras sencillas. Antes, un tag era el pistoletazo de salida: la imagen, los despliegues alojados y los paquetes de Nix se construían cada uno por su cuenta después, a partir de él. Ahora es al revés — primero hay un attempt de release, el propio attempt carga con la build y los tests, la imagen Docker se publica solo cuando pasa, y el comprobante de lo publicado queda registrado en el tag. Para ti, como usuario, la diferencia práctica es esta: el tag respalda una imagen que ya se ha probado, en lugar de un tag desde el que construyes después.

El comunicado también marca el límite: este release incluye el tag, la GitHub release y la imagen Docker. La app de escritorio, los paquetes de Termux y la Microsoft Store se quedan en su build actual y se mueven con el próximo release empaquetado.

Cuánto entró realmente en la ventana

Empecemos por el tamaño. Estas cifras son las oficiales, medidas en el commit 818c13be1dc4fd28987e1e881a9408224afd4535:

Métrica	Valor
Commits sin merge	8.867
Archivos modificados	8.342 (+772.490 / −225.600)
PR fusionados	2.106
Incidencias cerradas	3.027

Si quieres comprobar tú mismo el número de archivos, un solo comando lo hace (necesitas el historial completo de git en local):

cd ~/.hermes/hermes-agent
git fetch origin main --tags
git diff --shortstat v2026.9.24 818c13be1dc4fd28987e1e881a9408224afd4535
# 8342 archivos modificados, 772490 inserciones(+), 225600 eliminaciones(-)

v2026.9.24 es el tag anterior — que es la versión semántica v0.21.5. «Un release de patch sin notas» no significa «que no lleva nada dentro»; significa que esos 2.106 PR nunca se nombraron ni clasificaron uno por uno. Se documentarán con la v0.22.0, y el comunicado promete que nada de la ventana se queda fuera.

Tres comandos para confirmar qué versión tienes

No te fíes de la sensación ni de la palabra «success» en la salida de la actualización. Guíate por el tipo de instalación:

# 1. número de versión (las instalaciones por git también muestran la distancia hasta el tag + el commit corto)
hermes version

# 2. qué hizo realmente tu última actualización
hermes update

# 3. Docker / alojado: mira el propio tag de la imagen
docker pull nousresearch/hermes-agent:stable

El tercer caso merece una advertencia. Los usuarios de Docker y de Hermes Cloud no reciben un árbol de trabajo de git, sino una imagen. La palabra clave para los consumidores posteriores en este release es nousresearch/hermes-agent:stable (o :latest). Para quienes usan imágenes solo hay una respuesta fiable a «¿me he actualizado?» — el digest de la imagen, no la hora de la descarga que recuerdas.

Hay una pista más que se pasa por alto con facilidad. Las instalaciones por git registran cómo se actualizaron en un sello de instalación (install-stamp.json, que lee hermes version). Así que si dos máquinas informan de la misma versión pero se comportan de forma distinta, compara ese sello antes de sospechar del código — probablemente estés viendo la diferencia entre una instalación «ligera» y una de git completa.

Las correcciones de seguridad de esta ventana, en un solo sitio

Este release, a propósito, no documenta sus funciones, pero las correcciones de seguridad se destacan por separado — tres grupos, y en cada uno conviene comprobar de qué lado estás.

1. Endurecimiento de la autenticación del dashboard (PRs #133367, #133369, #133370, más el session takeover #130685). Un único informe de Tenable Research (TRA-725 … TRA-728) cubre cuatro problemas: un X-Forwarded-For falsificado podía reiniciar el límite de intentos del login por contraseña y saltarse el tope por IP; las solicitudes de login no autenticadas podían escribir valores sin límite en el log de auditoría; las rutas públicas /auth/ no tenían límite de tamaño del cuerpo de la solicitud; y el inicio de sesión nativo podía enviar códigos de login a una redirección que no era de loopback, lo que permitía el session takeover. Ya desglosamos los tres primeros con detalle en el artículo sobre el endurecimiento del login del dashboard — ahí están la causa de cada uno y si tu despliegue necesita un cambio de configuración. El cuarto (la redirección) solo se menciona explícitamente en el comunicado de este release, así que lee los dos juntos para tener la ronda completa.

2. Endurecimiento del filtro git del repositorio (#130661). Las llamadas automáticas a git — instantáneas del workspace de la sesión, worktrees de subagentes, kanban, limpieza de worktrees, hermes -w — podían ser secuestradas por programas de filtro clean / smudge / process definidos en la propia configuración de un repositorio no fiable, y ocurría antes de que escribieras tu primer prompt. También lo tratamos por separado: cuando la configuración de git se convierte en un punto de entrada para RCE. Si clonas repos que no conoces y abres una sesión dentro de ellos con frecuencia, este es tu motivo para actualizar.

3. Endurecimiento del remitente en el gateway de correo (#125212, #124322). Un nombre para mostrar entre comillas en la cabecera From podía manipularse para parecer un remitente incluido en la lista de permitidos, dejando que el mensaje de un atacante superara la allowlist de correo. También lo analizamos en el artículo sobre la suplantación de la identidad del remitente.

En una frase, los tres grupos son la misma clase de error: entrada sin techo, en la que se confía porque ha llegado. Ninguno de ellos es una función.

¿Deberías actualizar ahora?

No es difícil decidirlo:

• Expongas un dashboard o ejecutes el gateway en varias máquinas o profiles → actualiza. Dos de los tres grupos de seguridad inciden directamente en tu superficie de ataque.
• Clones repos de otras personas y dejas que el agent trabaje dentro de ellos (sobre todo si son de tu equipo) → actualiza. El problema del filtro git se dispara antes de que digas nada.
• Seas una sola máquina local sin puertos expuestos → nada se rompe en ningún caso, pero como el nuevo pipeline entrega una imagen ya probada como artefacto, moverse pronto sale más barato que moverse tarde.

La actualización sigue siendo el mismo comando de una línea: hermes update; los usuarios de Docker descargan :stable; la app de escritorio no necesita nada esta vez y sigue con el próximo release empaquetado.

Para terminar

• El cambio más grande de la v0.21.6 no es una función — es cómo se produce el release: attempt ref → imagen Docker probada → comprobante registrado al publicar.
• Tamaño de la ventana: 8.342 archivos modificados, 2.106 PR fusionados. Las notas completas y curadas llegan con la v0.22.0.
• No te fíes de la palabra «success» del actualizador. Confírmalo con hermes version y el digest de la imagen.
• Tres grupos de seguridad: autenticación del dashboard, filtros git, remitente de correo. Los dos primeros merecen acción hoy mismo.

Para los cambios de la ventana anterior que «ya funcionan pero nadie ha escrito», consulta nuestra guía de autocomprobación de la ventana de patch. Y si quieres saber exactamente qué sobrevive a un reinicio cuando activas YOLO, lee a continuación la persistencia de /yolo.