Por Canuto  

La versión 0.10.9.54 de MentisDB corrige, según el proyecto, una falla que permitía a ciertos tokens con alcance limitado operar sobre otras cadenas a través de un punto final heredado de MCP. La actualización también aborda un consumo de memoria elevado y restablece el funcionamiento del reordenamiento de resultados.
***

  • Según MentisDB, la vulnerabilidad afectaba a versiones hasta la 0.10.8.53 cuando el acceso con bearer token estaba activo y el token tenía alcance de cadena.
  • En una reproducción reportada por el proyecto con 13 cadenas y 2.704 pensamientos, el uso máximo de memoria bajó de más de 6 GB a cerca de 1,7 GB.
  • Las pruebas reportadas por MentisDB muestran que el reordenamiento mejoró los resultados en LoCoMo y LongMemEval.

MentisDB publicó la versión 0.10.9.54 y recomendó actualizar a quienes usan autenticación mediante bearer token. Según las notas del proyecto, la revisión corrige una falla de autorización en una ruta heredada de MCP que podía permitir que tokens limitados a ciertas cadenas actuaran fuera de ese alcance. La actualización también aborda un problema de consumo de memoria y repara el reordenamiento de resultados de búsqueda.

La versión también incorpora ajustes en el panel de control, la entrega de webhooks, la restauración de respaldos y la durabilidad de los registros. Según las notas de lanzamiento de MentisDB, el trabajo respondió a una auditoría del servidor, la interfaz, el almacenamiento, la búsqueda, las dependencias y la integración continua.

El problema de autorización estaba en una ruta heredada de MCP

MentisDB permite crear bearer tokens limitados a una o varias cadenas, una configuración que restringe la memoria disponible para cada agente. Sin embargo, el proyecto indicó que la ruta heredada de MCP /tools/execute no aplicaba correctamente esos límites en las versiones hasta la 0.10.8.53, siempre que estuviera habilitado el acceso con bearer token.

De acuerdo con la descripción de la vulnerabilidad publicada por MentisDB, en esas condiciones un token con alcance de cadena podía leer o modificar otras cadenas, invocar herramientas reservadas para permisos globales y fusionar o eliminar cadenas que no tenía autorizadas. También podía llamar a herramientas capaces de enumerar todas las cadenas y revelar sus rutas de almacenamiento, una exposición que iba más allá de la lectura de datos y alcanzaba operaciones administrativas.

El proyecto afirma que la corrección central consiste en hacer que la autorización revise los mismos campos que consume el ejecutor de cada operación. La versión nueva aplica una tabla compartida de autorización tanto a REST como a MCP, con el propósito de evitar que una diferencia entre interfaces vuelva a abrir una ruta de acceso no prevista.

Según las notas, requieren un token global acciones como enumerar cadenas, administrar webhooks, consultar agentes entre cadenas, modificar habilidades y vaciar datos mediante funciones de administrador. MentisDB también señala que ahora recorta y valida las claves usadas para fusionar o ramificar cadenas antes de comprobar los permisos, de modo que una clave con espacios añadidos no pueda apuntar a otra cadena.

Más controles para webhooks, panel y respaldos

La auditoría también llevó, según MentisDB, a restringir los destinos aceptados por los webhooks para bloquear direcciones privadas, de loopback y de enlace local, además de casos específicos de IPv4 traducido, NAT64 local y Teredo. El sistema vuelve a comprobar el DNS al momento de entregar cada solicitud, no sigue redireccionamientos y retira los webhooks mediante un disyuntor de circuito cuando corresponde.

En el panel de control, la actualización soluciona un XSS almacenado que, según las notas del proyecto, podía activarse mediante claves manipuladas. También añade protecciones CSRF tanto a las llamadas que modifican el estado como al formulario de inicio de sesión, y una lista blanca de encabezados Host para mitigar ataques de DNS rebinding. La variable MENTISDB_DASHBOARD_ALLOWED_HOSTS permite agregar nombres aprobados.

La restauración de respaldos ahora limita el manifiesto, la cantidad de archivos y los tamaños declarados, medidas que MentisDB presenta como destinadas a reducir el riesgo de procesar cargas inesperadamente grandes. A su vez, los archivos que contienen secretos se escriben con permisos 0600, un ajuste que restringe su lectura a los usuarios autorizados del sistema.

La actualización incluye cambios para quienes integran herramientas con MCP y para quienes ponen un proxy inverso delante del panel. Según las notas, las cargas que mezclen los campos tool y parameters con name y arguments ahora reciben una respuesta 400. Los proxies deben conservar el Host original o reenviar un nombre aprobado, mientras que los scripts que llaman a la API del panel deben añadir X-MentisDB-Dashboard: 1.

La corrección del consumo de memoria reduce el pico observado

