{"slug": "what-exactly-happened-in-the-litellm-attack", "title": "What exactly happened in the LiteLLM attack", "summary": "LiteLLM's release pipeline was compromised on October 21, 2026, and attackers published a malicious litellm==1.107.0 package to PyPI plus compromised Docker Hub and GitHub Container Registry images, according to LiteLLM's official incident report. The malicious PyPI package was available from approximately 11:39 to 13:23 UTC, and affected Docker Hub tags pointed to compromised images until approximately 14:20 UTC; the payload was designed to steal credentials and execute at Python interpreter startup. Attackers reportedly obtained GitHub CLI OAuth tokens tied to three LiteLLM engineers to bypass release protections, and LiteLLM recommends pinning to version 1.106.2 or another verified safe version while treating environments that ran the affected artifacts as potentially compromised.", "body_md": "[Return to Blogs](https://ctrlb.ai/blogs)\n\n# LiteLLM Supply Chain Attack: What Engineering and Security Teams Need to Know\n\nOn October 21, 2026, widely used open-source LLM gateway LiteLLM experienced a software supply chain compromise that resulted in malicious software being distributed through its official Python package and container image registries. The issue has now been resolved.\n\nThe compromised release, litellm==1.107.0, contained malware designed to steal credentials and enable remote code execution. The malicious package was available on PyPI for approximately two hours, while affected Docker images remained available for longer.\n\nFor organizations using LiteLLM to connect applications to large language models (LLMs), this incident highlights a critical security risk: **a compromise in the software supply chain can expose credentials and infrastructure well beyond the application where the compromised package is installed.**\n\n### What happened?\n\nAccording to LiteLLM’s [official incident report](https://docs.litellm.ai/blog/security-incident-oct-21-2026), attackers compromised the release pipeline and published a malicious version of the software.\n\nThe incident involved three key elements:\n\n- **Credential theft:** The malicious package contained a payload designed to collect sensitive credentials accessible to the compromised environment.\n- **Persistent malicious execution:** Additional components were designed to execute during Python interpreter startup, potentially allowing the attacker to maintain access and execute remote code.\n- **Compromised release artifacts:** The affected artifacts were published through official distribution channels, including PyPI, Docker Hub, and GitHub Container Registry (GHCR).\n\nThe attackers reportedly obtained GitHub CLI OAuth tokens associated with three LiteLLM engineers. These credentials were used to bypass release protections, modify the release workflow, and publish artifacts built from an attacker-controlled repository that closely resembled the legitimate LiteLLM repository.\n\nLiteLLM has removed the affected artifacts and reported that the incident was contained, with its investigation ongoing at the time of its initial report.\n\n### Which versions and deployments are affected?\n\n| Distribution | Affected versions or tags | \n|---|---|\n| PyPI | **litellm==1.107.0** | \n| Docker Hub | **v1.107.0** , latest, main-latest, main-stable | \n| GitHub Container Registry | Corresponding affected image tags, including **v1.107.0** ,**latest** ,**main-lates** t, and**main-stable** | \n\nThe exposure windows differed by distribution. The malicious PyPI package was available from approximately 11:39 to 13:23 UTC on October 21. Affected Docker Hub tags pointed to compromised images until approximately 14:20 UTC.\n\nLiteLLM advised open-source users to treat environments that installed or executed the compromised artifacts during the relevant windows as potentially compromised.\n\nThe company also stated that customers using its private LiteLLM Enterprise release were not affected by this incident.\n\nFor the definitive scope and latest updates, consult the [official LiteLLM advisory](https://docs.litellm.ai/blog/security-incident-oct-21-2026).\n\n### What should organizations do now?\n\nOrganizations using LiteLLM should verify their exposure and take appropriate containment measures.\n\n#### 1. Verify installed versions and container images\n\nCheck whether any development, staging, or production environment installed LiteLLM version 1.107.0 or ran a compromised container image during the exposure window.\n\nDo not rely solely on the current package version or image tag. Review deployment records, package installation logs, container digests, and build histories to determine what actually ran.\n\nLiteLLM recommends pinning to version 1.106.2 or another explicitly verified safe version. Its initial report states that versions published before the compromised release were unaffected by this incident.\n\n#### 2. Treat exposed environments as potentially compromised\n\nIf an affected artifact was executed, updating or downgrading the package alone may not be sufficient.\n\nFollow LiteLLM’s remediation instructions, isolate affected workloads where appropriate, and rebuild environments from verified clean artifacts. Avoid starting Python processes in an affected environment before following the vendor’s cleanup guidance, because the malicious components may execute during interpreter startup.\n\nInvestigate the affected host or container for indicators of compromise. The absence of a known indicator does not, by itself, establish that an environment is clean.\n\n#### 3. Rotate potentially exposed credentials\n\nIf a compromised artifact ran in an environment with access to secrets, assume those credentials may have been exposed and rotate them as appropriate.\n\nPrioritize:\n\n- LLM provider API keys and LiteLLM proxy secrets.\n- Cloud credentials and workload identity permissions.\n- Database credentials, including credentials used in connection strings.\n- SSH keys, developer access tokens, and other secrets available to processes on the affected host.\n\nReview cloud audit logs and identity activity for suspicious access. Also investigate whether exposed credentials were used from unfamiliar infrastructure or locations.\n\n#### 4. Review software supply chain controls\n\nThis incident is a reminder that trusted package registries and official container repositories do not, by themselves, guarantee that every published artifact is safe.\n\nEngineering and security teams should review their dependency management practices, including:\n\n- **Version pinning:** Avoid relying on floating package versions and mutable container tags for production workloads.\n- **Artifact verification:** Verify container digests, provenance, and signatures where available.\n- **Release pipeline security:** Restrict publishing permissions, enforce independent approvals, and protect CI/CD workflows against unauthorized modifications.\n- **Secrets management:** Limit the credentials available to build and runtime environments, and avoid exposing long-lived tokens unnecessarily.\n- **Detection and response:** Maintain sufficient package, container, identity, and cloud audit logs to investigate suspicious activity.\n\nThese controls cannot eliminate every supply chain risk, but they can reduce exposure and improve the ability to detect and contain an incident.\n\n### What This Means for Infrastructure and Security Teams\n\nThe LiteLLM incident highlights a few practical lessons:\n\n- **Check for affected versions:** Review package versions, container images, and deployment logs to determine whether any environment installed or ran the compromised LiteLLM release (1.107.0).\n- **Clean up affected systems:** If the compromised version ran in your environment, rebuild affected systems using trusted software and rotate any credentials that may have been exposed.\n- **Investigate system activity:** Check deployment logs, running processes, container activity, access logs, and network connections for signs of suspicious activity.\n- **Keep historical logs:** Investigations may require logs from before an incident was detected. Short retention periods can leave gaps in the timeline.\n\nYou can use CtrlB to collect, search, and retain large telemetry data, making historical data more accessible when investigating incidents like this one. You can learn more from [here](https://ctrlb.ai/blogs/ctrlb-would-have-detected-litellm-security-threat-immediately).\n\nObservability won't prevent every compromise, but having the right data can help teams understand what happened and respond faster.\n\n**Official source:** [LiteLLM Security Incident Report, October 21, 2026](https://docs.litellm.ai/blog/security-incident-oct-21-2026)\n\n*This advisory is based on information published by LiteLLM as of October 23, 2026. Refer to the official incident report for subsequent updates and detailed remediation instructions.*", "url": "https://wpnews.pro/news/what-exactly-happened-in-the-litellm-attack", "canonical_source": "https://ctrlb.ai/blogs/litellm-supply-chain-attack-teams-need-to-know", "published_at": "2026-10-23 17:24:18+00:00", "updated_at": "2026-10-23 17:43:06.492204+00:00", "lang": "en", "topics": ["ai-safety", "ai-infrastructure", "ai-tools", "developer-tools", "artificial-intelligence"], "entities": ["LiteLLM", "PyPI", "Docker Hub", "GitHub Container Registry", "GitHub"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/what-exactly-happened-in-the-litellm-attack", "markdown": "https://wpnews.pro/news/what-exactly-happened-in-the-litellm-attack.md", "text": "https://wpnews.pro/news/what-exactly-happened-in-the-litellm-attack.txt", "jsonld": "https://wpnews.pro/news/what-exactly-happened-in-the-litellm-attack.jsonld"}}