In this guide
  1. What this checklist is for
  2. 1. Find out whether the bad release reached you
  3. 2. Isolate, then rebuild from a clean pin
  4. 3. Rotate every secret that environment could see
  5. 4. Review what the malware actually did
  6. 5. Reduce the chance of the next one
  7. Related incidents on One Signal Desk

TL;DR: If a package you installed was malicious, do not just “upgrade and hope.” Check lockfiles, CI logs, container tags and developer machines for the bad version, rebuild from a version the vendor lists as clean, and rotate every secret that environment could see. A cooldown on brand-new npm versions reduces how often this happens; it does not clean a host that already ran the malware.

What this checklist is for

Use this when a registry package, container image, or desktop-extension build was published with malware or a backdoor. It is a type-level checklist. The exact version pins, image tags and rotation list come from the vendor and from our incident article.

For stolen keys after the rebuild, continue on the leaked secrets rotation checklist. For a vendor’s own breach of customer data, use the vendor breach checklist. Broader alerts: security coverage.

1. Find out whether the bad release reached you

  1. Read the vendor or registry notice for the exact malicious version, tags and time window.
  2. Search where the package could have landed:
    • Application and developer lockfiles (requirements.txt, poetry.lock, Pipfile.lock, package-lock.json, pnpm-lock.yaml, yarn.lock).
    • CI and CD logs, including cache restores and “latest” tags.
    • Container images and Kubernetes manifests. For LiteLLM 1.107.0, the malicious Docker tags included latest, main-latest and main-stable, per our LiteLLM article.
    • Local virtualenvs, Docker caches and CI runners that may still have the wheel or image.
  3. For LiteLLM 1.107.0 specifically: the issue’s reporter and StepSecurity said the malware runs on every Python start in an environment where 1.107.0 is installed, even if nothing imports litellm. Check the environment, not only application import graphs.

2. Isolate, then rebuild from a clean pin

  1. Take any affected host, pipeline or image out of production if it still runs the bad release.
  2. Rebuild from scratch on a version the maintainer lists as clean. Do not “upgrade in place” over a compromised environment and trust the result.
  3. For LiteLLM, our article (checked when that story was published) tracked 1.106.2 or earlier as the pin BerriAI listed; re-read the live LiteLLM article before you pin, in case the vendor has published a newer clean release.
  4. Pin the version in the lockfile. Avoid floating latest tags until you have a reason to trust them again.
  5. Rotate CI caches and rebuild container images from a known-good base, so a cached malicious wheel cannot sneak back in.

3. Rotate every secret that environment could see

Treat secrets the compromised process could read as exposed. That often includes:

  • Cloud and source-control tokens (AWS, GCP, Azure, GitHub, GitLab).
  • SSH keys and developer tokens on the same machine.
  • Provider API keys and any proxy or database of keys (LiteLLM’s reporter said the malware collected cloud, SSH and AI-tool credentials, environment variables, and provider API keys stored in a LiteLLM proxy database).
  • Registry and package-publish tokens.

Create new credentials, deploy them, then revoke the old ones. The detailed rotation order is in the leaked secrets rotation checklist.

4. Review what the malware actually did

Follow the vendor, the security firm, or our article for indicators of compromise. Do not invent a cleanup script. If you cannot rule out credential theft or a follow-on implant, rebuild the host or runner from a known-good image after rotation.

5. Reduce the chance of the next one

GitHub’s package firewall, in preview for Enterprise Cloud, screens npm installs for CI and coding agents. It supports npm only and does not cover Python packages such as LiteLLM. If you use npm, pnpm or Bun, you can copy its cooldown without Enterprise: a waiting period before brand-new versions install. Steps are in GitHub’s package firewall and how to set a cooldown.

A cooldown would not have cleaned a machine that already installed a bad release. It only slows down the next one.

Sources

Last checked: Nov 10, 2026, 1:16 p.m. Manila (UTC+8). Method: We built this type-level checklist from the live One Signal Desk articles linked above (HTTP 200 on Nov 10) and from the vendor and researcher steps those articles already quote. We did not invent a current “safe” LiteLLM version beyond what the live article states, and we flag a send- or patch-day re-read of that pin. Thumbnail is a reuse-licensed image, credited with its license under the picture. No HowTo or FAQ schema. No affiliate links. How we work.