Fugas críticas de memoria y fallos de RCE sin parches afectan a Ollama
Una vulnerabilidad crítica en **Ollama**, apodada 'Bleeding Llama', podría permitir a atacantes no autenticados filtrar memoria de procesos sensible. Además, dos fallos de ejecución remota de código (RCE) sin parches en el mecanismo de actualización de Ollama para Windows representan un riesgo significativo, lo que subraya la necesidad de medidas de seguridad inmediatas.

Investigadores de ciberseguridad han descubierto una vulnerabilidad de seguridad crítica en **Ollama** que, de ser explotada, podría permitir a un atacante remoto y no autenticado filtrar toda la memoria del proceso.
Esta falla de lectura fuera de límites, que podría afectar a más de 300.000 servidores a nivel mundial, se rastrea como **CVE-2026-7482** (puntuación CVSS: 9.1) y ha sido apodada **Bleeding Llama** por **Cyera**.
**Ollama** es un popular framework de código abierto que permite la ejecución local de modelos de lenguaje grandes (LLMs). El proyecto cuenta con más de 171.000 estrellas y ha sido bifurcado más de 16.100 veces en GitHub.
"Ollama antes de la versión 0.17.1 contiene una vulnerabilidad de lectura fuera de límites en el heap en el cargador de modelos GGUF", según la descripción de la CVE. "El endpoint `/api/create` acepta un archivo GGUF proporcionado por el atacante en el que el desplazamiento y el tamaño declarados de los tensores exceden la longitud real del archivo; durante la cuantización en fs/ggml/gguf.go y server/quantization.go (WriteTo()), el servidor lee más allá del buffer del heap asignado."
**GGUF** (GPT-Generated Unified Format) es un formato de archivo para almacenar modelos de lenguaje grandes para su carga y ejecución local.
La vulnerabilidad se deriva del uso del paquete `unsafe` por parte de Ollama al crear un modelo a partir de un archivo GGUF, específicamente en la función `WriteTo()`, eludiendo las garantías de seguridad de memoria.
### Escenario de Ataque
Un actor malintencionado puede enviar un archivo GGUF manipulado a un servidor Ollama expuesto, configurando la forma del tensor a un número extremadamente grande para activar la lectura del heap fuera de límites durante la creación del modelo a través del endpoint `/api/create`. La explotación exitosa puede filtrar datos sensibles de la memoria del proceso de Ollama.
Estos datos filtrados pueden incluir variables de entorno, claves API, prompts del sistema y datos de conversación de usuarios concurrentes, que luego pueden ser exfiltrados subiendo el artefacto del modelo resultante a través del endpoint `/api/push` a un registro controlado por el atacante.
La cadena de explotación involucra los siguientes pasos:
* Subir un archivo GGUF manipulado con una forma de tensor inflada a un servidor Ollama accesible por red utilizando una solicitud POST HTTP.
* Utilizar el endpoint `/api/create` para activar la creación del modelo, lo que desencadena la vulnerabilidad de lectura fuera de límites.
* Utilizar el endpoint `/api/push` para exfiltrar datos de la memoria del heap a un servidor externo.
"Un atacante puede aprender básicamente cualquier cosa sobre la organización a partir de tu inferencia de IA: claves API, código propietario, contratos de clientes y mucho más", dijo Dor Attias, investigador de seguridad de **Cyera**.

