Skip to content

Supabase's October 30 change: new public tables need a grant for Data API access. What to doSupabase's October 30 change is live: new public tables need a grant for Data API access. What broke and how to fix it

24 tools · 139 fixes · 42 issue guides · Sources: Supabase, GitHub, postgresql.org, Vercel + 53

Incident feed

LiteLLM says a key committed to a public repo in May, and never revoked, led to its compromised October release

On October 23, 2026, LiteLLM published its root cause analysis of the compromised litellm 1.107.0 release. It says a master key for an internal agent service was committed to a public GitHub repository on May 27, the commit was force-pushed over, but the key was never revoked. On October 10 an attacker used the key to read a GitHub organization owner's CLI token, used CI workflows to collect two more maintainers' tokens, and on October 21 published the malicious release to PyPI and LiteLLM's container registries.

Share link · Share on X

Information disclosureLeaked keys

What was reported

LiteLLM published the attack chain behind its v1.107.0 release on October 23, 2026. It says that on May 27, 2026, an opencode.json configuration file committed to the public LiteLLM-Labs/lite-harness repository contained the master key to a deployment of the LiteLLM Agent Platform, an internal service for running agents that open pull requests. The team spotted the mistake and force-pushed over the commit, and marked the exposed keys for revocation. The post says revocation "did not occur for the master key."

The Agent Platform held a GitHub CLI OAuth token belonging to one of LiteLLM's GitHub organization owners. The post says the token was not tied to a service account and was not scoped down. On October 10, an attacker used the master key to call the platform's API, and one request returned that token. With owner access, the attacker pushed throwaway branches whose CI workflows sent repository secrets to an outside endpoint, then deleted the workflow runs. Two of those secrets held the GitHub CLI tokens of two more maintainers.

On October 21, the attacker used the owner's token to override branch protection and point LiteLLM's release workflow at a lookalike fork, then used a second maintainer's token to approve the production release. LiteLLM says it had relaxed its release approval rule that week to allow any two engineers to trigger and approve a release. Seven litellm==1.107.0 wheels were published to PyPI at about 4:40 AM PT, followed by Docker Hub and GHCR images. PyPI quarantined the release by 6:23 AM PT, and the Docker tags were removed by 7:20 AM PT. LiteLLM says the artifacts were live for about two hours, and that it is now revoking every token tied to its internal systems and vendor platforms. Its post calls the incident "a strong illustration of the risks associated with failing to rotate a potentially exposed key."

Keys committed to GitHub covers why deleting a key from your repository is not enough, and how to revoke and replace it.

How to prevent it

If a key ever lands in a public commit, revoke it at the service that issued it and replace it, even if you deleted the file or force-pushed the commit away. Rewriting Git history does not stop anyone who already copied the key.

Sources

Related

The weekly fix

The weekly fix: 3 real security mistakes in vibe-coded apps and how to fix them, every Tuesday.

One email, every Tuesday. A welcome note follows the first signup.