Ollama, una de las plataformas más populares para la ejecución local de modelos LLM, se ha encontrado con dos clases de problemas críticos a la vez: una fuga de memoria de proceso sin autenticación (CVE-2026-7482, Bleeding Llama, CVSS 9.1) y una cadena relacionada de vulnerabilidades en el mecanismo de actualización del cliente para Windows (CVE-2026-42248, CVE-2026-42249, CVSS 7.7), que proporcionan ejecución persistente de código durante el inicio de sesión. Esto afecta a cientos de miles de servidores y estaciones de trabajo en los que Ollama está integrada con servicios corporativos y herramientas de desarrollo, y exige una actualización inmediata de las versiones, la separación de instancias y la desactivación de la autoactualización del cliente para Windows hasta la publicación de los parches.

Detalles técnicos: de la fuga de memoria al RCE persistente

Bleeding Llama (CVE-2026-7482): fuga de memoria a través de modelos GGUF

La vulnerabilidad CVE-2026-7482 está descrita en la base de datos de CVE.org como un error de lectura fuera del heap en el cargador del formato GGUF en Ollama hasta la versión 0.17.1. La entrada está disponible en la ficha oficial de CVE y se ha duplicado en la NVD. El código afectado se encuentra en los archivos fs/ggml/gguf.go y server/quantization.go, en la función WriteTo().

La esencia del problema:

• La interfaz /api/create acepta un archivo de modelo en formato GGUF proporcionado por el cliente.
• El archivo GGUF contiene metadatos sobre el tensor (desplazamiento, tamaño, forma), similares a los descritos en la guía de tensores de TensorFlow.
• Ollama confía en los tamaños y la forma declarados del tensor, sin contrastarlos con la longitud real del archivo.
• Durante la cuantización del tensor del modelo en WriteTo() se produce una lectura más allá del búfer de heap asignado.

La causa raíz es el uso del paquete unsafe en Go al trabajar con estructuras binarias GGUF. La documentación de Go indica explícitamente que el paquete unsafe elude las garantías de seguridad de memoria y, en este caso, eso se ha traducido en la posibilidad de leer bytes adicionales de la memoria del proceso.

Los investigadores de Cyera han mostrado una cadena de explotación en tres pasos:

1. Carga de un archivo GGUF especialmente manipulado, con una forma de tensor inflada, en un servidor Ollama accesible por red mediante HTTP POST.
2. Lanzamiento de la creación del modelo a través de /api/create, lo que inicia la lectura fuera de los límites del búfer e inserta fragmentos de memoria en el artefacto resultante del modelo.
3. Exportación del modelo obtenido a un registro externo controlado por el atacante mediante /api/push.

Aspectos críticos para la protección:

• La explotación no requiere autenticación: la interfaz REST de Ollama no tiene, por defecto, verificación de autenticidad incorporada.
• El atacante controla el contenido del GGUF, pero los datos extraídos son bytes arbitrarios de la memoria del proceso de Ollama, no limitados por los límites del archivo.
• El código fuente del proyecto es abierto y está disponible en GitHub, lo que facilita la preparación de un exploit.

En la práctica, esto convierte cualquier instancia de Ollama expuesta a Internet en una fuente de fugas de información:

• variables de entorno (incluidas claves de proveedores cloud, tokens de CI/CD, etc.);
• prompts de sistema de LLM e instrucciones confidenciales;
• código y datos procesados por herramientas integradas con Ollama (por ejemplo, herramientas de desarrollo);
• fragmentos de diálogos de otros usuarios atendidos por el mismo proceso.

CVE-2026-42248 y CVE-2026-42249: la autoactualización de Ollama para Windows como vector de RCE persistente

El segundo grupo de vulnerabilidades está relacionado con el mecanismo de actualización del cliente de Ollama para Windows. La investigación fue publicada por el equipo de Striga en su sitio Striga Research, y la coordinación de la divulgación estuvo a cargo de CERT Polska.

