LiteLLM's real root cause was a key left in a public repo for four months.

A correction to last week's LiteLLM story, what the root-cause analysis shows about long-lived keys and unscoped CLI tokens, and an AI-written Linux root exploit for a bug that distributions were still patching.

Hey 👋

Two stories this week, and the first one starts with a correction.

Last week I wrote that LiteLLM traced its break-in to GitHub tokens sitting in its own gateway logs. That was LiteLLM’s working theory on 21 October. On 23 October the company published a root-cause analysis that contradicts it for the first token. I’ll go through what changed, because the real chain is more useful than the theory was.

The second story is Anthropic saying that Claude wrote a working root exploit for a Linux kernel bug, and that the fix hadn’t reached Ubuntu’s stable kernels three days later.

My take, in one line: the attacker’s skill was not the scarce thing in either story. A key nobody revoked and a patch that hadn’t shipped were.

---

This week in AI security

LiteLLM: the first token did not come from the logs

LiteLLM published an attack-chain write-up on 23 October that it describes as the canonical record. It supersedes the 21 October incident post, which I used for last week’s issue.

The correction itself, in LiteLLM’s words: “Our first post suspected the tokens were taken from the logs of an internal LiteLLM deployment. The request logs show the first token came from a different service.” Here is the chain it now describes:

• 27 May. A config file was committed to the public LiteLLM-Labs/lite-harness repository. It “inadvertently contained an administrative key to an internal deployment of LiteLLM Agent Platform.” A follow-up commit deleted the file, but the original commit stayed in the repo’s public history until 22 October.
• Never revoked. “Because of human error, nobody followed through on revoking the administrative key,” so it “was still valid more than four months later.”
• 10 October. The attacker used the key to call the Agent Platform API. One request, GET /api/v1/managed_agents/agents?limit=100, returned a GitHub CLI token. It belonged to LiteLLM’s GitHub organization owner.
• Same evening. Throwaway CI workflows on branches named ci-tmp-* posted secrets, including GH_TOKEN and RELEASE_PLEASE_TOKEN, to webhook.site. The runs were deleted within three minutes. On 12 October the same trick was repeated on private repositories. LiteLLM says this is where the second and third maintainer tokens came from, and that the attacker used separate tokens “to evade detection by way of noisy audit logs.”
• 21 October. The release sequence from last week’s issue, using three different people’s tokens.

So the attacker had owner access to the GitHub organization for 11 days before shipping anything. And LiteLLM puts the weight on a single sentence about the token type: “GitHub CLI tokens are not scoped, are post-2fa, and not subject to GitHub’s ‘super-user’ 2fa reauth flows.”

What about the Claude Code claim from last week? LiteLLM’s first post said it had “observed specific situations in which Claude Code will embed a user’s GitHub CLI OAuth token into a response body.” The new write-up doesn’t mention Claude Code at all. It neither repeats the claim nor retracts it, and I still found no statement from Anthropic. For now I’d treat it as unconfirmed, not as disproved.

One more detail matters if you pull LiteLLM images or verify signatures. The attacker exfiltrated more tokens, and LiteLLM believes the private half of its old cosign signing key was exposed. It rotated the key on 23 October. The compromised v1.107.0 images “also carry a valid signature from the previous key.” A valid signature from the old key proves nothing about an image published after 21 October.

So what: the compromise needed no log mining and no zero-day. It needed one admin key that outlived the file it was committed in, and one CLI token with the full rights of its owner. Deleting a secret from a repo’s latest commit does nothing for the key.

Do this: scan the full history of your public repos for committed secrets, not just the current tree, and revoke anything you find instead of deleting it. Then list the GitHub CLI tokens your org owners and maintainers hold. LiteLLM says they are unscoped, so for anything automated, switch to a fine-grained token or an app with the narrowest scope that works.

---

Anthropic: Claude wrote a root exploit for a Linux kernel bug

On 27 October, Anthropic’s Frontier Red Team published results from using Claude to find vulnerabilities. The headline claim: “After initial prompting, Claude wrote an exploit that allows a remote attacker to send packets to Linux servers with a multipath TCP listener to run arbitrary commands as root.” The bug is CVE-2026-98432, which Anthropic says “was patched upstream and backported to all maintained stable kernel branches.” In its proof of concept, “it takes 48 minutes to leak a kernel pointer and another five minutes to reach the shell command execution.” No exploit code was released.

