MaxKB: la ruta de despacho del agente permite que un usuario al que se le ha denegado una herramienta aún pueda llamarla y leer sus credenciales.

MaxKB, el asistente de IA empresarial de código abierto mantenido por 1Panel-dev, incluye una lista de permisos por usuario y por herramienta para que un administrador pueda conceder a un miembro del espacio de trabajo una herramienta y denegarle otra. Según el aviso de seguridad publicado el 2 de septiembre de 2026, esa denegación se aplicaba a las rutas propias de la herramienta, pero no a la ruta que utiliza un agente o flujo de trabajo para llamar a la misma herramienta. Un miembro del espacio de trabajo con el rol más bajo podía indicar el identificador de una herramienta denegada al crear un flujo de trabajo, ejecutar el flujo de trabajo y recibir no solo la salida de la herramienta, sino también las credenciales que MaxKB descifra en el servidor para ejecutarla. Las versiones 2.0.0 a 2.9.2 están afectadas, y el aviso no indicó ninguna versión corregida. Este registro —la elusión de autorización en el despacho de herramientas de MaxKB— es una entrada en el OrcaRouter AI Incident Archive, que contiene el conjunto completo de registros y las entradas adyacentes a este incidente.

Lo que hace que el caso merezca una lectura atenta no es la puntuación. Es que el producto ya tenía la verificación correcta, la aplicaba en la puerta obvia y dejaba sin vigilancia una segunda puerta a la misma capacidad. El aviso, GHSA-383v-fx78-pphm, fue escrito por el investigador que lo encontró y publicado a través del sistema de avisos de GitHub a las 07:43 UTC del 2 de septiembre de 2026, acreditando a Matteo Panzeri (@matte1782). El registro CVE, CVE-2026-77516, se publicó después, el 21 de septiembre de 2026.

Lo que establece el aviso

El modelo por herramienta de MaxKB es WorkspaceUserResourcePermission, descrito en el aviso como una lista de permitidos con denegación predeterminada que se resuelve en el momento de la solicitud. Las rutas dedicadas de herramientas lo aplican. El aviso enumera la aplicación en apps/tools/views/tool.py, donde Operate.put, Operate.get, Debug.post, Export.get y Delete llevan cada uno una comprobación de permiso de vista frente al permiso de herramienta del espacio de trabajo del llamador. Debug.post es la ruta más cercana a simplemente ejecutar una herramienta, y está restringida.

La ruta de envío del agente y del flujo de trabajo no vuelve a aplicar esa comprobación. El aviso señala tres lugares distintos en los que esta falta. En apps/application/serializers/application.py, el serializador de la aplicación vincula tool_ids, skill_tool_ids y mcp_tool_ids directamente desde la entrada de la solicitud sin autorización por herramienta; y el aviso señala que la asimetría es visible en el mismo archivo, porque knowledge_id_list se valida contra las bases de conocimiento accesibles del usuario unas líneas más abajo, mientras que las herramientas no. En apps/common/utils/shared_resource_auth.py, filter_authorized_ids deja pasar todas las herramientas del propio espacio de trabajo del solicitante de forma incondicional; la compuerta entre espacios de trabajo en la que se apoya es un hook exclusivo de la edición enterprise que no está presente en la edición community, y nunca consulta WorkspaceUserResourcePermission. Y en el punto final, apps/application/flow/step_node/tool_lib_node/impl/base_tool_lib_node.py ejecuta el código almacenado de la herramienta con sus init_params descifrados por rsa_long_decrypt bajo la identidad de la aplicación, sin ninguna comprobación de concesión por herramienta.

El aviso califica el resultado como una ejecución de tipo confused deputy: el despacho del flujo de trabajo ejecuta una herramienta, y sus secretos almacenados, a los que el mismo llamador tiene denegado el acceso en las rutas propias de la herramienta. La exposición de credenciales es la parte que va más allá del uso no autorizado ordinario de una herramienta. Los init_params de una herramienta se cifran en reposo con RSA y se descifran en el servidor solo en el momento de la ejecución, de modo que un llamador que desencadena esa ejecución recibe valores que nunca tuvo y que no podría haber proporcionado.

La demostración, en las cifras del propio investigador

El aviso informa de una confirmación dinámica en v2.9.2, ejecutada desde la imagen oficial todo en uno, 1panel/maxkb:v2.9.2. La configuración era un espacio de trabajo, un administrador y un segundo miembro con el rol USER. El administrador creó la Herramienta A y la Herramienta B, colocó un secreto aleatorio nuevo en la Herramienta B, en sus init_params, y escribió el cuerpo de la Herramienta B para que devolviera ese secreto al ejecutarse. Luego se concedió al miembro un permiso por herramienta solo para la Herramienta A, y el aviso indica que el estado de cero concesiones para la Herramienta B se volvió a comprobar en la base de datos después de la ejecución.

