The LiteLLM Supply Chain Attack: What Every Caribbean Business Using AI Must Know

Honoré Daumier, The Third-Class Carriage, 1864. The Metropolitan Museum of Art, public domain.

On March 24, 2026, two versions of LiteLLM, one of the most widely used Python packages in AI development, were found to contain malware. It was deliberate: code built to steal every credential on the machine and leave a backdoor for later. If your business runs AI tools written in Python, check your systems using the steps below.

What LiteLLM is and why attackers chose it

LiteLLM is an open-source Python library that lets developers call OpenAI, Anthropic, Google, Azure, Bedrock and dozens of other model providers through one interface. It has around 95 million monthly downloads on PyPI, about three million a day, and many agent frameworks and orchestration tools pull it in automatically.

Because it is a gateway, a typical LiteLLM deployment holds API keys for several AI providers in its environment variables. Few packages in an AI stack sit closer to so many secrets.

How the attack worked

A group called TeamPCP published two poisoned versions to PyPI, 1.82.7 and 1.82.8. They obtained the maintainer's publishing credentials through an earlier compromise of Trivy, an open-source security scanner used in LiteLLM's build pipeline. The bad versions were live for at least two hours before removal.

The malware collected:

• environment variables, including API keys and tokens;
• SSH keys;
• AWS, Google Cloud and Azure credentials;
• Kubernetes configurations and secrets across all namespaces;
• CI/CD secrets, Docker configurations and database credentials;
• cryptocurrency wallets.

It installed a persistent systemd service running sysmon.py that polls the attacker's servers for more payloads. Version 1.82.8 also dropped a .pth file, which Python runs at every interpreter start-up, even if nothing imports LiteLLM. Where it found a Kubernetes service account token, it read all cluster secrets and deployed privileged pods to every node. Developer laptops, CI runners and production servers were all exposed.

Customers using LiteLLM Cloud or the official LiteLLM Proxy Docker image were not affected, because those builds used a locked version and did not pull the latest release from PyPI.

Part of a wider campaign against security tools

Date (March 2026)	Target
19	Trivy vulnerability scanner compromised
21	Checkmarx/KICS GitHub Action hijacked
22	44 Aqua Security internal repositories defaced
24	LiteLLM backdoored on PyPI

The group went after a scanner first, then used that foothold to reach tools that depended on it. Some researchers link TeamPCP to the LAPSUS$ group; attribution was still under investigation at the time of writing.

Why Caribbean businesses are more exposed

BPOs in Jamaica, fintechs in Barbados, financial firms in The Bahamas, energy companies in Trinidad and government agencies across CARICOM are all deploying AI tools, often in Python. Four local conditions raise the risk:

• Thin security staff. A 200-person BPO in Montego Bay may have one IT person, now responsible for auditing every Python environment for a package they may never have heard of.
• Hidden dependencies. LiteLLM often arrives inside another framework. If you do not inspect your dependency tree, you will not know it is there.
• Shared keys. Many teams use one set of API keys across development, testing and production, so one leaked key exposes everything.
• Unpinned installs. Build scripts that run pip install litellm with no version take whatever is newest, including a poisoned release.

Checking and cleaning your systems

Find it. Run pip show litellm in every virtual environment, container image, CI runner and server. To see which package pulled it in, run pipdeptree -r -p litellm. Search lockfiles (requirements.txt, poetry.lock, uv.lock) for 1.82.7 and 1.82.8. Any machine that installed either version should be treated as compromised.

Look for persistence. Check for ~/.config/sysmon/sysmon.py, unfamiliar systemd services, unexpected .pth files in site-packages, and unknown pods, especially in kube-system.

Rotate credentials. Replace every AI provider key, cloud credential, database password, SSH key and CI token that was reachable from an affected machine. Rotate first, investigate second: the keys are the prize.

Rebuild, do not clean. Rebuild affected machines and images from a known-good base. Removing the files you found does not prove you found everything.

Watch outbound traffic. Look in firewall and proxy logs for HTTPS connections to unfamiliar hosts from build servers and production. If you find them, bring in an incident response firm.

Habits that would have prevented this

• Pin versions with hashes. litellm>=1.80 would have pulled the bad release. litellm==1.82.6 with a hash would not. Use pip install --require-hashes or a lockfile tool.
• Scan dependencies. pip-audit, Safety and Snyk flag known-bad versions in the full tree.
• Store secrets in a manager. Use AWS Secrets Manager, HashiCorp Vault or similar, and give each service only the keys it needs.
• Separate environments. Production should never hold development keys, personal SSH keys or broad cloud credentials, and should talk only to the hosts it needs.
• Treat CI as production. This attack entered through a build-pipeline tool. Limit what secrets CI jobs can read.

None of this is exciting work. It is also the part of AI engineering that decides whether a breach costs you an afternoon or your client list.

What CARICOM governments should take from it

A supply chain attack hits every country at once. Governments deploying AI should make dependency scanning, version pinning and credential separation baseline requirements in procurement. Indicators of compromise should be shared quickly between national incident response teams, with CARICOM IMPACS as a possible regional channel. Every agency running AI tools needs at least one person trained in dependency management and incident response.

What I cannot tell you is how many Caribbean organisations installed the bad versions. No one in the region collects that data, which is itself part of the problem.

"The LiteLLM attack compromised the package that holds the keys to every AI provider in your stack. If you run AI systems and you have not audited your Python environments, stop reading and go do it now." - Adrian Dunkley, AI Boss

What to do next

1. IT lead: search every environment today. Run pip show litellm and search lockfiles for 1.82.7 and 1.82.8 across laptops, CI runners, images and servers.
2. IT lead: rotate keys on any hit. Rotate all credentials reachable from an affected machine first, then rebuild it from a clean image.
3. Development team: pin and hash every dependency within a week. Commit a lockfile and turn on hash checking in CI.
4. Development team: add pip-audit to the build. Fail the build on any known-malicious or vulnerable package.
5. Management: split credentials by environment this quarter. Separate API keys for development, testing and production, held in a secrets manager.
6. Data protection officer: assess the breach duty. If personal data may have been exposed, decide within days whether it must be reported to the Information Commissioner.

Frequently Asked Questions

How do I know if LiteLLM was installed indirectly?

Run pipdeptree -r -p litellm in each environment to list the packages that depend on it, or search your lockfiles for litellm. Container images need checking too: run pip show litellm inside a container started from each image. A dependency can be present in an image even if no one on the team ever typed its name.

Is it safe to use LiteLLM now?

The compromised versions were removed from PyPI, and later releases were published by the maintainers after the incident. Pin to a specific version you have checked against the project's security advisories, install it with hash checking, and keep watching the project's GitHub advisories for updates.

Who should a Caribbean company report an incident like this to?

Contact your national computer incident response team where one exists, such as JaCIRT in Jamaica or TT-CSIRT in Trinidad and Tobago. If personal data may have been exposed, data protection law may require notification: in Jamaica the Data Protection Act 2020 requires controllers to notify the Information Commissioner of qualifying breaches within 72 hours. Regulated firms should also check their regulator's incident reporting rules.

Does rotating API keys cost anything?

Rotation is free with the major AI and cloud providers. The cost is staff time and a short outage while services pick up new keys. Keeping keys in a secrets manager makes the next rotation take minutes instead of hours.

How can package maintainers stop this happening to their projects?

Use PyPI's Trusted Publishing, which issues short-lived tokens from the CI system instead of storing a long-lived password or API token. Turn on two-factor authentication for every maintainer account, and restrict which workflows can publish. Treat third-party tools in the release pipeline as able to reach your publishing credentials.