The Force-Push Was Not the Revocation.

The canonical account is LiteLLM's root-cause post, byline Oliver Jensen and Mateo Wang. The page header says 23 October 2026. The post's own timeline marks publication at 21:00 UTC that day. It says an Agent Platform master key committed to public LiteLLM-Labs/lite-harness at 18:53:14 UTC on 27 May was identified for revocation and was not revoked. At 21:27:10 UTC on 10 October a read of the agents list returned a GitHub CLI OAuth token for one of two organization owners.

US trends at 22:10 UTC were UFC 333, college football, and the Cheesecake Factory. Hacker News led with a Bitcoin challenge and, further down, Node2Shell. The Hacker News carried the key story on 24 October. The primary is the vendor timeline, not that rewrite.

Critical Critical because the vendor says that unrevoked key was enough to read an owner token, and that token was enough to publish litellm==1.107.0. The 21 October incident post remains the artifact list. This page is the entry path that post had not settled.

The file left the tip. The key stayed valid.#

The vendor's step 0 is one line: opencode.json with the Agent Platform master key is committed to public LiteLLM-Labs/lite-harness at 18:53:14 UTC on 27 May. The narrative says the error was found quickly, the commit was force-pushed over, and the exposed keys were flagged for revocation. Revocation did not occur for the master key.

The repository is still public. GitHub says it was created at 18:10:10 UTC on 27 May, 43 min 4 sec before that vendor timestamp, and pushed_at is 04:57:35 UTC on 22 October. A commit list for 27 May on the default branch does not contain 18:53:14 UTC. Commit 25330ee80c82 is on that branch at 21:51:33 UTC. The subject is harnesses: remove leaked opencode.json. The diff GitHub returns lists a gitignore change, a README change, a renamed entrypoint, and a Dockerfile change. It does not list opencode.json. A contents read returns 404 for that path on main, on 25330ee, and on parent fd437f73. From the vendor's commit time to that subject is 2 hours 58 min 19 sec. This brief did not search dangling objects. It did not print a key. A missing path on the tip is the branch you clone today. The vendor says the key was still accepted on 10 October.

The first post named the wrong service.#

The root-cause post says the 21 October write-up suspected the tokens were taken from the logs of an internal LiteLLM deployment. It says the request logs show the first token came from a different service. From 69.48.229.143, between 21:13 and 21:28 UTC on 10 October, the caller used the master key against the Agent Platform API. At 21:27:10 UTC GET /api/v1/managed_agents/agents?limit=100 returned every managed agent's configuration, including the owner's GitHub CLI token. This brief did not call that API.

The vendor describes the token as a GitHub CLI OAuth token on an organization owner's account, not a service account, and not scoped down. They say GitHub CLI tokens are post-2FA and are not subject to GitHub's super-user 2FA reauthentication on sensitive organization or repository actions. From that read to the first malicious PyPI wheel at 11:39:51 UTC on 21 October is 10 days 14 hours 12 min 41 sec.

Their credential table has three further rows, and this brief does not print a secret value:

The 10 October runs were deleted at 22:14:14 and 22:14:31 UTC with the owner's token. The vendor says a second round on 12 October, 12:08 to 12:30 UTC, posted secrets from private repositories and was not on the path to the poisoned artifacts. They say those tokens were rotated. BerriAI/project-releaser, the private repository they name for the release workflow, returns 404 on the public API. Commit 20535d8fa1 is still fetchable on BerriAI/litellm, committer 10:46:29 UTC on 21 October, signature unsigned. The wheel window is the 21 October brief. This one does not reopen the cook files.

From the incident post's 18:20 UTC on 21 October to this root-cause line at 21:00 UTC on 23 October is 2 days 2 hours 40 min. The post says assumptions in the status updates were later inaccurate, and that this page is the canonical source.

What 1.106.3 actually ships.#

The root-cause post says they expected to ship, by the end of that day, a release that removes the eMudhra certificate authority from the trust store. PyPI tonight has four new versions, none yanked, and no 1.107.0 key. Latest is 1.106.3.

The v1.106.3 notes say the eMudhra root is removed from every certificate bundle the SDK, proxy, and Docker images trust, and that those notes also apply to 1.103.8, 1.104.6, and 1.105.4. The same notes say image and Helm signing moves to the cosign key in commit e82a3c6, and that verification with the previous key in commit 0112e53 fails. Tag v1.106.3 points at commit 4fa8bf1ff551, committer 01:30:49 UTC on 24 October. From the root-cause timestamp at 21:00 UTC on 23 October to the first 1.106.3 wheel is 12 hours 14 min 52.573 sec. This brief did not print the new public key and did not verify an image.

1. 2026-05-27
   Vendor: opencode.json committed 18:53:14 UTC. Repo created 18:10:10 UTC. Subject commit 25330ee at 21:51:33 UTC does not list that file. Key not revoked.
2. 2026-10-10
   21:27:10 UTC the agents list returns the owner GitHub CLI token. 22:11 and 22:12 UTC two maintainer tokens leave via throwaway workflows.
3. 2026-10-21
   Wheels 11:39:51 to 11:40:13 UTC. Incident post 18:20 UTC suspects an internal LiteLLM log path.
4. 2026-10-23
   21:00 UTC root-cause post. The request logs show the Agent Platform API. 2 days 2 hours 40 min after the incident post.
5. 2026-10-24
   PyPI 1.106.3 from 09:14:52 UTC. eMudhra root removed. Cosign key changed. May master key not named. 1.107.0 still absent.

What to do with the two clocks.#

1. Treat the 23 October root-cause post as the entry path and the 21 October incident post as the artifact list. The wheel and image times in that earlier brief are the same times this post reprints. A host that started litellm==1.107.0 is still in scope. PyPI has no 1.107.0 key tonight. That absence does not clean a disk.
2. On the current line, PyPI latest is 1.106.3, first file 09:14:52.573 UTC on 24 October. The matching backports on PyPI are 1.103.8, 1.104.6, and 1.105.4. The 1.106.3 notes remove the eMudhra root and require the cosign key in e82a3c6. A policy still pinned to 0112e53 will fail that check. This release is not a rotation of the May master key.
3. A force-push is a file clock. Revocation is the impact clock. The vendor says the master key stayed valid after the file left the branch they rewrote. From their commit time to the token read is 136 days 2 hours 33 min 56 sec. Delete-and-forget on an agent config is how that interval starts.
4. The token that came back was a GitHub CLI OAuth token for an organization owner, stored so the Agent Platform could open pull requests. The vendor says that class of token is post-2FA and skips the super-user reauthentication step. Keep that credential off any agent record a master key can list. A service account with a narrow scope is the replacement they say was missing.
5. Log the 10 October window on the Agent Platform API, source 69.48.229.143, and the 21 October release actions from 199.91.221.39. The public API for BerriAI/project-releaser returns 404. The organization audit log is the record they say still has each branch-protection override. This brief did not request that log.
6. The package clock for customers tonight is 1.106.3, or the backport on the line you already pin, plus the new signing key. The impact clock is any GitHub token the 10 October read could have used, and any host that already started 1.107.0. Installing 1.106.3 does not unpublish the first and does not scrub the second.