MaxKB : le chemin de dispatch de l’agent permet à un utilisateur à qui l’accès à un outil a été refusé de l’appeler quand même et de lire ses identifiants.

MaxKB, l'assistant IA d'entreprise open source maintenu par 1Panel-dev, fournit une liste d'autorisations par utilisateur et par outil afin qu'un administrateur puisse accorder un outil à un membre d'un espace de travail et en refuser un autre. Selon l'avis de sécurité publié le 2 septembre 2026, ce refus était appliqué sur les routes propres à l'outil, mais pas sur le chemin qu'un agent ou un workflow utilise pour appeler le même outil. Un membre d'un espace de travail disposant du rôle le plus bas pouvait nommer l'identifiant d'un outil refusé lors de la création d'un workflow, exécuter le workflow et recevoir non seulement la sortie de l'outil, mais aussi les identifiants que MaxKB déchiffre côté serveur pour l'exécuter. Les versions 2.0.0 à 2.9.2 sont affectées, et l'avis ne mentionnait aucune version corrigée. Cette fiche — le contournement d'autorisation de répartition d'outils de MaxKB — est une entrée dans OrcaRouter AI Incident Archive, qui contient l'ensemble complet des fiches et les entrées voisines de cet incident.

Ce qui rend ce cas digne d'une lecture attentive, ce n'est pas le score. C'est que le produit disposait déjà du bon contrôle, l'appliquait sur la porte évidente, et laissait sans surveillance une seconde porte menant à la même fonctionnalité. L'avis, GHSA-383v-fx78-pphm, a été rédigé par le chercheur qui l'a découvert et publié via le système d'avis de GitHub à 07:43 UTC le 2 septembre 2026, créditant Matteo Panzeri (@matte1782). L'enregistrement CVE, CVE-2026-77516, a suivi le 21 septembre 2026.

Ce que l’avis établit

Le modèle par outil de MaxKB est WorkspaceUserResourcePermission, décrit dans l’avis comme une liste d’autorisation à refus par défaut, résolue au moment de la requête. Les routes d’outil dédiées l’appliquent. L’avis indique l’application dans apps/tools/views/tool.py, où Operate.put, Operate.get, Debug.post, Export.get et Delete comportent chacun une vérification des autorisations de vue par rapport à l’autorisation d’outil d’espace de travail de l’appelant. Debug.post est la route la plus proche de l’exécution simple d’un outil, et elle est soumise à autorisation.

Le chemin de répartition de l'agent et du workflow ne réapplique pas cette vérification. L'avis de sécurité recense trois endroits distincts où elle fait défaut. Dans apps/application/serializers/application.py, le sérialiseur d'application lie tool_ids, skill_tool_ids et mcp_tool_ids directement à partir des données de la requête, sans autorisation par outil — et l'avis souligne que l'asymétrie est visible dans le même fichier, car knowledge_id_list est validé par rapport aux bases de connaissances accessibles par l'utilisateur quelques lignes plus bas, alors que les outils ne le sont pas. Dans apps/common/utils/shared_resource_auth.py, filter_authorized_ids laisse passer inconditionnellement tous les outils de l'espace de travail de l'appelant ; le contrôle inter-espaces de travail sur lequel il s'appuie est un hook réservé à l'édition entreprise, absent de l'édition communautaire, et il ne consulte jamais WorkspaceUserResourcePermission. Enfin, au point d'exécution, apps/application/flow/step_node/tool_lib_node/impl/base_tool_lib_node.py exécute le code stocké de l'outil avec ses init_params déchiffrés par rsa_long_decrypt sous l'identité de l'application, sans aucune vérification d'autorisation par outil.

L'avis qualifie le résultat d'exécution de type confused deputy : le dispatch de workflow exécute un outil, et ses secrets stockés, alors que le même appelant se voit refuser l'accès à cet outil et à ses secrets sur les routes propres de l'outil. L'exposition des identifiants est la partie qui dépasse l'utilisation non autorisée ordinaire d'un outil. Les init_params d'un outil sont chiffrés au repos avec RSA et déchiffrés côté serveur uniquement au moment de l'exécution, de sorte qu'un appelant qui déclenche cette exécution reçoit des valeurs qu'il n'a jamais détenues et qu'il n'aurait pas pu fournir.

La démonstration, selon les propres chiffres du chercheur

L'avis rapporte une confirmation dynamique sur la v2.9.2, exécutée à partir de l'image tout-en-un officielle, 1panel/maxkb:v2.9.2. La configuration comprenait un espace de travail, un administrateur et un second membre détenant le rôle USER. L'administrateur a créé l'outil A et l'outil B et a placé un nouveau secret aléatoire dans init_params de l'outil B, puis a écrit le corps de l'outil B pour qu'il renvoie ce secret lorsqu'il est exécuté. Le membre a ensuite reçu une autorisation par outil pour l'outil A uniquement, et l'avis indique que l'état sans autorisation pour l'outil B a été vérifié à nouveau dans la base de données après l'exécution.

