# The Force-Push Was Not the Revocation.

> LiteLLM's 23 October root-cause post says an Agent Platform master key committed at 18:53:14 UTC on 27 May was never revoked. At 21:27:10 UTC on 10 October the agents list returned an owner GitHub CLI token. The 21 October post suspected proxy logs. PyPI 1.106.3 on 24 October changes the image signing key and does not rotate the May key.

Source: https://hackerlogs.com/blog/litellm-agent-key-revoke-clock
Published: 2026-10-24

## Key takeaways

- The canonical post is LiteLLM's root-cause page. Its own timeline marks publication at 21:00 UTC on 23 October. Oliver Jensen and Mateo Wang are the byline.
- The vendor times the public opencode.json commit at 18:53:14 UTC on 27 May and the token read at 21:27:10 UTC on 10 October. That gap is 136 days 2 hours 33 min 56 sec.
- The 21 October incident post suspected logs on an internal LiteLLM deployment. This post says the request logs show the Agent Platform API instead.
- PyPI latest tonight is 1.106.3. The first wheel uploaded at 09:14:52.573 UTC on 24 October. The notes remove the eMudhra root and change the cosign key. They do not name the May key.
- A host that started litellm 1.107.0 is still in scope. Version 1.107.0 is absent from PyPI tonight. Installing 1.106.3 does not clear that host.

The canonical account is [LiteLLM's root-cause post](https://docs.litellm.ai/blog/security-incident-oct-21-2026-attack-chain), 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 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](https://docs.litellm.ai/blog/security-incident-oct-21-2026) remains the artifact list. This page is the entry path that post had not settled.

<img src="/litellm-agent-key-revoke-clock.svg" alt="Three panels for the LiteLLM agent-key clock: a 27 May commit with no revocation, 136 days until an owner token came back, and a 24 October release that changes a signing key." width="1200" height="675" />

## 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 vendor separates the two clocks. The file clock is the force-push they describe on 27 May. The impact clock is revocation, which they say did not happen. From 18:53:14 UTC on 27 May to 21:27:10 UTC on 10 October is 136 days 2 hours 33 min 56 sec. A contents 404 tonight does not shorten that interval.

## 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:

| Credential | When the vendor says it moved | What they say it did |
| --- | --- | --- |
| Agent Platform master key | Public commit, 27 May | Read the Agent Platform API on 10 October |
| Owner GitHub CLI token | Returned by that API at 21:27:10 UTC | Pushed the exfiltration branches, changed the release workflow, ran staging, force-pushed the cover-up |
| Second maintainer token, `GH_TOKEN` on `BerriAI/litellm` | Throwaway workflow at 22:11:45 UTC on 10 October | Approved the production gate at 11:11:18 UTC on 21 October |
| Third maintainer token, `RELEASE_PLEASE_TOKEN` on `BerriAI/litellm-auto` | Throwaway workflow at 22:12:09 UTC on 10 October | Deleted the release run records at 11:53:49 and 11:54:01 UTC |

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`.

| Version | First PyPI file | GitHub release published |
| --- | --- | --- |
| 1.103.8 | 07:56:13.584 UTC on 24 Oct | 08:11:40 UTC |
| 1.104.6 | 08:33:12.004 UTC | 08:40:34 UTC |
| 1.105.4 | 08:44:19.614 UTC | 08:52:07 UTC |
| 1.106.3 | 09:14:52.573 UTC | 09:34:13 UTC |

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.

## 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.

## Sources

- [The attack chain behind the v1.107.0 LiteLLM release](https://docs.litellm.ai/blog/security-incident-oct-21-2026-attack-chain) (2026-10-23)
- [Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised](https://docs.litellm.ai/blog/security-incident-oct-21-2026) (2026-10-21)
- [Leaked LiteLLM Master Key Let Attackers Steal GitHub Tokens and Hijack Release Pipeline](https://thehackernews.com/2026/10/leaked-litellm-master-key-let-attackers.html) (2026-10-24)
- [LiteLLM release v1.106.3](https://github.com/BerriAI/litellm/releases/tag/v1.106.3) (2026-10-24)
- [litellm on PyPI](https://pypi.org/project/litellm/)
- [LiteLLM-Labs/lite-harness](https://github.com/LiteLLM-Labs/lite-harness) (2026-05-27)