---
title: Trusting and Bundling Packages Keeps Getting Harder for developers in 2026
url: https://apyhub.com/blog/npm-supply-chain-attacks-package-trust
author: Nikolas Dimitroulakis
published: 2026-07-06T00:00:00Z
tags: [change-log]
---

# Trusting and Bundling Packages Keeps Getting Harder for developers in 2026

# Bundling Was Supposed to Be the Safe Choice: Why Trusting Packages Keeps Getting Harder

## Introduction

Bundling open-source packages means building software from libraries someone else wrote. You pull them in through a package manager like npm or PyPI. It became the industry default because it works: less to build, community-tested, free.

But every package you adopt is code you ship without reading. It updates on a schedule you don't control. It is maintained by people you have never met. That arrangement always ran on trust, and in 2025 that trust broke in public. One phishing email put malicious code into packages with over 2 billion weekly downloads. A self-replicating worm compromised hundreds of packages with no human attacker in the loop.

This post lays out the record, explains why the problem is structural, and makes a simple case: for everything outside your core product, consuming certified external services is now the safer choice than bundling packages.

## Why Bundling Won

Bundling deserves its dominance. Before package ecosystems, every team rebuilt the same utilities: date parsing, file compression, string handling, color output. Package managers ended that. A solved problem stayed solved.

So dependency graphs grew. A typical JavaScript application declares a few dozen direct dependencies and inherits hundreds of transitive ones behind them. Most of them, nobody on the team has ever opened.

That depth is exactly what made 2025 possible. The packages compromised in last year's biggest attacks were small utilities. They arrive as a dependency of a dependency. You don't see them until they execute.

## The Breach Record

None of this is speculation. Every incident below is documented by government agencies, security researchers, or both.