La moitié refusée du test a renvoyé ce que le produit promet. En tant que membre, la route de débogage de Tool B a répondu 403, la route de mise à jour a répondu 403, la route d’exportation a répondu 403, et Tool A autorisé a renvoyé 200 comme contrôle de cohérence. La moitié de contournement a ensuite lié Tool B dans une application de workflow via un nœud de bibliothèque d’outils — la liaison a été acceptée avec HTTP 200 et sans vérification par outil — et l’exécution du workflow a renvoyé HTTP 200 avec un corps contenant le nom de l’outil, le secret sentinelle et la liste de clés ["api_key"].

L'avis indique que le secret est apparu à trois niveaux : dans la réponse de l'API de workflow, dans un enregistrement d'exécution d'outil avec l'état SUCCESS, et dans la ligne de base de données où, pour l'outil B, init_params se trouve sous la forme d'un texte chiffré RSA de 344 octets — ce qui permet au chercheur d'affirmer que la valeur a été déchiffrée côté serveur sous l'identité de l'application plutôt que fournie par l'appelant. Le même membre à qui l'accès a été refusé sur la route d'exécution de l'outil a obtenu le secret déchiffré de l'outil en l'intégrant dans un workflow.

Un score publié, un autre plus élevé revendiqué

Le score associé à CVE-2026-77516 est CVSS 3.1 5.4, Moyen, avec le vecteur AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N. L’enregistrement de NVD montre que ce score provient du flux d’avis de GitHub plutôt que de l’analyse propre à NVD, et l’entrée porte le statut Deferred, ce qui signifie que NVD ne l’a pas enrichie. La classification propre à l’archive suit ce score publié : gravité moyenne, aucun préjudice réel enregistré.

La section de l’avis consacrée à l’impact plaide elle-même pour davantage. Elle indique une gravité de 7,1, élevée, sur un vecteur qui porte l’impact sur la confidentialité à un niveau élevé, et précise que la valeur monte à 8,1 lorsque l’outil envoyé effectue des écritures privilégiées sous l’identité de l’application. Il s’agit d’un désaccord sur la manière de compter l’exposition des identifiants, non sur l’existence ou non du contournement — le même document démontre à la fois la faille et affirme qu’elle est sous-évaluée. Rien dans les sources publiques ne permet de trancher quelle valeur est correcte, et la note « moyen » de l’archive suit le score CVE publié plutôt que l’argument de l’avis.

Deux évaluations supplémentaires sont consignées. Les points de décision SSVC de la CISA, ajoutés à l’entrée NVD le 28 septembre 2026, consignent l’exploitation comme « poc », l’automatisabilité comme « no » et l’impact technique comme « partial » — la valeur « poc » indique qu’une preuve de concept existe, ce qui est bien le cas dans l’avis lui-même ; il ne s’agit pas d’un constat d’exploitation dans la nature. Le modèle EPSS de FIRST a estimé la probabilité d’exploitation au cours des 30 prochains jours à 0,242 %, au 15,2e percentile, dans l’estimation datée du 27 octobre 2026.

Un correctif antérieur à l’avis, et aucun dans la plage affectée

Le tableau des versions de l’avis indique que les versions affectées vont de 2.0.0 à 2.9.2, qu’aucune version corrigée n’est mentionnée, et son texte précise qu’aucune version corrigée n’est disponible au moment de l’examen, ajoutant qu’un correctif dans une version étiquetée permettrait à une CVE de s’y rattacher. Le dépôt du fournisseur raconte une histoire légèrement différente, et cette différence compte pour quiconque doit décider quoi exécuter.

Dans le dépôt MaxKB, les fonctions qui ferment le chemin de distribution — validate_bound_tool_permissions et get_authorized_tool_ids dans apps/application/serializers/application.py — sont absentes du tag v2.9.2 ainsi que des versions v2.10.2-lts, v2.10.3-lts et v2.10.4-lts, et présentes à partir de v2.10.5-lts. Cette version a été publiée le 6 août 2026, quatre semaines avant l'avis de sécurité. Le même tag ajoute une vérification des outils par utilisateur à base_tool_lib_node.py, s'appuyant sur WorkspaceUserResourcePermission, et ajoute un filtre tenant compte de l'utilisateur à shared_resource_auth.py — autrement dit, il met en œuvre, dans les grandes lignes, les trois étapes de remédiation que l'avis recommande par la suite.

Personne n’a publiquement établi ce lien. Les notes de version de v2.10.5-lts ne mentionnent pas de correctif lié aux autorisations des outils ; elles recensent quatre éléments de sécurité sans rapport et un lot de travaux sur des fonctionnalités et des correctifs. L’avis ne nomme pas 2.10.5, et sa plage affectée s’arrête simplement à 2.9.2, la dernière version de la branche 2.9. L’historique des versions ne montre aucun correctif 2.9.x après l’avis, si bien qu’un déploiement sur 2.9.2 ne dispose d’aucune build corrigée dans sa propre branche. La version actuelle est v2.10.8-lts, publiée le 22 octobre 2026, dont les notes décrivent des correctifs X-Pack apportés à l’autorisation des outils partagés, et non quoi que ce soit dans le chemin de répartition de l’édition communautaire.

