Socket Finds Malicious LiteLLM Workflows Ran 11 Days Before Supply-Chain Attack

Summary

Socket says two malicious GitHub Actions workflows ran in the LiteLLM repository on October 10 and 12, targeting organization and environment secrets. The runs succeeded, but successful exfiltration is unconfirmed; LiteLLM says audit logs link the first workflow’s GH\_\

Key points

Socket recovered two malicious commits that added .github/workflows/cache.yml on short-lived branches on October 10 and 12, 2026; both branches were deleted the same day.
Repository performance metrics record a successful run for each workflow. These aggregate records confirm execution, but do not show whether the collectors received the secrets.
The October 10 workflow encoded six organization-level secrets and attempted to send them to a webhook[.]site collector. The October 12 workflow used six jobs to target 14 additional secrets, including environment-scoped credentials.
The workflows used push-triggered jobs and temporary branches to run in the repository’s context, where GitHub secrets were available. Deployment records corroborate activity from the October 12 branch.
The repository activity log attributes the branch creation, pushes, and deletions to the account ishaan-berri, but does not establish who used the account or how its credentials were obtained.
LiteLLM later reported that it traced initial access to an Agent Platform master key accidentally committed publicly and not revoked. It says audit logs link the GH_TOKEN targeted by the October 10 workflow to approval of the October 21 malicious release.

Article Details

Attack Vectors: Malicious GitHub Actions workflows were pushed to short-lived branches in the upstream BerriAI/litellm repository, triggered on push, and deleted after running.
The workflows read repository and organization secrets, and the October 12 workflow bound jobs to GitHub Environments to access environment-scoped secrets.
The workflows wrote secret values to a temporary file, base64-encoded the file, and used curl to POST it to webhook.site endpoints. Successful receipt of the data was not confirmed.
LiteLLM’s investigation reportedly traced initial access to an Agent Platform master key accidentally committed to a public repository in May and not revoked; it says the attacker used the key to obtain a GitHub organization owner’s token. Socket says it has not established how the earlier workflow access was obtained.
Defensive Notes: Review the complete Actions run history and repository activity log; the performance metrics establish successful runs but do not reveal run contents or the full number of possible cycles.
Use organization audit-log data, including source addresses, user agents, session history, and recently created access tokens, SSH keys, or OAuth grants, to investigate whether account activity involved compromised credentials, a stolen credential, or legitimate use.
Treat the October 10 and October 12 workflow executions as evidence of secret exposure, while recognizing that successful job status does not prove the collectors received the data.

Indicators of compromise

Type	Indicator	Context
URL	`hxxps[:]//webhook[.]site/4da03473-a3e7-4dc2-a087-9c564b4208e1`	Specific webhook.site endpoint configured by the October 12 workflow to receive the encoded secrets; successful receipt was not confirmed.
URL	`hxxps[:]//webhook[.]site/65a42464-3cfa-4b02-a18c-17a6d7b86f37`	Specific webhook.site endpoint configured by the October 10 workflow to receive the encoded secrets; successful receipt was not confirmed.

MITRE ATT&CK

T1059.004 · Unix ShellThe GitHub Actions workflow steps used shell commands, including echo, base64, and curl, to package and send secret values.T1078.004 · Cloud AccountsThe repository activity log attributes the branch creation, pushes, and deletions to the GitHub account ishaan-berri; the article says this identifies the credential used, not who held it or whether its use was legitimate.T1132.001 · Standard EncodingThe workflows base64-encoded the secret file before posting it to the configured collector endpoints.T1195.002 · Compromise Software Supply ChainLiteLLM reportedly connected the earlier secret-stealing workflows to the October 21 release attack that published malicious litellm==1.107.0 artifacts; Socket does not independently assert that the October 10 theft produced the access used in that attack.T1552.004 · Private KeysThe October 10 workflow read PROVIDER_INFO_SYNC_APP_PRIVATE_KEY from GitHub Actions secrets and included it among the values prepared for exfiltration.T1567.004 · Exfiltration Over WebhookThe workflows configured POST requests carrying base64-encoded secrets to specific webhook.site endpoints; successful receipt was not confirmed.

Products

GitHubThis update does not revisit it. It reports a different finding: the attacker held access to the GitHub organization long before October 21.GitHub ActionsUTC. The second, 1a6e3c1e41f1b5c8eeaeeb2ae94bcd95390fa891, followed on October 12. The repository's GitHub Actions Performance Metrics record one successful run for each.LiteLLMteam found that a malicious secret-exfiltration workflow was already running successfully in the BerriAI/litellm repository on October 10, 2026, eleven days before the release-pipeline attack that published malicious PyPIBerriAI/litellm release pipeline on October 21, 2026, which produced malicious litellm==1.107.0 wheels on PyPI and a malicious container image, has been documented separately. This update does not revisit it. It