Four Custodians of AI Provider Keys, Hit in Sixteen Days

Fireworks, OpenCode and Railway are hosted platforms that store customer secrets, and an intruder reached each one. Fireworks says internal credentials were used to capture evaluation-job variables and that it found no access to customer models, datasets or inference traffic. OpenCode's Console was reached through a legacy system being retired. Railway says some encrypted variables were obtained in decrypted form.

LiteLLM is different. It is the open source gateway many teams run themselves, and the poisoned release ran inside their own environments. It reads the proxy's provider-key table directly, takes cloud credentials, SSH keys and environment variables, and installs a backdoor that checks in hourly.

LiteLLM says the attacker used three engineers' GitHub accounts, apparently through stolen GitHub CLI OAuth tokens: one changed the pipeline, one approved the release, one deleted the workflow records. Branch protection stopped the first attempt, then a token belonging to an organization owner overrode it. The build ran from a look-alike repository, Berri-AI instead of BerriAI, and the official source tag stayed clean. JFrog notes that reading the source would have missed it.

LiteLLM has not said how the tokens were stolen. Hijacked publishing access is a repeat pattern in our own briefings: in arrayref, a compromised maintainer account pushed malicious crates to crates.io.

Only OpenCode ties its breach to distillation, the pulling of a strong model's answers at scale to train a cheaper copy. Anthropic says distillers often use stolen API credentials from legitimate customers. Railway says its incident is part of a series aimed at AI inference providers. Fireworks and LiteLLM have named no motive, and no source links the four incidents to one actor.

Our read, not the vendors': a gateway or platform holds keys for many customers in one place, so one intrusion yields a pile of paid, aged accounts with normal usage history. That is plausible, not proven. Stored tokens as the way in is not new: in Salesloft Drift, attackers stole the OAuth tokens a vendor held for customers and used them against customer CRMs.

On Mar 24, versions 1.82.7 and 1.82.8 reached PyPI for about 40 minutes after attackers took LiteLLM's publishing token through a poisoned Trivy scanner (Cloud Security Alliance). CloudSEK later counted more than 2,500 organizations in the captured data, which means potential exposure, not confirmed compromise. JFrog says the October release uses different payloads and infrastructure and that no evidence links it to the March actor. Both went after the same asset: the keys a gateway holds.

In the Agentic Applications Top 10, ASI04 Agentic Supply Chain Vulnerabilities covers LiteLLM and the hosted custodians, and ASI03 Identity & Privilege Abuse covers the stolen keys. In the LLM Applications Top 10, LLM02 Sensitive Information Disclosure names API keys as protected information, and LLM06 Unbounded Consumption covers what stolen keys are used for, including distillation theft.

The OWASP GenAI Security Project does not endorse any product, service or tool, including Optimus Labs. We cite its lists to classify these incidents.

The eight practices for storing a customer's key are in briefing #13. LiteLLM adds a question for any vendor: who can change what you ship? Our read: keep an organization owner's token out of developer tooling, require approval from an account not reachable the same way, and copy workflow logs where an account cannot delete them. Environment variables are a favorite place to look: in the Coder registry hijack, poisoned modules scraped credentials from environment variables, config files and shell history, and no CVE was assigned.

As of Oct 21, 2026, unpublished: how LiteLLM's GitHub tokens were stolen, how many Railway accounts were read and how the attacker got in, how the Fireworks intruder got the internal credentials, whether the four share an actor, and how many of the stolen keys are in use today.