Attackers hijack LiteLLM releases to distribute credential-stealing malware

LiteLLM’s official source tag was clean. The software distributed under that version was not. On October 21, 2026, attackers hijacked the project’s release pipeline to publish malicious Python packages and container images. The compromised release, version 1.107.0, carried credential-stealing malware and tools for remote code execution, prompting warnings to treat affected environments as compromised.

LiteLLM provides a common interface and proxy for AI model providers. Socket’s malware analysis found targets extending beyond those providers’ access keys: cloud identities, developer credentials, private keys, browser data and AI coding-tool authentication files. The payload could therefore reach secrets outside the gateway’s immediate job.

Official distribution, attacker-controlled source

In its incident report, LiteLLM said attackers used credentials associated with three engineers’ GitHub accounts, apparently stolen GitHub CLI OAuth tokens. One account changed the release pipeline and triggered a release run; another approved it. Credentials associated with a third account deleted workflow records, limiting the logs available to investigators.

The company said the malicious artifacts were built from an attacker-controlled repository. Container build records identified Berri-AI/litellm, a name differing by one hyphen from the legitimate BerriAI/litellm project. Upwind’s original investigation found the payload absent from the official version tag but present in the distributed packages. Inspecting that tag alone would have missed the malicious files.

Exposure was not limited to users explicitly choosing 1.107.0. Container labels such as latest, main-latest and main-stable also pointed to compromised images. LiteLLM said its private enterprise registry was unaffected. The company has revoked the involved tokens, temporarily removed all but one unaffected GitHub organization member, and removed registry trust links to the organization.

Python startup was enough

The wheels installed three files into Python’s library directory: cook.pth, cook.py and sitecustomize.py. Python normally processes these startup hooks before application code runs. That allowed the payload to execute without an application importing LiteLLM. Simply downloading a wheel or inspecting its archive as data did not trigger those hooks, according to Socket.

The collector sought readable secrets across the host, including other processes’ environment variables on Linux and cloud instance credentials. It also specifically targeted LiteLLM deployments with a configured database connection, attempting to query saved credentials and model settings. Socket cautioned that this code did not demonstrate successful access to any particular deployment or decryption of every returned credential.

Collected information was encrypted, packed into an archive and sent to an attacker endpoint disguised as a health check. A separate background loader could fetch and execute remotely supplied Python without checking a signature or content hash. Its destination came from a changeable file hosted in a GitHub repository.

Socket found that pointer empty at 13:01:44 UTC, preventing the loader from reaching its download stage at that moment. That did not disable the independent credential collector. The analysis also found platform limits: some database and browser-password routines would not work on ordinary macOS installations, while other collection modules remained applicable.

Recovery starts outside the affected Python environment

LiteLLM warns against beginning cleanup with pip, Python’s package manager: starting it can run the malicious hooks again. Its guidance favors rebuilding container images and isolated Python environments from scratch rather than relying on a package reinstall. Removing only LiteLLM’s own directory would leave the startup files and an existing background process untouched.

• Check deployment records, lockfiles, caches and running image identifiers, including systems that followed floating container tags. If Python ran with 1.107.0 installed, isolate the environment and preserve useful evidence before rebuilding.
• Use the explicitly pinned version 1.106.2 recommended by LiteLLM. For affected environments, rotate accessible secrets, including cloud role credentials, provider keys saved in the proxy database, master and virtual keys, and the database password.
• Do not treat missing malware files or a missing upload marker as proof of safety. LiteLLM advises assuming data theft succeeded if 1.107.0 was installed on a host with outbound internet access.

LiteLLM labels the incident contained, with its investigation continuing. It has not identified how the attackers obtained the GitHub tokens and says it cannot yet assert that no further access to those accounts remains.