An AI gateway designed to steal your data

In March 2026, a critical supply chain attack targeted the popular Python library LiteLLM, widely used as an AI agent gateway. Attackers injected malicious code into versions 1.82.7 and 1.82.8 hosted on PyPI. The malware executed upon import or interpreter start, deploying obfuscated scripts to steal sensitive infrastructure data. Targets included AWS credentials, Kubernetes configurations, database secrets, SSH keys, and crypto wallet files. The payload utilized cloud metadata services to extract runtime secrets, significantly expanding the potential blast radius within cloud environments. Data was encrypted and exfiltrated to remote command-and-control servers. This incident highlights the severe risks associated with third-party dependencies in AI infrastructure. Organizations using LiteLLM must immediately audit their installations, rotate compromised credentials, and implement strict software supply chain verification processes to prevent unauthorized package modifications and mitigate data loss risks.

Dissecting the supply chain attack on LiteLLM, a multifunctional gateway used in many AI agents. Explaining the dangers of the malicious code and how to protect yourself.

In March 2026, a critical supply chain attack targeted the popular Python library LiteLLM, widely used as an AI agent gateway. Attackers injected malicious code into versions 1.82.7 and 1.82.8 hosted on PyPI. The malware executed upon import or interpreter start, deploying obfuscated scripts to steal sensitive infrastructure data. Targets included AWS credentials, Kubernetes configurations, database secrets, SSH keys, and crypto wallet files. The payload utilized cloud metadata services to extract runtime secrets, significantly expanding the potential blast radius within cloud environments. Data was encrypted and exfiltrated to remote command-and-control servers. This incident highlights the severe risks associated with third-party dependencies in AI infrastructure. Organizations using LiteLLM must immediately audit their installations, rotate compromised credentials, and implement strict software supply chain verification processes to prevent unauthorized package modifications and mitigate data loss risks. Dissecting the supply chain attack on LiteLLM, a multifunctional gateway used in many AI agents. Explaining the dangers of the malicious code and how to protect yourself. A significant proportion of cyberincidents are linked to supply chain attacks, and this proportion is constantly growing. Over the past year, we have seen a wide variety of methods used in such attacks, ranging from creation of malicious but seemingly legitimate open-source libraries or delayed attacks in such seemingly legitimate libraries, to the simplest yet most effective method: compromising the accounts of popular library owners to subsequently release malicious versions of their libraries. Such libraries are used by developers everywhere and are included in many solutions and services. The consequences of an attack can vary widely, ranging from delivering malware to a developer’s device to compromising an entire infrastructure if the malicious library has made its way into the code of a service or product. This is exactly what happened in March 2026, when attackers injected malicious code into the popular Python library LiteLLM, which serves as a multifunctional gateway for a large set of AI agents. The attackers released two trojanized versions of LiteLLM that delivered malicious scripts to the victim’s system. Both versions made their way into the PyPI repository for Python. A technical analysis revealed that the attackers’ primary targets were servers storing confidential data related to AWS, Kubernetes, NPM, etc., as well as various databases (MySQL, PostgreSQL, MongoDB, etc.). In the latter case, the attackers were primarily interested in database configurations. In addition, the malware’s logic included functionality for stealing confidential data from crypto wallets and techniques for establishing a foothold in the Kubernetes cluster. Repository compromise The compromise affected the package distribution channel via PyPI: on March 24, 2026, malicious LiteLLM versions litellm==1.82.7 and litellm==1.82.8 were uploaded to the registry. It was specifically the package’s distribution contents that were compromised: in version 1.82.7, the malicious code was embedded in proxy_server.py, and in 1.82.8, the file litellm_init.pth was added. Technical analysis Both versions of the library contained the same malicious code, but its execution was implemented differently. In version 1.82.7, it was executed only when the proxy functionality was imported, while in 1.82.8, a .pth file was added that was able to execute the code every time the interpreter started. Example of the malicious code in proxy_server.py The malicious code in the proxy_server.py and litellm_init.pth files contained Python code encoded in Base64. After execution, the infected script saved this code alongside itself as a p.py file and immediately executed it. The p.py script launched the main payload – another script, also encoded in Base64 – without saving it to disk. At the same time, it wrote the output of this payload to a file in the directory from which it was launched. Before being written, the output was encrypted using the AES-256-CBC algorithm with a random key generated in the code, which was saved to the session.key file. The key file was also encrypted – using a pre-initialized public RSA key. The encrypted key and the output were combined into a tpcp.tar.gz archive and sent to the attackers’ remote server. What exactly happened within the malicious payload whose output was sent to the C2 server? After it was launched, a recursive scan of the working directories on the victim’s system (/root, /app/, /var/www, etc.) began. In each directory, the script scanned the contents of files, which it output to the stdout buffer, from where it was then saved to the aforementioned file as the result. Next, the script collected system information and also saved it to the file. After that, it proceeded to search for sensitive data. It was interested in the following...