Reporting checked against the linked primary sources on October 25, 2026. The incidents described occurred earlier that week.
News update — October 25, 2026. LiteLLM disclosed that attackers compromised its software-release process on October 21 and distributed malicious versions of its popular AI integration package. The incident matters because malicious code could run during Python startup, even when an affected application did not directly import LiteLLM.
The project confirmed that litellm 1.107.0 was published as a compromised release on PyPI. Certain Docker image tags were also affected for limited windows on the same day. Those artifacts have been removed or replaced, but removing a malicious download does not automatically clean machines where it already executed.
What happened?
According to LiteLLM’s revised incident timeline, an attacker obtained access that ultimately allowed changes to its release workflow. A malicious package was built and released through the distribution channels users normally trust. The vendor’s October 23 investigation supersedes some of its early assumptions about the intrusion path.
The compromised package could collect credentials and other secrets. Microsoft Security researchers reported that its Python startup components could execute during normal interpreter initialization, increasing the potential exposure of developer workstations, CI/CD systems, and containers.
Which users need to check?
LiteLLM identified the affected PyPI build as litellm==1.107.0, distributed on October 21 between about 11:39 and 13:23 UTC. The affected container tags included v1.107.0, latest, main-latest, and main-stable during specified intervals that day.
Users who had pinned a clean earlier release and did not start an affected container during that window may not be affected by this specific compromise. Review the vendor’s current incident page for exact hashes and timing, especially if you use automated builds.
What should an affected team do?
- Use a separate trusted machine or clean environment to investigate.
- Check lockfiles, build records, and container digests against the vendor’s affected artifacts.
- If malicious code may have executed, treat accessible API keys, cloud credentials, deployment secrets, and service tokens as potentially exposed.
- Rebuild compromised environments from known-clean sources and rotate credentials using the vendor’s incident-response recommendations.
- Review cloud and service audit logs for unauthorized access. Involve your security team rather than assuming a package downgrade alone solves credential theft.
The project’s initial guidance explicitly warned affected teams not to begin remediation by running pip install in a possibly compromised Python environment because the malicious startup hook could execute again.
Why the wider software industry should care
Software supply-chain incidents blur the line between a trusted distribution channel and trusted code. A legitimate-looking package version is not proof its release pipeline was uncompromised. Pinning known versions, controlling CI permissions, and maintaining an inventory of dependencies make the response to incidents more manageable.
CyberUnpacked takeaway: if your organization installed the affected LiteLLM build on October 21, investigate the environment and credentials. Simply upgrading to another version may not be enough.
Primary sources
- LiteLLM’s incident report, updated with affected artifacts and response
- LiteLLM’s October 23 attack-chain investigation
- Microsoft Security analysis of the package compromise