Should I rotate my OpenAI API key after the LLM 0.37.2 advisories?

Rotate the key if your LLM installation defined a custom model with an api_base in extra-openai-models.yaml while an OpenAI key was stored or exported. Under either advisory the key reached that endpoint silently, so the operator of the provider, proxy or gateway may hold it. Installations that never configured a custom api_base model are not affected.

Which LLM configurations are safe from the OpenAI key leak?

Configurations that use only the built-in OpenAI models are safe, because the problem is the key chosen for a custom api_base endpoint. For the first advisory, a custom model is safe once the key named by api_key_name has actually been stored with llm keys set. For the second, the leak needed responses: true together with the -o chat_completions 1 option.

Why did LLM fall back to the OpenAI key for a third-party endpoint?

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.

MEDVulnerability

LLM 0.37.2: the CLI could send your OpenAI key to another provider

LLM sent a user's OpenAI API key to third-party endpoints under two configurations, and version 0.37.2 stops both.

November 11, 2026 · Simon Willison · Research by Daniel de Araujo

LLM

MEDVulnerability

LLM, Simon Willison's command-line tool for language models, sent a user's configured OpenAI API key to third-party endpoints in two separate cases. Daniel de Araujo reported both, and version 0.37.2 fixes them.

01What happened

Simon Willison released LLM 0.37.2 on November 11, 2026 to fix two security advisories, GHSA-v9h7-jj4g-f862 and GHSA-r639-rr7r-x72w. Daniel de Araujo reported both. GitHub rates each one moderate, and neither carries a CVE.

02How it works

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, a model that sets api_key_name kept OPENAI_API_KEY as its key environment variable, so 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, 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.

03Who is affected

Only installations that define custom OpenAI-compatible models with an api_base in extra-openai-models.yaml are exposed, and the affected version ranges are listed below. 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.

04What to 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.

Questions people ask

Should I rotate my OpenAI API key after the LLM 0.37.2 advisories?: Rotate the key if your LLM installation defined a custom model with an api_base in extra-openai-models.yaml while an OpenAI key was stored or exported. Under either advisory the key reached that endpoint silently, so the operator of the provider, proxy or gateway may hold it. Installations that never configured a custom api_base model are not affected.
Which LLM configurations are safe from the OpenAI key leak?: Configurations that use only the built-in OpenAI models are safe, because the problem is the key chosen for a custom api_base endpoint. For the first advisory, a custom model is safe once the key named by api_key_name has actually been stored with llm keys set. For the second, the leak needed responses: true together with the -o chat_completions 1 option.
Why did LLM fall back to the OpenAI key for a third-party endpoint?: 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.

Sources 4 links, all fetched

1simonwillison.netRelease Announcement
2github.comGHSA-v9h7-jj4g-f862
3github.comGHSA-r639-rr7r-x72w
4github.comLLM Releases