New Evidence Shows LiteLLM Secret-Stealing Workflows Ran 11 Days Before Supply Chain Attack

What it is

Socket's Threat Research team recovered two malicious commits in BerriAI/litellm that show the attacker had push access to the GitHub organization from at least 10 October 2026, eleven days before the 21 October release attack that published litellm==1.107.0. Both commits add .github/workflows/cache.yml with the subject ci: bump cache config. The file is absent from main (checked at commit f2118fc).

How it works

Each cycle ran four steps: cut a throwaway branch ci-tmp-<hex> from a recent legitimate commit, push one commit adding the workflow, let on: [push] fire it in the upstream repository's context (where secrets.* resolves), then delete the branch.

• 10 October, 22:11 UTC: commit b69bc36 on ci-tmp-a351cc, cut from 000b368. One job, 24 lines, six org-level secrets.
• 12 October, 12:16 UTC: commit 1a6e3c1 on ci-tmp-4d8517, cut from c4bd202. Six jobs, 97 lines. Five jobs bind real GitHub Environments (e2e-changed, integration-postgres, integration-providers, integration-redis, integration-redis-postgres) to unlock their secret scopes.

Each job writes secrets as KEY=value lines to /tmp/c.env, base64-encodes the file, and posts it to a webhook.site endpoint. A trailing || true makes every run report success. The two runs used different collector endpoints and non-overlapping secret sets, and each job sent its own X-Tag header.

The 10 October run took GH_TOKEN, PROVIDER_INFO_SYNC_APP_ID, PROVIDER_INFO_SYNC_APP_PRIVATE_KEY, LINEAR_API_KEY, LITELLM_API_KEY and TOGETHER_API_KEY. The 12 October run took 14 more, including ANTHROPIC_API_KEY, OPENAI_API_KEY, AWS_BEARER_TOKEN_BEDROCK, GITGUARDIAN_API_KEY, DATABASE_URL, POSTGRES_USER, TAVILY_API_KEY and E2E_LINEAR_STORAGE_STATE_B64 (live Linear session state). Twenty secret names were exposed in total.

LiteLLM's own investigation, published after Socket's report, traces initial access to an Agent Platform master key committed to a public repository in May and never revoked. It says audit logs link the GH_TOKEN stolen on 10 October to approval of the malicious release.

Preconditions / Affected

Running the workflow needed push access to the upstream repository, since fork pull requests do not receive secrets. The activity log attributes all six events (two branch creations, two pushes, two deletions) to the account ishaan-berri. That identifies the credential used, not the person holding it.

What to do

The page gives no commands. Its evidence implies these checks for any organization that may be exposed:

• Treat every secret listed above as compromised, starting with GH_TOKEN and the GitHub App private key, which outlast a single session.
• Look at Insights, Actions performance metrics, filtered to the workflow name, for runs of workflows that no longer exist on the default branch.
• Check environment deployment history. Records persist after the workflow file is deleted. The integration-redis entry titled ci: bump cache config, deployed from ci-tmp-4d8517, was still marked Active.
• Review the organization audit log for the pushing account: source addresses, user agents, sessions, and any token, SSH key or OAuth grant created shortly before 10 October. Socket has not seen this data.
• Search the activity log for short-lived ci-tmp-* branches created and deleted within minutes.

Caveats

Socket says 10 October is only the earliest date it can evidence, and more cycles, before or after, would be hard to find. It recovered two. It could not confirm the collectors received data, because || true hides failures. It has not traced use of the stolen credentials and does not itself assert the 10 October theft produced the 21 October access. How the account was accessed is also unestablished by Socket; LiteLLM's account of the master key is the only stated origin.