CERT/CC ha publicado el boletín VU#645818, en el que describe una vulnerabilidad de omisión de autenticicación en el API de consola del motor de búsqueda e indexación Xerj, una solución abierta orientada a agentes de IA y compatible con Elasticsearch API. La vulnerabilidad CVE-2026-97406 permite a un atacante que disponga de un token de API válido crear credenciales «hijas» independientes con el mismo nivel de acceso, eludiendo el requisito de autenticación con passkey. Un detalle crítico: la revocación del token padre comprometido no afecta a los tokens hijos creados a partir de él. En el momento de la publicación del boletín no existe un parche oficial, y los coordinadores de CERT/CC no han conseguido contactar con el desarrollador. Las organizaciones que utilicen Xerj deben auditar de inmediato los tokens de API emitidos y restringir el acceso al API de consola.
Esencia técnica de la vulnerabilidad
Según el boletín de CERT/CC, la arquitectura de Xerj establece que la emisión de nuevos tokens de API debe autorizarse exclusivamente mediante una sesión validada a través de passkey. Sin embargo, la implementación convierte tanto las sesiones normales de navegador como los bearer tokens de API en un único objeto genérico AuthSession. El manejador de creación de tokens acepta este objeto sin comprobar si la sesión se autenticó específicamente mediante passkey.
La superficie vulnerable es el backend de consola integrado que, según la documentación de arquitectura del proyecto, se monta en la ruta /_xerj-console/api/v1/*. Al mismo tiempo, la documentación sobre autorización afirma que solo el superusuario puede crear claves con ámbito limitado, pero la vulnerabilidad permite eludir esta restricción.
Características clave de la vulnerabilidad:
- Precondición: el atacante debe obtener o interceptar un token de API de Xerj válido
- Mecanismo: invocación directa del endpoint de creación de tokens mediante autenticación bearer sin confirmación por passkey
- Resultado: creación de credenciales independientes con permisos idénticos a los del token original
- Persistencia: la plataforma no implementa una lógica jerárquica de revocación: los tokens hijos permanecen activos tras la revocación del token padre
En el material disponible no se proporciona una puntuación CVSS para CVE-2026-97406. El rango de versiones afectadas tampoco se ha determinado.
Escenario de escalada hasta la toma de control completa del instancia
Según CERT/CC, la vulnerabilidad es especialmente peligrosa cuando se ve comprometido un token perteneciente al propietario de la cuenta de Xerj. En ese caso se describe la siguiente cadena de ataque: el atacante crea un token hijo con permisos administrativos completos, luego lo utiliza para emitir una invitación a una nueva cuenta, activa la invitación en su propio navegador y registra un passkey totalmente independiente bajo su control. El resultado es un acceso persistente al instancia de Xerj y a sus índices de datos que no puede eliminarse revocando el token comprometido inicialmente.
El boletín califica esto como un pleno bypass de los controles multifactor, ya que el requisito de passkey —elemento central de la protección— queda completamente neutralizado.
Evaluación del impacto
Xerj se posiciona como un motor de búsqueda para agentes de IA que indexa datos locales. La compromisión de un instancia potencialmente abre el acceso a todos los datos indexados, incluido código fuente, documentación y otros materiales que utilizan los agentes de IA en su trabajo. Para las organizaciones que han integrado Xerj en sus flujos de trabajo de desarrollo con uso de IA, las consecuencias pueden incluir la filtración de propiedad intelectual y la compromisión de la cadena de suministro de datos para los modelos de IA.
En el material disponible no se han encontrado indicios de explotación activa de la vulnerabilidad en ataques reales. Tampoco hay atribución a grupos o campañas concretas.
Estado de corrección y recomendaciones
CERT/CC informa de que no ha sido posible contactar con el desarrollador para una divulgación coordinada, y que a la fecha de publicación del boletín (20 de octubre de 2026) no existe un parche oficial. En la página de lanzamientos del proyecto se ha publicado la versión v1.0.0-rc.96, pero en la descripción de la versión no se menciona la corrección de CVE-2026-97406. Esto no excluye la existencia de una corrección, pero tampoco la confirma.
Hasta que aparezca un parche confirmado se recomienda:
- Restringir el acceso de red al API de consola (
/_xerj-console/api/v1/*): permitir conexiones solo desde redes de confianza o cerrar por completo el endpoint si la consola no se utiliza - Auditar todos los tokens de API emitidos: identificar los tokens creados a través del API (y no mediante una sesión con passkey) y revocar tanto estos como todas las credenciales hijas que potencialmente hayan generado
- Revisar el historial de invitaciones y registro de passkey: cualquier invitación o registro de un nuevo passkey que haya tenido lugar tras la creación de un token de API debe considerarse sospechoso
- Configurar monitorización: supervisar los accesos al endpoint de creación de tokens y las operaciones posteriores de emisión de invitaciones o registro de passkey, ya que esta secuencia de acciones es característica de la cadena de ataque descrita
- Seguir las actualizaciones en el repositorio oficial de Xerj y no considerar ninguna actualización como corrección de CVE-2026-97406 mientras esto no se confirme explícitamente en las notas de la versión
Es fundamental entender que la simple revocación del token comprometido no es una medida de respuesta suficiente. Debido a la ausencia de una lógica jerárquica de revocación, todos los tokens hijos creados antes del momento de la detección siguen siendo válidos. La respuesta al incidente debe incluir una rotación completa de todos los tokens del instancia y una revisión de los passkey registrados.
