Hackers sneak crypto wallet-stealing code into a popular AI tool that runs every time

A compromised maintainer account on PyPI led to the release of two malicious versions of the LiteLLM Python package, versions 1.82.7 and 1.82.8, on March 24th. These versions contained a payload designed to steal sensitive information, including cryptocurrency wallet credentials, Solana validator materials, and cloud secrets, executing automatically upon Python startup.

Attack Details and Scope

The attacker gained access to a maintainer account and published the malicious versions between 10:39 UTC and 16:00 UTC on March 24th. LiteLLM, a popular unified interface for over 100 large language model providers with nearly 96 million downloads in the last month, is integrated into many developer environments, making it a prime target. Version 1.82.7 required a direct import to activate its payload, while version 1.82.8 planted a litellm_init.pth file, which executes code at every Python startup. FutureSearch estimates that version 1.82.8 alone had 32,464 downloads in 46 minutes, affecting an estimated 46,996 downloads in total. Approximately 2,337 PyPI packages depended on LiteLLM, with 88% vulnerable to the compromised version range.

Targeted Information and Crypto Focus

Reverse engineering by SafeDep revealed the malware's explicit targeting of crypto assets. It searched for Bitcoin wallet configuration files and wallet*.dat files, Ethereum keystore directories, and Solana configuration files. Special attention was given to Solana, with targeted searches for validator key pairs, vote account keys, and Anchor deploy directories. The payload also harvested SSH keys, environment variables, cloud credentials (AWS, GCP, Azure), and Kubernetes secrets. When AWS credentials were found, it queried AWS Secrets Manager and SSM Parameter Store for more data. The malware also created privileged pods in kube-system and installed persistence mechanisms.

The combination of harvested artifacts, such as wallet files with passphrases, deploy secrets, CI tokens, or cluster credentials from the same host, creates a significant risk for crypto teams. This could lead to wallet drains, malicious contract deployments, or signer compromises.

Broader Campaign and Potential Outcomes

The LiteLLM compromise is linked to a wider supply chain campaign, as noted in LiteLLM's incident report and analyses by Datadog and Snyk. This campaign targeted infrastructure tooling that provides access to wallet-adjacent material. The attack vector consistently involved exploiting secret-rich developer ecosystems.

The bull case for this incident relies on the rapid detection and response. PyPI quarantined the malicious versions by 11:25 UTC on March 24th, and LiteLLM removed the builds, rotated credentials, and engaged security firms. If exposed environments were secured before exploitation, the damage might be limited to credential exposure. The incident also highlights the growing importance of practices like PyPI's Trusted Publishing, which uses short-lived OIDC-backed identities instead of long-lived API tokens.

However, the bear case centers on the potential for delayed discovery. The payload installed persistence and harvested secrets before detection, meaning compromised environments could remain vulnerable for weeks. Adversaries can hold exfiltrated credentials and act later. The most dangerous scenario involves shared operator environments, such as those used by crypto exchanges or validator operators, where a compromised build runner could expose an entire control plane. This could lead to validator authority compromise.

Remediation and Best Practices

Teams that installed or upgraded LiteLLM on March 24th, or used builds with unpinned transitive dependencies resolving to versions 1.82.7 or 1.82.8, should treat their environments as fully compromised. Recommended actions include rotating all accessible secrets, auditing for litellm_init.pth, revoking and reissuing cloud credentials, and verifying that validator authority material was not accessible from exposed hosts. The incident underscores the need for tighter role separation for crypto teams, including offline cold validator withdrawers, isolated deployment signers, short-lived cloud credentials, and locked dependency graphs. Hermetic builds are recommended as a remediation standard.