Un nuevo advisory de CERT revela que subir un archivo GGUF manipulado a cualquier instancia de Ollama expuesta puede exfiltrar silenciosamente la memoria heap del servidor — sin autenticación.
Correr LLMs de forma local se convirtió en algo cotidiano para muchos devs. Ollama lo hizo trivialmente fácil: un comando, un modelo corriendo en tu máquina, una API en el puerto 11434. Esa simplicidad, sin embargo, tiene una sombra — y un nuevo advisory de CERT publicado el 22 de abril lo deja muy difícil de ignorar.
CVE-2026-5757 es una vulnerabilidad crítica de divulgación remota de información no autenticada en el motor de cuantización de modelos de Ollama. Un atacante que pueda alcanzar la interfaz de carga de modelos de tu instancia no necesita credenciales, no necesita explotar una condición de carrera, y no necesita ser especialmente sofisticado. Sube un archivo GGUF maliciosamente manipulado, dispara la cuantización, y el servidor le entrega fragmentos de su propia memoria heap — potencialmente incluyendo API keys, tokens, historial de conversaciones, o cualquier otra cosa que estuviera en memoria en ese momento.
Cómo funciona
La causa raíz es una combinación de tres gaps de diseño en el pipeline de cuantización:
1. Sin bounds checking en los metadatos del tensor. El motor de cuantización lee conteos de elementos del header del archivo GGUF y los acepta sin validarlos contra el tamaño real de los datos enviados.
2. Acceso inseguro a memoria vía unsafe.Slice de Go. Un conteo de elementos controlado por el atacante crea un slice de memoria que se extiende mucho más allá del buffer de datos legítimo — y dentro del heap de la aplicación.
3. Un camino de exfiltración inadvertido. Los datos del heap fuera de límites se procesan y se escriben en una nueva capa del modelo. Luego la propia API de registry de Ollama puede hacer push de esa capa a un servidor controlado por el atacante. La herramienta exfiltra la memoria por vos.
No es una cadena de ataque teórica. Son tres decisiones de ingeniería mundanas que, combinadas, convierten una herramienta de IA local en un memory leak con plomería de exfiltración incorporada.
Quién está realmente en riesgo
La documentación oficial de Ollama indica que la herramienta está diseñada para uso local y recomienda no exponerla a redes no confiables. En la práctica, una parte significativa de los deployments reales ignora esto. Devs que corren Ollama en VMs cloud, pipelines de CI/CD, servidores homelab compartidos, o contenedores Docker con puertos expuestos son todos potencialmente alcanzables. El endpoint /api/push — el camino de exfiltración — no requiere autenticación por default, igual que la mayor parte de la superficie de API de Ollama.
Este no es territorio nuevo para Ollama. CVE-2025-63389 (CVSS 9.8, diciembre de 2025) documentó que todos los endpoints principales de la API — /api/tags, /api/copy, /api/delete, /api/generate, /api/chat — no requieren autenticación. CVE-2026-5757 apila un mecanismo de exfiltración activo sobre esa exposición preexistente.
La conversación más difícil
El ecosistema de runtimes locales de LLM — Ollama, LM Studio y similares — fue construido para la comodidad del developer, no para entornos adversariales. Esa fue una decisión de diseño razonable cuando estas herramientas vivían en laptops. Se convierte en una responsabilidad en el momento en que tocan cualquier red compartida con partes no confiables.
A medida que las cargas de trabajo de IA migran a infraestructura compartida — servidores de equipo, entornos de staging, workers de CI, instancias de GPU gestionadas — el modelo de amenaza cambia. Una herramienta que estaba “bien en mi MacBook” no está automáticamente bien en un contenedor Docker con una IP pública.
Al momento de escribir este artículo, no hay un parche disponible. El advisory de CERT señala que no se pudo contactar al vendor para una divulgación coordinada. El investigador que encontró el problema, Jeremy Brown, lo descubrió usando investigación de vulnerabilidades asistida por IA — un detalle que vale la pena notar, porque señala que el ritmo de descubrimiento de vulnerabilidades en este espacio se está acelerando.
Qué hacer ahora mismo
Revisá tu firewall. El puerto 11434 no debería ser accesible desde redes no confiables. En Linux: sudo ufw deny 11434. En cloud providers, revisá las reglas de tu security group.
Deshabilitá la carga de modelos si no la necesitás. El ataque requiere acceso a la interfaz de carga de modelos. Si tu deployment no necesita aceptar modelos enviados por usuarios, restringí o deshabilitá ese endpoint.
Auditá tus supuestos de deployment. Si Ollama está corriendo en un contenedor, en una VM, o en un pipeline de CI — mapeá qué es accesible y desde dónde.
Seguí el repositorio de Ollama para parches. El repo está en GitHub - ollama/ollama: Get up and running with Kimi-K2.5, GLM-5, MiniMax, DeepSeek, gpt-oss, Qwen, Gemma and other models. · GitHub. Suscribite a los releases.
No corras Ollama con privilegios elevados si podés evitarlo. Un memory leak en un proceso corriendo como root es significativamente peor que uno corriendo como usuario sin privilegios.
Para equipos de LatAm en particular: muchos devs de la región corren Ollama en instancias VPS compartidas o VMs cloud de bajo costo donde la configuración del firewall suele saltearse por comodidad. Verificá tu setup antes de asumir que estás protegido.