Correção de segurança na llm 0.37.2 evita vazamento de chave da OpenAI para outros provedores

A versão 0.37.2 da ferramenta de linha de comando llm, de Simon Willison, corrige duas falhas que podiam enviar a chave da OpenAI configurada no sistema para endpoints de terceiros compatíveis com a API.

O que estava em jogo no extra-openai-models.yaml

A llm é a ferramenta de linha de comando open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) → criada por Simon Willison para rodar modelos de linguagem↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI → de dezenas de provedores sem sair do terminal. Um dos recursos mais usados por quem mistura fornecedores é o extra-openai-models.yaml: um arquivo de configuração que permite cadastrar modelos servidos por endpoints compatíveis com a API da OpenAI, mas hospedados por outros provedores.

Desde a versão 0.37, esse cadastro ficou mais simples com o comando llm openai endpoint add, que evita editar o YAML na mão. Cada entrada define, entre outras coisas, o endereço do endpoint e o campo api_key_name, que diz à llm qual chave usar ao autenticar naquele provedor específico. É exatamente nesse ponto que Simon Willison, em post publicado em 11 de novembro de 2026 no próprio blog, descreveu a correção de duas falhas de segurança.

As duas formas de vazamento corrigidas

As vulnerabilidades foram reportadas por Daniel de Araujo e registradas como duas GitHub Security Advisories: GHSA-v9h7-jj4g-f862 e GHSA-r639-rr7r-x72w. O próprio post resume o problema de forma direta, sem rodeios técnicos adicionais.

Daniel relatou duas formas pelas quais isso poderia acidentalmente enviar sua chave de API da OpenAI configurada para um desses provedores: se a chave nomeada por api_key_name nunca tivesse sido armazenada, ou se um modelo com responses: true fosse executado com -o chat_completions 1.

Simon Willison, criador da llmDaniel reported two ways this could accidentally send your configured OpenAI API key to one of those providers: if the key named by api_key_name had never been stored, or if a responses: true model was run with -o chat_completions 1.

Os dois cenários são comuns no dia a dia de quem testa vários provedores rapidamente. No primeiro, o usuário cadastra um endpoint de terceiro, dá um nome ao api_key_name esperado, mas nunca chega a rodar o comando que de fato guarda essa chave (ou esquece de exportar a variável correspondente). O post original não detalha o mecanismo interno da falha, mas o efeito relatado por Willison é que, nessa situação, a chave da OpenAI configurada no sistema acabava sendo enviada ao endpoint do outro provedor.

No segundo cenário, o gatilho é a flag -o chat_completions 1. Alguns modelos cadastrados têm responses: true, sinalizando que devem ser chamados pelo formato mais novo de Responses API da OpenAI. Ao forçar esse modelo a usar o formato clássico de chat completions via essa opção, a lógica que decide qual chave anexar à requisição parece ter sido ignorada, e a chave da OpenAI voltava a vazar para o endpoint de terceiro no lugar da credencial própria daquele provedor.

Por que isso importa pra quem roda múltiplos provedores

Quem usa a llm com um único provedor, direto da OpenAI, não é afetado por essa classe de bug. O risco é real para quem monta pipelines que alternam entre modelos, testando o mesmo prompt em diferentes provedores compatíveis com a API da OpenAI, e mantém, ao mesmo tempo, uma chave oficial da OpenAI configurada no mesmo ambiente. Esse é exatamente o perfil de dev que a llm foi pensada para atender desde o início.

Uma chave de API da OpenAI vazada para um provedor terceiro não é um problema abstrato: ela aparece em logs de acesso de outra empresa, pode ser reaproveitada por engano em sistemas de billing cruzado e, no pior caso, acaba em algum lugar fora do controle de quem a gerou. Para times que rodam a llm em CI, scripts de avaliação de modelos ou notebooks compartilhados, o vazamento silencioso é ainda mais perigoso, porque não gera nenhum erro visível no momento em que acontece.

Como saber se você foi afetado e o que fazer agora

Não há, no post original, um comando específico de diagnóstico retroativo: a recomendação prática é tratar qualquer configuração que já tenha passado pelos dois cenários descritos como potencialmente exposta. Antes de mais nada, atualize a ferramenta:

pip install -U llm
# ou, se você usa uv
uv tool upgrade llm

Depois de atualizar, vale revisar o próprio extra-openai-models.yaml (ou a saída de llm openai endpoint add quando usado) e conferir se todo api_key_name referenciado tem, de fato, uma chave armazenada correspondente. Para quem usa modelos com responses: true e já rodou comandos com -o chat_completions 1 antes de 11 de novembro de 2026, o mais prudente é rotacionar a chave da OpenAI exposta, já que não há como saber, só pelo lado do cliente, se algum provedor terceiro registrou aquela credencial em log.

A correção reforça um ponto que vale para qualquer ferramenta que faça ponte entre múltiplos provedores de API: é preciso falhar de forma explícita quando uma configuração esperada, como uma chave de API, não existe, em vez de arriscar reaproveitar silenciosamente uma credencial mais sensível. É esse tipo de detalhe, pequeno na superfície, que separa uma chamada de API comum de um vazamento de segredo em produção.

Fonte: Simon Willison