**September 8, 2025 — chalk, debug, and 18 other packages.** A maintainer known as Qix got a phishing email from a fake domain, npmjs.help. It asked him to update his two-factor authentication. The fake page captured his username, password, and a live 2FA code. Within hours, [malicious versions of about 20 packages were live on npm](https://www.sonatype.com/blog/npm-chalk-and-debug-packages-hit-in-software-supply-chain-attack), including chalk and debug. Together, these packages see [over 2 billion downloads every week](https://thehackernews.com/2025/09/20-popular-npm-packages-with-2-billion.html). The payload stole cryptocurrency by rewriting wallet transactions in the browser. The malicious versions were [live for roughly two hours](https://www.paloaltonetworks.com/blog/cloud-security/npm-supply-chain-attack/). At that download volume, two hours is a very long time.

**August 2025 — s1ngularity / Nx.** Attackers [stole a publishing token and pushed malicious versions](https://www.sonatype.com/blog/ongoing-npm-software-supply-chain-attack-exposes-new-risks) of several Nx build-system packages. They exfiltrated data from users' systems and leaked private repositories.

**September 2025 — Shai-Hulud, the first self-replicating npm worm.** This was the escalation. Documented in a [CISA alert](https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem), Shai-Hulud [compromised 500+ npm packages](https://www.stepsecurity.io/blog/ctrl-tinycolor-and-40-npm-packages-compromised). Once installed, it harvested AWS, GCP, and Azure credentials from developer machines and CI pipelines. It published the stolen secrets to public GitHub repositories. Then it used any npm tokens it found to infect more packages and publish them. No human needed. The worm spread on its own.

**November 2025 — Shai-Hulud 2.0.** The second wave was worse. The malware [ran during npm's preinstall phase](https://unit42.paloaltonetworks.com/npm-supply-chain-attack/), before tests or security checks could see it. It compromised maintainer accounts from projects including [Zapier, PostHog, and Postman](https://www.microsoft.com/en-us/security/blog/2025/12/09/shai-hulud-2-0-guidance-for-detecting-investigating-and-defending-against-the-supply-chain-attack/). Unit 42 counted over 25,000 malicious repositories created across roughly 350 GitHub accounts. GitGuardian found [11,858 unique leaked secrets, of which 2,298 were still valid](https://thehackernews.com/2025/11/shai-hulud-v2-campaign-spreads-from-npm.html) when analyzed. The campaign even spread into Maven Central through automated rebundling.

**May 2026 — it continues.** Microsoft documented a [new wave compromising 170+ npm packages and 2 PyPI packages](https://www.microsoft.com/en-us/security/blog/2025/12/09/shai-hulud-2-0-guidance-for-detecting-investigating-and-defending-against-the-supply-chain-attack/). It was the first attack to span npm and PyPI in one coordinated operation.

**And this did not start in 2025.** The [xz-utils backdoor](https://en.wikipedia.org/wiki/XZ_Utils_backdoor) (CVE-2024-3094, a maximum severity score of 10.0) was a multi-year operation. An attacker spent almost two years contributing real work to a compression library used by most Linux distributions. They [earned maintainer rights, then shipped a backdoor](https://securitylabs.datadoghq.com/articles/xz-backdoor-cve-2024-3094/) targeting SSH. One engineer caught it while investigating a half-second performance glitch. The industry's honest assessment: the discovery was mostly luck.

Look at the trend, not any single incident. Account takeover in hours. Then automated self-propagation. Then execution before security checks. Then cross-registry spread. Each wave removed another defense that teams were counting on.

## Why Packages Are Hard to Trust Now

These attacks share mechanics that individual diligence cannot fix:

1. **Maintainer accounts are single points of failure.** The chalk/debug attack required phishing exactly one person. Most critical open-source packages are maintained by one or two unpaid people. And as xz-utils showed, even "maintainer" status can be faked over years.
2. **Phishing now beats standard MFA.** The npmjs.help attack captured a live 2FA code in real time. Authenticator apps did not stop it.
3. **Nobody audits transitive depth.** Teams review the packages they add. Nobody reviews the hundreds underneath. Shai-Hulud spread through utility packages most victims did not know they had.
4. **Packages run code at install time.** npm install scripts run on developer laptops and inside CI runners that hold cloud credentials. Shai-Hulud 2.0 moved to the preinstall phase because it runs earliest and is watched least.
5. **AI agents make it worse.** An agent pulls in whatever package completes the task. It does not notice a name one keystroke off from a real package. It does not pause on an unknown maintainer. It removes the one suspicious human who sometimes caught these things.

The existing tooling helps, and teams should use it. Lockfiles, SBOMs, provenance checks, dependency scanning: all worth having. But it is reactive. A lockfile pins what you got. It cannot tell you the maintainer was compromised an hour before you ran install. During the chalk/debug window, automated update bots did exactly their job: they bumped the version, tests passed, and the malware shipped.

## The Real Bill for "Free" Packages

Bundling was never free. Every dependency brings its own release schedule, breaking changes, and upstream decisions you have to absorb. The vulnerability queue grows faster than anyone triages it. A patch fixes one thing and breaks twenty.

The 2025 attacks added a new line item: incident response for breaches you did not cause. After each Shai-Hulud wave, teams had to audit their trees, rotate every credential that touched a build environment, hunt for persistence in CI, and rebuild from clean caches. Wiz put it plainly about chalk/debug: the crypto theft was minimal, but the real damage was the countless engineering hours the whole industry spent checking exposure and cleaning up. You paid that bill even if you never installed a bad version.

That is the maintenance tax of bundling. Less upfront effort than building, but a compounding stream of triage, patching, upgrades, and now breach response.

## The Safer Alternative: Consume Services Instead of Shipping Packages

Here is the good news: a large part of your dependency graph does not need to exist.

Nobody should unbundle React. Frameworks, languages, and core libraries stay. But look at the utility layer: file conversion, document generation, data validation, OCR, extraction, enrichment, image processing. These capabilities usually arrive as packages. Each one brings a transitive tree, install scripts, and maintainer risk. And none of them make your product different.

Consume them as external services instead, and something powerful happens: the code leaves your supply chain entirely.

```
BUNDLED                                CONSUMED AS A SERVICE

your app                               your app
 └─ pdf-lib                             └─ HTTPS call ──► certified
     ├─ dep A ── dep D                                     PDF service
     ├─ dep B ── dep E ── dep F        no packages in your build
     └─ dep C (preinstall script,      no install scripts
        runs in your CI with           no transitive tree
        your credentials)              nothing for a worm to infect
```

Think about what this removes. There is no package on the developer's laptop. Nothing runs in your CI. There are no install scripts, no transitive dependencies, no Dependabot queue for that capability, ever. A worm like Shai-Hulud has nothing to propagate through, because the code never enters your build. The provider patches, upgrades, and monitors the capability. You just call it.

That makes a consumed service structurally safer than a bundled package. The package model puts unknown code inside your systems and asks you to watch it forever. The service model keeps the code outside your systems and puts the maintenance burden on the party running it.

One condition has to hold: you need to know what the service does with your data. A random, unvetted API would just move the trust problem. This is why certification matters, and why it should be machine-readable.

On [ApyHub](https://apyhub.com/), every API in the [catalog](https://apyhub.com/catalog) is curated and certified before it is available. Each service carries a machine-readable certificate stating its non-functional properties: where data is processed, how long it is retained, which sub-processors exist, and how it aligns with GDPR, SOC 2, and ISO 27001. In simplified form:

```json
{
  "service": "document-conversion",
  "certificate": {
    "data_residency": "EU",
    "retention": { "payload_stored": false, "retention_period_days": 0 },
    "sub_processors": [],
    "standards_alignment": ["GDPR", "SOC 2", "ISO 27001"],
    "issued_at": "2026-05-14"
  }
}
```

Compare that to a package. A package gives you a version number and a changelog. A certified service tells you, in a form you can check before the first call, exactly how it handles your data. That is more than the package model ever offered.

And because the catalog is MCP-native, AI agents read the same trust signals humans do. The consumers least able to judge an unfamiliar package are exactly the ones that most need a verifiable fact before they act. The catalog spans 200+ APIs and 1,000+ endpoints under one subscription, so replacing a dozen utility packages does not mean taking on a dozen new vendors.

[**Explore the catalog →**](https://apyhub.com/catalog)

## A Practical Decision Guide

For an engineering manager looking at a dependency graph after the last eighteen months:

1. **Split dependencies into core and utility.** Core: frameworks, language tooling, libraries woven into your domain logic. Utility: self-contained jobs called at arm's length. Convert this file. Validate this input. Extract this text.
2. **Keep core, and harden it.** Lockfiles, pinned versions, delayed adoption of brand-new releases, least-privilege CI credentials. Gating install scripts in CI is one of the highest-leverage changes you can make after the preinstall attacks.
3. **Move utility capabilities out of the graph.** Replace them with certified external services whose residency, retention, and standards match requirements you write down once, at the organization level.
4. **Hold agents to the same bar.** Whether an agent picks a package or an API, the rule is the same: nothing unverifiable reaches production through an automated decision.
5. **Re-measure.** Count your direct and transitive dependencies before and after. Fewer alerts, fewer upgrades, and a smaller breach surface are the return.

## Conclusion

Bundling was the right call when the alternative was building everything by hand. For core dependencies it still is. But its trust model — one volunteer maintainer, one phishable account, hundreds of unread packages running code in your CI — is failing in new ways with every wave: faster, self-propagating, earlier in the install, across registries. The tooling helps, but it reacts after the fact.

The structural fix is to carry fewer packages in the first place. Start with the utility layer, which never needed to be code you ship. Consume those capabilities as certified services instead: the code stays out of your systems, the maintenance stays with the provider, and the trust is written down in a certificate you can check. That is the safer way to build now, and it is the layer [ApyHub](https://apyhub.com/) provides.

[**Try ApyHub →**](https://apyhub.com/)

## FAQ

**What is a software supply chain attack?**
It is an attack that compromises software before it reaches you — through a package, a maintainer account, a build tool, or a service you depend on. Trusted channels then deliver the malicious code. The 2025 npm incidents are examples: attackers compromised maintainers, and the package manager did the delivery.

**What was the Shai-Hulud attack?**
Shai-Hulud was the first self-replicating worm in the npm ecosystem, documented by CISA in September 2025. It compromised 500+ packages, harvested cloud credentials from developer machines and CI pipelines, published stolen secrets to public GitHub repositories, and used stolen npm tokens to spread automatically.

**What happened with the chalk and debug npm packages?**
In September 2025, a maintainer was phished through a fake npm domain that captured his password and a live 2FA code. Attackers published malicious versions of about 20 packages with over 2 billion combined weekly downloads. The payload targeted cryptocurrency transactions and was live for roughly two hours.

**Are npm packages safe to use?**
Core, well-governed packages remain reasonable to use with precautions: lockfiles, pinned versions, delayed upgrades, restricted install scripts, and least-privilege CI credentials. But the risk is structural, so the safest dependency is often the one you remove from the graph entirely.

**Do lockfiles and SBOMs prevent supply chain attacks?**
They help, but they are records, not guarantees. A lockfile pins the version you resolved. An SBOM inventories your components. Neither can tell you that a maintainer's account was compromised an hour before you installed.

**Why are AI coding agents a supply chain risk?**
An agent pulls in whatever package completes the task. It does not recognize typosquatted names or suspicious maintainers, and it removes the human review that sometimes caught poisoned dependencies. Restricting agents to verifiable packages and certified services closes that gap.

**Is using external APIs safer than bundling packages?**
For non-core capabilities, yes — provided the service is certified. A consumed API keeps the capability's code, its transitive tree, and its install scripts entirely out of your build, so there is nothing for a supply-chain worm to infect. A machine-readable certificate then tells you how the service handles your data, which is more than any package offers.

**How does ApyHub certify its APIs?**
Every API on [ApyHub](https://apyhub.com/) is curated and certified before it is listed. Its certificate states data residency, retention, sub-processors, and alignment with GDPR, SOC 2, and ISO 27001 in machine-readable form, so both humans and AI agents can check a service's properties before consuming it.

***

## About ApyHub

[ApyHub](https://apyhub.com/) is a curated API catalog and trusted operational layer where developers, teams, and AI agents discover and consume production-ready APIs. The catalog spans 200+ APIs and 1,000+ endpoints, available under a single subscription priced in atoms. Every API ships with machine-readable certification covering data handling and alignment with GDPR, SOC 2, and ISO 27001, and every endpoint is MCP-ready by default. ApyHub is headquartered in Amsterdam, with offices in the Netherlands, Greece, and India, and serves 65,000+ developer workspaces every month. The free tier requires no card. API builders can publish and monetize their own services as [ApyHub providers](https://apyhub.com/api-provider).