Um novo aviso de CERT revela que fazer upload de um arquivo GGUF manipulado para qualquer instância exposta do Ollama pode exfiltrar silenciosamente a memória heap do servidor — sem autenticação.
Executar LLMs localmente se tornou algo cotidiano para muitos devs. O Ollama o tornou trivialmente fácil: um comando, um modelo rodando na sua máquina, uma API na porta 11434. Essa simplicidade, porém, tem uma sombra — e um novo aviso de CERT publicado em 22 de abril deixa isso muito difícil de ignorar.
CVE-2026-5757 é uma vulnerabilidade crítica de divulgação remota de informações não autenticada no mecanismo de quantização de modelos do Ollama. Um atacante que consiga acessar a interface de upload de modelos da sua instância não precisa de credenciais, não precisa explorar uma condição de corrida, e não precisa ser especialmente sofisticado. Faça upload de um arquivo GGUF maliciosamente manipulado, dispare a quantização, e o servidor entrega fragmentos de sua própria memória heap — potencialmente incluindo chaves de API, tokens, histórico de conversas, ou qualquer outra coisa que estivesse na memória naquele momento.
Como funciona
A causa raiz é uma combinação de três lacunas de design no pipeline de quantização:
1. Sem verificação de limites nos metadados do tensor. O mecanismo de quantização lê contagens de elementos do header do arquivo GGUF e as aceita sem validá-las contra o tamanho real dos dados enviados.
2. Acesso inseguro à memória via unsafe.Slice do Go. Uma contagem de elementos controlada pelo atacante cria um slice de memória que se estende bem além do buffer de dados legítimo — e para dentro do heap da aplicação.
3. Um caminho de exfiltração inadvertido. Os dados do heap fora dos limites são processados e escritos em uma nova camada do modelo. Depois a própria API de registry do Ollama pode fazer push dessa camada para um servidor controlado pelo atacante. A ferramenta exfiltra a memória para você.
Não é uma cadeia de ataque teórica. São três decisões de engenharia mundanas que, combinadas, transformam uma ferramenta de IA local em um vazamento de memória com encanamento de exfiltração incorporado.
Quem está realmente em risco
A documentação oficial do Ollama indica que a ferramenta foi desenvolvida para uso local e recomenda não expô-la a redes não confiáveis. Na prática, uma parte significativa dos deployments reais ignora isso. Devs que executam Ollama em VMs na cloud, pipelines de CI/CD, servidores homelab compartilhados, ou contêineres Docker com portas expostas são todos potencialmente alcançáveis. O endpoint /api/push — o caminho de exfiltração — não requer autenticação por padrão, assim como a maior parte da superfície da API do Ollama.
Este não é território novo para o Ollama. CVE-2025-63389 (CVSS 9.8, dezembro de 2025) documentou que todos os principais endpoints da API — /api/tags, /api/copy, /api/delete, /api/generate, /api/chat — não requerem autenticação. CVE-2026-5757 adiciona um mecanismo de exfiltração ativa sobre essa exposição preexistente.
A conversa mais difícil
O ecossistema de runtimes locais de LLM — Ollama, LM Studio e similares — foi construído para conveniência do desenvolvedor, não para ambientes adversariais. Essa foi uma decisão de design razoável quando essas ferramentas viviam em laptops. Torna-se uma responsabilidade no momento em que tocam qualquer rede compartilhada com partes não confiáveis.
À medida que as cargas de trabalho de IA migram para infraestrutura compartilhada — servidores de equipe, ambientes de staging, workers de CI, instâncias de GPU gerenciadas — o modelo de ameaça muda. Uma ferramenta que estava “bem no meu MacBook” não está automaticamente bem em um contêiner Docker com um IP público.
No momento da redação deste artigo, não há um patch disponível. O aviso de CERT aponta que não foi possível contactar o fornecedor para divulgação coordenada. O pesquisador que encontrou o problema, Jeremy Brown, o descobriu usando pesquisa de vulnerabilidades assistida por IA — um detalhe que vale a pena notar, pois indica que o ritmo de descoberta de vulnerabilidades neste espaço está se acelerando.
O que fazer agora
Verifique seu firewall. A porta 11434 não deveria ser acessível a partir de redes não confiáveis. No Linux: sudo ufw deny 11434. Em provedores de cloud, verifique as regras do seu security group.
Desabilite o upload de modelos se não precisar. O ataque requer acesso à interface de upload de modelos. Se seu deployment não precisa aceitar modelos enviados por usuários, restrinja ou desabilite esse endpoint.
Audite suas suposições de deployment. Se o Ollama está rodando em um contêiner, em uma VM, ou em um pipeline de CI — mapeie o que é acessível e de onde.
Acompanhe o repositório do Ollama para patches. O repo está em GitHub - ollama/ollama: Get up and running with Kimi-K2.5, GLM-5, MiniMax, DeepSeek, gpt-oss, Qwen, Gemma and other models. · GitHub. Inscreva-se nos releases.
Não execute o Ollama com privilégios elevados se conseguir evitar. Um vazamento de memória em um processo rodando como root é significativamente pior que um rodando como usuário sem privilégios.
Para equipes da América Latina em particular: muitos devs da região executam Ollama em instâncias VPS compartilhadas ou VMs de cloud de baixo custo onde a configuração do firewall costuma ser pulada por conveniência. Verifique sua configuração antes de assumir que você está protegido.