The LiteLLM Supply Chain Breach

Understanding the TeamPCP Campaign and LiteLLM's Role

The compromise of LiteLLM, a widely used Python library and proxy layer for interacting with various Large Language Model (LLM) providers, was not an isolated incident. Instead, it was a critical component of a broader, multi-stage supply chain attack orchestrated by a threat actor group identified as TeamPCP. This sophisticated campaign systematically targeted a range of developer tools and platforms, demonstrating a calculated approach to infiltrating the software supply chain.

TeamPCP's operations unfolded over several days in March 2026, beginning with the compromise of other prominent tools before reaching LiteLLM. The attackers leveraged compromised credentials and established persistence within various ecosystems, including GitHub Actions, npm, and other package registries. This methodical progression allowed them to expand their reach and impact, moving from one compromised project to another, siphoning credentials, and reusing access or tradecraft at each stage.

The campaign's trajectory highlights a significant shift in attack methodologies, where adversaries target foundational components of the software development lifecycle. By compromising widely adopted libraries like LiteLLM, attackers can potentially gain access to numerous downstream projects and organizations that rely on these components. This incident serves as a stark reminder that the security of our AI and LLM deployments is intrinsically linked to the integrity of the underlying software supply chain.

The Mechanics of the LiteLLM Compromise

The LiteLLM supply chain attack involved the injection of malicious payloads into legitimate package versions, specifically 1.82.7 and 1.82.8, which were released on March 24, 2026. The attackers employed distinct, yet equally insidious, methods for executing their malicious code within these versions.

In version 1.82.7, the malicious logic was embedded directly within the litellm/proxy/proxy_server.py file. This meant that any system installing this version and subsequently importing the proxy module within their application would inadvertently execute the attacker's payload. The code was injected in a base64-encoded format, making it less immediately obvious upon casual inspection.

The compromise in version 1.82.8 presented an even greater threat due to its mechanism of execution. This version included a new file named litellm_init.pth within the package wheel. According to Python's site documentation, executable lines within .pth files are automatically run during the interpreter's startup. This critical detail meant that merely having litellm version 1.82.8 installed on a system was sufficient to trigger the malicious payload, regardless of whether the application explicitly imported any LiteLLM modules. This method ensured a higher probability of execution and persistence across affected systems.

Both versions carried a payload designed to collect sensitive information, encrypt it, and exfiltrate it to attacker-controlled domains. The sophistication of these injection techniques underscores the evolving nature of supply chain attacks, where attackers seek to bypass traditional security measures by compromising trusted software components at their source.

Impact and Indicators of Compromise

The immediate impact of the LiteLLM supply chain attack was the potential for widespread data exfiltration and system compromise across environments where the malicious versions were installed. The payload was meticulously designed to harvest a broad spectrum of sensitive information, including environment variables, SSH keys, cloud credentials (AWS, GCP, Azure), Kubernetes data, Docker configurations, shell history, database credentials, cryptocurrency wallet files, and CI/CD secrets. This collected data was then encrypted using a hybrid AES-256 and RSA-4096 scheme before being exfiltrated to attacker-controlled domains, primarily models.litellm[.]cloud.

Beyond data theft, the malware aimed to establish persistence on compromised systems. It achieved this by writing a Python script, sysmon.py, to ~/.config/sysmon/ and installing it as a user systemd service named sysmon.service. This backdoor allowed the attackers to maintain access and continuously poll https://checkmarx[.]zone/raw for second-stage payloads, such as /tmp/pglog, which would then be executed. In Kubernetes environments, the threat escalated further, with the malware attempting to create privileged node-setup-* pods to spread persistence across the entire cluster.

Organizations need to be vigilant in identifying potential compromises. Key indicators of compromise (IOCs) include:

• File Presence: Look for litellm_init.pth within the site-packages/ directory, as well as ~/.config/sysmon/sysmon.py, ~/.config/systemd/user/sysmon.service, /tmp/pglog, and /tmp/.pg_state.
• Network Activity: Monitor for outbound HTTPS connections to models.litellm[.]cloud and checkmarx[.]zone.
• Kubernetes Anomalies: Review audit logs for unusual secret access, the creation of privileged pods, or any pods named node-setup-*.

With versions 1.82.7 and 1.82.8 downloaded approximately 16,846 and 102,293 times respectively during their malicious availability, the potential exposure was significant. This highlights the critical need for robust detection mechanisms and a proactive security posture to mitigate the risks associated with compromised software supply chains.

Remediation and Proactive Defense Strategies

Responding to a supply chain attack like the LiteLLM compromise requires immediate and comprehensive action. If an organization installed either litellm version 1.82.7 or 1.82.8, it is crucial to treat any environment where these versions were present as potentially compromised.

Immediate Remediation Steps:

• Isolate Affected Systems: Quickly identify and isolate all hosts, containers, CI jobs, and developer workstations that installed the malicious versions. While distinguishing between systems where the package was merely present versus those where the payload likely executed is important, err on the side of caution and assume compromise if execution cannot be definitively ruled out.
• Map and Rotate Credentials: Review all credentials accessible to the affected processes. This includes cloud credentials, GitHub and package publishing tokens, CI secrets, SSH keys, Kubernetes service account tokens, .env files, and access to centralized secret stores. Prioritize rotating credentials that could enable further code publication, CI/CD access, or infrastructure creation.
• Rebuild Environments: Rebuild compromised environments from known-good images with pinned dependencies. Do not simply revert the LiteLLM package, as this does not constitute a complete remediation.
• Hunt for Follow-on Activity: Actively search for signs of persistence or follow-on attacks. This includes monitoring for outbound traffic to models.litellm[.]cloud and checkmarx[.]zone, as well as checking for suspicious filesystem artifacts like litellm_init.pth, ~/.config/sysmon/sysmon.py, and sysmon.service. In Kubernetes, scrutinize audit logs for unusual secret access or privileged pod creation.

Proactive Defense Strategies:

To prevent similar supply chain attacks, organizations should adopt a multi-layered security approach:

• Dependency Scanning: Implement continuous scanning of all third-party dependencies for known vulnerabilities and malicious injections. Tools that monitor package integrity and flag suspicious changes are invaluable.
• Least Privilege: Enforce the principle of least privilege for all development and deployment environments. Limit the permissions of CI/CD pipelines and developer workstations to only what is strictly necessary.
• Supply Chain Security Tools: Utilize supply chain security solutions that can detect and prevent the introduction of malicious code into your development pipeline. This includes tools that can analyze package behavior and identify anomalous activities.
• Code Review and Auditing: Conduct thorough code reviews, especially for changes to critical dependencies. Regular security audits of your codebase and infrastructure can help identify weaknesses before they are exploited.
• Network Segmentation: Segment networks to limit the blast radius of a potential compromise. If one part of your system is compromised, network segmentation can prevent attackers from easily moving laterally to other critical assets.
• Incident Response Plan: Develop and regularly test a comprehensive incident response plan specifically tailored for supply chain attacks. Knowing how to react swiftly and effectively can significantly reduce the impact of such incidents.

The LiteLLM supply chain attack serves as a critical lesson in the evolving landscape of cybersecurity. As AI and LLM technologies become more integrated into our systems, securing their underlying components is paramount. By understanding the attack mechanisms and implementing robust defense strategies, we can collectively enhance the resilience of our software ecosystems against sophisticated threats like TeamPCP.