La mitad denegada de la prueba devolvió lo que promete el producto. Como miembro, la ruta de depuración para Tool B respondió 403, la ruta de actualización respondió 403, la ruta de exportación respondió 403 y la Tool A concedida devolvió 200 como comprobación de sanidad. La mitad de bypass vinculó entonces Tool B en una aplicación de flujo de trabajo mediante un nodo de biblioteca de herramientas —la vinculación se aceptó con HTTP 200 y sin comprobación por herramienta— y ejecutar el flujo de trabajo devolvió HTTP 200 con un cuerpo que contenía el nombre de la herramienta, el secreto centinela y la lista de claves ["api_key"].

El aviso indica que el secreto apareció en tres capas: en la respuesta de la API del flujo de trabajo, en un registro de ejecución de herramienta con estado SUCCESS y en la fila de la base de datos donde el init_params de Tool B figura como un texto cifrado RSA de 344 bytes — lo que, según sostiene el investigador, demuestra que el valor se descifró del lado del servidor bajo la identidad de la aplicación en lugar de haber sido proporcionado por el llamador. El mismo miembro al que se le denegó el acceso en la ruta de ejecución de la herramienta obtuvo el secreto descifrado de la herramienta al vincularlo en un flujo de trabajo.

Una puntuación publicada, otra más alta alegada

La puntuación asociada a CVE-2026-77516 es CVSS 3.1 5.4, Media, con el vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N. El registro de NVD muestra que esa puntuación procede del feed de avisos de GitHub y no del propio análisis de NVD, y la entrada tiene el estado Deferred, lo que significa que NVD no la ha enriquecido. La clasificación del propio archivo sigue esa puntuación publicada: severidad media, sin daños reales registrados.

La propia sección de impacto del aviso sostiene que debería ser mayor. Indica una gravedad de 7,1, Alta, en un vector que eleva el impacto sobre la confidencialidad a alto, y señala que la cifra asciende a 8,1 cuando la herramienta despachada realiza escrituras privilegiadas bajo la identidad de la aplicación. Se trata de un desacuerdo sobre cómo contabilizar la exposición de credenciales, no sobre si la omisión de autenticación existe: el mismo documento demuestra la falla y sostiene que se le está restando peso. Nada en el registro público resuelve cuál de las cifras es correcta, y la calificación media del archivo sigue la puntuación publicada del CVE en lugar del argumento del aviso.

Constan en el registro dos evaluaciones adicionales. Los puntos de decisión SSVC de CISA, añadidos a la entrada del NVD el 28 de septiembre de 2026, registran la explotación como «poc», automatizable como «no» y el impacto técnico como «partial» —el valor «poc» refleja que existe una prueba de concepto, lo cual es cierto, en el propio aviso; no es una conclusión de explotación en la naturaleza. El modelo EPSS de FIRST situó la probabilidad de explotación en los próximos 30 días en 0,242 %, en el percentil 15,2, en la estimación fechada el 27 de octubre de 2026.

Una corrección anterior al aviso, y ninguna dentro del rango afectado.

La tabla de versiones del aviso indica que las versiones afectadas son de la 2.0.0 a la 2.9.2, que no hay versiones parcheadas y que, según su texto, no hay ninguna versión corregida disponible en el momento de la revisión; además, añade que una corrección en una versión etiquetada permitiría anclar un CVE a ella. El repositorio del proveedor cuenta una historia ligeramente distinta, y la diferencia importa a cualquiera que esté decidiendo qué ejecutar.

En el repositorio de MaxKB, las funciones que cierran la ruta de despacho — validate_bound_tool_permissions y get_authorized_tool_ids en apps/application/serializers/application.py — están ausentes de la etiqueta v2.9.2 y de v2.10.2-lts, v2.10.3-lts y v2.10.4-lts, y presentes desde v2.10.5-lts en adelante. Esa versión se publicó el 6 de agosto de 2026, cuatro semanas antes del aviso. La misma etiqueta añade a base_tool_lib_node.py una comprobación de herramientas por usuario, basada en WorkspaceUserResourcePermission, y añade a shared_resource_auth.py un filtro que tiene en cuenta al usuario — es decir, implementa, a grandes rasgos, los tres pasos de remediación que el aviso recomienda posteriormente.

Nadie ha declarado públicamente esa conexión. Las notas de la versión v2.10.5-lts no mencionan una corrección de permisos de herramientas; enumeran cuatro elementos de seguridad no relacionados y un conjunto de trabajo de funciones y errores. El aviso no nombra la 2.10.5, y su rango afectado simplemente termina en la 2.9.2, la última versión de la línea 2.9. El historial de versiones no muestra ningún parche de la 2.9.x posterior al aviso, por lo que un despliegue en la 2.9.2 no tiene ninguna compilación corregida dentro de su propia línea. La versión actual es v2.10.8-lts, publicada el 22 de octubre de 2026, cuyas notas describen correcciones de X-Pack a la autorización de herramientas compartidas, en lugar de algo en la ruta de despacho de la edición comunitaria.

