Imaginez : vous trouvez un serveur MCP utile dans le catalogue officiel de Hermes, vous cliquez sur installer, il demande quelques variables d’environnement, vous collez votre clé API, et tout fonctionne. Imaginez maintenant que l’entrée du catalogue soit malveillante — ou simplement mal écrite. Avant le correctif fusionné le 26 août, n’importe quelle variable d’environnement de la requête d’installation était persistée verbatim dans le fichier .env de votre profil — y compris HERMES_YOLO_MODE, un interrupteur qui change carrément votre posture de sécurité. Autrement dit, installer un outil MCP était théoriquement la clé du « auto-yolo à chaque démarrage futur ». Ce trou est désormais fermé (PR #91139).

À quoi ressemblait la vulnérabilité

Le problème se trouvait dans POST /api/mcp/catalog/install. Avant le correctif, l’endpoint acceptait un mapping env arbitraire et persistait chaque valeur non vide dans le fichier .env du profil sélectionné avant de lancer l’installation. L’endpoint était censé recevoir les identifiants que vous tapez dans l’assistant, mais comme il acceptait n’importe quoi, une requête pouvait attacher HERMES_YOLO_MODE (ou tout autre contrôle d’exécution) à une soumission d’identifiants par ailleurs légitime, l’écrire dans .env, et lui donner effet au prochain démarrage de processus.

Le danger plus subtil était la persistance générique elle-même : dès qu’un endpoint peut écrire des clés arbitraires dans .env, il devient une primitive d’écriture universelle — capable de remplacer la racine de confiance du catalogue MCP, d’acquérir l’autorité d’exécution d’ACP Copilot, ou d’injecter n’importe quel contrôle HERMES_*. Le catalogue est censé vous aider à renseigner des identifiants, pas détenir ce genre de pouvoir.

Le correctif : les identifiants du catalogue sont un schéma fermé

Le comportement corrigé :

• Validation en schéma fermé : chaque entrée du catalogue déclare les variables d’environnement dont elle a besoin (sa liste auth.env). Tout nom présent dans la soumission mais non déclaré → HTTP 400, rejeté avant la première écriture ou action d’installation ;
• Valider tout le mapping avant la première écriture : une requête mélangeant clés valides et invalides ne peut pas persister partiellement des identifiants ;
• Denylist au niveau des noms : l’écrivain d’environnement partagé refuse de persister les variables de contrôle d’exécution et d’approbation 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 et compagnie — si bien qu’une entrée de catalogue mal formée ne peut pas s’auto-autoriser ;
• Les erreurs ne fuient pas de secrets : seuls les noms rejetés ; les valeurs soumises ne sont jamais renvoyées en écho.

À noter que la denylist est spécifique aux noms, pas un blocage général de HERMES_* — de nombreux identifiants d’intégration suivent eux-mêmes la convention HERMES_* (par exemple HERMES_LANGFUSE_PUBLIC_KEY), et écraser tout le préfixe casserait tous les assistants de configuration des providers. Le portail bloque les contrôles d’exécution et laisse passer les identifiants d’intégration.

Ce qui change pour les utilisateurs lambda

Pratiquement rien. Le desktop n’affiche et ne soumet déjà que les champs d’identifiants déclarés par l’entrée du catalogue, si bien que les installations légitimes gardent exactement la même forme de requête ; les serveurs MCP configurés manuellement ne sont pas touchés. C’est du durcissement défensif pur : vous l’utilisez comme d’habitude, les attaquants perdent un point d’entrée.

Nos conseils

• Continuez à utiliser les installations du catalogue : le flux est désormais adossé à un schéma fermé — les identifiants n’atterrissent que dans des clés déclarées ;
• Configuration MCP manuelle — jetez un œil à votre .env : si vous écrivez vous-même les configs de serveurs MCP et placez des variables dans .env, suivez le moindre privilège — n’y déposez pas d’interrupteurs de la classe HERMES_YOLO_MODE ; utilisez hermes config ou les contrôles CLI dédiés quand vous en avez besoin ;
• Contribuer des entrées au catalogue : déclarez dans auth.env chaque variable d’environnement dont votre entrée a besoin — c’est ce qui façonne le formulaire de l’utilisateur et évite que les installations soient rejetées avec un 400.

Pour conclure

Au fond, ce correctif réduit les permissions : les installations du catalogue sont passées de « peut écrire des variables d’environnement arbitraires » à « ne peut écrire que des identifiants déclarés », avec une denylist au niveau des noms sur les variables de contrôle de sécurité. Les correctifs de sécurité sont les mises à jour les plus faciles à négliger, et pourtant ils protègent le moment où vous êtes le plus détendu — les assistants d’installation tiers. Pour creuser le côté MCP de Hermes, voir les variables de contexte de config MCP et le catalogue MCP distant officiel ; et si vous utilisez la supervision par webhooks, déployer ce correctif est une mise à jour facile qui apporte la tranquillité d’esprit.