Honeynet UNAMex Lab Logo
Honeynet UNAMex Lab

Bleeding Llama: la fuga de memoria crítica que expone 300,000 servidores de IA local

Bleeding Llama: cuando el servidor de IA local se convierte en una ventana abierta a tu memoria

El 5 de mayo del presente año, investigadores de la firma de seguridad Cyera publicaron los detalles técnicos de una vulnerabilidad crítica en Ollama, la plataforma de código abierto más utilizada para ejecutar modelos de lenguaje extenso (LLMs) de forma local. Bautizada como Bleeding Llama y registrada como CVE-2026-7482 con una puntuación CVSS de 9.1 (Crítico), la falla permite a cualquier atacante remoto extraer fragmentos arbitrarios de la memoria del servidor, incluyendo conversaciones de usuarios, claves API, variables de entorno y código propietario utilizando solo tres llamadas HTTP, sin necesidad de ninguna credencial.

Al momento de la divulgación, aproximadamente 300,000 instancias de Ollama se encontraban directamente expuestas en internet público, sin ninguna capa de autenticación.

Antes de entender la vulnerabilidad, conviene situar el contexto. Ollama es una herramienta de código abierto que permite a cualquier persona ejecutar modelos de lenguaje extenso —como Llama 3, Mistral, Gemma o Phi— directamente en su propio hardware, sin depender de servicios externos como OpenAI o Anthropic. Con más de 170,000 estrellas en GitHub y 100 millones de descargas en Docker Hub, su adopción abarca desde desarrolladores individuales hasta grandes empresas que lo despliegan como asistente de IA interno para miles de empleados.

La propuesta de valor es clara: privacidad y control total. Los datos no salen de tu infraestructura, no pagan por llamadas a una API externa y no dependen de la disponibilidad de un tercero. Ollama fue diseñado con el principio de “fricción cero”: instalación en un solo comando, API disponible de inmediato, sin pasos de configuración adicionales. Es el enfoque correcto para un desarrollador que lo usa en su laptop personal. El problema comienza cuando esa misma configuración —pensada para localhost— se escala sin modificaciones a redes corporativas o servidores accesibles desde internet.

¿Qué es un “out-of-bounds heap read” y por qué es peligroso?

Para entender Bleeding Llama, es necesario comprender un concepto fundamental de bajo nivel: cómo los programas gestionan la memoria.

Cuando un programa como Ollama se ejecuta, el sistema operativo le asigna un bloque de memoria para que trabaje. Parte de esa memoria se llama heap (montículo), y es donde el programa almacena datos dinámicos durante su ejecución: las conversaciones activas de los usuarios, las variables de entorno cargadas al inicio, los tokens de autenticación de servicios integrados, el código fuente enviado para análisis, y mucho más.

Imagina el heap como un cuaderno de notas compartido donde el programa va anotando todo lo que necesita recordar mientras trabaja. El programa puede escribir y leer en cualquier sección de ese cuaderno, pero solo debería acceder a las páginas que le fueron asignadas.

Un out-of-bounds read (lectura fuera de límites) ocurre cuando el programa, por un error de lógica, lee más allá del bloque que le fue asignado. En términos del cuaderno: empieza a leer páginas que no le pertenecen, páginas que contienen las notas privadas de otras partes del sistema.

La clase de vulnerabilidad es bien conocida en seguridad —es prima hermana del famoso Heartbleed de 2014, que afectó a millones de servidores que usaban OpenSSL—, pero sigue siendo explotada con éxito décadas después porque los errores de gestión de memoria son extraordinariamente difíciles de eliminar por completo del código.

El suceso: un fallo silencioso en el corazón del pipeline de inferencia

El problema reside en cómo Ollama procesa los archivos de modelo en formato GGUF —el estándar para almacenar los pesos de un LLM—, concretamente en las funciones WriteTo() y ConvertToF32() de los archivos fs/ggml/gguf.go y server/quantization.go.

¿Qué es un archivo GGUF?

