On the evening of Wednesday 21 October 2026, at 18:39 Western Indonesia Time (WIB), a new version called litellm 1.107.0 appeared on PyPI, the package registry Python developers use worldwide. It looked like any routine release. It carried a credential-stealing payload. About two hours later the release was pulled, but servers that had already installed it did not clean themselves.

If you run a shop or a café, you have probably never heard of LiteLLM. That is fair. This article is still for you, because the lesson is not the package name but the route: a third-party package, installed by a vendor, on a server that holds your business's keys.

What happened that evening

LiteLLM is an open-source library that gives applications a single interface to more than 100 AI models, including those from OpenAI and Anthropic. Applications with AI features, such as a chatbot that answers orders or an automatic sales summary, may well use it. BleepingComputer reports roughly 92 million downloads a month on PyPI.

The sequence: seven 1.107.0 packages went live on PyPI at 18:39 WIB, and Docker images (ready-made packages that servers run directly) followed at 18:46 WIB. PyPI pulled the release at about 20:20 WIB and the Docker images were cleaned by 21:20 WIB. LiteLLM's own record and Datadog differ by three minutes on the PyPI removal, so we say "about". Every WIB time here is the UTC time plus seven hours.

Timeline for 21 October 2026: litellm 1.107.0 published on PyPI at 18:39 WIB, Docker images at 18:46 WIB, PyPI pulls the release at about 20:20 WIB, Docker images cleaned at 21:20 WIB

According to LiteLLM, the intruder held GitHub credentials belonging to three of its developers and ran the official release process against a lookalike repository named Berri-AI/litellm. The real one, BerriAI/litellm, differs by a single hyphen. The code on the official GitHub stayed clean. What was poisoned was the finished package. How the credentials were stolen is, by LiteLLM's own admission, partly unconfirmed. Nor is it the first time: in March 2026, versions 1.82.7 and 1.82.8 of the same project were compromised. The sources we read do not conclude that the two incidents are connected.

Why this is your café's business

We have no data on how many Indonesian businesses were affected, and we are not claiming any were. But the mechanism does not care about business size. Python reads certain startup files every time it launches, and this malware rides on that. It runs in every Python process on the server, even if LiteLLM itself is never called.

Four layers of the chain you rely on: your business, a vendor-built application, third-party AI tooling, and the keys and access on the server that the malware hunts

According to Datadog and BleepingComputer, it looks for cloud keys, .env files, SSH keys, Git tokens, AI service credentials, and browser passwords and cookies, and sends them encrypted to a lookalike domain, litellm[.]dev. As an illustration, and it is our illustration, not a case finding: a server running an ordering chatbot usually holds more than an AI key. It has access to the orders database, a payment gateway key, and a notification email account, often all in one .env file.

The consequence people miss most: pulling the package gives nothing back. Datadog notes that deleting the litellm folder does not remove the malware, because the three files it leaves behind must be deleted by hand, and running pip on that server triggers it again. Secrets that already left must be treated as leaked, and the only fix is to replace them.

Five cause-and-effect steps from a compromised developer account to business secrets being sent out of the server

The question nobody asks

Using third-party tools is normal; nearly all modern software does. What is not normal is a vendor who cannot answer within a day: which tools are in your system, which versions, which keys sit on the server, and whose name is on the accounts. The same project was hit twice in seven months. Our view is that a vendor without that list today will scramble at the next incident, and the owner will pay for it.

This week's checklist

Send your vendor or agency one message and ask for written answers to these seven points:

  1. Is LiteLLM in my system, and which version? Ask directly; do not wait for them to bring it up.
  2. Did you ever pull version 1.107.0? The window was between 18:39 and 21:20 WIB on 21 October 2026.
  3. Which keys are stored on the server? Ask for a written list: AI, payments, database, email, cloud.
  4. Whose name is on the cloud and payment accounts? They should be in the business's name, not a developer's.
  5. Are package versions pinned? Those most exposed were the ones pulling "the latest version" automatically, not the ones that fix a version.
  6. Are there spend limits and usage alerts? Set them on AI and cloud keys so odd usage shows up fast.
  7. If there is an incident, who tells whom, and within how many hours?
Eight cards forming a checklist: seven questions for the vendor and one core card, rotate keys, do not just delete the package

If the answer to point 2 is "yes", follow LiteLLM's guidance: pin the version to 1.106.2, the version it names as safe before the incident, rebuild the server from scratch, then replace every secret that server could read, from a clean machine. Start with payment and cloud keys, then AI and email. After that, ask the vendor to check the cloud account logs for use from outside your infrastructure.

If you would like someone to help read your vendor's answers, or to check what is stored on your application server, message us on WhatsApp at +62 823 1499 5005. XETUP builds and maintains systems for businesses, so questions like these are everyday work for us. Bring your vendor's answers and we will read them together.

Sources: LiteLLM incident post, BleepingComputer, Datadog Security Labs.