Qué no está establecido

Hay tres cosas que conviene separar de la demostración. En primer lugar, no existe ningún informe público de que el bypass se haya utilizado contra nadie. El registro es una vulnerabilidad que se encontró, no una intrusión que se haya investigado; no tiene víctima, ni actor atribuido ni daño, y la prueba de concepto del aviso fue ejecutada por el investigador en un entorno de trabajo controlado. En segundo lugar, ninguna organización de noticias, regulador ni segundo equipo de investigación parece haber analizado la falla: la cobertura existente se limita a bases de datos y agregadores de vulnerabilidades —VulDB, la base de datos de Rapid7, Armis, SOCRadar y openCVE, entre otros—, que enumeran el CVE y recogen la descripción del aviso, y ninguno de los cuales ofrece una evaluación independiente del código. Por lo tanto, el mecanismo tal como se describe aquí se basa en un único aviso y en el código fuente del propio proveedor. En tercer lugar, no existe ninguna cifra sobre cuántos despliegues de MaxKB se encuentran en el rango afectado, y ni el proveedor ni el investigador han publicado una.

La población en riesgo es reducida, pero no es trivial de contabilizar: las instalaciones de MaxKB de edición comunitaria autoalojadas en las versiones 2.0.0 a 2.9.2 que tienen más de un miembro en el espacio de trabajo, en las que un administrador ha utilizado permisos por herramienta para denegar una herramienta que contiene credenciales. La falla no es de ejecución remota de código y requiere una cuenta válida con bajos privilegios, por lo que el impacto en la confidencialidad es lo que determina la puntuación, y no la ruta de ataque. Lo que obtiene un atacante está acotado por lo que contienen las herramientas denegadas —claves de API, tokens y todo aquello a lo que estos dan acceso—, que es también la razón por la que los autores del aviso sostienen que el impacto es mayor de lo que implica una calificación baja de confidencialidad.

Qué puede hacer un operador

La remediación del aviso está dirigida a los mantenedores y no a los operadores, y sus tres pasos se corresponden con el código que apareció en v2.10.5-lts: aplicar la concesión por herramienta antes de ejecutar una herramienta en las implementaciones de la biblioteca de herramientas y del nodo de herramienta, validar todos los tool_ids, skill_tool_ids y mcp_tool_ids en el momento del enlace tal como ya se hace con knowledge_id_list, y hacer que filter_authorized_ids consulte la concesión por herramienta en lugar de basarse únicamente en la pertenencia al espacio de trabajo.

Para un equipo que ejecuta una compilación afectada, los pasos prácticos que se derivan de la propia descripción del aviso son estos.

• Considera cada secreto almacenado en los init_params de una herramienta en una implementación afectada como accesible para cualquier miembro del espacio de trabajo, incluido el rol más bajo, y rota esas credenciales en lugar de asumir que la denegación por herramienta las protegió.

• Audite la membresía del espacio de trabajo. El bypass requiere una cuenta autenticada en el espacio de trabajo, por lo que eliminar a los miembros inactivos o que no sean de confianza reduce la exposición incluso cuando el código no se puede parchear.

• Revisar qué flujos de trabajo y agentes vinculan herramientas que contienen credenciales, ya que esa vinculación es el paso que el aviso indica que se acepta sin una verificación por herramienta.

• Si va a actualizar, tenga en cuenta que la comprobación por usuario aparece en el repositorio a partir de la v2.10.5-lts y que el aviso no designa ninguna versión como la que corrige el problema: quien confíe en la actualización estará confiando en el código fuente etiquetado, no en una declaración de parche del proveedor.

Nada de esto hace que el fallo sea dramático. Lo hace ordinario de una manera concreta e instructiva: el modelo de autorización se diseñó correctamente, se documentó correctamente y se aplicó en las rutas que alguien se acordó de proteger. La ruta de despacho fue escrita por personas que pensaban en lo que un flujo de trabajo debería poder hacer, no en quién lo estaba solicitando; y en una plataforma de agentes, esa es la ruta que toman la mayoría de las solicitudes.

La lección del registro es estructural y no numérica. Un permiso por recurso es tan sólido como su punto de entrada menos protegido, y una plataforma de agentes acumula puntos de entrada rápidamente: una ruta de depuración, una ruta de exportación, un nodo de flujo de trabajo, un activador de chat. MaxKB tenía la lista de concesiones y la verificación; lo que le faltaba, para la línea de 2.0 a 2.9, era la costumbre de hacer la misma pregunta en cada puerta.