Un modelo de lenguaje no es más que una enorme colección de números —llamados pesos— organizados en estructuras matemáticas llamadas tensores. Un archivo GGUF es el contenedor estándar que empaqueta todos esos tensores junto con metadatos que describen su forma: cuántas dimensiones tiene cada tensor, cuántos elementos contiene en cada dimensión, qué tipo de datos almacena, etc.

La parte crítica: Ollama confía ciegamente en esos metadatos. Cuando recibe un archivo GGUF para crear una instancia de modelo, lee las dimensiones del tensor declaradas en el propio archivo y asume que son correctas. El fallo: nunca verifica que esas dimensiones coincidan con el tamaño real de los datos contenidos en el archivo.

Cómo se construye el exploit

Un atacante puede construir un archivo GGUF malicioso donde el campo de dimensiones del tensor apunta a un valor arbitrariamente grande —por ejemplo, declarar que un tensor contiene 10 millones de elementos cuando en realidad solo tiene 100. Al procesar este archivo, el bucle de cuantización en ConvertToF32() itera más allá del límite del buffer asignado en el heap, leyendo memoria que no le pertenece.

Lo que hace este bug especialmente grave es la función de conversión utilizada: la transformación F16→F32 es lossless —preserva cada byte exactamente, sin alteración ni pérdida—. Ese contenido leído ilegalmente queda perfectamente embebido en el archivo de modelo resultante, listo para ser exfiltrado.

A continuación, el atacante simplemente usa el endpoint nativo /api/push de Ollama para enviar ese modelo contaminado —con la memoria del heap adentro— a un servidor de registry bajo su control. En ese punto, puede analizar el volcado de memoria con calma y extraer cualquier dato de valor que encuentre.

El ataque se ejecuta de forma completamente silenciosa: Ollama no genera errores, no se cae y no deja rastros evidentes en los logs. Desde la perspectiva del sistema, todo funcionó con normalidad.

El problema: tres peticiones HTTP bastan para vaciar la memoria de tu servidor de IA

La cadena de explotación es alarmantemente simple:

Paso Endpoint Acción
1 POST /api/blobs/sha256:<hash> Subir el archivo GGUF malicioso con dimensiones de tensor infladas
2 POST /api/create Disparar la cuantización; el OOB read embebe el heap en el modelo
3 POST /api/push Enviar el modelo contaminado al registry del atacante

Ninguno de estos endpoints requiere autenticación en la distribución estándar de Ollama. Y si la instancia está configurada con OLLAMA_HOST=0.0.0.0, algo documentado y ampliamente utilizado para despliegues en red, cualquier actor con acceso al puerto 11434 puede ejecutar esta secuencia desde cualquier lugar del mundo.

¿Qué tan fácil es encontrar instancias vulnerables?

Herramientas como Shodan y Censys son motores de búsqueda especializados en dispositivos y servicios expuestos en internet. De la misma forma que Google indexa páginas web, estas plataformas indexan puertos y servicios abiertos. Una búsqueda simple por el puerto 11434 —el que usa Ollama por defecto— arroja decenas de miles de resultados: instancias completamente expuestas, sin autenticación, listas para ser consultadas por cualquiera.

No es necesario ser un hacker sofisticado para encontrar objetivos. Cualquier persona con conocimientos básicos de estas herramientas puede identificar en minutos servidores vulnerables en todo el mundo.

El inventario de datos en riesgo

Lo que puede estar en la memoria del proceso en el momento del ataque depende del contexto de despliegue. En un entorno corporativo, el inventario es devastador:

Análisis: la paradoja de migrar a IA local por privacidad

La ironía central de Bleeding Llama es que muchas organizaciones adoptan Ollama precisamente para proteger su privacidad: no quieren que sus prompts, su código o sus datos de clientes salgan hacia servicios externos. La lógica es válida. El error está en asumir que “los datos no van a la nube” es equivalente a “los datos están seguros”.

