# KLM Innovation Security Monitor - Weekend Edition
**Date:** October 24, 2026

> Informational security guidance for awareness and prioritization. Not certification, legal advice, or a guarantee of protection.

## Executive Summary
LiteLLM published its root cause for the poisoned 1.107.0 release on October 23rd, and it changes the story. The way in wasn't tokens in a gateway's logs, as LiteLLM first suspected. It was a master key for an internal agent platform that was committed to a public repo in May, force-pushed away, and never revoked. That key returned a GitHub organization owner's token, and the attacker sat on it for eleven days before shipping the release. Microsoft's analysis of the payload adds a response rule worth sharing with your team: don't run `python` or `pip` inside a suspect environment to check it, because starting Python is what runs the stealer. LiteLLM shipped clean releases early on October 24th with a new image-signing key, so update any `cosign` checks that pin the old one.

PingCAP, the company behind TiDB, says an attacker used a compromised GitHub account and keys left in repos and Terraform state to copy customer records between September 9th and October 7th, including credentials customers had pasted into support tickets. And FastMCP fixed a bug where a low-privilege caller could run a protected tool just by calling it by name.

## Headline Developments

### 1. LiteLLM's root cause: a master key from a May commit, never revoked, led to the poisoned release (HIGH)
**Source:** [LiteLLM: The attack chain behind the v1.107.0 LiteLLM release](https://docs.litellm.ai/blog/security-incident-oct-21-2026-attack-chain) (October 23rd)
- LiteLLM says a configuration file committed to its public `LiteLLM-Labs/lite-harness` repository on May 27th contained the master key to a deployment of the LiteLLM Agent Platform, an experimental service its own agents used to open pull requests. The team force-pushed over the commit and marked the exposed keys for revocation, but the master key was never revoked.
- On October 10th, LiteLLM says, the attacker used that key to call the Agent Platform API, and one request returned the configuration of every managed agent, including the GitHub CLI OAuth token of one of its two GitHub organization owners. LiteLLM says the token wasn't tied to a service account or scoped down, and that GitHub CLI tokens aren't subject to GitHub's re-authentication prompts for sensitive actions. The same evening, throwaway CI workflows posted repository secrets, including two more maintainers' GitHub tokens, to an outside endpoint, and the runs were deleted within minutes.
- On October 21st the attacker overrode branch protection to point the release workflow at a lookalike `Berri-AI/litellm` fork and approved the production gate with a second maintainer's token. LiteLLM says the gate normally needs approval from a special account locked to a physical device, but it had relaxed that earlier in the week so any two engineers could release. It also says the attacker's activity on other internal systems focused on finding upstream inference API tokens. LiteLLM's first incident post suspected the tokens came from an internal gateway's logs; the root cause says the first token came from the Agent Platform instead.
- Microsoft says the malicious wheels dropped `cook.pth`, `cook.py` and `sitecustomize.py` outside the `litellm` directory, so starting Python could run the collector even if nothing imported LiteLLM, and deleting the package directory may leave them behind. It recommends investigating from a known-clean system, rebuilding rather than cleaning, and rotating every credential the host could reach, including provider keys and the proxy's `DATABASE_URL` ([Microsoft Security Blog: Inside the LiteLLM 1.107.0 supply chain compromise](https://www.microsoft.com/en-us/security/blog/2026/10/23/inside-the-litellm-1-107-0-supply-chain-compromise-credential-theft-through-python-startup-hooks/), October 23rd).
- LiteLLM published 1.103.8, 1.104.6, 1.105.4 and 1.106.3 early on October 24th. Each removes the eMudhra root CA from the certificate bundles it trusts, and each is signed with a new `cosign` key from commit `e82a3c6`, so verification with the old key now fails ([LiteLLM v1.106.3 release](https://github.com/BerriAI/litellm/releases/tag/v1.106.3)).

**Why this matters:** It's HIGH rather than CRITICAL because the bad artifacts were pulled within about two hours on October 21st and clean releases are out. The lesson is about the key, not the malware. Removing a secret from Git history doesn't un-leak it, and an agent platform that hands back a human owner's unscoped token in an API response is a secrets store whether anyone planned it that way or not.

### 2. PingCAP: a stolen GitHub account, keys in Terraform state, and customer credentials in support tickets (HIGH)
**Source:** [NebuSec: Investigating the PingCAP Security Incident](https://nebusec.ai/research/pingcap-security-incident/) (findings as of October 21st)
- PingCAP's CEO says that between September 9th and October 7th an unauthorized party used compromised credentials to access its internal systems and copy information, including information customers entrusted to it ([PingCAP: A Note from Our CEO on the PingCAP Security Incident](https://www.pingcap.com/trust-hub/security/ceo-note-october-2026/), October 23rd).
- NebuSec, which PingCAP hired to investigate, says the attacker got in through a compromised GitHub account, then used keys and tokens found in private repositories and plaintext Terraform state to reach Google Cloud, Jira and PingCAP's internal chat. From Jira support tickets the attacker collected credentials customers had shared during support work, including AWS keys that reached S3 buckets holding customers' TiDB diagnostic data. NebuSec counts eight compromised Google Cloud service accounts and bulk exports of 6,458 BigQuery tables.
- The copied data includes control-plane metadata, customer SQL editor history, AI interactions, CRM and billing records, source code, and logs and attachments from support tickets. NebuSec says it found no evidence the attacker reached live customer TiDB databases or kept a foothold in production, and that the TiDB Cloud API key values were encrypted with a key that wasn't exposed. That protection doesn't extend to credentials customers put in support materials.
- PingCAP tells customers to replace active TiDB Cloud management API keys now without waiting for an individual notice, rotate anything they've ever shared with PingCAP support, and watch for targeted phishing, since contact and billing details were copied ([PingCAP: Security Update, Customer Actions](https://www.pingcap.com/trust-hub/security/customer-actions-october-2026/)). NebuSec published the attacker's IP addresses for log review.

**Why this matters:** It's HIGH because customer credentials left the building and some of them, the ones in support tickets, were never protected by the vendor's encryption. Most teams don't count "pasted into a vendor's support ticket" as a place their keys live. This is a reason to start.

### 3. FastMCP: a hidden admin tool could still be called directly (MEDIUM)
**Source:** [GitHub: FastMCP advisory GHSA-7xgj-8392-5q4r](https://github.com/PrefectHQ/fastmcp/security/advisories/GHSA-7xgj-8392-5q4r) (October 20th)
- FastMCP, a Python framework for building MCP servers, checked authorization on a tool after applying server transforms when it listed tools, but checked the original tool when a client called it directly. When a transform changes the metadata an authorization rule looks at, such as a tag, a low-privilege caller who knows or guesses the tool's name can run it even though it's hidden from their list. The same ordering bug applies to resources, templates and prompts.
- The reporter's proof of concept shows an unprivileged caller getting an empty tool list, then calling the hidden tool by name and getting its protected output back. It needs a valid low-privilege identity and a server that combines transforms with metadata-based authorization checks.
- It affects `fastmcp` and `fastmcp-slim` 3.0.0 through 3.4.9 and 4.0.0 through 4.1.1, and it's fixed in 3.4.10 and 4.1.2. GitHub rates it moderate (CVSS 3.1 6.8), and there's no CVE yet. Until you upgrade, the maintainers say to enforce authorization in the tool handler or at the server boundary rather than in a policy a transform can change.

**Why this matters:** It's MEDIUM because it needs an authenticated caller and a specific configuration. The pattern is common, though: hiding a tool from a list isn't the same as denying the call, and tool names are rarely secret.

## Continuity Footnotes
- **CISA KEV:** Arista VeloCloud Orchestrator (CVE-2026-114625) and Collabora's built-in CODE Server app for Nextcloud (CVE-2026-110447), covered October 23rd, are due Monday, October 26th. CISA hasn't added anything since. PHP2Shell, GitLab CVE-2026-110264 and LiteLLM CVE-2026-114612 still aren't on the catalog ([CISA Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)).
- **eMudhra intermediate CA key compromise:** covered October 20th. New today: LiteLLM's October 24th releases remove the eMudhra root CA from the bundles its SDK, proxy and Docker images trust (Story 1).

## Pattern Analysis
1. **Secrets outlive the place they leaked (October 23rd to 24th):** a force-pushed commit (Story 1), plaintext Terraform state and old support tickets (Story 2). In each case the secret was "gone" from where people looked and still worked for the attacker. Revocation is the fix; deletion isn't.
2. **Platforms that hold someone else's keys (October 17th to 24th):** LiteLLM's Agent Platform returned a human owner's GitHub token in an API response (Story 1), and PingCAP's support system held customers' AWS keys (Story 2). It's the same week as OpenCode, Railway and Zeabur, where attackers went straight for stored AI provider keys.
3. **Authorization that depends on what you can see (October 24th):** FastMCP's list-versus-call gap (Story 3) is the MCP version of a hidden admin URL. Check the call, not the menu.

## Recommended Actions

**Immediate (this weekend):**
1. **If any system installed LiteLLM 1.107.0 or pulled `latest`, `main-latest` or `main-stable` on October 21st,** isolate it and investigate from a known-clean machine without starting Python on it. Rebuild it from verified artifacts, then rotate every credential it could reach, including provider keys, cloud and CI secrets, and the proxy's `DATABASE_URL`.
2. **If you verify LiteLLM images with `cosign`,** switch to the public key from commit `e82a3c6` before your next deploy, or verification will fail.
3. **If you're a TiDB Cloud customer,** replace your active management API keys and rotate anything you've ever sent to PingCAP support: keys, connection strings, and logs with secrets in them.
4. **If you run FastMCP servers with transforms and tool authorization,** upgrade to 3.4.10 or 4.1.2.
5. **Patch Arista VCO and Collabora's built-in CODE Server app before Monday's federal deadline** if you haven't yet.

**This month:**
6. **Treat any secret that ever touched a public commit as burned.** Revoke and reissue it, even if the commit was force-pushed away within minutes, and keep a record that the revocation happened.
7. **Give agents and automation their own service identities with scoped, short-lived tokens,** never a human owner's personal token, and make sure no API returns those tokens in plain text.
8. **Inventory the places your credentials live outside your vault,** including Terraform state, CI secrets, agent configs and vendor support tickets, and stop sending secrets through support channels.

## Sources
- [LiteLLM: The attack chain behind the v1.107.0 LiteLLM release](https://docs.litellm.ai/blog/security-incident-oct-21-2026-attack-chain)
- [Microsoft Security Blog: Inside the LiteLLM 1.107.0 supply chain compromise: Credential theft through Python startup hooks](https://www.microsoft.com/en-us/security/blog/2026/10/23/inside-the-litellm-1-107-0-supply-chain-compromise-credential-theft-through-python-startup-hooks/)
- [LiteLLM v1.106.3 release](https://github.com/BerriAI/litellm/releases/tag/v1.106.3)
- [PingCAP: A Note from Our CEO on the PingCAP Security Incident](https://www.pingcap.com/trust-hub/security/ceo-note-october-2026/)
- [NebuSec: Investigating the PingCAP Security Incident: Credential Exposure and Cloud Data Collection](https://nebusec.ai/research/pingcap-security-incident/)
- [PingCAP: Security Update, Customer Actions, October 2026](https://www.pingcap.com/trust-hub/security/customer-actions-october-2026/)
- [GitHub: FastMCP advisory GHSA-7xgj-8392-5q4r, post-transform component authorization is skipped on direct calls](https://github.com/PrefectHQ/fastmcp/security/advisories/GHSA-7xgj-8392-5q4r)
- [CISA Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)

*Informational security guidance. Not certification.*