The packages you trust are now the ones attackers target

For years, the standard advice on open-source risk was to watch for misspelt package names and obscure libraries. This year, malicious code reached developers through some of the most downloaded libraries in the JavaScript ecosystem, published from accounts that were entitled to publish them.

Two incidents that changed the picture

On 31 March 2026, two new versions of Axios, one of the most widely used JavaScript libraries for making web requests, were published with a malicious dependency. That dependency downloaded further malware, including a remote access trojan.

On 20 April, the US Cybersecurity and Infrastructure Security Agency (CISA) issued an alert. It told teams to downgrade, to replace every credential that had been present on an affected system, and to change the way they install packages.

On 4 August 2026, a worm that researchers named ChainDrop began spreading through npm, the main package registry for JavaScript. It got in through the code repositories of widely used caching libraries. It then used stolen publishing tokens to release infected versions of every other package those maintainers could publish. Hundreds of packages were affected, some with more than 150 million downloads a week.

Once installed, the malware collected environment variables, SSH keys, cloud and npm credentials, secrets stored in cloud secret managers, Kubernetes and Vault credentials, and secrets from build pipelines.

The risky package is no longer the obscure one that nobody has heard of. It is the popular one that everyone installs automatically.

Why these attacks work

Installing runs code

Both attacks relied on code that runs during installation. By default, npm runs a package’s install scripts on whatever machine installs it, including build servers that hold production credentials.

Build servers hold the keys

Build pipelines often make cloud credentials, publishing tokens and deployment secrets available to every step. A compromised dependency can read all of them.

Updates arrive immediately

Automatic updates and loose version ranges mean a new release can be installed within minutes of being published, long before anyone discovers that it is malicious.

Tokens last too long

A stolen publishing token keeps working until someone revokes it. That is how one compromised account led to hundreds of infected packages.

Controls that would have limited the damage

1. Disable install scripts where you can

   Turn off install scripts in your build pipelines by default, and allow them only for the packages that genuinely need them. CISA recommended exactly this after the Axios compromise.

2. Wait before installing new releases

   Setting a minimum package age of around seven days means most malicious releases are found and removed before you install them. It costs almost nothing.

3. Pin versions and use lockfiles

   Commit your lockfiles, install exactly what they specify in your builds, and review any change to them in the same way as any other code change.

4. Give build steps only the secrets they need

   Limit each pipeline step to the credentials it requires, use short-lived credentials instead of stored keys, and restrict which external services your build machines can reach.

5. Keep a record of what you run

   If you produce a software bill of materials for every build, you can find out whether you are affected by a new incident in minutes rather than days.

6. Secure your own publishing

   If you publish packages, use short-lived tokens or publish directly from your pipeline, and require strong authentication on every account that can release.

Sources

• CISA alert: Supply chain compromise impacts Axios Node Package Manager, 20 April 2026
• Datadog Security Labs: ChainDrop worm compromises popular npm packages, August 2026
• Wiz and Elastic Security Labs: analyses of the keyv and cacheable compromise, August 2026