LiteLLM Suspects GitHub Token Leak in AI Gateway Logs Behind Malicious Package Release

LiteLLM on Wednesday disclosed that threat actors compromised “multiple independent security controls” to push a malicious version of the Python package containing a credential stealer and a backdoor.

On October 21, 2026, LiteLLM’s release pipeline was compromised to push 1.107.0 to the Docker Hub registry and the Python Package Index (PyPI) repository. The incident took place around 4:00 a.m. PST. The following compromised versions were published –

• LiteLLM v1.107.0 (PyPI)
• v1.107.0, latest, main-latest, and main-stable (Docker)
• v1.107.0, latest, main-latest, and main-stable (GHCR)

Users who downloaded an unpinned version of LiteLLM between 11:39 a.m. and 1:23 p.m. UTC via pip or used the Docker image v1.107.0, latest, main-latest, or main-stable between 11:46 a.m. and 2:20 p.m. UTC are impacted.

The poisoned version incorporated code to harvest credentials and keys, and run arbitrary code from a remote server every hour, turning it into a remote access trojan (RAT).

Specifically, the Python interpreter processes a path file (“cook.pth”), which includes a command to import “cook,” a Python script (“cook.py”) that deobfuscates itself and runs a stealer routine named “privcollect” to gather system, browser, developer, cloud, and AI tool secrets, and exfiltrate the data to “litellm[.]dev/healthcheck” via an HTTP POST request.

In addition, the interpreter attempts to execute “sitecustomize.py,” which runs only on Linux and macOS machines, and is configured to fetch “domain.txt” from a now-removed GitHub dead drop (“github[.]com/letters9813”). Should this file return a valid response, the malware proceeds to download a second-stage Python script from “/codepy” and execute it.

“It forks a background daemon that acquires a lock at ‘/tmp/remote_code_loader.lock’ to prevent multiple instances, then enters an infinite loop,” Aikido researcher Ilyas Makari said. “Every hour, the daemon fetches the attacker’s current C2 domain from a GitHub repository (raw[.]githubusercontent[.]com/letters9813/pythonclient-test/main/domain[.]txt), then fetches and executes a Python payload from https://{domain}/codepy.”

“The dual-technique approach, using both .pth files and sitecustomize.py simultaneously, appears to be the first documented case in the wild,” Wiz researchers Benjamin Read and Rami McCarthy said.

Wiz said it has since observed abuse of stolen credentials, starting about 4.5 hours post-exfiltration, with the attacker validating AWS instance role credentials captured from compromised CI runners and Kubernetes nodes from the following IP addresses between 4:20 p.m. and 5:01 p.m. UTC –

• 168.100.8[.]57
• 165.227.201[.]8

“Each credential was checked with sts:GetCallerIdentity, followed by bedrock:ListFoundationModels and a ListModels call, consistent with LLMjacking,” Wiz added. “In a small number of environments, the attacker also enumerated IAM (ListRoles, ListUsers, ListAccessKeys) and performed general discovery (ListAccounts, DescribeTrails, etc.).”

In an advisory published Wednesday, LiteLLM said it had hardened its release pipeline following a similar incident that took place earlier this March. This included moving releases to a private repository, making Docker release tags immutable, and signing Docker images.

However, after the open-source project maintainers temporarily expanded release permissions to allow two internal engineers to publish daily bugfix backports for customers, the attacker leveraged their access to three sets of developer GitHub CLI credentials to ultimately push a malicious version.

The entire sequence of actions is below –

• On October 19, 2026, LiteLLM temporarily expanded release permissions for two internal engineers.
• The attacker had access to three sets of developer GitHub CLI credentials, including one that had the ability to run GitHub workflows.
• The attacker used a token belonging to one of its GitHub organization owners to disable branch protections and force-push the malicious changes.
• The attacker ran the compromised workflow, pointing it to a lookalike repository “Berri-AI/litellm” instead of “BerriAI/litellm,” causing the poisoned artifacts to be signed and published.

“After a thorough investigation, we have observed specific situations in which Claude Code will embed a user’s GitHub CLI OAuth token into a response body, and in situations where response bodies are logged, these tokens may appear in LiteLLM logs,” LiteLLM said.

The maintainers said they also identified an “unexpected, innocuously named user account” in its internal LiteLLM deployment that was exposed to the public internet. It’s suspected that the attacker gained access to this deployment, obtained the GitHub CLI OAuth tokens from its logs, and subsequently used those credentials to compromise the release workflow.

It’s currently unclear how the deployment became publicly accessible and how the attacker obtained access to it. However, LiteLLM has theorized that it was likely through a recently patched vulnerability.

The use of a “.pth” file to launch the stealer program is notable as it mirrors the modus operandi observed in the March 2026 attack attributed to TeamPCP. However, Socket told The Hacker News that there is no evidence at this stage to link the two incidents.

“The public evidence reviewed so far doesn’t establish a connection to the March attack,” Socket said. “The embedded RSA public keys differ, as do the exfiltration implementation and backdoor behavior. That doesn’t rule out the same operator using different tooling, but we don’t have evidence to support that attribution. Whether credentials stolen in March played a role also remains unverified.”

Developers are advised to remove LiteLLM 1.107.0 from their machines, isolate hosts on which the malicious version was installed, hunt for the malicious Python artifacts, block access to the exfiltration domain, rotate all credentials, and investigate the execution of “/codepy.”

“A single compromised install can hand an attacker the ability to push malicious code downstream,” JFrog security researcher Guy Korolevski said. “The lesson for security teams is that a clean source repository tells you little about the artifact you actually install, so verify the exact wheel and vet versions before they reach a build. If 1.107.0 ran anywhere in your environment, rotate every reachable credential and rebuild.”