Falha `CVE-2026-7482` no Ollama expõe memória do processo por arquivo `GGUF` malformado

Leitura fora dos limites no carregador de modelos permite que instâncias expostas do Ollama vazem variáveis de ambiente, chaves de API, prompts e dados de conversas em memória.

Componente	Carregador de modelos GGUF do Ollama, com processamento em fs/ggml/gguf.go e server/quantization.go durante WriteTo().
Versões	Ollama anterior à versão 0.17.1 para CVE-2026-7482; no Windows, falhas de atualização foram descritas em instalações 0.12.10 até 0.17.5, com relato técnico também citando exposição até 0.22.0.
Vetor	Envio remoto e não autenticado de um arquivo GGUF manipulado ao endpoint /api/create, com deslocamento e tamanho de tensor declarados além do comprimento real do arquivo.
Impacto	Leitura fora dos limites do heap do processo, com vazamento condicionado de variáveis de ambiente, chaves de API, prompts de sistema, artefatos de ferramentas integradas e conversas concorrentes.
Artefatos	CVE-2026-7482, /api/create, /api/push, GGUF, WriteTo(), CVE-2026-42248, CVE-2026-42249, OLLAMA_UPDATE_URL, %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup.
Prioridade	Atualizar o Ollama, retirar APIs expostas da internet, exigir autenticação por proxy ou gateway, revisar logs de criação e envio de modelos e isolar instâncias que processaram arquivos GGUF não confiáveis.

Resumo técnico

A vulnerabilidade CVE-2026-7482 afeta o fluxo de criação de modelos do Ollama quando a instância recebe um arquivo GGUF controlado por atacante. O problema é uma leitura fora dos limites no heap durante o carregamento e a quantização do modelo. A condição nasce quando metadados do tensor informam deslocamento e tamanho que não correspondem ao comprimento real do arquivo. Ao processar esses valores, o servidor passa a ler memória além do buffer alocado para o conteúdo recebido. Como a API REST do Ollama não fornece autenticação nativa, instâncias publicadas diretamente em rede ou expostas por configuração permissiva ficam em uma superfície crítica, principalmente quando o endpoint /api/create está acessível por origem não confiável.

O risco técnico não se limita ao arquivo enviado. O processo do Ollama pode manter em memória dados sensíveis usados durante inferência local, integração com ferramentas de desenvolvimento e atendimento simultâneo de usuários. Em ambientes reais, essa memória pode conter variáveis de ambiente, chaves de API, prompts de sistema, trechos de código proprietário, entradas e saídas de conversas e artefatos produzidos por ferramentas conectadas ao servidor. A exploração bem-sucedida permite transformar a criação de um modelo em um canal de extração de dados do processo. A pontuação CVSS informada para CVE-2026-7482 é 9.1, refletindo o vetor remoto, a ausência de autenticação como pré-condição e o impacto direto sobre confidencialidade.

Fluxo técnico

O fluxo de exploração começa com um arquivo GGUF especialmente construído. Esse formato armazena modelos de linguagem para execução local e inclui metadados necessários para localizar tensores dentro do arquivo. Na falha, o atacante declara dimensões, deslocamentos ou tamanhos que fazem o carregador acreditar que existe uma região de dados maior do que a área efetivamente presente no arquivo. Quando o Ollama processa a criação do modelo pelo endpoint /api/create, o caminho de código associado a fs/ggml/gguf.go e server/quantization.go chega à rotina WriteTo(). O uso do pacote unsafe nesse ponto remove garantias de segurança de memória que normalmente impediriam leituras fora da região alocada.

Depois da leitura fora dos limites, os bytes obtidos do heap podem ser incorporados ao artefato resultante da criação ou quantização. O caminho descrito para extração envolve o endpoint /api/push, que pode enviar o modelo resultante a um registro controlado pelo atacante. Isso transforma a instância vulnerável em origem de vazamento: a requisição inicial aciona o processamento malicioso, e a operação posterior transporta o material contaminado por fragmentos de memória. A exploração exige que o atacante consiga alcançar a API do Ollama e acionar criação de modelo com conteúdo fornecido por ele. Não há necessidade de credenciais quando a instância foi publicada sem camada externa de autenticação.

A mesma divulgação técnica também descreve duas falhas independentes no mecanismo de atualização do Ollama para Windows. CVE-2026-42248 é uma ausência de verificação de assinatura antes da instalação do binário de atualização. CVE-2026-42249 é uma travessia de caminho causada pela montagem do diretório local de preparação a partir de cabeçalhos HTTP sem sanitização suficiente. Quando combinadas, essas falhas permitem que uma resposta de atualização controlada direcione um executável para a pasta de inicialização do Windows e obtenha execução persistente no próximo login do usuário. A cadeia depende de capacidade de influenciar o servidor de atualização alcançado pelo cliente, de AutoUpdateEnabled ativo e de um caminho como OLLAMA_UPDATE_URL apontando para uma origem controlada, inclusive sobre HTTP em um cenário local ou intermediado.

Superfície afetada

A exposição principal está em servidores Ollama acessíveis pela rede, especialmente aqueles publicados na internet ou em segmentos internos amplos sem proxy de autenticação. O endpoint /api/create é a peça crítica para CVE-2026-7482, porque aceita o arquivo GGUF que dispara a leitura fora dos limites. O endpoint /api/push aumenta o impacto quando o atacante consegue usá-lo para exportar o artefato gerado a um registro sob seu controle. A presença de mais de centenas de milhares de servidores potencialmente alcançáveis torna o problema relevante para ambientes de pesquisa, desenvolvimento, engenharia de dados e automação que adotaram inferência local sem a mesma disciplina de exposição aplicada a serviços de produção.

