Security fix in llm 0.37.2 prevents OpenAI key leak to other providers

Version 0.37.2 of llm, Simon Willison's command-line tool, fixes two flaws that could send the OpenAI key configured on the system to third-party endpoints compatible with the API.

What was at stake in extra-openai-models.yaml

llm is the open-source command-line tool created by Simon Willison to run language models from dozens of providers without leaving the terminal. One of the most used features for those who mix vendors is extra-openai-models.yaml: a configuration file that lets you register models served by endpoints compatible with the OpenAI API but hosted by other providers.

Since version 0.37, this registration has gotten simpler with the llm openai endpoint add command, which avoids editing the YAML by hand. Each entry defines, among other things, the endpoint address and the api_key_name field, which tells llm which key to use when authenticating with that specific provider. It's exactly at this point that Simon Willison, in a post published on November 11, 2026 on his own blog, described the fix for two security flaws.

The two leak paths fixed

The vulnerabilities were reported by Daniel de Araujo and registered as two GitHub Security Advisories: GHSA-v9h7-jj4g-f862 and GHSA-r639-rr7r-x72w. The post itself summarizes the problem directly, without further technical detours.

Daniel 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.

Simon Willison, creator of llm

Both scenarios are common in the day-to-day of those who quickly test multiple providers. In the first, the user registers a third-party endpoint, names the expected api_key_name, but never runs the command that actually stores that key (or forgets to export the corresponding variable). The original post doesn't detail the internal mechanism of the flaw, but the effect reported by Willison is that, in this situation, the OpenAI key configured on the system ended up being sent to the other provider's endpoint.

In the second scenario, the trigger is the -o chat_completions 1 flag. Some registered models have responses: true, signaling that they should be called using OpenAI's newer Responses API format. By forcing this model to use the classic chat completions format via this option, the logic that decides which key to attach to the request appears to have been bypassed, and the OpenAI key leaked again to the third-party endpoint instead of that provider's own credential.

Why this matters for those running multiple providers

Those who use llm with a single provider, directly from OpenAI, are not affected by this class of bug. The risk is real for those who build pipelines that switch between models, testing the same prompt across different providers compatible with the OpenAI API, while also keeping an official OpenAI key configured in the same environment. That's exactly the developer profile llm was designed to serve from the start.

An OpenAI API key leaked to a third-party provider is not an abstract problem: it shows up in another company's access logs, can be mistakenly reused in cross-billing systems, and, in the worst case, ends up somewhere outside the control of whoever generated it. For teams running llm in CI, model evaluation scripts, or shared notebooks, the silent leak is even more dangerous, because it doesn't produce any visible error at the moment it happens.

How to know if you were affected and what to do now

The original post doesn't include a specific retroactive diagnostic command: the practical recommendation is to treat any configuration that has already gone through the two scenarios described as potentially exposed. First of all, update the tool:

pip install -U llm
# or, if you use uv
uv tool upgrade llm

After updating, it's worth reviewing extra-openai-models.yaml itself (or the output of llm openai endpoint add when used) and checking whether every referenced api_key_name actually has a corresponding stored key. For those using models with responses: true who have already run commands with -o chat_completions 1 before November 11, 2026, the most prudent move is to rotate the exposed OpenAI key, since there's no way to know, from the client side alone, whether some third-party provider logged that credential.

The fix reinforces a point that applies to any tool bridging multiple API providers: it must fail explicitly when an expected configuration, such as an API key, doesn't exist, rather than risk silently reusing a more sensitive credential. It's this kind of detail, small on the surface, that separates a routine API call from a secret leak in production.