Supply Chain Security in Open Source: Lessons from npm Attacks and the LiteLLM PyPI Breach

Software supply chain attacks happen when an attacker compromises something you trust in the path between source code and production: a package, a maintainer account, a build pipeline, a dependency mirror, or even a signed software update. Instead of breaking into your application directly, the attacker poisons one of the upstream components your developers, CI runners, or customers already trust.

That strategy has moved from edge-case to mainstream. The wave of npm compromises in 2025, followed by the LiteLLM incident on PyPI in March 2026, showed just how efficient modern attackers have become at turning one trusted package into access to hundreds, thousands, or even millions of downstream environments.

For startups and SMEs, this matters more than ever. Most smaller teams build quickly, rely heavily on open source, and run automated pipelines that fetch dependencies without much friction. That speed is useful for product delivery, but it also creates a large attack surface when basic supply chain controls are missing.

npm under siege in 2025 and 2026

The JavaScript ecosystem has always depended on deep, fast-moving dependency trees. That convenience is exactly what makes npm such an attractive target.

In March 2026, Cymulate published a useful recap of three major npm incidents that shaped the threat landscape in 2025: the mass compromise of high-profile packages such as chalk and debug, the self-propagating Shai-Hulud worm, and the s1ngularity campaign targeting the Nx toolchain.

The `chalk` and `debug` compromise showed the blast radius of a single account

According to public reporting summarized by Cymulate, attackers compromised a maintainer account and published malicious versions of around 18 high-profile npm packages in September 2025, including chalk, debug, ansi-styles, strip-ansi, and supports-color.

Those package names may sound small, but they sit near the center of the JavaScript ecosystem. When a library with enormous transitive reach is compromised, the impact is not limited to direct users; it spreads across application builds, CI pipelines, internal tools, and software shipped to customers. Cymulate described the weekly download blast radius as exceeding one billion downloads.

The attack reportedly began with a convincing phishing message impersonating npm support, followed by credential theft and 2FA reset. That is an important lesson on its own: even when the package registry itself is not breached, one well-crafted phishing email can be enough to poison a large part of the ecosystem.

Shai-Hulud raised the stakes with self-propagation

If the chalk and debug incident highlighted scale, Shai-Hulud highlighted automation. Multiple security researchers described it as the first wormable supply chain malware seen in npm at this scale.

The malware did not stop at stealing secrets from one environment. It harvested tokens from developer machines and CI contexts, abused GitHub Actions for persistence and exfiltration, and republished tainted packages from compromised maintainers. In other words, it used one compromise to manufacture the next one.

That is a meaningful escalation. Traditional package malware often behaves like a one-time infostealer. A wormable supply chain implant behaves more like an infection engine embedded inside the development workflow itself.

s1ngularity showed that developer tooling is now a target

The s1ngularity campaign, also highlighted in Cymulate's analysis, targeted the Nx toolchain with a focus on credential theft. That matters because modern attackers are no longer interested only in end-user applications. They increasingly target the tools developers use to build, test, package, and deploy software.

The practical implication is simple: if your organization treats build systems and developer workstations as lower-risk than production, your threat model is outdated. In many modern supply chain attacks, the build path is the production path.

The LiteLLM PyPI compromise in March 2026

The LiteLLM incident is especially instructive because it sits at the intersection of open source, AI infrastructure, and CI/CD compromise.

On March 24, 2026, malicious versions 1.82.7 and 1.82.8 of the popular litellm package were published to PyPI. LiteLLM is widely used as a gateway library that helps applications communicate with multiple LLM providers through a unified interface. That makes it a valuable target because systems that use it often store API keys, cloud credentials, environment variables, and deployment secrets in the same place.

According to LiteLLM's own incident update, the affected packages were removed from PyPI, and the team believed the compromise originated from the broader Trivy supply chain incident. The project stated that attackers appeared to bypass official CI/CD workflows and upload malicious packages directly to PyPI.

Sonatype reported that the poisoned packages delivered a multi-stage credential stealer, while BleepingComputer documented a three-stage payload that harvested sensitive data and established persistence. Public reporting identified the following behaviors:

malicious code embedded in litellm/proxy/proxy_server.py
a .pth persistence file (litellm_init.pth) in version 1.82.8
harvesting of environment variables, SSH keys, cloud provider credentials, Kubernetes tokens, database secrets, and .env files
exfiltration to attacker-controlled infrastructure

LiteLLM also noted an important defensive detail: customers using the official LiteLLM Proxy Docker image were not affected because that deployment path pinned dependencies in requirements.txt and did not rely on the compromised PyPI releases. That is exactly the kind of boring, disciplined control that reduces real-world exposure.

The lesson here is not limited to one package. AI-adjacent libraries are becoming high-value supply chain targets because they frequently sit close to API keys, cloud tokens, model credentials, and orchestration tooling. If your stack includes LLM frameworks, agent platforms, MCP servers, or AI gateways, dependency hygiene is now directly tied to secret management.

Historical examples still matter

These incidents feel new, but the underlying playbook has been visible for years.

XZ Utils backdoor

