According to the reported incident analysis, the attack involved a lookalike GitHub repository, Berri-AI/litellm, which was reportedly used to trigger a release workflow. The attacker modified the pyproject.toml build configuration to inject three malicious files-cook.pth, cook.py, and sitecustomize.py—into the Python site-packages directory.

The malicious files reportedly abuse Python interpreter startup mechanisms to execute code automatically when Python initializes, potentially without requiring an application to explicitly import LiteLLM. Consequently, other Python applications running within the affected environment may also be exposed, depending on the execution context and the presence of the malicious files.

1. Credential Stealing Component (privcollect)

• Browser credentials, session cookies, and authentication tokens.
  
  
• SSH and GPG private keys and related credentials.
  
  
• Cloud credentials and access tokens associated with Amazon Web Services (AWS), Microsoft Azure, and Google Cloud.
  
  
• Environment variables, CI/CD secrets, and source-code repository access tokens.
  
  
• Authentication tokens associated with AI development tools, including Cursor and GitHub Copilot.

The reported sitecustomize.py component establishes a mechanism for retrieving and executing additional Python code. It reportedly launches a detached background process that periodically contacts an attacker-controlled GitHub repository used as a dead-drop mechanism.

The process may retrieve and execute attacker-supplied code, potentially enabling further compromise of the affected environment. This behavior may facilitate additional payload delivery, unauthorized access, and continued malicious activity.

Impact

• Credential compromise: Theft of cloud credentials, browser sessions, SSH/GPG keys, AI development-tool tokens, and CI/CD secrets.
  
  
• Unauthorized access: Compromise of developer workstations, build agents, CI/CD runners, containers, and production systems.
  
  
• LLM infrastructure compromise: Exposure of upstream LLM provider API keys, LiteLLM proxy credentials, and other secrets accessible to the affected deployment.
  
  
• Cloud infrastructure compromise: Potential lateral movement into connected cloud environments and other systems using stolen credentials.
  
  
• Remote code execution: Execution of additional attacker-controlled code within affected environments, potentially resulting in further system compromise.
  
  
• Supply-chain propagation: Risk of distributing compromised artifacts through internal package mirrors, container registries, build pipelines, or deployment processes if affected artifacts are reused.

• Software developers and application development teams.
  
  
• DevOps and Site Reliability Engineering (SRE) teams.
  
  
• Cloud security architects and system administrators.
  
  
• CI/CD pipeline and build infrastructure managers.
  
  
• AI/ML platform operators and organizations using LLM orchestration frameworks.
  
  
• Security Operations Centre (SOC) and incident response teams.

• Identify systems that installed LiteLLM 1.107.0 and systems that pulled or ran affected Docker images.
  
  
• Isolate suspected compromised hosts and containers as appropriate, preserving relevant logs and forensic evidence before making changes.
  
  
• Investigate for the malicious files, associated processes, marker files, and suspicious outbound connections. Terminate malicious processes after appropriate evidence collection.
  
  
• Rebuild or redeploy affected containers from a verified clean image. Avoid relying solely on in-place cleanup of potentially compromised containers.
  
  
• Remove compromised package and image artifacts from local caches, internal package mirrors, and container registries.
  
  
• Reinstall a verified clean LiteLLM release. The supplied analysis identifies 1.106.2 as a clean version; verify its integrity and suitability before pinning it.
  
  
• Review package lockfiles, dependency manifests, build logs, container digests, and deployment records to establish the scope of exposure.

• Cloud provider credentials, access keys, tokens, and exposed workload credentials.
  
  
• SSH/GPG keys and other credentials accessible to the compromised environment.
  
  
• Browser passwords, session cookies, and authentication tokens where exposure is plausible.
  
  
• AI development-tool tokens, including those associated with Cursor and GitHub Copilot.
  
  
• CI/CD secrets, source-code repository tokens, container registry credentials, and secrets stored in Vault or similar systems.
  
  
• Upstream LLM provider API keys and other credentials accessible to the LiteLLM proxy.
  
  
• LiteLLM proxy master_key and salt_key, where applicable, following the relevant recovery and key-management procedures.

• Search requirements.txt, poetry.lock, pyproject.toml, other dependency manifests, and software inventories for LiteLLM version 1.107.0.
  
  
• Inspect Python site-packages directories for cook.pth, cook.py, and unexpected or modified sitecustomize.py files.
  
  
• Review endpoint, DNS, proxy, firewall, container, and CI/CD logs for connections to the identified domains and dead-drop URL.
  
  
• Investigate unexpected requests to GitHub-hosted content and URLs containing /codepy.
  
  
• Review LiteLLM proxy database access, upstream provider usage, cloud audit trails, and source-code repository activity for evidence of credential misuse.
  
  
• Block confirmed malicious infrastructure using appropriate DNS, proxy, firewall, and endpoint controls, while retaining logs for incident response.
  
  
• Continue monitoring affected environments for unauthorized access, persistence, and suspicious use of previously exposed credentials.