Latest in AI
LLM 0.37.2 API Key Fix: Who Is Affected and What to Check
Two credential-routing bugs can send an OpenAI key to a custom endpoint; upgrading fixes future requests, not past exposure.
LLM 0.37.2 fixes two bugs that could send your OpenAI API key to a different provider's endpoint. If you use Simon Willison's CLI or Python library with custom OpenAI-compatible models, check the configuration before making more requests. This is a credential-routing problem, not a claim that OpenAI itself was breached.
Which LLM configurations are affected?
The first advisory covers versions from 0.6 up to, but not including, 0.37.2. A custom model with both api_base and api_key_name could fall back to OPENAI_API_KEY when the named key was missing. A misspelled alias or a new machine without the stored provider key could trigger it. Ordinary Chat models were affected too.
The second advisory covers versions from 0.32a2 to before 0.37.2. A custom endpoint configured with responses: true could receive the stored OpenAI key or its environment-variable equivalent when invoked with -o chat_completions 1. That path could fail even though the normal Responses request used no OpenAI credential. A correctly stored provider-specific key passed through from the outer model avoided this particular case.
Both advisories are rated Moderate. They describe unintended disclosure to the configured endpoint, not proof that every user was affected or that a provider misused a received key.
Upgrade first, then inspect the endpoint configuration
The 0.37.2 release notes confirm both fixes. Upgrade LLM through the package manager or environment you used to install it, then check the version in the actual shell, service or notebook that runs your jobs. Updating a laptop's CLI does not update a separate virtual environment or container.
Review extra-openai-models.yaml and the commands your scripts execute. For each custom api_base, identify the intended provider and credential alias. Confirm that the named key exists without printing its value into logs, tickets or screenshots. Pay particular attention to newly provisioned machines, recently renamed aliases and scripts that switch Responses models to Chat Completions.
With the first fix, a missing named key now produces a No key found error instead of silently borrowing the OpenAI environment key. That error is a useful stop sign. Store the intended provider's credential under the correct alias rather than making the warning disappear by reusing an unrelated secret.
Decide whether an old key needs replacing
An upgrade prevents the documented routing mistakes on future calls; it cannot retract a credential already transmitted. If your history matches an affected configuration and you made requests to an external endpoint, treat the OpenAI key as potentially disclosed. Replace it through the issuing service, update the applications that legitimately use it and review usage for unexpected activity.
A self-hosted gateway needs a more specific review. Establish who operates it, whether it retained authorization headers and which people or systems could access those records. A request reaching infrastructure you control is not automatically a public leak, but it can still cross a credential boundary you did not intend.
Do not test the old behavior against a live third-party endpoint using a real key. If your team needs a regression test, use a controlled mock endpoint and a disposable marker string. The test should assert which credential would leave the process, without sending a production secret anywhere.
Why a successful request was not a sufficient test
The dangerous part of this failure is that a request could keep working. A fallback intended to make configuration more forgiving crossed from one provider's credential into another provider's URL. In the second case, switching API modes constructed a delegated client whose key-selection behavior differed from the original client.
For teams maintaining multi-provider tooling, test the combination of endpoint, authentication and API mode together. Include missing aliases and alternate execution paths, not just the correctly configured happy path. A client that fails loudly when the intended key is absent is easier to operate safely than one that finds another credential and carries on.
I’m Paras. I work at the intersection of AI, engineering and distribution.
I help developer-tool teams explain security fixes and technical releases clearly, so users understand what to change and why.