szybnev/cve-2026-7482Reproduz a leitura fora dos limites (heap out-of-bounds) da CVE-2026-7482 no carregamento e na quantização de GGUF do Ollama, com análise diferencial de artefatos quantizados para demonstrar a influência do OOB.
Este repositório contém meu script local de reprodução para a CVE-2026-7482, uma leitura fora dos limites (heap out-of-bounds read) nos caminhos vulneráveis de carregamento e quantização de GGUF do Ollama.
O resultado importante deste trabalho é restrito: consegui fazer a condição de Heap OOB ocorrer de forma confiável e produzir artefatos GGUF quantizados influenciados por OOB. Não consegui demonstrar um impacto claro de caixa-preta, como recuperação confiável de segredos em texto puro ou extração direta de strings canário do artefato resultante.
O exp.py cria dois arquivos GGUF:
Ele envia ambos os arquivos para uma instância vulnerável do Ollama através da API local do Ollama, aciona a quantização com /api/create, copia os blobs GGUF gerados do contêiner Docker local e compara a saída maliciosa com a saída do controle de zeros.
A comparação diferencial é útil porque mostra que o caminho de quantização vulnerável usou bytes que não estavam presentes no arquivo GGUF malicioso original. Nos meus testes, esse comportamento foi estável no Ollama 0.17.0 e rejeitado pelo caminho corrigido no 0.17.1.
requests0.17.0 exposto em uma porta de API localollama-old-testExemplo de alvo de laboratório:
docker run -d --name ollama-old-test -p 11435:11434 ollama/ollama:0.17.0
Instale a única dependência Python:
python3 -m pip install requests
Execute o teste padrão contra http://localhost:11435 e o contêiner ollama-old-test:
python3 exp.py
Argumentos explícitos:
python3 exp.py http://localhost:11435 ollama-old-test Q4_K_M F16
python3 exp.py http://localhost:11435 ollama-old-test Q8_0 F16
python3 exp.py http://localhost:11435 ollama-old-test Q8_0 F32
O script grava artefatos locais como:
malicious_model.ggufcontrol_model.ggufquantized_model.ggufcontrol_quantized_model.ggufq8_dequantized_f32.binq8_pseudo_f16.binq8_pseudo_f16.txtNos meus testes locais, a versão vulnerável do Ollama criou saídas quantizadas onde o payload do tensor malicioso diferia de um tensor de controle de zeros, apesar de o arquivo GGUF malicioso não conter esses bytes.
Isso é suficiente para mostrar um artefato influenciado por OOB. Não é suficiente para afirmar divulgação prática de dados em caixa-preta.
Também testei dados no estilo canário em prompts de modelo concorrentes e pesquisei nos artefatos gerados, nos bytes float32 desquantizados Q8_0 e na saída de reconstrução pseudo-F16. Não recuperei canários exatos nem fragmentos significativos de texto puro.
A provável razão é que os bytes não são copiados diretamente como memória heap bruta. Eles passam pelo pipeline de conversão e quantização do modelo:
bytes de heap -> interpretados como valores de tensor F16/F32 -> convertidos/quantizados -> saída de tensor GGUF
Esse caminho é com perdas, especialmente com formatos quantizados como Q4_K_M. O Q8_0 preserva mais informações numéricas do que o Q4_K_M, mas ainda assim não produziu recuperação confiável de texto puro nos meus testes no estilo caixa-preta.
Este é um auxiliar de reprodução em laboratório local e análise de artefatos.
Ele não fornece uma primitiva confiável de exfiltração remota de segredos. Também exige acesso local ao Docker para copiar o blob gerado pelo Ollama do contêiner de teste, portanto a etapa de análise não é um fluxo de trabalho puramente remoto de caixa-preta.
A conclusão prática dos meus testes é:
Também existe um repositório PoC separado por 0x0OZ:
Essa implementação demonstra um fluxo de trabalho mais forte no estilo caixa-branca, enviando o artefato de modelo gerado para um registro controlado. Com a correção do fluxo de upload para registro do meu PR, ele é concluído corretamente no meu laboratório local:
Mesmo com esse caminho melhor de coleta de artefatos de ponta a ponta, a mesma ressalva de qualidade de dados permanece importante: a saída são dados quantizados/transformados pelo modelo, não um despejo direto de heap bruto.
Este repositório é apenas para pesquisa de vulnerabilidades autorizada e reprodução defensiva. Teste somente contra sistemas que você possui ou para os quais tenha permissão explícita de avaliação.