CVE-2026-97406 : Xerj Console API auth bypass, sans patch

Les faits

Le CERT/CC (Computer Emergency Response Team Coordination Center de Carnegie Mellon) a publié le 20 octobre 2026 l'advisory VU#645818 concernant une vulnérabilité critique dans Xerj, un moteur de recherche et d'indexation open source conçu pour les agents d'intelligence artificielle. Référencée CVE-2026-97406 avec un score CVSS de 9.1, cette faille permet à un attaquant disposant d'un simple bearer token de contourner l'authentification forte par passkey normalement exigée pour interagir avec l'API Console de Xerj.

Xerj est un projet open source qui expose une interface compatible avec l'API Elasticsearch, permettant aux modèles d'IA d'interroger un index structuré. Il est utilisé comme composant de mémoire persistante et de récupération de contexte dans de nombreuses architectures d'agents IA modernes, notamment dans des pipelines RAG (Retrieval-Augmented Generation) et des systèmes d'agents autonomes. Sa diffusion dans l'écosystème IA en fait une cible d'autant plus stratégique que les organisations qui le déploient ne disposent pas toujours d'équipes de sécurité dédiées.

La vulnérabilité est enracinée dans un défaut de conception architectural : Xerj convertit indistinctement les sessions navigateur standard et les bearer tokens API en un même objet générique de type AuthSession. Cette normalisation efface la distinction entre les deux modes d'authentification. L'endpoint de création de tokens API (/api-token/create) est supposé n'être accessible qu'aux sessions authentifiées par passkey. En pratique, un bearer token ordinaire suffit à invoquer cet endpoint, permettant de créer de nouveaux tokens persistants sans jamais présenter de passkey.

Le second problème structurel identifié par le CERT/CC aggrave considérablement l'impact : Xerj ne dispose d'aucune logique de révocation hiérarchique. Lorsqu'un token parent est révoqué, l'ensemble des tokens descendants créés à partir de lui restent actifs et fonctionnels. Un attaquant qui exploite CVE-2026-97406 pour créer un token de seconde génération peut maintenir son accès indéfiniment, même après que l'organisation a détecté et révoqué le token parent compromis. Cette propriété transforme une intrusion ponctuelle en accès persistant quasi inarrachable sans réinitialisation complète du système d'authentification.

Contrairement à la majorité des CVE critiques, CVE-2026-97406 se distingue par l'absence totale de correctif au moment de la publication de l'advisory CERT/CC le 20 octobre 2026. Le CERT/CC précise que le vendor n'a pas pu être contacté pour coordonner la divulgation, et qu'aucun patch officiel n'est disponible à ce jour. La version affectée est Xerj Console API 1.0.0-rc.11. Sources : CERT/CC VU#645818, OpenCVE, SecurityOnline.

L'absence de patch dans un contexte de score CVSS 9.1 est particulièrement préoccupante pour les organisations qui exposent leur instance Xerj sur un réseau accessible. Même en contexte interne, un attaquant ayant obtenu un premier point d'entrée sur le réseau de l'organisation peut exploiter CVE-2026-97406 pour s'octroyer un accès persistant et discret à l'ensemble des données indexées par l'agent IA : historiques de conversations, documents internes, bases de connaissances propriétaires.

Il n'existe a ce jour aucune indication d'exploitation active dans la nature pour CVE-2026-97406. Cependant, la nature pré-authentification de la faille et la disponibilité du code source de Xerj sur des dépôts publics facilitent le développement d'exploits. Le délai entre publication d'un advisory CERT/CC bien documenté et apparition d'exploits publics est généralement compris entre 24 et 72 heures pour ce type de vulnérabilité.

Le composant CWE associé est CWE-306 (Missing Authentication for Critical Function). La sévérité est justifiée par la combinaison de trois facteurs : exploitabilité pré-authentification avec un bearer token valide (accessible à tout utilisateur légitime), création de tokens descendants persistants non révocables, et absence de patch avec un délai de résolution inconnu.

Impact et exposition

Xerj est principalement déployé par des équipes de développement, des startups IA et des organisations ayant intégré des agents IA dans leurs processus métiers. Une instance Xerj compromise donne accès à l'ensemble des données indexées : selon la configuration du pipeline, il peut s'agir de documents confidentiels, d'emails, de tickets clients ou de bases de connaissances propriétaires. L'exposition maximale concerne les instances accessibles depuis Internet ou depuis un réseau interne sans segmentation stricte.

Recommandations

• Bloquer immédiatement l'accès réseau à l'endpoint /api-token/create via règle firewall ou WAF jusqu'à disponibilité d'un patch officiel
• Auditer tous les tokens existants : identifier les tokens de second niveau potentiellement créés via l'exploit et réinitialiser le système complet d'authentification si des tokens suspects sont trouvés
• Restreindre l'accès à la Console API aux seules adresses IP des administrateurs légitimes via liste blanche
• Surveiller le dépôt Xerj pour toute release de patch et l'appliquer en priorité dès disponibilité
• Inventorier les données indexées dans Xerj pour évaluer l'impact potentiel d'une compromission