LiteLLM's October 2026 incident: confirmed token exposure and gateway-log precautions

What it is

Status as of 25 October 2026. Re-check LiteLLM's canonical postmortem and affected-artifact list as the investigation develops. Its 23 October account explicitly corrects the earlier theory that GitHub CLI tokens were stolen from gateway logs. The confirmed initial route was a previously exposed, unrevoked Agent Platform master key, followed by an API response containing an organization's owner-level GitHub CLI OAuth token. The vendor links that credential exposure to the compromised 1.107.0 publication on 21 October. Canonical postmortem.

Accordingly, gateway log theft should not be described as this incident's established root cause. Protecting logs remains a separate defensive requirement: OWASP recommends excluding access tokens, passwords and other secrets from ordinary log records. Logging guidance.

Why it matters

An agent may encounter a credential in a tool response, configuration result or diagnostic message. Recording complete request and response bodies can create another copy with different readers and retention. Authentication-header redaction alone therefore cannot establish that an entire transcript is safe to store.

Privilege also determines the damage. An automation credential should not inherit an organization owner's authority merely because that account configured the integration. GitHub recommends applications for organizational or long-lived integrations and documents repository restrictions, permissions and expiration for personal access tokens. These credential types must not be confused with the OAuth token identified in this incident. GitHub token guidance.

How to apply

• Establish artifact exposure without starting a suspected Python environment. The incident guidance warns that Python startup, including pip, can execute the installed malicious startup files. Use deployment records and offline filesystem inspection instead. Incident guidance.
• For containers, run docker inspect --type=container --format='{{.Config.Image}}' CONTAINER with trusted host tooling and the actual container name. If a mutable tag was used, obtain the historical resolved digest from deployment records and compare it with the vendor's artifact list. Docker inspect.
• If an affected artifact ran, isolate the environment, preserve evidence and rebuild from trusted inputs. The incident post recommends 1.106.2 as a temporary pin; reinstalling alone does not establish that a compromised host is clean. Revoke credentials that the affected environment could reach.
• Review gateway log destinations, transcript stores, error reporting and exports. Use an allowlist of event fields: actor identifier, operation, outcome and correlation identifier. Remove sensitive body content before it reaches storage, rather than only hiding it in the viewer.
• Restrict gateway administration and log access to authorized operators. Keep internal gateways off the public internet unless explicitly designed and secured for that exposure. Use narrowly scoped automation identities and short credential lifetimes where supported.
• Test logging with synthetic secret markers, including error paths. Confirm that markers are absent from every configured sink while security events remain traceable. This is a proposed verification procedure, not a claimed test result.

Pitfalls

Deleting leaked text does not revoke a credential. A newly clean image does not erase historical exposure. Do not cite the vendor's initial hypothesis as established evidence, or interpret the temporary version pin as a guarantee against every unrelated vulnerability.