A poisoned release of LiteLLM turned a routine Python install into a crypto-aware secret stealer that searched for wallets, Solana validator material, and cloud credentials every time Python started.

On Mar. 24, between 10:39 UTC and 16:00 UTC, an attacker who had gained access to a maintainer account published two malicious versions of LiteLLM to PyPI: 1.82.7 and 1.82.8.

LiteLLM markets itself as a unified interface to more than 100 large language model providers, a position that places it inside credential-rich developer environments by design. PyPI Stats records 96,083,740 downloads in the last month alone.

The two builds carried different levels of risk. Version 1.82.7 required a direct import of litellm.proxy to activate its payload, while version 1.82.8 planted a .pth file (litellm_init.pth) in the Python installation.

Python’s own documentation confirms that executable lines in .pth files run at every Python startup, so 1.82.8 executed without any import at all. Any machine that had it installed ran compromised code the moment Python next launched.

FutureSearch estimates 46,996 downloads in 46 minutes, with 1.82.8 accounting for 32,464 of them.

Additionally, it counted 2,337 PyPI packages that depended on LiteLLM, with 88% allowing the compromised version range at the time of the attack.

LiteLLM’s own incident page warned that anyone whose dependency tree pulled in LiteLLM through an unpinned transitive constraint during the window should treat their environment as potentially exposed.

The DSPy team confirmed it had a LiteLLM constraint of “superior or equal to 1.64.0” and warned that fresh installs during the window could have resolved to the poisoned builds.

Built to hunt crypto

SafeDep’s reverse engineering of the payload makes the crypto targeting explicit.

The malware searched for Bitcoin wallet configuration files and wallet*.dat files, Ethereum keystore directories, and Solana configuration files under ~/.config/solana.

SafeDep says the collector gave Solana special treatment, showing targeted searches for validator key pairs, vote account keys, and Anchor deploy directories.

Solana’s developer documentation sets the default CLI keypair path at ~/.config/solana/id.json. Anza’s validator documentation describes three authority files central to validator operation, and states that theft of the authorized withdrawer gives an attacker complete control over validator operations and rewards.

Anza also warns that the withdrawal key should never sit on the validator machine itself.

SafeDep says the payload harvested SSH keys, environment variables, cloud credentials, and Kubernetes secrets across namespaces. When it found valid AWS credentials, it queried AWS Secrets Manager and the SSM Parameter Store for additional information.

It also created privileged node-setup-*pods in kube-system and installed persistence through sysmon.py and a systemd unit.

For crypto teams, the compounded risk runs in a specific direction. An infostealer that collects a wallet file alongside the passphrase, deploy secret, CI token, or cluster credential from the same host can convert a credential incident into a wallet drain, a malicious contract deployment, or a signer compromise.

Related Reading

Curve Finance TVL falls over $1B following Vyper vulnerability exploit

Curve’s CRV token became highly volatile following the attack, prompting fears of a contagion.

Jul 31, 2023 · Oluwapelumi Adejumo

The malware assembled exactly that combination of artifacts.

Targeted artifactExample path / fileWhy it mattersPotential consequenceBitcoin wallet fileswallet*.dat, wallet config filesMay expose wallet materialWallet theft riskEthereum keystores~/.ethereum/keystoreCan expose signer material if paired with other secretsSigner compromise / deployment abuseSolana CLI keypair~/.config/solana/id.jsonDefault developer key pathWallet or deploy authority exposureSolana validator authority filesvalidator keypair, vote-account keys, authorized withdrawerCentral to validator operations and rewardsValidator authority compromiseAnchor deploy directoriesAnchor-related deployment filesCan expose deploy workflow secretsMalicious contract deploymentSSH keys~/.ssh/*Opens access to repos, servers, bastionsLateral movementCloud credentialsAWS/GCP/Azure env or configExpands access beyond the local hostSecret-store access / infra takeoverKubernetes secretscluster-wide secret harvestOpens control plane and workloadsNamespace compromise / lateral spread

This attack is part of a wider campaign, as LiteLLM’s incident note links the compromise to the earlier Trivy incident, and Datadog and Snyk both describe LiteLLM as a later stage in a multi-day TeamPCP chain that moved through several developer ecosystems before reaching PyPI.

The targeting logic runs consistently across the campaign: a secret-rich infrastructure tooling provides faster access to wallet-adjacent material.

Potential outcomes for this episode

The bull case rests on the speed of detection and the absence, so far, of publicly confirmed crypto theft.

PyPI quarantined both versions by approximately 11:25 UTC on Mar. 24. LiteLLM removed the malicious builds, rotated maintainer credentials, and engaged Mandiant. PyPI currently shows 1.82.6 as the latest visible release.

If defenders rotated secrets, audited for litellm_init.pth, and treated exposed hosts as burned before adversaries could convert exfiltrated artifacts into active exploitation, then the damage stays contained to credential exposure.

The incident also accelerates the adoption of practices already gaining ground. PyPI’s Trusted Publishing replaces long-lived manual API tokens with short-lived OIDC-backed identity, approximately 45,000 projects had adopted it by November 2025.

LiteLLM’s incident involved the abuse of release credentials, making it much harder to dismiss the case for switching.

For crypto teams, the incident creates urgency for tighter role separation: cold validator withdrawers kept fully offline, isolated deployment signers, short-lived cloud credentials, and locked dependency graphs.

The DSPy team’s rapid pinning and LiteLLM’s own post-incident guidance both point toward hermetic builds as the remediation standard.

The bear case turns on lag. SafeDep documented a payload that exfiltrated secrets, spread inside Kubernetes clusters, and installed persistence before detection.

An operator who installed a poisoned dependency inside a build runner or cluster-connected environment on Mar. 24 may not discover the full scope of that exposure for weeks. Exfiltrated API keys, deploy credentials, and wallet files do not expire on detection. Adversaries can hold them and act later.

Sonatype puts malicious availability at “at least two hours”; LiteLLM’s own guidance covers installs through 16:00 UTC; and FutureSearch’s quarantine timestamp is 11:25 UTC.

Teams cannot rely solely on timestamp filtering to determine their exposure, as those figures do not yield a clear all-clear.

The most dangerous scenario in this category centers on shared operator environments. A crypto exchange, validator operator, bridge team, or RPC provider that installed a poisoned transitive dependency inside a build runner would have exposed an entire control plane.

Kubernetes secret dumps across namespaces and privileged pod creation in the kube-system namespace are control-plane access tools designed for lateral movement.

If that lateral movement reached an environment where hot or semi-hot validator material was present on reachable machines, the consequences could range from individual credential theft to compromise of validator authority.

PyPI’s quarantine and LiteLLM’s incident response closed the active distribution window.

Teams that installed or upgraded LiteLLM on Mar. 24, or that ran builds with unpinned transitive dependencies resolving to 1.82.7 or 1.82.8, should treat their environments as fully compromised.

Some actions include rotating all secrets accessible from exposed machines, auditing for litellm_init.pth, revoking and reissuing cloud credentials, and verifying that no validator authority material was accessible from those hosts.

The LiteLLM incident documents a path of an attacker who knew exactly which off-chain files to look for, had a delivery mechanism with tens of millions of monthly downloads, and built persistence before anyone pulled the builds from distribution.

The off-chain machinery that moves and safeguards crypto sat directly in the payload’s search path.