Bleeding Llama: la vulnerabilidad crítica de Ollama (CVE-2026-7482) que expone memoria y secretos

Investigadores en ciberseguridad han revelado una vulnerabilidad crítica en Ollama —el framework que permite ejecutar modelos de lenguaje de gran tamaño (LLM) localmente— que puede exponer la memoria completa del proceso y, por tanto, secretos sensibles. Catalogada como CVE-2026-7482 y apodada "Bleeding Llama", la falla es un out-of-bounds read en el cargador de modelos GGUF y ha recibido una puntuación CVSS alta (9.1), lo que indica un riesgo real y explotable en entornos con instancias expuestas.

En términos técnicos, el problema surge cuando el servidor acepta un archivo GGUF malformado mediante el endpoint de creación de modelos; al procesarlo, una función que utiliza la ruta peligrosa del paquete unsafe en Go lee más allá del búfer asignado, lo que permite filtrar contenido arbitrario de la memoria del proceso. En la práctica esto puede traducirse en la divulgación de variables de entorno, claves de API, mensajes del sistema (system prompts) y conversaciones de usuarios concurrentes. El atacante puede además transformar esa lectura en exfiltración real subiendo el artefacto resultante a un registro controlado por él mediante el endpoint de subida del servidor.

El tamaño e importancia de Ollama como alternativa local al cloud hace que esta falla sea especialmente preocupante: el proyecto tiene una amplia huella en desarrolladores y organizaciones y, según reportes, la vulnerabilidad podría impactar a cientos de miles de servidores. Puede revisarse el repositorio oficial del proyecto para confirmar versiones y actualizaciones publicadas por los desarrolladores: https://github.com/ollama/ollama. Para el registro y detalles formales del CVE consulte el aviso en la base de datos nacional de vulnerabilidades: https://nvd.nist.gov/vuln/detail/CVE-2026-7482.

El caso se complica porque, en paralelo, investigadores han encontrado dos fallos en el mecanismo de actualización de la aplicación de Ollama para Windows que, combinados, permiten ejecución de código persistente al inicio de sesión. Estas vulnerabilidades incluyen la falta de verificación de firma del binario de actualización y un recorrido de directorio (path traversal) que puede escribir ejecutables en la carpeta de arranque de Windows si el proceso de actualización está controlado por un atacante. El resultado puede ser persistencia silenciosa y ejecución con los privilegios del usuario que corre Ollama.

¿Qué deben hacer administradores y usuarios ahora? En primer lugar, aplicar parches y versiones oficiales en cuanto estén disponibles y publicadas por los mantenedores del proyecto; si no hay actualización inmediata, contemple desconectar las instancias de Ollama de redes públicas y auditar todo endpoint REST expuesto. Proteja las instancias con un proxy de autenticación o un gateway API delante del servicio, ya que la API REST de Ollama no incorpora autenticación por defecto. Limite el acceso de red a IPs y subredes de confianza y coloque las máquinas detrás de un firewall. En entornos Windows, mientras se evalúa o aplica parche, desactive las actualizaciones automáticas del cliente y elimine cualquier acceso directo en la carpeta de inicio del usuario para impedir la ejecución silenciosa al iniciar sesión.

No se pase por alto la mitigación de impacto: rote claves y credenciales potencialmente almacenadas en las máquinas afectadas, revise registros y artefactos subidos (incluyendo modelos almacenados en registries) y realice búsquedas de archivos inusuales en la carpeta de Startup en Windows. Considere ejecutar Ollama en contenedores o entornos con privilegios mínimos, y limite las conexiones con otras herramientas automatizadas (por ejemplo, integra‑dores de cadenas de herramientas) que puedan enviar datos sensibles al proceso y así ampliar la superficie de ataque.

Finalmente, este incidente subraya dos tendencias más amplias: por un lado, correr LLM locales reduce dependencia de la nube pero aumenta la responsabilidad sobre la seguridad del host; por otro lado, el uso de rutas inseguras dentro de lenguajes «seguro por diseño» como Go (p. ej. el paquete unsafe) puede introducir vulnerabilidades críticas si no se aplica un control estricto. Organizaciones que dependen de despliegues locales de modelos deben incorporar revisiones de seguridad específicas para cargas útiles de modelos (GGUF u otros) y monitorizar activamente exposiciones de servicios. Manténgase informado a través de los avisos oficiales del proyecto y de fuentes de CVE, y priorice la contención y la auditoría si tiene instancias accesibles en red.