Simon Willison released LLM 0.37.2 on November 11, 2026 to fix two security advisories that caused the tool to send a user’s OpenAI API key to third-party endpoints. Daniel de Araujo reported both flaws, tracked as GHSA-v9h7-jj4g-f862 and GHSA-r639-rr7r-x72w. GitHub rates each one moderate, and neither carries a CVE.
Quick Take
- What: LLM sent OpenAI API keys to custom endpoints in two scenarios involving extra-openai-models.yaml configurations
- Who is affected: Users who defined custom OpenAI-compatible models with an api_base in extra-openai-models.yaml (versions 0.6–0.37.1 for the first flaw, 0.32a2–0.37.1 for the second)
- What to do: Upgrade to LLM 0.37.2 and rotate any OpenAI API key that was available while a custom api_base model was configured
In plain English
LLM is a command-line tool that lets developers talk to different AI language models. Two bugs meant that if you set up a custom model pointing to a third-party server, the tool would accidentally send your OpenAI password (called an API key) to that other server instead of the correct password. The other server’s operator could then see and use your OpenAI key. This only happened if you configured custom models in a specific way.
What you should do: If you only used the built-in OpenAI models, you were not affected. If you did set up custom models, you should update to version 0.37.2 and get a new OpenAI API key because the old one may have been sent to someone else’s server.
What happened
Both flaws sit in how LLM decides which key to send when a model defined in extra-openai-models.yaml points at a custom api_base. In the first case, a model that sets api_key_name kept OPENAI_API_KEY as its key environment variable. When the named key had never been stored, the tool fell back to the OpenAI key and sent it to the third-party endpoint instead of failing. In the second case, a model with responses: true run with the -o chat_completions 1 option built a delegate object that did not inherit needs_key, so the delegate used the stored or environment OpenAI key. In both cases nothing told the user the OpenAI key had been sent.
Only installations that define custom OpenAI-compatible models with an api_base in extra-openai-models.yaml are exposed. The first flaw affects LLM 0.6 through 0.37.1. The second affects 0.32a2 through 0.37.1. A typo in api_key_name, skipping llm keys set, or a fresh machine with only OPENAI_API_KEY exported is enough to trigger the first flaw.
What you should do
Upgrade to LLM 0.37.2. Rotate any OpenAI API key that was available while a custom api_base model was configured, because that key may have reached the provider, proxy or gateway behind the endpoint with no visible error. Configurations that use only the built-in OpenAI models are safe, because the problem is the key chosen for a custom api_base endpoint.
What it means
The advisories show that credential handling in multi-provider CLI tools requires explicit checks at every delegation point. In the first advisory, register_models set needs_key to the alias but left key_env_var pointing at OPENAI_API_KEY, so get_key fell back to the OpenAI environment variable. In the second, the delegate object created for the chat-completions path never inherited needs_key from the outer model and used its default value instead. Version 0.37.2 corrects both paths.