Migrar a inferencia local resuelve el problema de la confianza en el proveedor externo, pero transfiere la responsabilidad de seguridad a la organización. Y eso tiene implicaciones que van mucho más allá de instalar un software: significa asumir la operación de infraestructura de servidor, con todos los controles que eso implica.

El escenario más peligroso documentado por los investigadores es precisamente el más común en empresas: una instancia de Ollama compartida que actúa como asistente de IA para cientos o miles de empleados. Ese único proceso concentra en su heap el historial de conversaciones de toda la organización. Un atacante que lo comprometa no obtiene una sesión: obtiene el perfil completo de actividad de IA de la empresa.

El modelo de amenaza que muchos ignoran

En ciberseguridad, el modelo de amenaza es el ejercicio de preguntarse: ¿quién podría atacarnos, cómo y con qué objetivo? Muchas organizaciones que adoptan IA local nunca hacen este ejercicio para su infraestructura de Ollama. Asumen que el riesgo está en el proveedor externo (OpenAI, Anthropic) y descuidan la seguridad del servidor local.

Bleeding Llama demuestra que ese modelo de amenaza es incompleto. El adversario no es solo el proveedor de IA; también es cualquier actor que pueda acceder al puerto 11434 de tu servidor, ya sea desde internet o desde tu propia red interna.

La cadena de divulgación: un problema en sí misma

El investigador de Cyera, Dor Attias, reportó la vulnerabilidad al equipo de Ollama el 2 de febrero de 2026. El parche estuvo disponible en la versión 0.17.1 hacia finales de febrero, pero los release notes no indicaban que se trataba de una corrección de seguridad crítica. Para un administrador que revisa las notas de versión, parecía una actualización rutinaria.

La solicitud de CVE enviada a MITRE —la organización que coordina el registro oficial de vulnerabilidades— en marzo quedó sin respuesta durante semanas. Esto obligó al equipo a recurrir a Echo, una CVE Numbering Authority (CNA) alternativa, que asignó el identificador CVE-2026-7482 el 28 de abril y lo publicó el 1 de mayo.

El resultado es una cadena de divulgación con múltiples puntos de falla:

  1. El parche se distribuyó sin señalización de urgencia, lo que redujo drásticamente la tasa de actualización.
  2. El proceso de asignación de CVE por MITRE presentó demoras, fragmentando la capacidad de respuesta coordinada.
  3. Las instancias expuestas en internet no tienen mecanismo de notificación automática; sus administradores no reciben ninguna alerta cuando aparece una vulnerabilidad crítica.

El resultado fue una ventana de aproximadamente tres meses durante la cual el parche existía pero miles de operadores nunca supieron que debían priorizarlo. Es el mismo patrón que se repite con otras vulnerabilidades críticas en software de infraestructura: la brecha más peligrosa no siempre es técnica, sino comunicacional.

Recomendaciones de seguridad

Para administradores y equipos de operaciones

Para equipos de seguridad y SOC

Para usuarios individuales

Recapitulando…

Bleeding Llama expone una tensión real en el ecosistema de IA: las mismas características que hacen que Ollama sea fácil de adoptar —sin autenticación, sin configuración, listo para usar— son las que lo convierten en un riesgo crítico cuando se despliega fuera del entorno para el que fue diseñado.

El fallo técnico es un out-of-bounds read en la gestión de memoria del parser de GGUF; el problema sistémico es más profundo. La seguridad de un modelo de IA no puede separarse de la seguridad del host que lo ejecuta, ni de los procesos operacionales que rodean su despliegue: parcheado oportuno, comunicación clara de vulnerabilidades y segmentación de red adecuada.

La lección no es dejar de usar herramientas de inferencia local, a pesar de que ese camino tiene sus propios riesgos, sino entender que migrar a IA local no es solo una decisión de privacidad frente a proveedores externos: es también asumir la responsabilidad de operar infraestructura de servidor con los controles que eso implica. Un LLM local sin hardening no es más privado que un LLM en la nube; simplemente tiene un atacante diferente.

Y en el caso de Bleeding Llama, ese atacante solo necesitó tres llamadas HTTP.

Fuentes consultadas: