Bleeding Llama: un fallo de parsing GGUF filtra la memoria del proceso Ollama a atacantes no autenticados

¿De qué se trata?

En mayo de 2026, investigadores de Cyera divulgaron públicamente la CVE-2026-7482 (CVSS 9.1), una lectura fuera de límites sin autenticación en Ollama, el popular runtime de inferencia local. La denominaron Bleeding Llama. El fallo permite a un atacante remoto que pueda alcanzar la API HTTP de un servidor Ollama extraer fragmentos arbitrarios de la memoria heap del servidor — variables de entorno, claves de API, system prompts y fragmentos de conversaciones de otros usuarios — sin autenticarse en ningún momento.

El defecto reside en el parser GGUF de Ollama. Cuando el servidor procesa un fichero de modelo GGUF cuyo offset y tamaño de tensor declarados exceden la longitud real del fichero, funciones en fs/ggml/gguf.go y server/quantization.go leen más allá del buffer asignado en el heap durante la cuantización. El resultado es una fuga de memoria controlable.

La corrección se publicó en Ollama v0.17.1 el 25 de febrero de 2026 sin marcarse como una release de seguridad. El CVE solo fue asignado por Echo (una CNA de terceros) el 28 de abril de 2026, después de que MITRE no respondiera durante casi dos meses, y la divulgación pública apareció en mayo de 2026. Durante aproximadamente diez semanas, el parche existía pero los operadores no tenían ninguna señal para priorizarlo. Las instancias de Ollama expuestas en Internet — estimadas en más de 300 000 servidores a nivel global — estuvieron vulnerables durante toda esa ventana.

Cómo funciona

Bleeding Llama es un caso de manual de ruptura de frontera de confianza: un servidor parsea un formato de fichero no fiable y confía en los campos de metadatos que describen cómo leer la carga útil.

# Esquema conceptual basado en el aviso público de Cyera.
# No se reproduce ningún payload explotable contra un sistema en producción.

[ atacante ]
     │
     │ 1. POST /api/create   ─── carga un GGUF malicioso con tamaño de tensor inflado
     ▼
[ servidor Ollama ]
     │
     │ 2. parsing de los metadatos GGUF
     │    └── el offset / tamaño del tensor NO se acota contra la longitud del fichero
     │
     │ 3. la fase de cuantización lee N bytes del heap
     │    donde N proviene del descriptor de tensor controlado por el atacante
     │    └── lectura fuera de límites más allá del buffer asignado
     │
     │ 4. POST /api/push     ─── el servidor exporta el "modelo" resultante
     ▼
[ endpoint de exfiltración del atacante ]
     │
     └── bytes del heap: env vars, claves API, system prompts, conversaciones de otros usuarios

Hay dos elementos de contexto que importan para el impacto.

Primero, el formato GGUF es el packaging estándar de los pesos de modelos en local — cada modelo open-weight moderno se entrega así. Un fichero GGUF es simplemente un blob binario con una cabecera de metadatos que indica al cargador dónde vive cada tensor y cuál es su tamaño. Bleeding Llama es exactamente la clase de bug que cabría predecir para ese diseño: el parser creyó a la cabecera.

Segundo, los dos endpoints utilizados en la cadena (/api/create y /api/push) son no autenticados por defecto en Ollama. La documentación oficial lo señala, y la dirección de bind por defecto es 127.0.0.1, pero muchos despliegues reales la sobrescriben con OLLAMA_HOST=0.0.0.0 para que la máquina sirva la red de un desarrollador o una flota de contenedores. Ese único cambio de variable de entorno convierte Bleeding Llama de una molestia local en una primitiva de ataque remota expuesta en Internet.

La memoria filtrada es el heap del proceso Ollama, que de forma rutinaria contiene: el system prompt actualmente en servicio, los prompts de usuario recientes y las salidas del modelo, variables de entorno (que en VMs cloud suelen incluir claves AWS / GCP / Anthropic / OpenAI) y material TLS si la pila lo ha tocado. Tres llamadas a la API son suficientes para reproducir una divulgación controlable.

Por qué importa

Tres puntos a señalar para cualquier equipo que opere infraestructura LLM.

El primero es el más obvio: la superficie de ataque de los runtimes LLM “locales” es mucho más amplia de lo que los equipos asumen. Ollama se despliega a menudo con el modelo mental de una herramienta de desarrollador, pero en la práctica es un servidor de inferencia accesible por red que maneja secretos y PII en el momento en que un usuario habla con él. Los escaneos realizados por investigadores externos en mayo de 2026 encontraron que una fracción sustancial de la infraestructura IA autohospedada está expuesta a Internet público sin autenticación. Bleeding Llama es un ejemplo del lado de divulgación de memoria, pero la misma postura es lo que hizo a la CVE-2026-33626 (SSRF de LMDeploy) y a la CVE-2026-42208 (SQLi de LiteLLM) masivamente explotables en horas.

El segundo es el problema del parche silencioso. La corrección se publicó en v0.17.1 el 25 de febrero con una nota de versión que no era de seguridad. El CVE se emitió el 28 de abril. Durante setenta días, los operadores que usaban escáneres de vulnerabilidades o herramientas de gestión de parches no tenían CVE contra el que coincidir ni señal de severidad que los apuntara a la actualización. Este patrón no es específico de Ollama — muchos frameworks de IA carecen de un pipeline de avisos de seguridad, y varios backlogs de CNAs de MITRE se han deslizado en el último año. Si su inventario de IA depende de feeds CVE para disparar el parcheado, está sistemáticamente atrasado en infraestructura de IA.

El tercero es la implicación de cadena de suministro GGUF. Los ficheros de modelo son ahora el equivalente a artefactos ejecutables — disparan lógica de parsing compleja del lado servidor. Tratarlos como datos inertes es erróneo. Cualquier pipeline que ingiere ficheros GGUF de fuentes externas (descargas de Hugging Face, registros mirroreados, fine-tunes subidos por usuarios) está expuesto a cualquier bug de parsing que tenga el consumidor. Bleeding Llama es uno; casi con certeza no será el último.

Defensas

Actualice a Ollama v0.17.1 o posterior. Es la única corrección para el bug subyacente del parser. Las versiones antiguas no se pueden parchear de forma segura in-place porque las comprobaciones de límites se añaden a lo largo de las rutas de código GGUF y de cuantización.

Audite su dirección de bind y su autenticación. Si su Ollama corre con OLLAMA_HOST=0.0.0.0 o detrás de un load balancer público, trátelo como un servicio expuesto. Vincúlelo a 127.0.0.1 y acceda vía SSH o VPN, o póngalo detrás de un reverse-proxy que imponga autenticación y rate-limit sobre /api/create y /api/push. El aviso de runZero documenta consultas que puede utilizar para localizar sus propias instancias expuestas.

Segmente por red su runtime LLM lejos de los secretos. Una fuga de heap solo puede exfiltrar lo que el proceso toca. No haga circular credenciales cloud de producción, claves de API de terceros ni PII a través de variables de entorno de un servidor de inferencia expuesto al público. Use un sidecar con un rol IAM estrictamente acotado, o un broker de secretos que distribuya tokens de corta vida bajo demanda. Es el mismo principio que limita el radio de impacto de SSRF y RCE en la misma familia de frameworks IA.

Trate GGUF como entrada no confiable. Si su pipeline obtiene ficheros de modelo de cualquier fuente que no controle de extremo a extremo, valide la cabecera del fichero fuera del proceso — por ejemplo, parseando los metadatos en un binario sandboxed y rechazando ficheros cuyas extensiones de tensor declaradas no coincidan con la longitud del fichero. Varios registros open-weight están empezando a publicar manifiestos GGUF firmados; préfiéralos.

Suscríbase a los avisos de su proveedor de runtime IA, no solo a los feeds CVE. Bleeding Llama es el caso de estudio que muestra por qué los feeds CVE por sí solos son insuficientes. Suscríbase directamente a los GitHub Security Advisories de Ollama, LiteLLM, LMDeploy, vLLM y de su proveedor de inferencia. Vigile sus notas de versión para detectar parches silenciosos y asuma por defecto que cualquier cambio no trivial en un parser puede ser relevante para la seguridad.

Adopte las mitigaciones de cadena de suministro del OWASP LLM Top 10. OWASP LLM03 (Supply Chain) y LLM07 (System Prompt Leakage) aplican directamente aquí. La revisión 2026 ahora referencia explícitamente el parsing de ficheros de modelo como parte de la superficie de ataque de cadena de suministro.

Estado

Elemento	Referencia	Fecha	Notas
CVE	CVE-2026-7482, CVSS 9.1	Asignado 2026-04-28 (CNA Echo)	Envío inicial a MITRE 2026-03-02; reasignado por Echo tras la falta de respuesta de MITRE
Descubrimiento	Cyera Research (“Bleeding Llama”)	Divulgación pública mayo 2026	Timeline de divulgación responsable documentada en el aviso de Cyera
Parche	Ollama v0.17.1	2026-02-25	Publicado sin etiqueta de seguridad en las notas de versión
Publicación pública	Cyera / The Hacker News	2026-05	Confirma más de 300 000 servidores expuestos en todo el mundo
Componente afectado	fs/ggml/gguf.go, server/quantization.go	—	Lectura fuera de límites en el heap durante la cuantización
Versiones afectadas	Ollama < 0.17.1	—	Incluye todas las ramas menores anteriores
Mapeo OWASP	LLM03 (Supply Chain), LLM07 (System Prompt Leakage)	Revisión 2026	El parsing de ficheros de modelo ahora forma parte del alcance de supply chain
Divulgaciones relacionadas	LMDeploy CVE-2026-33626 (SSRF), LiteLLM CVE-2026-42208 (SQLi), Langflow CVE-2026-33873 (RCE)	2026	Mismo patrón: endpoints sin autenticar en frameworks de IA

Bleeding Llama no es un ataque novedoso y exótico — es un bug clásico de seguridad de memoria en un parser, envuelto alrededor de un formato de fichero específico de la IA. Lo que lo hace digno de atención es la realidad operativa que lo rodea: el runtime está más expuesto a la red de lo que sus desarrolladores asumen, el parche fue silencioso, el CVE llegó tarde y los bytes filtrados son exactamente los secretos que los despliegues LLM acumulan. Trate sus servidores de inferencia como los servicios de data plane de producción en que se han convertido.