Software supply chain attacks: when trusted updates turn bad

What a supply chain attack is

Most software is built from other software: open-source libraries, packages, plugins and build tools. A software supply chain attack targets one of those links. Instead of attacking thousands of victims one by one, attackers compromise a single trusted component, and everyone who installs or updates it receives the malicious version automatically.

Think of contaminating an ingredient at the factory rather than tampering with meals in each restaurant.

A recent example: LiteLLM

LiteLLM is a widely used open-source tool that lets developers connect applications to many different AI models. On 21 October 2026, a malicious version, 1.107.0, was published to the Python package index (PyPI) and as container images. According to LiteLLM's own incident report:

• The attacker held stolen access tokens for three developers' GitHub accounts.
• They used an owner-level token to switch off branch protections and point the official release pipeline at a lookalike repository.
• The pipeline then signed and published the poisoned package. It was live on PyPI for about two hours.
• The malware stole credentials from the environment and could load further remote code.

Anyone who installed it was told to assume their secrets were taken and to rotate cloud keys, AI provider keys and database passwords. Other packages and tools were hit in similar ways the same month.

Why these attacks are rising

• Huge reach: one poisoned package can reach thousands of companies.
• Trust: organisations rightly install updates quickly, which helps attackers when the update itself is bad.
• Valuable secrets: developer and build systems hold keys to cloud accounts and customer data.
• Stretched maintainers: many critical open-source projects are run by small teams with limited security resources.

How organisations can defend

1. Protect developer accounts with phishing-resistant MFA, short-lived tokens and minimal permissions.
2. Lock down release pipelines: require approvals that cannot be overridden by a single account, and alert on changes to protections.
3. Pin versions and use lock files, so you update deliberately rather than automatically pulling the newest release.
4. Verify what you install: check signatures and hashes, and keep a software bill of materials (SBOM) listing your components.
5. Limit secrets: do not leave long-lived keys in build environments; use secret managers and rotate regularly.
6. Watch outbound traffic from build and server environments for unexpected connections.

Tip: Removing a malicious package does not undo stolen credentials. If you installed a compromised version, rotate every secret it could reach.

What it means for everyone else

For home users, the best protection is still to install software only from official stores and sources and keep it updated: supply chain attacks are rare compared with fake downloads. The EU's Cyber Resilience Act also pushes software makers to manage their components and report exploited flaws. Our technical notes on container supply chain security and managing secrets go further.