Vault : le correctif lit les minuscules, et ton deny en majuscules ne matche plus

Le serrurier change le barillet. Avant, la porte lisait le nom tel que tu l'écrivais, et la pièce du fond le rangeait autrement, souvent en minuscules, parfois en lui retirant les espaces autour. Après, la porte ne lit plus que la forme rangée. Si ton panneau « interdit » était écrit avec une majuscule, il ne désigne plus la même poignée. Le trou, c'était l'écart entre les deux lectures. Le correctif ferme l'écart. Il peut aussi décrocher le panneau.

Le 7 octobre 2026, HashiCorp publie HCSEC-2026-43. Le numéro de faille est CVE-2026-89322. Vault et Vault Enterprise n'évaluaient pas les politiques ACL de façon cohérente contre la forme canonique des noms de ressources et de politiques. Un utilisateur authentifié, avec des droits délégués, peut ainsi contourner un deny explicite, accéder à une ressource protégée, ou assigner une politique pourtant refusée. Le bulletin dit que ça peut mener à une élévation de privilèges. « Peut ». Je le laisse à ce mode-là.

Le trou, avant le barillet neuf

Les versions touchées : Vault Community Edition jusqu'à 2.1.1, corrigée en 2.1.2. Vault Enterprise jusqu'à 2.1.1, corrigée en 2.1.2, 1.21.12, 1.20.17 et 1.19.23. Quatre numéros côté Enterprise. Un seul côté Community. Si tu es sur une branche Enterprise 1.19, 1.20 ou 1.21, le bulletin te donne un palier sur ta branche. Il ne te dit pas de sauter à 2.1.2 pour être le seul corrigé. Community, lui, n'a qu'un numéro de correctif dans le texte : 2.1.2. Je n'invente pas un 1.x Community.

Le fond du bulletin rappelle comment une ACL est censée marcher. Elle accorde ou refuse des capacités sur des chemins. Une règle plus spécifique l'emporte sur un joker plus large. denied_parameters peut empêcher un principal de poser certaines valeurs. On s'en sert pour déléguer la gestion de rôles, d'utilisateurs, de jetons, d'identités, tout en protégeant quelques ressources et les politiques les plus hautes. Et beaucoup de composants, dont plusieurs méthodes d'auth, les politiques ACL, les entités et les groupes d'identité, traitent ces noms comme insensibles à la casse.

L'écart est entre deux moments. Vault évaluait la politique sur le nom tel qu'il arrivait dans la requête. Le composant, ensuite, normalisait : casse ignorée, ou espaces autour du nom. Une requête qui désignait la ressource protégée, ou la politique refusée, sous un nom non canonique, pouvait donc passer à côté de la restriction, puis s'appliquer quand même à la ressource, ou à la politique deny. Le bulletin donne deux issues : obtenir les identifiants d'un rôle d'auth explicitement refusé, ou assigner une politique explicitement refusée à un jeton, un rôle, un utilisateur, une identité. Côté Enterprise, les politiques Sentinel évaluées sur le chemin de la requête étaient dans le même cas.

Ce n'est pas un visiteur anonyme. Il faut un principal déjà authentifié, avec des droits délégués larges sur le point d'accès concerné, et une politique qui compte soit sur une règle plus spécifique pour refuser ou limiter à côté d'un allow plus large, soit sur des denied_parameters pour restreindre les noms de politiques assignables. Assigner une politique refusée suppose en plus qu'elle existe déjà, et que le principal puisse obtenir un jeton qui la porte. Les politiques root et internes ne s'assignent pas par ce biais. Créer un jeton sans sudo reste limité aux politiques de l'appelant. Si tu ne combines pas un allow large et une restriction plus précise, si tes noms de politiques ne jouent pas sur une casse non canonique, et si tu n'utilises pas denied_parameters pour borner des noms de politiques, le bulletin dit que tu n'es pas concerné.

L'ordre, qui n'est pas « mets à jour d'abord »

La remédiation tient en deux gestes, et l'ordre est écrit. Évaluer le risque, et envisager la montée vers Community 2.1.2, ou Enterprise 2.1.2, 1.21.12, 1.20.17 ou 1.19.23.

Ensuite, la phrase que je ne veux pas que tu lises en diagonale. Après la mise à jour, les règles ACL et les politiques Sentinel Enterprise, pour les ressources concernées, sont évaluées contre le nom de ressource en minuscules. Les règles qui citent un nom en casse mixte, y compris les deny, ne matcheront plus. Il faut les réécrire en minuscules avant de monter de version.

Le correctif aligne la lecture. Il aligne aussi tes vieux panneaux sur une orthographe que tu n'avais peut-être pas utilisée. Une règle écrite avec une majuscule ne désigne plus le nom que l'évaluation ne compare plus qu'en minuscules. Le bulletin ne dit pas « réécris si tu as le temps ». Il dit avant.

Le détail, plus haut, parle aussi d'espaces autour du nom dans la normalisation. La phrase de remédiation, elle, ne parle que de la casse. Je ne fabrique pas une deuxième consigne pour les espaces. Je note que les deux phrases ne disent pas la même chose, et je m'arrête où le texte s'arrête.

Les portes laissées sur l'ancien barillet

Une dernière limite, dans le même paragraphe. Les méthodes d'auth Okta, LDAP et RADIUS, et les clients SCIM de Vault Enterprise, ne sont pas couverts par ce correctif. Pour ces ressources-là, le bulletin demande d'éviter de combiner un allow large et un deny plus spécifique. Je ne décris pas le reste du chemin. La consigne est négative : ne pas compter sur ce couple-là, ici, même une fois le numéro de version changé.

Le signalement est attribué à Han Sang-Kyung (HAN-BAMBO), et à d'autres parties, internes et externes. Le bulletin ne dit pas que quelqu'un s'en sert déjà dehors. Je ne l'ajoute pas.

✍️ À toi : si tes deny Vault sont en casse mixte, et si tu as déjà le diff qui les passe en minuscules avant la montée. Le bulletin donne l'ordre. Ton dépôt de politiques a la réponse.

Le trou, c'était deux lectures du même nom. Le barillet neuf n'en garde qu'une, les minuscules. Tant que tes interdictions sont écrites comme l'ancienne porte les lisait, la mise à jour les décroche en même temps qu'elle ferme l'écart. Le numéro de version ne suffit pas. L'orthographe du deny fait partie du correctif.