Fix for llm tool stops OpenAI keys leaking to other providers
Version 0.37.2 of the open-source command-line tool patches two cases where a user's configured OpenAI key could be sent to a third-party endpoint.
By The Agentic Times ·

Simon Willison released version 0.37.2 of llm, his open-source command-line tool for working with large language models, on 11 November 2026. The release fixes a security issue reported by Daniel de Araujo that could cause a user's configured OpenAI API key to be sent to a different provider's API endpoint.
According to the release notes, llm has a mechanism called extra-openai-models.yaml that lets people point the tool at API endpoints from other providers that are compatible with OpenAI's interface. That configuration file is now managed by the llm openai endpoint add command, which was introduced in version 0.37.
de Araujo reported two ways that mechanism could accidentally forward the wrong credential. The first is when the key named by the api_key_name setting had never actually been stored. The second is when a model configured with responses: true was run with the option -o chat_completions 1. In either case, according to Willison, the user's configured OpenAI API key could be sent to the third-party provider instead of the credential intended for that provider.
The issue is tracked in two GitHub security advisories, GHSA-v9h7-jj4g-f862 and GHSA-r639-rr7r-x72w. Willison says both are fixed in 0.37.2.
The practical risk here is credential exposure rather than remote code execution. An API key sent to a third-party endpoint lands in that provider's request handling, where the user has no visibility over how it is logged or retained. API keys for commercial model providers are billable credentials, so anyone who obtains one can spend against the owner's account.
The root cause sits in the awkward space between a bug and a misconfiguration. OpenAI-compatible endpoints are widely used because they let a single client talk to many different inference providers without code changes. The trade-off is that the client has to keep track of which credential belongs to which endpoint, and that bookkeeping is easy to get wrong when a named key is missing or when options conflict with the model's declared configuration. In the cases de Araujo reported, llm fell back to the OpenAI key rather than failing.
The pattern matters beyond this one tool. Command-line utilities and agent frameworks increasingly hold several provider credentials at once and switch between endpoints on a per-request basis. Any gap in the mapping between credential and destination becomes a leak path, and the leak is silent: the request succeeds, the model responds, and nothing in the terminal output indicates that the wrong key travelled with it.
Users of llm who have configured custom OpenAI-compatible endpoints should update to 0.37.2. Anyone who suspects their OpenAI key may have been sent to another provider would normally rotate that key, although the release notes do not say whether any keys are known to have been exposed in practice, nor do they indicate how long the issue was present.
Willison has not published further detail beyond the release notes and the two advisories. There is no indication in the source material that the flaw was exploited.
Sources
- simonwillison.nethttps://simonwillison.net/2026/Nov/11/llm