"Además, los ingenieros a menudo conectan Ollama a herramientas como Claude Code. En esos casos, el impacto es aún mayor: todas las salidas de la herramienta fluyen al servidor Ollama, se guardan en el heap y potencialmente terminan en manos de un atacante."
Se aconseja a los usuarios aplicar los últimos parches, limitar el acceso a la red, auditar las instancias en ejecución para detectar exposición a Internet y aislarlas y asegurarlas detrás de un firewall. También se recomienda implementar un proxy de autenticación o una puerta de enlace API delante de todas las instancias de Ollama, ya que la API REST carece de autenticación incorporada.
### Dos Fallos sin Parche en Ollama Llevan a Ejecución de Código Persistente
Investigadores de **Striga** han detallado dos vulnerabilidades en el mecanismo de actualización de Ollama para Windows que pueden encadenarse para lograr la ejecución de código persistente. Estas deficiencias permanecen sin parchear después de su divulgación el 27 de enero de 2026, tras un período de divulgación de 90 días.
Según Bartłomiej "Bartek" Dmitruk, cofundador de **Striga**, el cliente de escritorio de Windows se inicia automáticamente al iniciar sesión desde la carpeta de Inicio de Windows, escucha en 127.0.0[.]1:11434 y consulta periódicamente las actualizaciones en segundo plano a través del endpoint `/api/update` para ejecutar cualquier actualización pendiente en el próximo inicio de la aplicación.
Las vulnerabilidades identificadas se relacionan con un recorrido de directorios y una verificación de firma faltante que, cuando se combinan con la rutina de inicio de sesión, pueden permitir a un atacante con la capacidad de influir en las respuestas de actualización ejecutar código arbitrario en cada inicio de sesión. Los fallos se enumeran a continuación:
* **CVE-2026-42248** (puntuación CVSS: 7.7) - Una vulnerabilidad de verificación de firma faltante que no verifica el binario de actualización antes de la instalación, a diferencia de su versión para macOS.
* **CVE-2026-42249** (puntuación CVSS: 7.7) - Una vulnerabilidad de recorrido de directorios que se deriva del hecho de que el actualizador de Windows crea la ruta local para el directorio de preparación del instalador directamente desde las cabeceras de respuesta HTTP sin sanitizarla.
Para explotar los fallos, el atacante necesita controlar un servidor de actualización accesible por el cliente Ollama de la víctima. Esto podría llevar a un escenario en el que se proporcione un ejecutable arbitrario como parte del proceso de actualización y se escriba en la carpeta de Inicio de Windows sin generar problemas de verificación de firma.
Un enfoque implica anular OLLAMA_UPDATE_URL para que el cliente apunte a un servidor local en HTTP plano. La cadena de ataque también asume que AutoUpdateEnabled está activado, que es la configuración predeterminada.
La falta de verificación de integridad puede llevar a la ejecución de código por sí sola sin explotar la vulnerabilidad de recorrido de directorios. En este caso, el instalador se coloca en el directorio de preparación esperado. Durante el próximo lanzamiento desde la carpeta de Inicio, se invoca el proceso de actualización sin volver a verificar la firma, lo que provoca la ejecución del código del atacante.
Si bien esta ejecución remota de código no es persistente, ya que la próxima actualización legítima sobrescribe el archivo preparado, la adición del recorrido de directorios permite a un actor malintencionado redirigir el ejecutable para que se escriba fuera de la ruta habitual, logrando así la ejecución de código persistente.
Según **CERT Polska**, que asumió el proceso de divulgación coordinada, las versiones de Ollama para Windows 0.12.10 a 0.17.5 son vulnerables a los dos fallos. Mientras tanto, se recomienda a los usuarios desactivar las actualizaciones automáticas y eliminar cualquier acceso directo existente de Ollama de la carpeta de Inicio ("%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup") para deshabilitar la ruta de ejecución silenciosa al iniciar sesión.
"Cualquier instalación de Ollama para Windows que ejecute las versiones 0.12.10 a 0.22.0 es vulnerable", dijo Dmitruk. "El recorrido de directorios escribe ejecutables elegidos por el atacante en la carpeta de Inicio de Windows. La falta de verificación de firma los mantiene allí: la limpieza posterior a la escritura que eliminaría archivos sin firmar en un actualizador funcional es una operación nula en Windows. En el próximo inicio de sesión, Windows ejecuta lo que sea que haya quedado."
"La cadena produce ejecución de código persistente y silenciosa al nivel de privilegio del usuario que ejecuta Ollama. Los payloads realistas incluyen shells inversos, roba-información que exfiltran secretos del navegador y claves SSH, o droppers que pivotan a mecanismos de persistencia adicionales. Cualquier cosa que se ejecute como el usuario actual. Eliminar el binario depositado de la carpeta de Inicio pone fin a la persistencia, pero los fallos subyacentes permanecen."