The kernel CVE team’s record adds what Anthropic’s post leaves out. It is a race in the TCP handshake that causes a use-after-free in ip_options_build(), scored CVSS 9.8, introduced in kernel 4.4. The fixes landed in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3.

Two things in the record are worth reading closely:

• The CVE text doesn’t mention multipath TCP. The MPTCP listener is the path Anthropic’s exploit used. The Hacker News makes the same point. Whether the bug is reachable without MPTCP isn’t something I could settle from the record.
• Distribution status lags. Ubuntu published the CVE on 15 October. As of 30 October its page showed no fixed package for any release: 22.04 and 24.04 were “work in progress,” and 20.04 and older were marked “Vulnerable.” The Hacker News reports Red Hat and Amazon rating the bug lower than the kernel team’s 9.8, and Debian and Oracle having shipped fixes. I only read Ubuntu’s page directly.

I can’t tell you how much of the 53 minutes is Claude and how much is Anthropic’s setup. The post says “after initial prompting,” which leaves room for a lot of human steering. The part I can verify is the timeline: a public 9.8 with a root exploit demonstrated, and stable distribution kernels still unfixed 15 days after the CVE.

So what: the gap between “CVE published” and “fix on your hosts” used to be the defender’s slack. A model that can write the exploit shortens the attacker’s side of that gap, and the distribution’s side didn’t move.

Do this: check your distribution’s tracker for CVE-2026-98432, not your kernel version, since vendors backport fixes. For hosts that are internet-facing and unfixed, check whether you need MPTCP (sysctl net.mptcp.enabled). Turning it off blocks the path Anthropic demonstrated. My inference is that it is not a fix for the bug itself, so keep patching on the list.

---

What I’m writing

The IETF agent-identity piece I mentioned last week is still in the queue. It covers what the IETF has actually finished for agent identity and what is still a draft. The short version hasn’t changed: the finished parts are general OAuth, and the agent-specific parts are drafts.

---

Tooling worth knowing

• LiteLLM’s attack-chain post has the full timestamped timeline, the request that returned the token, and the cosign fingerprint to verify against. post →
• Agent Security Scorecard: my free self-assessment against the OWASP Agentic Top 10. About 12 minutes, no login. Score your agents →
• AI Agent Pre-Deployment Security Checklist: 25 yes/no controls to clear before an agent with tool access goes to production. Get the checklist →

---

One thing to check this week

Spend twenty minutes on keys that outlived their reason to exist.

1. Scan history, not the tree. Run a secret scanner over the full git history of every public repo your org owns. The LiteLLM key was deleted from the file and still worked.
2. Revoke, then ask what it could reach. For anything you find, revoke first. Then ask what an attacker holding it could read, because LiteLLM’s key could read an API that returned a token.
3. List unscoped tokens. Find the CLI and OAuth tokens held by org owners and release maintainers. If one can approve a production release, it shouldn’t also be a token a service can hand out.

---

What I’m watching

→ LiteLLM’s follow-up. The attack-chain post says “We know many of you want to hear what we’ve learned and what we’re changing. We’ll share that next week.” Whether that includes branch protection that an owner token can’t override is the part I care about.

→ Anthropic on the token-in-response-body claim. Still no statement, and the root-cause analysis is now silent on it too.

→ Distribution kernels for CVE-2026-98432. Whether Ubuntu’s status moves from “work in progress” to a fixed package, and whether anyone shows the bug is reachable without MPTCP.

→ Microsoft Ignite, 17 November. Whether “controls outside the agent’s reach” ships as a product, and on which licence.

---

If you find a committed key that’s older than the repo’s last release, reply and tell me how long it had been there. I read everything.

Cheers, Amine

If a colleague maintains an open-source project with a release pipeline, forward this to them.

---

Sources

• The attack chain behind the v1.107.0 LiteLLM release, LiteLLM, 23 October 2026
• Security incident: LiteLLM v1.107.0, LiteLLM, 21 October 2026 (updated 23 and 30 October)
• Discovering vulnerabilities with Claude, Anthropic Frontier Red Team, 27 October 2026
• CVE-2026-98432 record, Linux kernel CVE team
• CVE-2026-98432, Ubuntu Security, page last updated 30 October 2026
• Linux kernel TCP flaw with 9.8 CVSS score affects Ubuntu, Red Hat and other distributions, The Hacker News, 29 October 2026