LLM 0.37.2: falha podia enviar sua chave da OpenAI a outro provedor

Simon Willison publicou em 11 de novembro de 2026 a release 0.37.2 do LLM, uma correção de segurança. Ela fecha dois caminhos pelos quais a chave da OpenAI configurada na ferramenta podia ser enviada a outro provedor compatível com OpenAI, cadastrado no extra-openai-models.yaml.

Segundo o anúncio no blog de Simon Willison, as falhas foram relatadas por Daniel de Araujo e registradas nos advisories GHSA-v9h7-jj4g-f862 e GHSA-r639-rr7r-x72w; já o advisory GHSA-r639-rr7r-x72w credita o relato ao usuário GitHub BluePlexus. O público afetado é quem usa o LLM apontando para endpoints de terceiros.

Como os endpoints compatíveis com OpenAI funcionam no LLM

O LLM permite usar APIs de outros provedores que seguem o formato da OpenAI. Isso é feito pelo arquivo extra-openai-models.yaml, onde cada modelo ganha um api_base (o endereço do provedor) e, normalmente, um api_key_name.

Desde a versão 0.37, lançada em 2 de novembro de 2026, o LLM ganhou o comando llm openai endpoint add para cadastrar esses modelos sem editar o YAML à mão. Hoje também existem os subcomandos llm openai endpoint list e llm openai endpoint path, usados mais adiante neste artigo.

Se liga: a 0.37.2 não é o lançamento desses comandos. Ela é uma correção posterior, focada em segurança.

E o que é o api_key_name? É o nome de uma chave que você salvou com llm keys set. Segundo a documentação de outros modelos, se o provedor é o OpenRouter, por exemplo, você roda llm keys set openrouter e coloca openrouter no api_key_name.

Quais eram as duas falhas que vazavam a chave da OpenAI

O anúncio no blog de Simon Willison descreve dois caminhos diferentes.

O primeiro acontecia quando a chave indicada em api_key_name nunca tinha sido armazenada. Nesse cenário, em vez de parar, o LLM podia enviar o valor da variável de ambiente OPENAI_API_KEY para o endpoint de terceiros.

O segundo está registrado no GHSA-r639-rr7r-x72w. Um modelo com responses: true e api_base, executado com -o chat_completions 1, enviava a chave da OpenAI armazenada ou a variável OPENAI_API_KEY ao endpoint. O mesmo valia para llm openai endpoint URL --responses -o chat_completions 1 rodado sem --key.

Em ambos os casos, o destino era o provedor que você mesmo cadastrou, não um servidor aleatório. Ainda assim, é uma chave de outra conta indo parar onde não deveria.

O que a versão 0.37.2 corrige na prática

No primeiro caso, modelos com api_base e api_key_name não enviam mais a OPENAI_API_KEY quando a chave nomeada não foi salva. Agora o comando falha com o erro No key found.

Tome cuidado! Se você tinha um api_key_name sem chave correspondente e tudo "funcionava", depois de atualizar vai começar a ver esse erro. A solução é rodar llm keys set com o nome exato usado no YAML.

No segundo caso, modelos com responses: true e api_base deixam de enviar a chave da OpenAI armazenada ou a OPENAI_API_KEY quando rodam com -o chat_completions 1.

De bônus, a release também corrigiu -a/--attachment e --at/--attachment-type para funcionarem com pipes, como a substituição de processos do Bash.

Como atualizar o LLM para a 0.37.2

O comando depende de como você instalou a ferramenta. A documentação de setup lista estas opções:

pip install -U llm
pipx upgrade llm
uv tool upgrade llm
brew upgrade llm

Rode só o que corresponde à sua instalação. Se você usa Homebrew e a versão nova ainda não apareceu por lá, a alternativa é:

llm install -U llm

Preciso rotacionar minha chave da OpenAI?

Depende de como você usava os endpoints. Comece localizando o arquivo de configuração:

llm openai endpoint path

No macOS, o caminho é ~/Library/Application Support/io.datasette.llm/extra-openai-models.yaml. Abra o arquivo e revise cada modelo que tem api_base.

Faça duas perguntas. Algum api_key_name aponta para uma chave que você nunca salvou com llm keys set? Algum modelo com responses: true foi rodado com -o chat_completions 1, ou você usou --responses -o chat_completions 1 sem --key?

Se a resposta for sim para qualquer uma, a chave da OpenAI pode ter chegado ao provedor de terceiros. Na nossa avaliação, rotacionar a chave é a medida prudente, mesmo sem sinal de uso indevido.

Se a resposta for não para as duas, a atualização já resolve.

Próximo passo

Atualize agora, revise o YAML e decida sobre a rotação com base nas duas perguntas acima.

Depois, salve com llm keys set a chave de cada provedor referenciado em api_key_name, para que cada endpoint use a credencial dele e nada mais.

Se quiser entender os comandos de endpoint que entraram antes desta correção, o anúncio da 0.37 explica a novidade.

Acompanhe os tutoriais do Hora de Codar no YouTube. Se quiser aprofundar o contexto, veja Disney e OpenAi fecham acordo!.