06 maio Bleeding Llama: falha no Ollama vaza dados de 300 mil servidores

Uma falha permite acessar dados confidenciais de servidores que rodam o Ollama sem precisar de senha ou credenciais. Descoberta pela empresa de segurança Cyera, a falha afeta cerca de 300 mil instâncias expostas na internet e recebeu nota 9.3 de 10 na escala de gravidade CVSS. Ela foi registrada como CVE-2026-7482 e apelidada de “Bleeding Llama”.

O Ollama é uma plataforma de código aberto que possibilita rodar modelos de linguagem diretamente em servidores próprios, sem depender de serviços como OpenAI ou Anthropic. Empresas usam a ferramenta para hospedar modelos como Llama e Mistral internamente, mantendo os dados dentro da própria infraestrutura. A solução tem mais de 170 mil estrelas no GitHub e passou de 100 milhões de downloads no Docker Hub.

Diagrama mostra o fluxo do ataque Bleeding Llama: o atacante envia um arquivo GGUF malicioso via /api/create, o servidor salva o modelo com dados vazados da memória heap e, em seguida, o /api/push envia o arquivo completo para um servidor externo controlado pelo atacante. Imagem: Cyera.

O problema é que, por padrão, o Ollama não exige autenticação. Ele também escuta em todas as interfaces de rede da máquina onde está instalado, o que significa que qualquer instância acessível pela internet está automaticamente exposta.

Como funciona a falha

Para entender o bug, é preciso saber o que são arquivos GGUF. Esse é o formato usado para armazenar os pesos dos modelos de linguagem, basicamente os dados que representam tudo que o modelo aprendeu durante o treinamento.

Os metadados do tensor original são copiados para um novo objeto com tipo atualizado, mas sem validação do tamanho real dos dados. Imagem: Cyera.

Dentro de um arquivo GGUF existem estruturas chamadas tensores, que são arrays multidimensionais de números. Cada tensor tem um campo que informa quantos elementos ele contém.

O problema está justamente aí. O Ollama não verifica se o número declarado de elementos corresponde ao tamanho real dos dados no arquivo. Um atacante pode criar um GGUF malicioso informando que o tensor tem 1 milhão de elementos quando, na prática, ele tem muito menos.

Quando o servidor tenta processar esse arquivo, ele lê muito além da área de memória reservada para aqueles dados.

Diagrama mostra como o Ollama processa um arquivo GGUF ao criar um modelo. O arquivo bruto passa pela função ggufLayer, que extrai metadados do arquivo e os tensores do modelo, estruturando tudo em uma camada interna usada nas etapas seguintes. Imagem: Cyera.

Isso é o que os pesquisadores chamam de heap out-of-bounds read, ou seja, uma leitura fora dos limites da memória alocada. O heap é a região da memória onde o sistema armazena dados em uso. No caso do Ollama, essa memória contém prompts de usuários, chaves de API, variáveis de ambiente e saídas de ferramentas conectadas ao servidor.

Por que os dados chegam intactos ao atacante

Normalmente, ao processar um arquivo GGUF, o Ollama converte os tensores de um formato para outro, o que poderia corromper os dados vazados durante o processo. Os pesquisadores encontraram uma forma de contornar isso usando uma conversão específica entre os formatos F16 e F32.

F16 e F32 são formas de representar números com diferentes níveis de precisão. A conversão de F16 para F32 é sem perda de dados, isso porque cada número passa de 2 bytes para 4 bytes sem descarte de informação. Isso significa que os dados lidos além do limite da memória chegam ao arquivo de saída exatamente como estavam na memória original.

O servidor valida o nome do modelo e os caminhos dos arquivos, mas não impede que o nome seja uma URL externa, lacuna que viabiliza a exfiltração dos dados vazados via /api/push. Imagem: Cyera.

Três chamadas de API são suficientes para o ataque completo

O ataque inteiro utiliza apenas três chamadas à API do Ollama, todas sem autenticação. Primeiro, o atacante envia o arquivo GGUF malicioso para o servidor. Depois, cria um modelo usando esse arquivo e define como nome do modelo uma URL controlada por ele.

Por fim, usa a função nativa de push do Ollama para enviar o modelo para um servidor externo.

Essa função de push existe para que usuários possam publicar modelos em repositórios remotos. O Ollama não impede que o nome do modelo seja uma URL arbitrária, o que torna possível redirecionar o envio para qualquer servidor. O arquivo enviado contém os dados vazados da memória, incluindo tudo que estava sendo processado no servidor no momento do ataque.

Diagrama mostra as duas formas de criar modelos no Ollama via /api/create: a partir de arquivos locais em formato GGUF ou a partir de um registro remoto. A ausência de validação no campo de nome do modelo permite que uma URL controlada pelo atacante seja usada no lugar de um identificador legítimo. Imagem: Cyera.

O que pode ser exposto

A Cyera demonstrou que a memória extraída contém prompts enviados por usuários, system prompts de outros modelos em execução no mesmo servidor e variáveis de ambiente da máquina hospedeira. Isso inclui chaves de API, tokens de autenticação e segredos de configuração.

Em ambientes corporativos, o impacto pode ser ainda maior. Quando o Ollama está conectado a ferramentas como o Claude Code, todas as saídas dessas ferramentas passam pelo servidor e ficam registradas na memória. Contratos de clientes, código proprietário e dados de produção podem ser expostos sem que a organização perceba.

Correção disponível e medidas recomendadas

A Ollama corrigiu a vulnerabilidade na versão 0.17.1. A recomendação imediata é atualizar todas as instâncias assim que possível. Além da atualização, as organizações devem colocar um proxy de autenticação na frente do servidor, restringir o acesso por firewall e isolar o Ollama em segmentos de rede sem exposição direta à internet.

Trecho do código-fonte do Ollama em Go mostra a função WriteTo, responsável pela conversão de tensores. A seção destacada em vermelho indica a chamada a ConvertToF32, que lê um número de elementos definido pelo próprio arquivo GGUF sem validar se esse valor corresponde ao tamanho real dos dados. Imagem: Cyera.

A Cyera também recomenda auditar instâncias em execução para verificar exposição externa. Qualquer servidor acessível pela internet deve ser tratado como potencialmente comprometido, e as credenciais que passaram por ele devem ser rotacionadas.

Acompanhe o TecMundo nas redes sociais. Para mais notícias de segurança e tecnologia, inscreva-se em nossa newsletter e canal do YouTube.