The LiteLLM Supply Chain Attack: Dependency Security for AI Tools and Lessons for Businesses

In brief: On 21 October 2026 a malicious version (1.107.0) of LiteLLM, an open source project that gives applications one entry point to AI models, stayed live on PyPI and in the official Docker images for about two hours. According to security firm Datadog's analysis, the release contained a credential stealer that runs whenever Python starts and a second-stage backdoor capable of remote code execution. The targets: cloud, developer, AI-tool and browser credentials. The attackers triggered the release process with stolen GitHub CLI OAuth tokens from three engineers; how the tokens were first stolen was unclear at the time of writing. If you think you may be affected, you need to rotate your secrets from a clean machine. The incident shows a wider lesson for businesses: the dependencies of the software you use are part of your security surface. Information is as of 23 October 2026 and based on Datadog Security Labs.

Last updated: 23 October 2026

What is LiteLLM and why does it matter?

LiteLLM is an open source project that lets applications connect to different AI providers' models through a single interface; it is used both as a Python library and as a proxy server. Components like this typically hold the API keys of several providers. That is why compromising one can open many doors at once.

What happened? (as Datadog tells it)

Datadog also mentions a separate, earlier LiteLLM incident this year (versions 1.82.7 and 1.82.8); no connection between the two had been established at the time of writing.

Could you be affected?

Check if any of these apply:

• You installed/updated LiteLLM from PyPI in the two-hour window on 21 October, or pulled the latest / main-latest / main-stable Docker tags.
• Your AI gateway, agency or development environment has automatic updates without version pinning.
• Your CI/CD pipelines install litellm from scratch on every build.

If you're unsure, ask your software team/agency which version was installed and when.

If you were affected: Datadog's recommended steps

1. Manually delete cook.pth, cook.py and sitecustomize.py from site-packages; uninstalling the package does not remove them.
2. Remove all code and data associated with litellm 1.107.0.
3. Go back to 1.106.2 (the last safe version according to Datadog).
4. From a clean machine, rotate all potentially affected credentials: LLM API keys, cloud and SSH keys, secrets in .env, GitHub tokens.
5. Audit the logs for whether these credentials were used during the exposure window.

The other news of the same days: eMudhra

According to TechCrunch, in the same days the private keys of eMudhra, an Indian certificate authority, were compromised, a situation that could let attackers issue fake certificates and impersonate legitimate sites. Node.js's security release updated its CA certificate store for this reason too. The practical takeaway: keep your runtimes and operating-system certificate stores up to date.

An 8-point dependency security routine for businesses

This incident is not specific to AI projects; every software project rests on dozens to hundreds of open source components. Ask your software team for this routine:

1. Version pinning: In production, specific, tested versions (lock files, image digests) instead of automatic updates to “the latest.”
2. A waiting period for new releases: Don't use a newly published package immediately; a short wait gives time for incidents to be noticed.
3. Dependency inventory (SBOM) and scanning: Know which component is used where; scan for vulnerabilities and malicious packages.
4. Separating secrets: Rather than scattering API keys across code and .env files, manage them with limited scope and in a way that makes them easy to rotate; reduce long-lived tokens on developer machines.
5. Least privilege: Give each key only the permissions it needs; set spending limits.
6. Protecting the release process: Protect release workflows with multi-factor authentication, short-lived tokens and mandatory review.
7. An incident plan: Have a written answer to “If a component is compromised, who rotates which secrets, and how quickly?”
8. Cover AI tools too: Code assistants, agents and gateways are dependencies as well; see our AI use policy guide and our AI-assisted development article.

For the general security framework, see our web application security guide.

Security in AI projects with Aktaş Digital

In AI chatbot, document analysis and automation projects, API key management, component selection and the maintenance plan are topics to handle from the very start. If you'd like to discuss the security and dependency status of an existing AI integration, you can use our quote form. Related services: AI solutions.

Frequently Asked Questions

We don't use LiteLLM; does this concern us?

You aren't directly affected; but a similar incident can happen in your dependencies. That's why the routine above (version pinning, inventory, secret management) applies to every project.

Is uninstalling the package enough?

According to Datadog, no: the malicious release leaves extra files in site-packages that must be deleted by hand. Secrets must also be rotated.

Which version is safe?

Datadog names 1.106.2 as the last safe version. Verify the current status from LiteLLM's own security announcement.

What happens if my AI API keys are stolen?

An attacker can use your keys to run AI services up on your bill or gain data access. Rotate the keys, review usage logs and billing activity, and set spending limits.

Conclusion

The LiteLLM incident shows that a software project's security depends not only on your own code but on every package you use. The first thing you can do today: ask your software team in writing which versions your AI and other critical components are pinned to, and which secrets would be rotated, and how, if an incident occurred.