The XZ Utils backdoor, disclosed in 2024, remains one of the clearest examples of how patient an attacker can be when targeting open source infrastructure. As Kaspersky documented, the compromise used a multi-stage implant hidden in build infrastructure and test files, ultimately targeting sshd on several Linux distributions through a malicious liblzma path. It was not a loud smash-and-grab operation; it was a carefully staged attempt to insert remote code execution into a foundational component of the Linux ecosystem.

SolarWinds Orion

The SolarWinds Orion compromise is still the reference point for what a software supply chain attack can look like at enterprise scale. ReversingLabs and many others documented how malicious code was inserted into Orion updates that were then signed and distributed to customers. Once a trusted update channel is compromised, downstream organizations effectively import the attack themselves.

PyPI hijacks and lookalike packages

PyPI has repeatedly seen typosquatting, account takeovers, and malicious packages that imitate trusted names or exploit abandoned namespaces. These attacks are often less sophisticated than XZ or SolarWinds, but they succeed for the same reason: developers install what looks legitimate, automation pulls it in at speed, and secrets or execution rights do the rest.

Common attack vectors across open source supply chains

Even though the technical details differ, the recurring attack paths are familiar.

Maintainer phishing and account takeover. One stolen maintainer credential can lead to malicious publishes under a legitimate project name.
CI/CD credential theft. Attackers increasingly target build runners, workflow secrets, package publishing tokens, and cloud credentials because they provide scale.
Typosquatting and dependency confusion. A misleading package name or a dependency source mismatch is often enough to land code execution in a build.
Malicious install hooks and runtime payloads. Post-install scripts, import-time execution, and persistence files like .pth are effective because they run automatically.
Maintainer burnout and abandoned packages. Projects with few maintainers, weak review processes, or inconsistent release controls are easier to subvert.

Group-IB's 2026 threat reporting described modern supply chain attacks as part of a self-reinforcing cybercrime ecosystem. That framing is useful. Attackers are not stealing secrets for their own sake; they are collecting access that can be reused for the next compromise, sold to other actors, or turned into ransomware and extortion later.

Why this matters for SMEs and startups

Smaller companies sometimes assume supply chain security is mainly a problem for hyperscalers or Fortune 500 software vendors. In practice, SMEs and startups are often more exposed.

They usually have:

smaller engineering teams with less time for dependency review
fast release cycles and heavy CI/CD automation
broad use of third-party packages, SDKs, and starter templates
shared credentials or over-privileged service accounts
limited incident response depth when something goes wrong

The business impact can be severe even when the technical compromise is brief.

One poisoned package can force you to rotate cloud keys, revoke CI tokens, rebuild containers, audit deployment logs, inspect developer endpoints, notify customers, pause releases, and answer difficult questions from partners or investors. For a small company, that operational shock can be more damaging than the malware itself.

What good mitigation looks like in practice

There is no single control that eliminates supply chain risk, but there are several measures that meaningfully reduce exposure.

1. Maintain an SBOM and know what you actually ship

If you cannot quickly answer which versions of which dependencies are in production, incident response becomes guesswork. A software bill of materials will not stop an attack, but it will drastically improve containment and communication when something upstream is compromised.

2. Pin dependencies and control upgrades

The LiteLLM case is a strong reminder that pinned versions matter. Lockfiles, vetted update windows, and private registry controls reduce the odds of silently pulling a malicious release into production or CI.

3. Scan dependencies continuously

Use dependency scanning for known vulnerabilities, malicious package detection, and suspicious publish activity. This should cover both direct and transitive dependencies, and ideally it should happen before code lands in production.

4. Prefer signed releases and verified provenance where possible

Package signing, provenance attestations, and registry verification are not silver bullets, but they make tampering harder and improve trust decisions. As ecosystem support improves, these controls should move from "nice to have" to baseline.

5. Apply least privilege to tokens and build identities

Publishing tokens, CI secrets, cloud credentials, and GitHub automation identities should all be tightly scoped. Short-lived credentials, environment separation, and clear ownership reduce how much damage a stolen token can do.

6. Harden developer workstations and CI runners

Developer endpoints and build agents now sit directly in the blast zone. Treat them as high-value systems: endpoint protection, restricted secret exposure, isolated runners for sensitive workflows, and logging around package install behavior all matter.

7. Practice rapid secret rotation

A recurring theme in recent incidents is that attackers win twice when organizations delay rotation. If a compromised package had access to keys, tokens, or environment variables, assume exposure and rotate fast.

A practical next step for engineering teams

If you want one realistic starting point, do this:

inventory your critical dependencies and build tools
identify which package registries and automation identities can publish or deploy
verify that secrets in CI are scoped and rotatable
pin the high-risk packages that sit closest to production credentials
add dependency and artifact monitoring to your release process

That is not glamorous work, but it is the foundation of real resilience.

How Bizjak Tech OÜ can help

Bizjak Tech OÜ helps startups and SMEs turn supply chain security from a vague concern into concrete engineering controls. That can include dependency risk reviews, CI/CD hardening, secret exposure reduction, secure build and deployment practices, vulnerability management, and practical remediation support after an incident or near miss.

If your team wants a clearer view of where your software supply chain is exposed, or needs help tightening release and dependency controls, get in touch.