El cliente para Windows:

• se inicia automáticamente en el inicio de sesión del usuario a través de la carpeta de inicio automático de Windows;
• funciona localmente en 127.0.0.1:11434 y se conecta periódicamente a /api/update para comprobar actualizaciones;
• al detectar una actualización, descarga e instala el binario en el siguiente arranque.

Se han detectado dos defectos:

• CVE-2026-42248 (CVSS 7.7): ausencia de verificación de la firma de la actualización; a diferencia de la versión para macOS, el cliente de Windows no comprueba la firma criptográfica del binario antes de instalarlo.
• CVE-2026-42249 (CVSS 7.7): path traversal; la ruta al directorio local donde se coloca el instalador se forma directamente a partir de las cabeceras HTTP de la respuesta del servidor de actualizaciones, sin normalización ni comprobación.

Si el atacante puede controlar el servidor de actualizaciones al que tiene acceso el cliente de Ollama (mediante la reasignación de OLLAMA_UPDATE_URL a un servidor HTTP local, la compromisión del servidor real o la manipulación del tráfico de red), la cadena de explotación es la siguiente:

1. El cliente solicita una actualización mediante /api/update.
2. El atacante devuelve una “actualización” —un archivo ejecutable arbitrario— y cabeceras que indican una ruta fuera del directorio esperado (por ejemplo, a la carpeta de inicio automático de Windows).
3. El cliente guarda el archivo en la ruta indicada sin comprobar la firma y sin eliminar posteriormente los archivos no firmados.
4. En el siguiente inicio de sesión, Windows ejecuta automáticamente el archivo grabado con los privilegios del usuario.

Según CERT Polska, son vulnerables las versiones de Ollama para Windows desde la 0.12.10 hasta la 0.22.0 inclusive, y en el momento de la publicación de las recomendaciones la vulnerabilidad sigue sin corregirse. Las medidas temporales incluyen desactivar las actualizaciones automáticas y eliminar el acceso directo de Ollama de la carpeta de inicio automático.

La ausencia de verificación de integridad ya permite una ejecución única de código en el contexto de la actualización; la incorporación del path traversal convierte esto en una ejecución persistente de código en cada inicio de sesión del usuario, mientras el archivo malicioso permanezca en la carpeta de inicio automático.

Evaluación del impacto y prioridad de riesgos

Bleeding Llama (CVE-2026-7482) es la principal amenaza para las organizaciones que:

• tienen servidores de Ollama accesibles desde Internet o desde redes internas amplias sin segmentación estricta;
• hacen pasar datos sensibles por Ollama: código fuente, contratos, documentos internos, datos de clientes;
• tienen Ollama integrada con herramientas adicionales (por ejemplo, herramientas de análisis de código) cuyos resultados se transfieren al modelo y se conservan en memoria.

Si no se toman medidas, las consecuencias pueden incluir:

• compromiso masivo de claves y tokens, con la consiguiente intrusión en otros sistemas;
• fuga de prompts confidenciales y de la lógica de negocio sobre la que se construyen los servicios internos de LLM;
• divulgación de datos de usuarios y clientes que pasan a través de los diálogos con el modelo.

CVE-2026-42248/CVE-2026-42249 representan un riesgo elevado para las estaciones de trabajo de desarrolladores y analistas donde Ollama para Windows se utiliza como interfaz local para los modelos y tiene acceso a:

• claves SSH y tokens de repositorios;
• credenciales del navegador y de VPN corporativas;
• directorios de trabajo de proyectos.

La cadena otorga al atacante una ejecución persistente de código malicioso con los permisos del usuario actual, suficiente para instalar spyware, robar secretos y avanzar más por la infraestructura. Al mismo tiempo, el único “punto de apagado” es eliminar el archivo de la carpeta de inicio automático; los defectos lógicos en el componente de actualización permanecen.

