El endpoint de ajustes de Cognee permitía que cualquier cuenta reapuntara el proveedor LLM de toda la instancia
Un aviso de julio de 2026 revela que la plataforma de «memoria IA» Cognee exponía una ruta de ajustes sin control de administrador: una cuenta autorregistrada podía redirigir todas las llamadas LLM de la instancia a un endpoint del atacante y extraer los datos de todos los usuarios.
En resumen Una vulnerabilidad divulgada el 7 de julio de 2026 en Cognee — una popular plataforma open source de «memoria IA» para agentes — muestra un endpoint de ajustes que cambiaba la configuración del proveedor LLM en toda la instancia sin ningún control de administrador o superusuario. Cualquier cuenta autorregistrada podía apuntar todas las llamadas al modelo del servidor a un endpoint bajo su control, convirtiendo el motor de memoria en un canal de exfiltración para todos los usuarios. Afecta a las versiones anteriores a la 1.2.0; la corrección está en la 1.2.0. Este es un análisis de autorización deficiente, no un exploit.
¿Qué es esto?
Cognee es una capa de memoria open source para agentes LLM: se hace .add() de documentos, se .cognify() en un grafo de conocimiento con embeddings y se .search() sobre el resultado. Combina un grafo, un almacén de vectores y metadatos relacionales en un único servicio de «memoria persistente». Con licencia Apache-2.0, supera holgadamente las diez mil estrellas en GitHub y se despliega tanto autoalojada como en entornos multiusuario.
El fallo, publicado en el ecosistema CVE el 7 de julio de 2026 y documentado en un aviso de VulnCheck y en el seguimiento de incidencias de Cognee, es una comprobación de autorización ausente en la API de ajustes. La ruta que escribe la configuración del proveedor LLM del servidor no realizaba ninguna verificación de administrador o superusuario, de modo que cualquier cuenta — incluida una creada por el atacante mediante el autorregistro abierto — podía sobrescribirla. Está calificado como CVSS 9.1 (crítico), con alto impacto en confidencialidad e integridad, y la debilidad se clasifica como falta de autenticación para una función crítica.
Cómo funciona
Aquí no hay ningún payload exótico. El problema es quién tiene permiso para invocar una función privilegiada, y la respuesta era «cualquiera». La secuencia es así:
Secuestro del proveedor a nivel de instancia (versiones vulnerables)
--------------------------------------------------------------------
1. El atacante se autorregistra una cuenta normal en la instancia de Cognee
2. El atacante llama al endpoint de ajustes para escribir la config del proveedor LLM
--> no se realiza ningún control de administrador / superusuario
3. La config apunta la URL base / el proveedor a un endpoint controlado por el atacante
4. Un singleton a nivel de proceso cachea esa config para todo el servidor
5. Los .cognify() y .search() de cada usuario enrutan ahora prompts + documentos
a través del endpoint del atacante
El amplificador crítico es el paso 4. Como la configuración vive en un caché singleton a nivel de proceso, una sola escritura no afecta solo a la sesión del atacante: cambia el proveedor de toda la instancia. A partir de ahí, prompts, documentos subidos, entidades extraídas y contenido del grafo de conocimiento de cada usuario transitan por una infraestructura que controla el atacante. Una brecha de confidencialidad (leer los datos de todos) y una de integridad (devolver salidas del modelo manipuladas a la memoria compartida) ocurren a la vez, sin privilegios ni interacción del usuario.
Por qué importa
Las plataformas de «memoria» de agentes se están convirtiendo en infraestructura compartida de confianza: los equipos vuelcan en ellas documentos internos, historiales de conversación y entidades extraídas precisamente para que varios agentes y usuarios consulten un cerebro común. Eso convierte la configuración del proveedor en un ajuste joya de la corona: decide adónde se envía cada prompt y cada documento. Tratar «cambiar el endpoint del modelo» como una acción de usuario ordinaria, en lugar de como una acción administrativa privilegiada, hace colapsar por completo la frontera entre inquilinos.
La lección más amplia no es específica de un proyecto. A medida que el instrumental LLM se apresura a añadir páginas de ajustes, paneles de administración y registro autoservicio, reaparece el fallo clásico de las aplicaciones web — un endpoint que modifica el estado sin comprobar nunca el rol de quien llama — con un radio de impacto más pesado, porque un único campo escribible controla ahora el enrutamiento de todo el tráfico de IA de la máquina. Un singleton global que cualquier llamante autenticado puede reescribir es control de acceso roto (CWE-306 / autorización ausente a nivel de función), el mismo fallo del que el OWASP Top 10 lleva años advirtiendo, disfrazado de IA.
Defensas
- Actualice a Cognee 1.2.0 o posterior. La corrección añade el control de autorización a la ruta de ajustes; si se autoaloja, parchee primero y revise en las notas de versión cualquier configuración que deba reestablecer.
- Restrinja el registro y la exposición de red. No deje el autorregistro abierto en una instancia de memoria accesible desde Internet. Colóquela tras un ingreso autenticado y limite quién puede alcanzar la API.
- Imponga autorización a nivel de función en cada ruta que modifique el estado. Todo endpoint que escriba configuración global o de proveedor debe verificar un rol de administrador/superusuario en el servidor — nunca confíe en que la interfaz oculte el botón. Audite su propio instrumental de IA en busca de rutas de ajustes que lo omitan.
- Trate la config de proveedor/URL base como un secreto privilegiado. Fije los endpoints de proveedor permitidos mediante el entorno o la config de despliegue, en lugar de un campo escribible en tiempo de ejecución, y alerte ante cualquier cambio de la URL base del modelo.
- Vigile el egreso del servicio de memoria. Que las llamadas al modelo salgan de repente hacia un host inesperado es un indicador de alta señal; monitorice y ponga en lista blanca los destinos salientes de los componentes de inferencia y memoria.
Status
| Elemento | Referencia | Fecha | Notas |
|---|---|---|---|
| Aviso | VulnCheck — CVE-2026-58473 | 2026-07-07 | Sobrescritura no autorizada de la config LLM vía la API de ajustes |
| Clase de debilidad | CWE-306 | — | Autenticación / autorización ausente para una función crítica |
| Severidad | CVSS 3.1 base 9.1 (crítico) | — | AV:N/AC:L/PR:N/UI:N — alto impacto en confidencialidad e integridad |
| Versiones afectadas | Cognee | < 1.2.0 | Despliegues multiusuario / autoalojados con autorregistro |
| Versión corregida | Cognee 1.2.0 | 2026-07 | Control de administrador añadido en la ruta de ajustes (commit d10b1b7) |
El encuadre honesto no es «hackearon una memoria de IA». Es que un servicio de memoria compartida enruta los datos de todos a través de un único endpoint configurable, y sigue vigente la regla más antigua del control de acceso: una función que cambia lo que hace todo el servidor debe comprobar que quien la invoca tiene permiso para cambiarlo.
Sources
- → https://nvd.nist.gov/vuln/detail/CVE-2026-58473
- → https://github.com/topoteretes/cognee/releases/tag/v1.2.0
- → https://github.com/topoteretes/cognee/issues/3084
- → https://www.vulncheck.com/advisories/cognee-unauthorized-llm-configuration-overwrite-via-api-v1-settings
- → https://github.com/topoteretes/cognee/commit/d10b1b77e2157c6238fd4d1acb1923a048991699