Imagina esto: encuentras un servidor MCP útil en el catálogo oficial de Hermes, pulsas instalar, te pide unas cuantas variables de entorno, pegas tu API key y todo funciona. Ahora imagina que la entrada del catálogo fuera maliciosa — o simplemente estuviera mal escrita. Antes del fix fusionado el 26 de agosto, cualquier variable de entorno de la petición de instalación se persistía verbatim en el archivo .env de tu profile — incluida HERMES_YOLO_MODE, un interruptor que cambia por completo tu postura de seguridad. En otras palabras, instalar una herramienta MCP era teóricamente la llave para «auto-yolo en cada arranque futuro». Ese agujero ya está cerrado (PR #91139).

Cómo era la vulnerabilidad

El problema vivía en POST /api/mcp/catalog/install. Antes del fix, aceptaba un mapeo env arbitrario y persistía cada valor no vacío en el archivo .env del profile seleccionado antes de ejecutar la instalación. El endpoint estaba pensado para recibir las credenciales que escribes en el asistente, pero como aceptaba cualquier cosa, una petición podía adjuntar HERMES_YOLO_MODE (o cualquier otro control de runtime) a un envío de credenciales por lo demás legítimo, escribirlo en .env y hacer que surtiera efecto en el siguiente arranque del proceso.

El peligro más sutil era la persistencia genérica en sí: una vez que un endpoint puede escribir claves arbitrarias en .env, se convierte en una primitiva de escritura genérica — capaz de reemplazar la raíz de confianza del catálogo MCP, adquirir autoridad de ejecutable Copilot ACP o inyectar cualquier control HERMES_*. El catálogo está para ayudarte a rellenar credenciales, no para tener ese tipo de poder.

El fix: las credenciales del catálogo son un schema cerrado

El comportamiento corregido:

• Validación de schema cerrado: cada entrada del catálogo declara qué variables de entorno necesita (su lista auth.env). Cualquier nombre del envío que no esté declarado → HTTP 400, rechazado antes de la primera escritura o acción de instalación;
• Validar todo el mapa antes de la primera escritura: una petición que mezcle claves válidas e inválidas no puede persistir credenciales parcialmente;
• Denylist a nivel de nombre: el escritor de entorno compartido se niega a persistir las variables de control de runtime y de aprobación de Hermes — HERMES_YOLO_MODE, HERMES_ACCEPT_HOOKS, HERMES_REDACT_SECRETS, HERMES_INTERACTIVE, HERMES_EXEC_ASK, HERMES_GATEWAY_SESSION, HERMES_CRON_SESSION, HERMES_SESSION_KEY, HERMES_CONFIG_PATH, HERMES_ENV_PATH y compañía — de modo que una entrada de catálogo mal formada no puede autorizarse a sí misma;
• Los errores no filtran secretos: solo se informan los nombres rechazados; los valores enviados nunca se devuelven.

Nota: la denylist es específica por nombre, no un bloqueo general de HERMES_* — muchas credenciales de integración siguen ellas mismas la convención HERMES_* (por ejemplo, HERMES_LANGFUSE_PUBLIC_KEY), y fulminar todo el prefijo rompería todos los asistentes de configuración de providers. La puerta bloquea los controles de runtime y deja pasar las credenciales de integración.

Qué cambia para los usuarios normales

Prácticamente nada. El escritorio ya renderiza y envía solo los campos de credenciales declarados por la entrada del catálogo, así que las instalaciones legítimas conservan exactamente su forma de petición; los servidores MCP configurados a mano no se tocan. Esto es endurecimiento puramente defensivo: tú lo usas como siempre, los atacantes pierden un punto de entrada.

Consejos para ti

• Sigue usando las instalaciones del catálogo: el flujo ahora está respaldado por un schema cerrado — las credenciales solo aterrizan en claves declaradas;
• Config MCP manual — echa un vistazo a tu .env: si escribes a mano configs de servidores MCP y pones variables en .env tú mismo, sigue el principio de mínimo privilegio — no dejes interruptores de la clase de HERMES_YOLO_MODE ahí; usa hermes config o los controles dedicados del CLI cuando los necesites;
• Contribuir entradas al catálogo: declara en auth.env todas las variables de entorno que tu entrada necesite — es lo que da forma al formulario del usuario y evita que las instalaciones se rechacen con un 400.

Para terminar

En el fondo, este fix estrecha los permisos: las instalaciones del catálogo pasaron de «pueden escribir variables de entorno arbitrarias» a «solo pueden escribir credenciales declaradas», con una denylist a nivel de nombre sobre las variables de control de seguridad. Los fixes de seguridad son las actualizaciones más fáciles de pasar por alto, y sin embargo protegen el momento en que estás más relajado: los asistentes de instalación de terceros. Para profundizar en el lado MCP de Hermes, consulta variables de contexto de la config MCP y el catálogo MCP remoto oficial; y si usas monitorización basada en webhooks, desplegar este fix es una mejora fácil que te dará tranquilidad.