Hermes Agent a encore publié une version — v0.21.6. Vous ouvrez la page de release et le premier paragraphe vous le dit : c’est une version corrective qui rassemble la fenêtre dans un tag stable, et les notes complètes et éditorialisées arrivent avec v0.22.0. Vous lancez hermes update, le terminal vous dit que ça a marché, et il vous reste une question à laquelle vous ne pouvez pas vraiment répondre : qu’ai-je réellement installé, et dois-je me dépêcher ? Cette fois, le doute est plus tenace que d’habitude, parce que ce n’est pas seulement le contenu qui est nouveau — la manière dont la release a été produite a changé, elle aussi. Cet article fait deux choses : il explique ce qui a changé dans le processus de release, et il vous donne trois commandes pour confirmer votre version vous-même.

Ce qui est nouveau : le premier tag issu du nouveau pipeline de releases stables

Le corps officiel le dit sans détour : v0.21.6 est la première release découpée par le nouveau pipeline de releases stables, et sa forme est « une ref de tentative, une image Docker testée, et un tag-reçu à la publication ».

Cela paraît abstrait, alors voici les choses en clair. Avant, un tag était le coup de départ : l’image, les déploiements hébergés et les paquets Nix se construisaient chacun tout seuls à partir de lui ensuite. Maintenant, c’est inversé — il y a d’abord une tentative de release, la tentative porte elle-même le build et les tests, l’image Docker n’est publiée qu’une fois qu’ils passent, et le reçu de ce qui a été publié est enregistré sur le tag. Pour vous, utilisateur, la différence pratique est la suivante : le tag s’appuie sur une image qui a été testée, plutôt que sur un tag à partir duquel vous construisez ensuite.

Le corps de la release trace aussi la frontière : cette release livre le tag, la release GitHub et l’image Docker. L’application desktop, les paquets Termux et le Microsoft Store restent sur leur build actuel et suivront la prochaine release groupée.

Ce qui est réellement entré dans la fenêtre

D’abord la taille. Ces chiffres sont les chiffres officiels, mesurés au commit 818c13be1dc4fd28987e1e881a9408224afd4535 :

Métrique	Valeur
Commits non fusionnés	8 867
Fichiers modifiés	8 342 (+772 490 / −225 600)
PR fusionnées	2 106
Issues fermées	3 027

Si vous voulez vérifier le nombre de fichiers vous-même, une seule commande suffit (il vous faut l’historique git complet en local) :

cd ~/.hermes/hermes-agent
git fetch origin main --tags
git diff --shortstat v2026.9.24 818c13be1dc4fd28987e1e881a9408224afd4535
# 8342 files changed, 772490 insertions(+), 225600 deletions(-)

v2026.9.24 est le tag précédent — c’est la version sémantique v0.21.5. « Une version corrective sans notes » ne veut pas dire « rien dedans » ; cela veut dire que ces 2 106 PR n’ont jamais été nommées et triées individuellement. Elles seront documentées avec v0.22.0, et le corps promet que rien dans la fenêtre n’est omis.

Trois commandes pour confirmer quelle version vous utilisez

Ne vous fiez pas au ressenti, ni au mot « success » dans la sortie de mise à jour. Fiez-vous au type d’installation :

# 1. numéro de version (les installations git affichent aussi la distance au tag + le commit court)
hermes version

# 2. ce que votre dernière mise à niveau a réellement fait
hermes update

# 3. Docker / hébergé : regardez le tag de l'image lui-même
docker pull nousresearch/hermes-agent:stable

Le troisième cas mérite un avertissement. Les utilisateurs de Docker et de Hermes Cloud n’ont pas un arbre de travail git, ils ont une image. Le mot-clé pour les consommateurs en aval dans cette release est nousresearch/hermes-agent:stable (ou :latest). Pour les utilisateurs d’images, il n’existe qu’une seule réponse fiable à « ai-je bien mis à niveau ? » — le digest de l’image, pas l’heure de pull dont vous vous souvenez.

Il y a un autre indice facile à manquer. Les installations git enregistrent la façon dont elles ont été mises à jour dans un tampon d’installation (install-stamp.json, lu par hermes version). Donc si deux machines rapportent la même version mais se comportent différemment, comparez ce tampon avant de suspecter le code — vous regardez probablement la différence entre une installation « légère » et une installation git complète.