El cambio también responde al issue #23, reportado por takver, quien describió un demonio que llegó a consumir 28,8 GiB después de actualizar un directorio de datos con numerosas cadenas y terminó eliminado por el sistema ante una situación de falta de memoria. Según MentisDB, una reproducción con 13 cadenas y 2.704 pensamientos superó un límite de 6 GB y permitió identificar dos causas relacionadas.

El proyecto atribuye el consumo a que cada cadena cargaba su propia sesión de FastEmbed con ONNX, de alrededor de 100 MB, y no la liberaba. Además, al abrir una cadena sin un sidecar de vectores actualizado, el sistema intentaba incrustar todo su historial en un lote sin límite dentro de la ruta de la solicitud, un diseño que podía elevar el consumo durante el inicio.

MentisDB afirma que la nueva versión comparte un modelo por proceso y limita la inferencia a fragmentos pequeños. Cuando faltan sidecars, un único trabajador en segundo plano los reconstruye mientras la cadena continúa ofreciendo resultados léxicos y de grafos. En la misma reproducción, el pico de memoria quedó en aproximadamente 1,7 GB, según el proyecto.

MentisDB trasladó la caché del modelo desde el directorio de trabajo hasta <MENTISDB_DIR>/.fastembed_cache y añadió la opción MENTISDB_EMBEDDINGS=off|local-text|fastembed. Esa configuración permite desactivar ONNX por completo o escoger entre las alternativas indicadas, una posibilidad útil para instalaciones que priorizan limitar recursos locales.

El reordenamiento vuelve a mejorar la recuperación

La opción enable_reranking=true presentaba, según el proyecto, un fallo silencioso: el total bruto de Reciprocal Rank Fusion, cercano a 0,05, reemplazaba la puntuación aditiva en lugar de sumarse como un componente complementario. Como resultado, la métrica LoCoMo R@5 había caído a 3,6%. La versión nueva modifica la fórmula para que RRF funcione como un bono de consenso escalado.

En las cifras reportadas por MentisDB para LoCoMo, el modo predeterminado pasó de R@5/R@10 de 63,8/72,7 a 63,9/73,5. Con reordenamiento, las métricas subieron desde 3,6/5,9 hasta 66,0/74,1. El contraste refleja la corrección del comportamiento anterior, aunque por sí solo no permite anticipar los resultados de cada instalación o tipo de consulta.

Las pruebas de LongMemEval también registraron avances, según la comparación publicada por el proyecto: el modo predeterminado pasó de R@5/R@10/R@20 de 66,8/72,0/78,2 a 68,0/72,8/78,8. Para el modo con reordenamiento, la medición R@5 pasó de 2,8 a 68,6.

El tesauro ahora se indexa por stem para que pueda ampliar consultas con palabras flexionadas, pero su peso se redujo después de que las pruebas mostraran que una expansión más frecuente desplazaba coincidencias literales. MentisDB también informó un aumento en la velocidad de consulta: de 206 a 384 consultas por segundo en LoCoMo y de 159 a 385 en LongMemEval.

Registros más durables y pasos para actualizar

La versión 0.10.9.54 mejora además, de acuerdo con las notas del proyecto, la recuperación de registros dañados: conserva un registro final incompleto y lo trunca antes del siguiente adjunto, mientras que la corrupción en medio de un archivo provoca un error de apertura en vez de descartar registros sin aviso. Los registros de datos se escriben de forma atómica y la superposición de borde implícito se pone al día después de un fallo.

Quienes necesiten durabilidad ante una pérdida de energía pueden activar MENTISDB_FSYNC=1, opción que solicita una sincronización de disco por cada compromiso de grupo. El proyecto también reportó una reducción del costo por adjunto, de 6,3-7,8 milisegundos a 1,4 milisegundos, y tiempos de ingestión menores en sus pruebas de referencia, realizadas en un equipo con carga variable.

En LoCoMo, el tiempo de ingestión bajó de 171,5 a 75,1 segundos, mientras que en LongMemEval pasó de 725,6 a 184,2 segundos, según las pruebas indicadas por MentisDB. No son una garantía de rendimiento uniforme: el propio reporte advierte que el equipo de prueba tenía una carga variable.

Para instalar la versión, el proyecto indica ejecutar cargo install mentisdb --locked --force y reiniciar el demonio. Entre las notas operativas, señala que las lecturas de una cadena desconocida ahora devuelven 404 y que primero se debe llamar a bootstrap. También advierte que las cadenas grandes pueden ofrecer brevemente resultados clasificados solo de forma léxica mientras se reconstruyen los sidecars.

Las notas agregan que volvió el binario para Intel en macOS, compilado sin embeddings locales, y que la caché de FastEmbed utiliza ahora una ubicación específica dentro del directorio de MentisDB. Para los usuarios con tokens de alcance de cadena, el proyecto recomienda actualizar y reiniciar el servicio, porque la falla de autorización descrita afecta a las versiones anteriores cuando el acceso mediante bearer token está habilitado.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados