Supply chain attacks: how trusted software becomes the way in

In a supply chain attack, the attacker does not target the company directly. They compromise a supplier, a software library, a plugin or the process that publishes updates, and the malicious code arrives through a trusted channel: a routine update, an installed package or a new plugin version. The firewall and antivirus let it through because it comes from a source the company has good reason to trust.

This week's example: LiteLLM 1.107.0

LiteLLM is a popular Python library with about 23 million downloads a week. On 21 October 2026, version 1.107.0 appeared on the official PyPI repository and on Docker Hub containing code that steals data. According to the project's own incident report:

• the attacker used stolen GitHub tokens belonging to three developers: one to remove the protection on the release process, one to approve the release and one to delete the run records;
• the packages were built from a repository with an almost identical name (Berri-AI/litellm instead of BerriAI/litellm), so the official source code for the version is clean and reviewing it would have revealed nothing;
• the malicious version was available on PyPI for 1 hour 44 minutes, and the Docker images, including latest, for 2 hours 34 minutes;
• the code wrote itself into the files Python runs at every start, so it ran even in programs that never use the library.

The code collected cloud service keys, SSH keys, Git, Kubernetes and Docker credentials, saved browser passwords and shell history. Researchers at Wiz report that the stolen AWS keys were in use about four and a half hours later. This is the second compromise of the same library this year: the first, in March, affected close to 2,500 organisations according to CloudSEK.

A window of less than two hours was enough because many systems install "the latest version" automatically, without anyone approving it.

How compromised versions reach companies

A compromised developer account

This is one of the most common routes. In September 2025 a maintainer of popular npm packages, including chalk and debug, received a phishing email about "updating two-factor authentication" and entered their credentials on a fake site. The attackers published versions with code that swaps the recipient address in cryptocurrency payments made in the browser. The packages are downloaded billions of times a week and were removed from the registry after about two hours. Similarly, in June 2024 several plugins in the official WordPress repository were found to contain injected code that created administrator accounts on the sites using them.

A compromised build and release process

With LiteLLM the project's code was clean; only the published packages were infected. The same happened in 2020 with SolarWinds: updates to the Orion monitoring system carried a backdoor, and around 18,000 customers installed them.

A malicious maintainer

In March 2024 a backdoor for remote access over SSH was found in versions 5.6.0 and 5.6.1 of XZ Utils, a compression library included in most Linux distributions. It was inserted by a contributor who had spent about two years earning the trust of the project's maintainer. It was discovered by chance, before it reached the stable releases of the major distributions.

An external service changes hands

Websites often load scripts from other domains. In 2024 the Polyfill.io service changed owners, and its script, embedded in over 100,000 sites, began redirecting some visitors to scam pages. The site owners had changed nothing.

Packages with similar names

Public registries regularly receive packages whose names differ by one letter from popular libraries. A single typo is enough to install malicious code.

Measures if you build or commission software

1. Pin versions. Use lock files (package-lock.json, poetry.lock, uv.lock) and install with npm ci or with hash checking (pip install --require-hashes). Reference Docker images by digest, not by tags such as latest.
2. Do not install new versions on the day they are published. Most compromised versions are found and removed within hours or days. Settings such as minimumReleaseAge in pnpm, exclude-newer in uv and the cooldown period in Dependabot delay automatic updates.
3. Treat developer accounts and tokens as keys to production: multi-factor authentication with a hardware key, short-lived tokens, and no tokens in logs.
4. Restrict permissions in the build pipeline (CI/CD). Branch protection must not be removable by a single account, and a release needs approval from another person. Build machines should not hold long-lived cloud keys.
5. Publish with verifiable provenance: Trusted Publishing on PyPI and npm, signed Docker images. Check provenance for the packages you consume too.
6. Keep a software bill of materials (SBOM) and follow security advisories such as OSV and the GitHub Advisory Database, so you know within hours, not weeks, whether you are affected.

Measures if you buy software and services

• Keep a list of suppliers with access to your systems or data: IT support, hosting, developers, accounting software. For companies within the scope of the Bulgarian Cybersecurity Act, supply chain security is a mandatory measure under Article 22(2)(4).
• Put security requirements and an incident notification duty into contracts, and after major incidents like this one, ask your suppliers whether they were affected.
• On websites, use plugins and themes only from reliable sources, remove unused ones and keep them updated. See the article on hacked WordPress sites.
• Avoid scripts loaded from other domains. Where they are necessary, use a Content Security Policy and Subresource Integrity, so the browser does not run a modified file.

If you installed a compromised version

Updating to a clean version is not enough, because the malicious code may already have taken hold, as with LiteLLM, where it stays in Python's startup files.

1. Isolate the affected machines and containers from the network.
2. Rebuild them from clean images instead of cleaning them.
3. From a different, clean machine, change every password and key the affected machine could reach: cloud services, databases, GitHub and package publishing tokens, SSH keys.
4. Review cloud service logs for use of those keys from unfamiliar addresses after the time of installation.

If personal data leaked, this is a personal data breach that in most cases has to be reported to the data protection authority within 72 hours.