Les correctifs de sécurité de cette fenêtre, au même endroit

Cette release ne documente volontairement pas ses fonctionnalités, mais les correctifs de sécurité sont signalés à part — trois groupes, et pour chacun il vaut la peine de vérifier de quel côté vous vous situez.

1. Durcissement de l’authentification du dashboard (PR #133367, #133369, #133370, plus la prise de contrôle de session #130685). Un seul rapport de Tenable Research (TRA-725 … TRA-728) couvre quatre problèmes : un X-Forwarded-For usurpé pouvait réinitialiser la limite de débit de connexion par mot de passe et contourner le plafond par IP ; des requêtes de connexion non authentifiées pouvaient écrire des valeurs non bornées dans le journal d’audit ; les routes publiques /auth/ n’avaient aucune limite de taille du corps de requête ; et la connexion native pouvait envoyer les codes de connexion vers une redirection non-loopback, ce qui permettait une prise de contrôle de session. Nous avons déjà détaillé les trois premiers dans l’article sur le durcissement de la connexion du dashboard — ce papier donne la cause de chacun et indique si votre déploiement nécessite un changement de config. Le quatrième (la redirection) n’est nommé explicitement que dans le corps de cette release, alors lisez les deux ensemble pour le tour complet.

2. Durcissement du filtre git des dépôts (#130661). Les appels git automatiques — instantanés de l’espace de travail de session, worktrees de sous-agents, kanban, nettoyage de worktree, hermes -w — pouvaient être détournés par des programmes de filtre clean / smudge / process définis dans la config d’un dépôt non fiable, et cela se produisait avant même que vous tapiez votre premier prompt. Nous avons traité celui-là séparément aussi : quand la config git devient un point d’entrée RCE. Si vous clonez régulièrement des dépôts inconnus et ouvrez une session dedans, voilà votre raison de mettre à niveau.

3. Durcissement de l’expéditeur du gateway e-mail (#125212, #124322). Un nom d’affichage entre guillemets dans l’en-tête From pouvait être forgé pour ressembler à un expéditeur autorisé, laissant le message d’un attaquant passer la liste d’autorisation e-mail. Nous avons analysé celui-là aussi dans l’article sur l’usurpation d’identité d’expéditeur.

En une ligne, les trois groupes relèvent de la même classe d’erreur : une entrée sans plafond, à laquelle on fait confiance parce qu’elle est arrivée. Aucun n’est une fonctionnalité.

Faut-il mettre à niveau maintenant ?

La décision n’est pas difficile :

• Vous exposez un dashboard, ou vous faites tourner le gateway sur plusieurs machines ou profils → mettez à niveau. Deux des trois groupes de sécurité touchent directement votre surface d’attaque.
• Vous clonez les dépôts d’autres personnes et laissez l’agent travailler dedans (surtout ceux de l’équipe) → mettez à niveau. Le problème de filtre git se déclenche avant même que vous ne disiez quoi que ce soit.
• Vous êtes une seule machine locale sans port exposé → rien ne casse dans un sens ou dans l’autre, mais comme le nouveau pipeline livre une image testée comme artefact, avancer tôt coûte moins cher qu’avancer tard.

La mise à niveau reste le même one-liner : hermes update ; les utilisateurs de Docker tirent :stable ; l’application desktop n’a besoin de rien cette fois et suivra la prochaine release groupée.

Pour conclure

• Le plus gros changement de v0.21.6 n’est pas une fonctionnalité — c’est la façon dont la release est produite : ref de tentative → image Docker testée → reçu enregistré à la publication.
• Taille de la fenêtre : 8 342 fichiers modifiés, 2 106 PR fusionnées. Les notes complètes et éditorialisées arrivent avec v0.22.0.
• Ne vous fiez pas au mot « success » de la mise à jour. Confirmez avec hermes version et le digest de l’image.
• Trois groupes de sécurité : auth du dashboard, filtres git, expéditeur e-mail. Les deux premiers valent la peine d’agir dès aujourd’hui.

Pour les changements de la fenêtre précédente qui « marchent déjà mais que personne n’a documentés », voyez notre guide d’auto-vérification de fenêtre corrective. Et si vous voulez savoir exactement ce qui survit à un redémarrage quand vous activez YOLO, lisez ensuite la persistance de /yolo.