GHSA-5mg7-485q-xm76: Supply Chain Compromise and Credential Harvesting Malware in LiteLLM

The LiteLLM package, a widely used AI management library and gateway, was the target of a sophisticated supply chain attack on March 24, 2026. Threat actors successfully bypassed repository security controls to publish two malicious package versions, 1.82.7 and 1.82.8, directly to the Python Package Index (PyPI). This compromise did not stem from a vulnerability in the LiteLLM source code itself, but rather a targeted attack against its build environment and release pipeline.

The malicious packages functioned as multi-stage malware designed to harvest sensitive developer and infrastructure credentials. Because LiteLLM operates as an AI gateway, it naturally processes and has access to high-value AI provider API keys (such as OpenAI and Anthropic), making it a lucrative target for credential theft. The exposure window lasted approximately three hours before PyPI security teams quarantined and removed the affected artifacts.

This incident highlights the critical risk posed by implicit trust in CI/CD pipeline dependencies. By compromising a third-party security scanning action, the attackers gained the execution privileges necessary to extract deployment secrets, entirely circumventing branch protection rules and multi-factor authentication requirements enforced at the repository layer.

The initial access vector for this supply chain compromise was the poisoning of a third-party GitHub Action used within the LiteLLM continuous integration pipeline. On March 19, 2026, the threat actor group identified as TeamPCP compromised the release tags for aqua-security/trivy-action, an open-source container security scanner. This action was explicitly defined as a step in the LiteLLM build workflow.

When the LiteLLM CI/CD pipeline executed using the poisoned Trivy action tags, it unknowingly pulled down and executed malicious shell code embedded by the attackers. This code was specifically engineered to access the runner's environment variables and memory space during the build process, allowing it to capture the PyPI publisher API tokens provisioned for the release job.

Possessing the valid PyPI publisher credentials, the threat actors no longer needed access to the LiteLLM GitHub repository. On March 24, 2026, they authenticated directly to the PyPI registry API and published the backdoored versions. This sequence demonstrates a classic CI/CD pivot, where a compromised tertiary dependency (Trivy action) leads to the compromise of primary deployment credentials.

The malware embedded within the published LiteLLM packages utilized Python's Path Configuration (.pth) file mechanism to guarantee execution and maintain persistence. When a Python package is installed via pip, .pth files included in the distribution are placed directly into the environment's site-packages directory.

During the initialization phase of the Python interpreter, the site module automatically scans the site-packages directory for any files ending in .pth. If a .pth file contains an executable statement prefixed with import, the interpreter evaluates and executes that code before any user scripts are run. The attackers leveraged this feature by embedding their stage-one payload invocation within a .pth file distributed with the malicious LiteLLM wheels.

This mechanism ensures the malware executes every time the Python interpreter starts within the compromised environment. The victim does not need to explicitly import litellm in their code; merely having the malicious package installed in the active virtual environment or system path is sufficient to trigger the payload upon any Python execution.

The embedded malware executes a sophisticated three-stage payload focused on broad credential theft and lateral movement. Stage 1 is an exhaustive information collection phase. The script traverses standard directory locations to harvest cloud provider credentials (targeting ~/.aws/credentials, GCP, and Azure configurations), SSH private keys (~/.ssh/), local .env files, and local cryptocurrency wallet data. Given the context of LiteLLM, it also aggressively scans environment variables for AI provider API keys.

Stage 2 handles the exfiltration of the harvested data. To evade rudimentary network-based data loss prevention (DLP) systems, the malware locally encrypts the aggregated secrets before transmission. The encrypted payload is then exfiltrated via HTTPS to models.litellm.cloud, a domain registered by the threat actors on March 23, 2026, specifically to masquerade as legitimate LiteLLM telemetry or model-fetching traffic.

Stage 3 introduces significant operational risk to containerized environments by deploying a "Kubernetes worm" module. This component inspects the local file system for injected Kubernetes service account tokens, typically mounted at /var/run/secrets/kubernetes.io/serviceaccount/token. If found, the malware uses the token to interact with the Kubernetes API, attempting to enumerate the cluster and move laterally to other pods or nodes.

The installation of LiteLLM version 1.82.7 or 1.82.8 results in a total loss of confidentiality for all secrets accessible to the Python environment's user context. Organizations must treat any system, container, or CI runner that installed these specific versions as fundamentally compromised. The impact extends beyond the immediate host, as the exfiltrated cloud credentials and Kubernetes tokens enable attackers to pivot into the broader infrastructure.

Immediate remediation requires isolating the affected environments from the network to halt ongoing exfiltration and lateral movement attempts. The malicious packages must be uninstalled, and dependencies should be pinned to known safe versions, such as 1.82.6 or verified subsequent releases. Forensic analysis should inspect network logs for connections to models.litellm.cloud to confirm if exfiltration occurred.

The most critical remediation step is comprehensive secret rotation. Because the malware indiscriminately harvests local state, administrators must systematically revoke and reissue all AWS/GCP/Azure IAM keys, GitHub Personal Access Tokens, SSH private keys, and AI provider API keys that were present on the affected systems. Failure to rotate these credentials leaves the infrastructure vulnerable to subsequent access by the threat actors, even after the malware is removed.