Stolen credentials used after LiteLLM's official packages and containers carried malware

Public release channels carried the malicious artifacts

LiteLLM's October 21 compromise reached all seven PyPI wheels for version 1.107.0 and official container images. The maintainer says wheel publication began at 11:39:51 UTC and removal was complete by 13:23. Container publication began at 11:46:56 through GitHub Container Registry and Docker Hub. Affected tags included v1.107.0, latest, main-latest and main-stable, so exposure checks cannot rely only on finding an explicitly pinned version. [6][9]

Affected GitHub images included berriai/litellm, litellm-database and litellm-non_root; their affected tags were unavailable by 13:51. Docker Hub's litellm/litellm exposure continued until 14:20, when affected tags were removed or redirected to clean artifacts. LiteLLM says its private enterprise registry was unaffected, but that does not exempt enterprise customers using public artifacts. Cached packages and internally retained images require separate examination: registry removal did not erase them. [6][7]

The official pipeline signed the attacker's build

StepSecurity reconstructs a compromise involving credentials associated with three developers. One privileged credential overrode branch protection, another satisfied the production approval gate, and a third deleted workflow records. The altered workflow built from the lookalike repository Berri-AI/litellm rather than the legitimate BerriAI/litellm. The official pipeline then signed and published the malicious artifacts. This describes misuse of developer credentials, not evidence that the developers knowingly participated. [8]

Socket independently retrieved container provenance and matched the referenced malicious files to an inspected wheel. That provides independent technical corroboration of the artifact substitution. The defensive inference is that a valid signature alone could not establish safety when the authorized build process itself was compromised. Inspecting only the official source tag would also have missed the injected files, making the relationship between source, workflow and published artifact central to this investigation. [7][8]

Python startup could activate the collector

The packages placed cook.pth, cook.py and sitecustomize.py in Python's library directory. Normal interpreter startup could activate the malicious code before application code ran, without an application importing LiteLLM. That includes Python-based inspection or repair tools. Endor Labs also found an important packaging distinction: the source archive contained altered build configuration but omitted the payload files found in the poisoned wheels. [9]

The collector targeted cloud credentials, developer tokens, private keys, browser data and AI-tool authentication files, and attempted to retrieve credentials and model configuration from LiteLLM proxy databases. These capabilities do not prove successful retrieval or decryption in every environment. Socket documents platform-specific limitations and found the remote-code loader's GitHub pointer empty at 13:01:44 UTC. That observation does not establish delivery of a second stage, but the credential collector operated independently. [7][12]

Wiz observed stolen AWS credentials being tested

The strongest evidence of downstream harm comes from Wiz's telemetry. It observed attackers validating stolen AWS role credentials from CI runners and Kubernetes nodes approximately 4.5 hours after exfiltration. Between 16:20 and 17:01 UTC on October 21, activity included identity checks and model enumeration. Some environments also showed IAM and account discovery. This establishes actual credential abuse rather than only a theoretical consequence of installing the malware. [10]

The scope remains uncertain. Wiz cites approximately 49,000 downloads using ClickPy data, but downloads are not a count of infected machines, organizations or people. The observed cloud activity also does not establish paid model inference, a financial-loss total or completed theft from every exposed environment. Organization counts associated with LiteLLM's earlier March incident must not be carried into this October incident. [10][11]

Initial entry remains provisional, despite strong artifact evidence

LiteLLM believes attackers obtained GitHub CLI OAuth tokens from logs in its internet-exposed internal deployment. It reports circumstances in which Claude Code placed those tokens in logged responses, but has not confirmed how attackers first entered that deployment. This remains a proposed route to credential exposure, not an established initial-access vulnerability. Removal accounts also differ: Wiz gives approximate cutoffs, while the maintainer separates registries and extends Docker Hub exposure to 14:20. [6][10]

The evidence has several distinct foundations: LiteLLM supplies the primary distribution timeline, StepSecurity reconstructs release-control abuse, Socket independently examines provenance and files, Endor Labs compares package formats, and Wiz reports subsequent credential use. SecurityWeek's October 23 report and Help Net Security's October 22 coverage synthesize the incident, but their repetition of researchers' findings is not additional independent confirmation. The artifact and telemetry evidence is stronger than the still-provisional entry explanation. [1][6][7][8][9][10][11]

Respond beyond replacing version 1.107.0

Start with historical exposure: inspect lockfiles, dependency caches, CI logs and actual container digests, including deployments that followed floating tags. Use the maintainer's channel-specific availability windows rather than one approximate removal time. Isolate suspect environments and preserve evidence before rebuilding. Do not begin by running Python or pip inside them, because startup hooks can execute again. Endor Labs recommends a clean rebuild. [6][9]

From a clean system, revoke or rotate reachable cloud, developer and provider credentials. Scope that work around what the affected environment could access, including process environments, cloud metadata and proxy databases. Replacing the package addresses the installed component, but does not invalidate credentials already stolen. Wiz's observations make review of subsequent credential use an immediate part of response, not a precaution to postpone until losses are confirmed. [9][10][12]

Look for credential use outside expected infrastructure and examine malicious versions of the three startup files, /tmp/remote_code_loader.lock, and traffic to www[.]litellm[.]dev. Treat filenames as investigation leads rather than verdicts: legitimate Python installations can contain sitecustomize.py. Correlating file contents, deployment history and cloud activity is more informative than a filename-only search. [8]

Watch for a firmer entry account and broader impact evidence

The next consequential developments would be confirmation of initial access, a defensible victim count, evidence of additional payload delivery, or documented financial and data losses. Those questions remain open in the supplied reporting. Our inference from the current evidence is narrower but actionable: organizations that executed the affected artifacts should investigate credential compromise even if they have already rebuilt, because artifact removal and credential containment are separate tasks. [6][7][9][10]