---
title: 'In the News: October 23, 2026 (Extra)'
description: "LiteLLM's own account of its compromised release says the attacker found developer GitHub tokens in a gateway's logs, and names Claude Code as a source."
canonical_url: 'https://darkfactory.dev/news/2026-10-23-extra'
markdown_url: 'https://darkfactory.dev/news/2026-10-23-extra.md'
collection: news
date_published: '2026-10-23T10:05:19-04:00'
date_modified: '2026-10-23T10:05:19-04:00'
---

# In the News: October 23, 2026 (Extra)


LiteLLM has published its own account of how a poisoned release reached PyPI and Docker on October 21. The company says the attacker took developer GitHub tokens from the logs of an internal LiteLLM deployment, and that Claude Code can put such a token into a response body. A second item covers Railway's disclosure that customer environment variables may have been exposed.

## 1. LiteLLM says leaked agent tokens in gateway logs led to its compromised release

**[Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised](https://docs.litellm.ai/blog/security-incident-oct-21-2026)** · Krrish Dholakia, Ishaan Jaffer, Oliver Jensen and Nate Armstrong · LiteLLM, October 21, 2026 (last updated 20:30 UTC; investigation still open)

LiteLLM's maintainers say a malicious `litellm==1.107.0` was live on PyPI for about two hours, from 11:39 to 13:23 UTC, and that four Docker tags (`v1.107.0`, `latest`, `main-latest`, `main-stable`) pointed at a compromised image until 14:20 UTC. They say the official source tag did not contain the malware; the artifacts were built from an attacker-controlled repository. Their advice is to pin to 1.106.2 or earlier, and to rotate the instance role, every provider key in the proxy database, the master and virtual keys, and the database password on any host that ran the bad version.

The attack chain is the new part. LiteLLM says the attacker held GitHub CLI credentials for three developers, one of them an organization owner. It says the attacker used that token to disable branch protections, force-push a change that pointed the release workflow at a lookalike repository (`Berri-AI/litellm` instead of `BerriAI/litellm`), and run it. Two days earlier the team had temporarily widened release permissions so two engineers could publish bugfix backports. The post says a third developer's credentials were then used to delete the workflow records.

On where the tokens came from, the post says LiteLLM has seen specific situations in which Claude Code embeds a user's GitHub CLI OAuth token in a response body. It says that where response bodies are logged, the tokens can land in LiteLLM logs, and it believes the attacker read them from an internal LiteLLM deployment that was exposed to the internet. It has not confirmed how the attacker got into that deployment and suspects a recently patched vulnerability. This is LiteLLM's account of its own incident. We have not seen a response from Anthropic, and the post does not say how often the Claude Code behavior occurs.

**Why it matters:** If LiteLLM's account holds, logs from any gateway that records agent response bodies can contain the credentials those agents carry, so they need the same access controls and retention limits as a secrets store. It also shows how a short-lived widening of release permissions combined with one organization-owner token to defeat controls the team had hardened after its March incident.

---

## Also this cycle

- **[Security Disclosure: Wednesday October 21st](https://blog.railway.com/p/security-disclosure-wednesday-october-21st)** · Jacob Cooper, Railway, October 21, 2026 · Railway says an unauthorized third party may have accessed encrypted environment variables and decrypted some of them, and that it believes this is part of attacks on platform companies aimed at AI inference providers. It told upstream providers to revoke keys, paused all deployments, and recommends rolling every environment variable stored in Railway. This reflects the post as published on October 21; later status updates were not read.