An OAuth token ended up in a log file, and a few steps later a poisoned package was sitting on PyPI. That's the whole story, and it should bother you more than the malware does.
What happened
On October 21, 2026, LiteLLM 1.107.0 showed up on PyPI and in Docker registries carrying a credential stealer and a RAT that polls hourly. LiteLLM's current theory is that the attacker got GitHub CLI OAuth tokens out of AI gateway logs. Claude Code had put a user's token into a response body, the gateway logged that body, and somebody found it. From there the attacker disabled branch protections and published the bad artifacts. Stolen cloud credentials were then used for LLMjacking against AWS Bedrock.
Note the word "suspects." This is LiteLLM's working theory, not a finished postmortem, so hold the details loosely.
Old dog, new tricks
Secrets in logs is one of the oldest bugs in the book. We've been leaking tokens through debug output, error traces, and verbose HTTP logging for as long as there have been tokens and logs. Nothing about that is new.
What's new is how the token got there. An AI coding tool pulled a credential into a model response, and the gateway did what gateways do, which is log the traffic. Nobody made an obviously dumb decision. Each component behaved reasonably in isolation. The leak lives in the seam between them.
Then there's the second half. Compromised release pipeline, branch protections switched off, poisoned package pushed to a registry that millions of builds trust. That's the supply chain playbook we've watched work repeatedly. The attacker didn't need a zero-day. They needed one token and a maintainer account with enough rights to turn off the guardrails.
The hype check
Expect the headline to be "AI tool leaks secrets." Partly true, mostly lazy. Strip the AI out and you have a credential-bearing payload written to a log store that someone else could read. Swap in any other service that echoes request data and you get the same incident.
But I wouldn't wave it off either, because the understated part is the logging. AI gateways exist to capture prompts and responses. That's the product. For debugging, cost tracking, and auditing, you want those bodies. Which means the log store is, by design, a pile of everything users and tools said to models. Developers paste stack traces, config files, and environment dumps into these things all day. Agentic tools go further and pull in whatever they can read on the machine. Treat that data as untrusted-but-sensitive from day one, because a token in there is a matter of when, not if.
And who benefits from the narrative? Anyone selling "AI security" as a fresh category loves a story where the AI is the villain. The less exciting reading is that this is a pipeline-hardening and log-hygiene failure that happened to route through a new kind of tool. That's less marketable, but I think it's closer to true.
Also worth noticing: one token, scoped broadly enough to flip branch protections, was the difference between a leak and a release. That's a privilege story as much as a logging one.
What to actually do about it
If you run any kind of LLM gateway or proxy, go look at what your logs contain right now. Not in theory. Grep them. You'll probably find things you didn't expect. Redaction at the logging layer is dull work and nobody gets promoted for it, but it's the control that would have mattered here.
For maintainers: long-lived OAuth tokens that can alter repo protection settings are a liability sitting in someone's home directory. Short-lived credentials, tighter scopes, and alerts when branch protections change would each have cut into this chain. Disabling protections should be loud.
For everyone consuming packages: pinning and hash verification help, but the window between publish and detection is where the damage happens. This was a RAT with hourly polling, so it was built to stick around quietly.
And the LLMjacking piece deserves a note. Stolen cloud creds got spent on Bedrock. Attackers have figured out that model access is a monetizable asset, so your cloud bill is now part of the blast radius.
The question I can't shake
We're wiring agentic tools into environments full of live credentials, then logging everything those tools say for observability. The two goals pull against each other. So where does the responsibility sit when a tool surfaces a secret into a response and a downstream system faithfully records it: with the tool vendor, the gateway operator, or the developer who had the token on disk in the first place?
— Cor, Skyblue Soft
Sources
AI-assisted draft or imaging, human-curated, reviewed and edited.
Top comments (0)