Alerta de seguridad: CVE-2026-45829 expone ChromaDB a ejecución remota de código sin autenticación

Un fallo crítico en la API Python de ChromaDB —la popular base de vectores usada para recuperación durante inferencia de LLM— permite a atacantes no autenticados ejecutar código arbitrario en servidores expuestos. La vulnerabilidad ha sido registrada como CVE-2026-45829 y fue reportada por los investigadores de HiddenLayer; su análisis técnico señala que la comprobación de autenticación ocurre demasiado tarde en el flujo, después de que el servidor ya ha descargado y ejecutado código remoto solicitado por un atacante.

El problema radica en un punto de la API marcado como “autenticado” donde un payload puede inyectar parámetros de modelo que fuerzan a ChromaDB a cargar artefactos remotos (por ejemplo, desde Hugging Face) con mecanismos que permiten ejecutar código remoto, como usar trust_remote_code. Según HiddenLayer, la función que valida credenciales se ejecuta tras la carga del modelo, lo que significa que la petición maliciosa puede provocar ejecución local incluso cuando el servidor responde con un error 500 posteriormente. El informe técnico con evidencias está disponible en el análisis de HiddenLayer: https://www.hiddenlayer.com/research/chromatoast-served-pre-auth.

ChromaDB es un proyecto de código abierto con una distribución Python ampliamente usada; la versión en PyPI acumula millones de descargas mensuales. El código vulnerable afecta a la implementación del servidor API en Python y, según los investigadores, el bug se introdujo en una versión 1.x y permaneció sin parchear al menos hasta la 1.5.8. Los mantenedores publicaron una versión 1.5.9 después del reporte, pero al momento del descubrimiento no estaba claro si los cambios corrigen por completo el vector explotable. La página oficial del proyecto sirve como referencia: https://github.com/chroma-core/chroma y la estadística de descargas puede consultarse en PyPI: https://pypistats.org/packages/chromadb.

El alcance operativo es relevante: los despliegues locales que no exponen el servidor Python por HTTP y los que usan el frontend en Rust no estarían afectados. Sin embargo, los escaneos de exposición en Internet realizados por los investigadores sugieren que una proporción elevada de instancias accesibles están en versiones vulnerables; en entornos de producción donde el API está accesible desde la red pública, el riesgo de explotación remota es real y serio.

Desde el punto de vista de gestión de riesgo, esta vulnerabilidad ejemplifica dos problemas tradicionales en aplicaciones ML/AI: la ejecución de código procedente de modelos compartidos (trust_remote_code) y la fragilidad de los flujos de autorización cuando el orden de operaciones permite que acciones sensibles ocurran antes de las comprobaciones de seguridad. La lección es clara: cargar artefactos sin validación previa es equivalente a aceptar ejecución remota no confiable.

Si administras instancias de ChromaDB, prioriza inmediatamente estas acciones: evita exponer la API Python al tráfico público; si necesitas acceso remoto, encapsula el servicio detrás de una VPN o túnel autenticado y limita el acceso por IP. Considera migrar al frontend en Rust para despliegues que requieran exposición externa hasta que exista confirmación de un parche auditado. Restringe el puerto de la API mediante reglas de firewall y políticas de red y deshabilita cualquier opción que haga trust_remote_code en tiempo de ejecución.

Además de mitigaciones de acceso, añade controles de detección e investigación: busca en tus registros patrones inusuales como descargas desde dominios de modelos (p. ej. huggingface.co), errores 500 correlacionados con fetch de modelos, picos de CPU o procesos nuevos que ejecuten código no esperado y creación de archivos de modelo en rutas no usuales. Si tu organización usa escaneo de seguridad interno, prioriza comprobaciones para tráfico saliente hacia repositorios de modelos públicos y configura alertas para operaciones de carga/ejecución de artefactos.

Para reducir la superficie a largo plazo, incorpora validación previa de artefactos ML: escanea paquetes de modelos, evita trust_remote_code salvo en entornos controlados y firma/verifica modelos internos. Aplica el principio de menor privilegio al proceso que carga y ejecuta modelos (entornos contenedorizados, cuentas con permisos limitados) y adopta controles de integridad y bloqueo de ejecución que impidan que artefactos remotos ejecuten comandos del sistema.

Si sospechas que tu instancia pudo haber sido comprometida, trátala como incidente: aísla el host, preserva logs y artefactos de modelo para análisis forense, rota credenciales que podrían haber quedado expuestas y revisa la integridad de tus datos y modelos. Comunica el hallazgo a equipos de seguridad y, si se confirma explotación, considera notificar a clientes afectados conforme a tus obligaciones regulatorias.

Finalmente, sigue de cerca la evolución del caso y aplica el parche oficial solo cuando la comunidad o los mantenedores publiquen una corrección verificada. Mantente informado en las fuentes públicas del incidente y en la ficha de la vulnerabilidad: https://nvd.nist.gov/vuln/detail/CVE-2026-45829. La combinación de mitigaciones de red, rechazo de trust_remote_code, auditoría de modelos y prácticas de despliegue seguras es la mejor defensa mientras persista la incertidumbre sobre la remediación completa.