Qu'est-ce qui n'est pas établi ?

Trois points méritent d’être distingués de la démonstration. Premièrement, aucun rapport public ne fait état de l’utilisation du contournement contre quiconque. Le dossier concerne une vulnérabilité qui a été découverte, non une intrusion qui a été investiguée ; il ne comporte aucune victime, aucun acteur attribué ni aucun préjudice, et la preuve de concept de l’avis a été exécutée par le chercheur dans un espace de travail contrôlé. Deuxièmement, aucune organisation de presse, aucun régulateur ni aucune seconde équipe de recherche ne semble avoir analysé la faille : la couverture existante se limite aux bases de données et agrégateurs de vulnérabilités — notamment VulDB, la base de données de Rapid7, Armis, SOCRadar et openCVE — qui répertorient le CVE et reprennent la description de l’avis, et dont aucun ne propose une évaluation indépendante du code. Le mécanisme tel que décrit ici repose donc sur un seul avis et sur le code source du fournisseur lui-même. Troisièmement, aucun chiffre n’existe quant au nombre de déploiements de MaxKB situés dans la plage concernée, et ni le fournisseur ni le chercheur n’en a publié.

La population à risque est étroite mais pas triviale à dénombrer : les installations autonomes de MaxKB en édition communautaire, versions 2.0.0 à 2.9.2, qui comptent plus d’un membre d’espace de travail, et où un administrateur a utilisé les autorisations par outil pour retirer un outil porteur d’identifiants. La faille n’est pas une exécution de code à distance et nécessite un compte valide à faibles privilèges, ce qui explique que l’impact sur la confidentialité soit le facteur déterminant du score plutôt que le vecteur d’attaque. Ce qu’un attaquant obtient est limité par ce que contiennent les outils refusés — clés d’API, jetons et tout ce que ceux-ci permettent de déverrouiller —, ce qui explique aussi pourquoi les auteurs de l’avis soutiennent que l’impact est plus important que ne le laisserait supposer une note de confidentialité faible.

Ce qu'un opérateur peut faire

La remédiation de l'avis s'adresse aux mainteneurs plutôt qu'aux opérateurs, et ses trois étapes correspondent au code apparu dans v2.10.5-lts : appliquer l'autorisation par outil avant d'exécuter un outil dans les implémentations de la bibliothèque d'outils et du nœud d'outil, valider tous les tool_ids, skill_tool_ids et mcp_tool_ids liés au moment de la liaison comme knowledge_id_list l'est déjà, et faire en sorte que filter_authorized_ids consulte l'autorisation par outil plutôt que la seule appartenance à l'espace de travail.

Pour une équipe utilisant une version affectée, voici les étapes pratiques qui découlent de la description même de l’avis.

• Considérez que tout secret stocké dans les init_params d'un outil sur un déploiement affecté est accessible à tout membre de l'espace de travail, y compris au rôle le plus bas, et renouvelez ces identifiants plutôt que de supposer que le refus propre à chaque outil les a protégés.

• Auditez l'appartenance à l'espace de travail. Le contournement nécessite un compte authentifié dans l'espace de travail ; ainsi, la suppression des membres dormants ou non fiables réduit l'exposition, même lorsque le code ne peut pas être corrigé.

• Examinez quels workflows et agents lient des outils porteurs d’identifiants, puisque cette liaison est l’étape que l’avis indique comme acceptée sans vérification par outil.

• En cas de mise à niveau, notez que le contrôle par utilisateur apparaît dans le dépôt à partir de la v2.10.5-lts, et qu'aucune version n'est désignée comme correctif par l'avis — un opérateur qui se fie à la mise à niveau se fie au source étiqueté, et non à une déclaration de correctif du fournisseur.

Rien de tout cela ne rend la faille spectaculaire. Cela la rend ordinaire d’une manière précise et instructive : le modèle d’autorisation a été conçu correctement, documenté correctement et appliqué aux routes que quelqu’un a pensé à protéger. Le chemin de dispatch a été écrit par des personnes qui pensaient à ce qu’un workflow devait pouvoir faire, pas à qui faisait la demande — et, dans une plateforme d’agents, c’est le chemin que prennent réellement la plupart des requêtes.

La leçon du dossier est structurelle plutôt que numérique. Une autorisation par ressource n’est aussi solide que son point d’entrée le moins protégé, et une plateforme d’agents accumule rapidement les points d’entrée : une route de débogage, une route d’exportation, un nœud de workflow, un déclencheur de chat. MaxKB disposait de la liste des autorisations et du contrôle ; ce qui lui manquait, pour la gamme 2.0 à 2.9, c’était l’habitude de poser la même question à chaque porte.