Es importante destacar que ambos vectores se complementan entre sí: la vulnerabilidad del lado servidor revela secretos y contexto, mientras que la del cliente proporciona un punto de apoyo fiable en los sistemas de los usuarios. Conceptualmente, son posibles escenarios en los que los datos filtrados mediante Bleeding Llama (por ejemplo, configuraciones de proxy o parámetros de actualización) faciliten la explotación posterior del cliente para Windows.

Recomendaciones prácticas y verificación de exposición

Servidores y contenedores: protección frente a Bleeding Llama

1. Actualizar inmediatamente Ollama a la versión 0.17.1 o superior.
   La versión utilizada puede comprobarse en el repositorio oficial de GitHub Ollama y en la versión 0.17.1. Todas las instancias por debajo de esta versión deben considerarse vulnerables.
2. Restringir el acceso de red al API de Ollama.
   • Cerrar el acceso directo desde Internet a todas las interfaces de Ollama.
   • Permitir el acceso solo a través de VPN, un API gateway o un reverse proxy con autenticación.
   • Segmentar estrictamente las redes internas: las instancias de desarrollo y prueba no deben ser accesibles desde segmentos de usuario.
3. Implementar un proxy autenticador o un API gateway.
   Dado que el REST API de Ollama no tiene autenticación incorporada, debe situarse delante de todas las instancias un componente que verifique credenciales, tokens o certificados de cliente.
4. Análisis de registros y posible compromiso.
   • Buscar en los logs solicitudes HTTP a /api/create con cuerpos voluminosos y orígenes atípicos, especialmente combinadas con llamadas posteriores a /api/push hacia registros externos.
   • Si la instancia era accesible desde el exterior y funcionaba con una versión vulnerable, asumir la fuga de todos los secretos presentes en la memoria del proceso de Ollama y llevar a cabo la rotación de claves, tokens y contraseñas.
5. Revisar la política de carga de modelos.
   No permitir que usuarios anónimos o no verificados carguen sus propios modelos GGUF en servidores que procesan datos sensibles.

Estaciones de trabajo con Windows: medidas temporales contra el RCE vía actualizaciones

Hasta que aparezca un parche oficial para el cliente de Ollama en Windows, se recomienda:

1. Desactivar la actualización automática.
   Seguir las indicaciones de CERT Polska: deshabilitar la opción AutoUpdateEnabled y no usar la variable OLLAMA_UPDATE_URL para redirigir a servidores no estándar o no seguros (HTTP).
2. Eliminar el inicio automático sin control.
   Borrar el acceso directo de Ollama de la carpeta de inicio automático:
   %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup. Esto no elimina las vulnerabilidades, pero priva al atacante de un punto cómodo de ejecución persistente.
3. Comprobar la presencia de archivos sospechosos en el inicio automático.
   Inventariar los ejecutables en la carpeta de inicio automático y compararlos con el conjunto esperado de programas; los archivos desconocidos o aparecidos recientemente requieren un análisis específico.
4. Reforzar el control del perímetro de red en torno a las actualizaciones.
   • Garantizar que el tráfico hacia el servidor de actualizaciones de Ollama pasa por un proxy controlado y no puede ser manipulado.
   • Prohibir el uso de HTTP sin cifrar para descargar actualizaciones a nivel de proxy o firewall.
5. Supervisión de la actividad de procesos.
   Configurar las soluciones de protección de endpoints para que supervisen la ejecución de archivos desconocidos desde la carpeta de inicio automático y los ejecutables generados por el proceso de Ollama.

Para infraestructuras donde Ollama se utiliza tanto en servidores como en estaciones de trabajo con Windows, la prioridad debe ser: actualizar las instancias de servidor a la versión 0.17.1+ con segmentación simultánea de la red y, a continuación, desactivar de forma centralizada la autoactualización del cliente de Windows y limpiar la carpeta de inicio automático en las estaciones de trabajo.