O impacto cresce quando o Ollama está integrado a ferramentas de codificação, agentes internos, pipelines de análise, assistentes com acesso a repositórios ou fluxos que injetam segredos no ambiente do processo. Como dados de usuários concorrentes e respostas de ferramentas podem residir temporariamente no heap, a falha tem efeito transversal: um atacante que envia um modelo malformado pode capturar fragmentos que pertencem a sessões diferentes da sua própria requisição. No Windows, a superfície adicional fica no cliente desktop que inicia com o login, escuta em 127.0.0.1:11434 e consulta atualizações em segundo plano por /api/update. Mesmo quando o serviço está limitado ao loopback, manipulações locais ou de atualização podem transformar a rotina de atualização em persistência no perfil do usuário.

• Instâncias Ollama anteriores a 0.17.1 com /api/create acessível a usuários não confiáveis ou à internet.
• Servidores que armazenam chaves, tokens, prompts de sistema ou credenciais em variáveis de ambiente do processo.
• Ambientes em que o Ollama recebe saídas de ferramentas de desenvolvimento, automação, repositórios ou agentes conectados.
• Clientes Ollama para Windows com atualização automática ativa e caminho de atualização influenciável pelo atacante.
• Perfis Windows em que a pasta %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup possa receber binários gravados pelo fluxo de atualização.

Hunting e telemetria

A investigação deve começar pelos logs de acesso à API do Ollama e por qualquer proxy reverso, gateway ou balanceador colocado à frente do serviço. Requisições POST para /api/create com arquivos GGUF incomuns, tamanhos desproporcionais, falhas de criação de modelo, mensagens de erro de quantização ou criação seguida rapidamente de /api/push para registros externos são sinais fortes de abuso. Também é necessário revisar conexões de saída originadas pelo processo do Ollama para domínios ou endereços que não fazem parte de registros internos autorizados. Como o vazamento pode ocorrer dentro de um artefato de modelo, a telemetria de rede deve correlacionar criação de modelo, escrita em disco e envio subsequente.

No endpoint, operadores devem procurar reinicializações inesperadas do processo, aumento de uso de memória durante criação de modelos, arquivos de modelo criados por usuários desconhecidos e artefatos com metadados GGUF inconsistentes. Em ambientes de desenvolvimento, a análise deve incluir histórico de comandos, automações e agentes que tenham enviado modelos ao servidor. Para Windows, a caça deve verificar alterações na pasta de inicialização, binários recém-gravados no perfil do usuário, execução no momento do login e modificações de variáveis como OLLAMA_UPDATE_URL. A ausência de assinatura válida em executáveis associados ao atualizador e a presença de caminhos anômalos durante staging são indicadores de comprometimento ou tentativa.

• Requisições POST para /api/create vindas de endereços externos, contas desconhecidas ou segmentos que não deveriam criar modelos.
• Sequência curta entre /api/create e /api/push, principalmente quando o destino é um registro externo não aprovado.
• Arquivos GGUF com metadados de tensor cujo deslocamento ou tamanho excede o comprimento real do arquivo.
• Conexões de saída do processo Ollama para registros de modelos, hosts HTTP ou destinos não catalogados.
• Criação ou modificação de executáveis em %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup após atividade de atualização.
• Uso ou alteração de OLLAMA_UPDATE_URL, especialmente apontando para HTTP ou infraestrutura local não gerenciada.

Mitigação

A primeira ação é atualizar o Ollama para uma versão corrigida para CVE-2026-7482, garantindo que instâncias anteriores a 0.17.1 não permaneçam em execução. A atualização deve ser acompanhada de redução imediata de superfície: remover exposição direta da API, restringir origem por firewall, publicar somente atrás de proxy autenticado ou gateway de API e negar criação de modelos a usuários ou redes não confiáveis. Como a API REST não autentica por padrão, confiar apenas no bind de rede ou em obscuridade de porta é insuficiente para ambientes compartilhados. Instâncias que já estiveram expostas devem ser tratadas como potencialmente acessadas, com revisão de logs, modelos gerados e tráfego de saída.

A contenção deve incluir rotação dos segredos que possam ter residido no processo: chaves de API, tokens de ferramentas, credenciais de repositórios, variáveis usadas por agentes e qualquer segredo injetado no ambiente do serviço. Também é recomendável separar instâncias por sensibilidade, evitando que servidores usados para experimentação com modelos não confiáveis compartilhem processo, ambiente ou permissões com fluxos que manipulam código, contratos, dados de clientes ou credenciais operacionais. Para o Windows, a mitigação provisória indicada é desativar atualizações automáticas e remover o atalho do Ollama da pasta de inicialização enquanto as falhas do atualizador não estiverem corrigidas no ambiente afetado. Após a limpeza, a validação deve confirmar que nenhum binário persistente permaneceu no perfil do usuário e que a rotina de atualização não executa payloads sem verificação de integridade.

• Atualizar servidores Ollama afetados por CVE-2026-7482 e bloquear versões anteriores a 0.17.1 em inventário e implantação.
• Colocar todas as instâncias atrás de autenticação, autorização e filtragem de origem; não expor /api/create diretamente à internet.
• Bloquear ou controlar /api/push para impedir envio de artefatos a registros externos não aprovados.
• Revisar logs de API, proxy e rede desde o período de exposição e isolar instâncias com criação de modelos suspeita.
• Rotacionar segredos presentes no ambiente do processo ou enviados por ferramentas conectadas ao Ollama.
• No Windows, desativar atualização automática e remover atalhos em %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup até validação da correção.
• Auditar OLLAMA_UPDATE_URL, diretórios de staging e binários de atualização para detectar manipulação de caminho ou ausência de assinatura.