llm 0.37.2 closes a leak: your OpenAI key could be sent to a third-party provider

Simon Willison's llm utility has long become a Swiss Army knife for many developers who talk to language models from the terminal. It can reach not only OpenAI but any provider with an OpenAI-compatible API. That very flexibility is where the problem was found: version 0.37.2 fixes a vulnerability that could cause a secret OpenAI key to be sent to the wrong recipient.

What happened

llm has a mechanism for connecting third-party endpoints through the extra-openai-models.yaml file. Starting with version 0.37, it is managed by a dedicated command, llm openai endpoint add. The idea is simple: many providers and local servers replicate the OpenAI API format, so they can be described in a config and used like ordinary models.

Researcher Daniel de Araujo discovered two ways in which your OpenAI key could end up on such a third-party endpoint. Two security advisories have been filed on GitHub: GHSA-v9h7-jj4g-f862 and GHSA-r639-rr7r-x72w.

• The key for api_key_name was not saved. For a third-party endpoint, you specify the name under which its key is stored. If that key was never saved, the tool should not have substituted anything else in its place. According to the vulnerability description, it substituted the configured OpenAI key.
• A model with responses: true was run with -o chat_completions 1. This combination switched the request to a different mode of operation, and the key could again go to the wrong place.

In both cases no malicious intent is required. It is enough to forget to add a key or to pass an option, and the secret ends up with a third party.

Why this is unpleasant

Imagine a typical setup. You have an OpenAI key saved in llm for work tasks. You connected the endpoint of a small provider or someone else's proxy to compare models. You entered the key name in the config but hadn't yet added the key itself. You run a command, and a request carrying your OpenAI key goes to a server you don't control.

That provider ends up with a working key tied to your limit and billing. Any third-party endpoint, especially a homemade or experimental one, can potentially log it. This is an ordinary secret leak caused by a configuration error, not an exotic attack.

What to do

1. Update to llm 0.37.2. This is the main step, and it closes both scenarios.
2. Open extra-openai-models.yaml and check which endpoints are described there. Make sure each has an api_key_name and that the corresponding key is actually saved.
3. Recall whether you ever ran models with responses: true together with -o chat_completions 1. If so, and the endpoint does not belong to OpenAI, it is better to consider the key compromised.
4. At the slightest doubt, reissue your OpenAI key. It is cheap, and there is no need for extra risk.

There is also a general lesson. Keys for different providers should be strictly separated. If you have several endpoints, your OpenAI key should not be the value the tool substitutes by default. For experiments with third-party APIs, it makes sense to create separate keys with limited quotas.

Limitations

The release note gives no details on exactly how the vulnerability is exploited and no data on real cases of leaks. The author describes the problem as accidental sending of a key, not as an attack that can be launched remotely. This reduces the severity but does not remove the need to update: configuration mistakes happen to everyone.

A similar class of bugs occurs in other tools where one client works with several providers. Anything that accepts an "OpenAI-compatible" address while also storing an OpenAI key is worth checking for the same behavior: what gets substituted when no key is found for the address.

Practical takeaway

If you use llm only with OpenAI, this barely affects you. If you have connected third-party endpoints, update now and check your config. And with any suspicious combination of options, reissue your key.