npm Supply Chain Attacks in 2026: How to Protect Your ProjectsAttaques Supply Chain npm en 2026 : Comment Protéger Vos Projets

On March 31, 2026, attackers compromised the npm account of the maintainer behind Axios — a package downloaded over 100 million times per week — and injected a cross-platform Remote Access Trojan (RAT) that silently ran on every developer machine that ran npm install within a 4-hour window. It was not an isolated incident. It was the logical continuation of a trend that made 2025 the worst year on record for npm supply chain attacks, with 454,648 malicious packages published in a single year.

If you use npm packages — and you do — this is your threat landscape. This article breaks down exactly how these attacks work, what the biggest incidents of 2025-2026 have in common, and what concrete defenses you can put in place today.

The Scale of the Problem in 2025-2026

The npm registry is the world's largest software package registry, with over 2.5 million packages and tens of billions of downloads per month. That scale is both its strength and its greatest vulnerability. Attackers have systematically industrialized the exploitation of this ecosystem.

These are not drive-by opportunists publishing random junk. They are organized threat actors — including North Korean state-sponsored groups — running automated campaigns at industrial scale.

The Biggest npm Supply Chain Attacks (2025-2026)

March 2026 — The Axios Compromise

Axios is one of the most depended-upon npm packages in existence. On March 31, 2026, attackers used social engineering to hijack the npm publishing credentials of a core maintainer. They published a backdoored version containing a cross-platform RAT (Remote Access Trojan) that targeted developers' environments — stealing environment variables, SSH keys, and API credentials from the machines of anyone who ran a fresh npm install during the 4-hour compromise window.

Why it matters: This was not a dependency of a dependency. This was a direct, first-party package with 100 million weekly downloads, used in production by Fortune 500 companies and solo developers alike. The attack vector was human — not a code vulnerability — demonstrating that even well-maintained packages with good security practices are exposed to account takeover.

Attribution was made to Sapphire Sleet / UNC1069, a North Korean threat cluster specializing in targeting software developers and cryptocurrency infrastructure.

September 2025 — The Great NPM Heist

Check Point Research documented one of the largest coordinated package takeover campaigns ever seen. Attackers gained unauthorized access to the publishing accounts of multiple widely-used packages simultaneously, including chalk and debug, along with 16 other packages. Combined, these packages account for over 2.6 billion downloads per week.

The campaign targeted packages with high download counts and relatively small maintainer teams — maximizing blast radius while minimizing the number of credentials needed to compromise. Malicious versions included obfuscated scripts that exfiltrated process.env to an attacker-controlled server.

November 2025 — Shai-Hulud 2.0: The Self-Replicating Worm

The most technically sophisticated attack of 2025 was Shai-Hulud 2.0, a self-replicating npm worm that automatically infected other packages on the machines of developers who had npm publish credentials. Once a developer installed the initial infected package and later ran npm publish on one of their own packages, the worm silently embedded itself into that new publication.

By the time it was contained, Shai-Hulud 2.0 had propagated to 796 packages representing over 132 million downloads per month. The original worm of this type, Shai-Hulud 1.0, was first documented in November 2025 and showed that self-replicating malware in open source registries is no longer theoretical.

October 2025 — PhantomRaven Campaign

The PhantomRaven campaign (documented by Sonatype) used a novel evasion technique: the malicious payload was hosted externally and loaded at runtime rather than bundled directly in the package. This bypassed most static analysis tools used by registries and CI/CD pipelines. Over 100 malicious packages were published, targeting 86,000 potential victims before takedown.

August 2025 — The nx Attack via Weaponized AI

Snyk documented a campaign targeting the popular build system nx (used by Angular, NestJS, and many enterprise projects). Attackers compromised a GitHub Actions token, used it to publish a backdoored version, and the malicious package was live for 5 hours and 20 minutes before removal. The attack used AI-generated code to make the malicious additions look like legitimate maintenance patches.

The 5 Main Attack Vectors

Understanding how these attacks are executed is the first step toward defending against them. The 2025-2026 wave used five primary vectors:

1. Account Takeover

The most impactful attacks — Axios, chalk, debug, nx — all used credential theft or social engineering to hijack legitimate maintainer accounts. Once inside, attackers have full publishing rights to package versions that immediately become trusted by every downstream user.

Why it works: npm's trust model is account-based. A published version from the correct account is treated as legitimate by the registry, by CDNs that mirror it, and by every lockfile that pins to it. There is no code signing by default.

2. Typosquatting

Attackers register package names one character away from popular packages: lodash → lod4sh, express → expres, react → re4ct. A developer who miskeys a package name installs the attacker's version instead. The SANDWORM_MODE campaign (February 2026) combined typosquatting with a self-propagating worm, targeting packages in the Solana and Ethereum ecosystems.

3. Dependency Confusion

If your organization uses private npm packages with names like @mycompany/utils, an attacker can publish a public package with the same name but a higher version number. Misconfigured npm clients that check both public and private registries will prefer the higher version — the malicious public one. This technique, popularized by researcher Alex Birsan in 2021, remains actively exploited in 2026.

4. Malicious New Packages

The most automated attack type: publish a package that mimics a useful tool, wait for developers to find it via search or blog posts, then activate the malware after reaching a sufficient install count. The IndonesianFoods campaign (November 2025) published over 100,000 packages in a few days — roughly one new malicious package every 7 seconds.

5. CI/CD Token Theft

Modern CI/CD pipelines require npm tokens with publish rights. These tokens appear in GitHub Actions secrets, environment variables, and sometimes in git history. Attackers specifically target CI/CD configurations to steal publish tokens and then use them to backdoor trusted packages — as demonstrated in the nx attack.

What Attackers Are After

Supply chain attackers in 2026 are not interested in breaking your application's business logic. They want three things:

• Environment variables — process.env contains database credentials, API keys, JWT secrets, cloud provider credentials, and payment processor tokens. A single exfiltration of a developer's environment can compromise an entire SaaS infrastructure.
• SSH keys and git credentials — to pivot into private repositories, steal source code, or insert backdoors into enterprise codebases.
• Cryptocurrency wallets and private keys — SANDWORM_MODE specifically targeted Solana and Ethereum developer tooling to steal crypto assets.

The payload delivery is increasingly sophisticated: delayed execution (activates only in certain environments), environment detection (targets only CI machines or developer laptops, not sandboxes), and external loading (PhantomRaven) that evades static analysis.

How to Detect Supply Chain Attacks in Your Projects

1. Pin your dependencies with lockfiles

Shell
# Always commit package-lock.json or yarn.lock
# Never use --no-package-lock or .npmignore on lockfiles

# Verify your lockfile is consistent with package.json
npm ci  # Uses lockfile exactly — fails if inconsistent
# Not: npm install  # May update lockfile silently

Using npm ci in CI/CD pipelines ensures you install exactly the versions recorded in the lockfile. npm install can silently upgrade minor versions, potentially pulling in a newly published malicious patch.

2. Enable npm audit and automate it

Shell
# Run on every CI build — fail the build on high severity
npm audit --audit-level=high

# Check for known malicious packages (not just CVEs)
npx better-npm-audit audit

Standard npm audit checks against the npm advisory database for known CVEs. However, it has a critical blind spot: it does not detect newly published malicious packages that have not yet been reported as vulnerabilities. The Axios backdoor would have passed npm audit during the 4-hour window it was live.

3. Monitor your dependency tree continuously

The fundamental problem with point-in-time scanning is that packages you depend on can be compromised at any moment after you last ran a scan. A lockfile that was safe at 9am can be dangerous by noon. Continuous monitoring — scanning your dependency tree against real-time threat intelligence — is the only approach that catches the Axios-class attack.

What to monitor:

• New CVEs affecting packages in your lockfile
• Packages with unexpected ownership changes
• Versions with unusual postinstall scripts added
• Dependencies that suddenly start making network requests

4. Restrict postinstall scripts

JSON
// In your .npmrc or package.json
// Disable lifecycle scripts from running automatically
{
  "scripts": {
    "preinstall": "npx npm-force-resolutions"
  }
}

Shell# Or use the --ignore-scripts flag for installs
npm install --ignore-scripts

# Review scripts before allowing them
npm install --dry-run 2>&1 | grep -i "postinstall\|preinstall"

Many supply chain attacks deliver their payload via postinstall or preinstall scripts — code that runs automatically when a package is installed, even without ever importing or requiring the package.

5. Use Subresource Integrity for published assets

If you publish packages yourself, enable 2FA on your npm account, rotate publish tokens regularly, and use provenance attestations — a feature npm introduced to cryptographically link a published package to its source repository and CI/CD build. This makes it significantly harder for an account takeover to go undetected.

Shell# Publish with provenance (links package to GitHub Actions run)
npm publish --provenance

# Consumers can verify provenance
npm info your-package dist.integrity

Building a Layered Defense

No single tool stops all supply chain attacks. The Axios compromise showed that even well-maintained, widely-scrutinized packages can be compromised. The defense strategy must be layered:

Layer	Tool / Practice	Catches
Install-time	npm ci, --ignore-scripts	Lockfile drift, postinstall payloads
Static analysis	npm audit, Socket.dev	Known CVEs, behavioral patterns
Continuous monitoring	CVE OptiBot	New CVEs on existing deps, real-time alerts
Runtime	Node.js permissions flag, network policies	Unexpected network calls, file access
Publishing	npm 2FA, provenance, token rotation	Account takeover, CI/CD token theft

The State-Sponsored Threat

One development that distinguishes 2025-2026 from earlier supply chain attack waves is the clear fingerprint of state-sponsored threat actors. Sonatype tracked over 800 npm packages linked to the Lazarus Group (a North Korean state-sponsored hacking group), representing 97% of the group's recorded activity. Lazarus-linked packages specifically target:

• Developers working on cryptocurrency applications
• Employees at crypto exchanges, DeFi protocols, and blockchain companies
• Developers with access to private keys for cold wallets

The Axios compromise was attributed to Sapphire Sleet / UNC1069 — a North Korean cluster with overlapping tooling and objectives. The target was not the Axios project itself; the target was every developer machine where npm install ran.

This means the threat model for npm supply chain attacks is no longer just "opportunistic criminals." It includes nation-state actors with significant resources and patience, willing to invest weeks in social engineering a single maintainer to gain access to packages with hundreds of millions of weekly downloads.

Frequently Asked Questions

How do I know if a package I use was compromised?

Check the npm advisory database (npm audit), Socket.dev for behavioral analysis, and Sonatype OSS Index. Subscribe to security mailing lists for packages you depend on. The most reliable approach is continuous monitoring that alerts you within minutes of a new advisory — rather than waiting for your next manual scan.

Does package-lock.json protect me from supply chain attacks?

Partially. A lockfile protects you from receiving a newly published malicious version the next time you run npm install — because it pins to a specific version by hash. But it does not protect you if: (1) you already installed the package before the malicious version was detected, (2) a developer on your team runs npm install without the lockfile, or (3) the package you pinned was already malicious when you first installed it.

What is the difference between a supply chain attack and a normal CVE?

A traditional CVE is a vulnerability in legitimate code — a bug that an attacker can exploit. A supply chain attack means the package itself was intentionally weaponized by someone who gained unauthorized access to publish it. The critical difference: npm audit tracks CVEs in a database that is updated after vulnerabilities are disclosed. A supply chain attack may be live and exfiltrating data for hours before it appears in any advisory database.

Should I use private npm mirrors or registries?

Private registries (Verdaccio, JFrog Artifactory, GitHub Packages) add a layer of control — you can vet packages before they enter your internal mirror. However, they require maintenance overhead and do not eliminate the need for ongoing monitoring. A compromised package that was approved before the attack is not blocked by the registry mirror.

How can I protect my npm publish credentials?

Enable 2FA (mandatory for top packages, recommended for all), use granular publish tokens (scoped to specific packages, not your entire account), rotate tokens every 90 days, never store tokens in environment files committed to git, and use provenance attestations in CI/CD to create a verifiable link between published versions and their source commits.

Are these attacks only a problem for large companies?

No. Freelancers and small agencies are often preferred targets because they tend to have weaker security postures while still having access to client credentials stored in environment variables. The Lazarus Group and similar actors cast wide nets — they collect credentials from thousands of developer machines and then decide which ones are most valuable to exploit deeply.

Le 31 mars 2026, des attaquants ont compromis le compte npm du mainteneur principal d'Axios — un package téléchargé plus de 100 millions de fois par semaine — et ont injecté un cheval de Troie d'accès à distance (RAT) multiplateforme qui s'est exécuté silencieusement sur chaque machine de développeur ayant lancé npm install pendant une fenêtre de 4 heures. Ce n'était pas un incident isolé. C'était la suite logique d'une tendance qui a fait de 2025 la pire année jamais enregistrée pour les attaques de supply chain npm, avec 454 648 packages malveillants publiés en une seule année.

Si vous utilisez des packages npm — et c'est le cas — c'est votre paysage de menaces. Cet article détaille exactement comment ces attaques fonctionnent, ce que les plus grands incidents de 2025-2026 ont en commun, et quelles défenses concrètes vous pouvez mettre en place dès aujourd'hui.

L'ampleur du problème en 2025-2026

Le registre npm est le plus grand registre de packages logiciels au monde, avec plus de 2,5 millions de packages et des dizaines de milliards de téléchargements par mois. Cette échelle est à la fois sa force et sa plus grande vulnérabilité. Les attaquants ont systématiquement industrialisé l'exploitation de cet écosystème.

Il ne s'agit pas d'opportunistes publient du contenu aléatoire. Ce sont des acteurs organisés — dont des groupes soutenus par des États-nations — qui mènent des campagnes automatisées à une échelle industrielle.

Les plus grandes attaques supply chain npm (2025-2026)

Mars 2026 — La compromission d'Axios

Axios est l'un des packages npm les plus utilisés au monde. Le 31 mars 2026, des attaquants ont utilisé l'ingénierie sociale pour détourner les identifiants de publication npm d'un mainteneur principal. Ils ont publié une version backdoorée contenant un RAT multiplateforme ciblant les environnements des développeurs — volant variables d'environnement, clés SSH et identifiants API depuis les machines de tous ceux qui ont exécuté npm install pendant la fenêtre de compromission de 4 heures.

Pourquoi c'est important : Ce n'était pas une dépendance de dépendance. C'était un package direct de premier plan avec 100 millions de téléchargements hebdomadaires, utilisé en production par des entreprises du Fortune 500 et des développeurs indépendants. Le vecteur d'attaque était humain — pas une vulnérabilité de code — démontrant que même les packages bien maintenus sont exposés à la prise de contrôle de compte.

L'attribution a été faite à Sapphire Sleet / UNC1069, un groupe nord-coréen spécialisé dans le ciblage des développeurs de logiciels et des infrastructures de cryptomonnaies.

Septembre 2025 — Le Grand Vol npm

Check Point Research a documenté l'une des plus grandes campagnes de prise de contrôle de packages jamais observées. Les attaquants ont obtenu un accès non autorisé aux comptes de publication de plusieurs packages très utilisés simultanément, notamment chalk et debug, ainsi que 16 autres packages. Ces packages représentent ensemble plus de 2,6 milliards de téléchargements par semaine.

La campagne ciblait des packages avec un volume de téléchargements élevé et des équipes de mainteneurs réduites — maximisant le rayon de l'explosion tout en minimisant le nombre d'identifiants nécessaires. Les versions malveillantes incluaient des scripts obfusqués qui exfiltraient process.env vers un serveur contrôlé par les attaquants.

Novembre 2025 — Shai-Hulud 2.0 : Le Ver Auto-Réplicant

L'attaque techniquement la plus sophistiquée de 2025 était Shai-Hulud 2.0, un ver npm auto-réplicant qui infectait automatiquement d'autres packages sur les machines des développeurs possédant des identifiants de publication npm. Lorsqu'un développeur installait le package infecté initial, puis exécutait npm publish sur l'un de ses propres packages, le ver s'intégrait silencieusement dans cette nouvelle publication.

Au moment de son endiguement, Shai-Hulud 2.0 s'était propagé à 796 packages représentant plus de 132 millions de téléchargements par mois. Le ver original de ce type, Shai-Hulud 1.0, a été documenté pour la première fois en novembre 2025 et a démontré que les malwares auto-réplicants dans les registres open source ne sont plus théoriques.

Octobre 2025 — Campagne PhantomRaven

La campagne PhantomRaven (documentée par Sonatype) a utilisé une technique d'évasion novatrice : le payload malveillant était hébergé à l'extérieur et chargé à l'exécution plutôt qu'intégré directement dans le package. Cela contournait la plupart des outils d'analyse statique utilisés par les registres et les pipelines CI/CD. Plus de 100 packages malveillants ont été publiés, ciblant 86 000 victimes potentielles avant leur suppression.

Août 2025 — L'attaque nx via IA Weaponisée

Snyk a documenté une campagne ciblant le système de build populaire nx (utilisé par Angular, NestJS et de nombreux projets d'entreprise). Les attaquants ont compromis un token GitHub Actions, l'ont utilisé pour publier une version backdoorée, et le package malveillant était actif pendant 5 heures et 20 minutes avant suppression. L'attaque utilisait du code généré par IA pour faire paraître les ajouts malveillants comme de légitimes correctifs de maintenance.

Les 5 Principaux Vecteurs d'Attaque

Comprendre comment ces attaques sont exécutées est la première étape pour s'en défendre. La vague 2025-2026 a utilisé cinq vecteurs principaux :

1. Prise de Contrôle de Compte

Les attaques les plus impactantes — Axios, chalk, debug, nx — ont toutes utilisé le vol d'identifiants ou l'ingénierie sociale pour pirater les comptes légitimes des mainteneurs. Une fois à l'intérieur, les attaquants ont tous les droits de publication pour des versions de packages qui deviennent immédiatement approuvées par chaque utilisateur en aval.

2. Typosquatting

Les attaquants enregistrent des noms de packages à un caractère près des packages populaires : lodash → lod4sh, express → expres. Un développeur qui se trompe d'un caractère installe la version de l'attaquant. La campagne SANDWORM_MODE (février 2026) combinait typosquatting et ver auto-propagé, ciblant des packages des écosystèmes Solana et Ethereum.

3. Confusion de Dépendances

Si votre organisation utilise des packages npm privés nommés @monentreprise/utils, un attaquant peut publier un package public avec le même nom mais un numéro de version plus élevé. Les clients npm mal configurés qui vérifient les registres public et privé préféreront la version plus élevée — la version publique malveillante.

4. Nouveaux Packages Malveillants

Le type d'attaque le plus automatisé : publier un package qui imite un outil utile, attendre que les développeurs le trouvent, puis activer le malware après avoir atteint un nombre suffisant d'installations. La campagne IndonesianFoods (novembre 2025) a publié plus de 100 000 packages en quelques jours — soit environ un nouveau package malveillant toutes les 7 secondes.

5. Vol de Tokens CI/CD

Les pipelines CI/CD modernes nécessitent des tokens npm avec des droits de publication. Ces tokens apparaissent dans les secrets GitHub Actions, les variables d'environnement, et parfois dans l'historique git. Les attaquants ciblent spécifiquement les configurations CI/CD pour voler des tokens de publication et s'en servir pour backdoorer des packages de confiance.

Comment Détecter les Attaques Supply Chain dans Vos Projets

1. Épinglez vos dépendances avec des lockfiles

Shell
# Toujours commiter package-lock.json ou yarn.lock
# Ne jamais utiliser --no-package-lock

# Utiliser npm ci en CI/CD (utilise le lockfile exactement)
npm ci
# Pas: npm install  # Peut mettre à jour le lockfile silencieusement

L'utilisation de npm ci dans les pipelines CI/CD garantit l'installation exacte des versions enregistrées dans le lockfile. npm install peut silencieusement mettre à niveau les versions mineures, risquant d'intégrer un patch malveillant nouvellement publié.

2. Activez npm audit et automatisez-le

Shell
# Exécuter à chaque build CI — échouer sur haute sévérité
npm audit --audit-level=high

Le npm audit standard vérifie la base de données des avis npm pour les CVE connus. Cependant, il a un angle mort critique : il ne détecte pas les nouveaux packages malveillants qui n'ont pas encore été signalés comme vulnérabilités. Le backdoor d'Axios aurait passé npm audit pendant la fenêtre de 4 heures où il était actif.

3. Monitorez votre arbre de dépendances en continu

Le problème fondamental de l'analyse ponctuelle est que les packages dont vous dépendez peuvent être compromis à tout moment après votre dernier scan. Un lockfile sûr à 9h du matin peut être dangereux à midi. La surveillance continue — scanner votre arbre de dépendances contre une intelligence des menaces en temps réel — est la seule approche qui détecte les attaques de type Axios.

4. Restreignez les scripts postinstall

Shell
# Utiliser --ignore-scripts pour les installations en production
npm install --ignore-scripts

# Vérifier les scripts avant de les autoriser
npm install --dry-run 2>&1 | grep -i "postinstall\|preinstall"

De nombreuses attaques de supply chain délivrent leur payload via des scripts postinstall ou preinstall — du code qui s'exécute automatiquement lors de l'installation d'un package, même sans jamais l'importer.

5. Activez la 2FA et utilisez la provenance

Shell
# Publier avec provenance (lie le package au run GitHub Actions)
npm publish --provenance

# Vérifier la provenance d'un package
npm info votre-package dist.integrity

La Menace Étatique

Un développement qui distingue 2025-2026 des vagues précédentes d'attaques de supply chain est l'empreinte claire d'acteurs étatiques. Sonatype a suivi plus de 800 packages npm liés au groupe Lazarus (groupe de hackers soutenu par l'État nord-coréen), représentant 97% de l'activité enregistrée du groupe. Les packages liés à Lazarus ciblent spécifiquement les développeurs travaillant sur des applications de cryptomonnaies et ceux ayant accès à des clés privées pour des portefeuilles.

La compromission d'Axios a été attribuée à Sapphire Sleet / UNC1069 — un cluster nord-coréen avec des outils et objectifs similaires à Lazarus. La cible n'était pas le projet Axios lui-même ; la cible était chaque machine de développeur sur laquelle npm install était exécuté.

Questions Fréquentes

Comment savoir si un package que j'utilise a été compromis ?

Vérifiez la base de données des avis npm (npm audit), Socket.dev pour l'analyse comportementale, et Sonatype OSS Index. Abonnez-vous aux listes de diffusion de sécurité pour les packages dont vous dépendez. L'approche la plus fiable est la surveillance continue qui vous alerte dans les minutes suivant un nouvel avis — plutôt que d'attendre votre prochain scan manuel.

Est-ce que package-lock.json me protège des attaques supply chain ?

Partiellement. Un lockfile vous protège de recevoir une version malveillante nouvellement publiée la prochaine fois que vous exécutez npm install — car il s'ancre à une version spécifique par hash. Mais il ne vous protège pas si : (1) vous avez déjà installé le package avant que la version malveillante soit détectée, (2) un développeur de votre équipe exécute npm install sans le lockfile, ou (3) le package épinglé était déjà malveillant lors de sa première installation.

Quelle est la différence entre une attaque supply chain et une CVE normale ?

Une CVE traditionnelle est une vulnérabilité dans du code légitime — un bug qu'un attaquant peut exploiter. Une attaque supply chain signifie que le package lui-même a été intentionnellement armé par quelqu'un qui a obtenu un accès non autorisé pour le publier. La différence critique : npm audit suit les CVE dans une base de données mise à jour après divulgation. Une attaque supply chain peut être active et exfiltrer des données pendant des heures avant d'apparaître dans une base de données d'avis.

Ces attaques concernent-elles uniquement les grandes entreprises ?

Non. Les freelances et les petites agences sont souvent des cibles préférées car ils ont tendance à avoir des postures de sécurité plus faibles tout en ayant accès aux identifiants clients stockés dans des variables d'environnement. Le groupe Lazarus et des acteurs similaires lancent des filets larges — ils collectent des identifiants de milliers de machines de développeurs puis décident lesquels valent la peine d'être exploités plus profondément.

Comment protéger mes identifiants npm publish ?

Activez la 2FA (obligatoire pour les packages les plus téléchargés, recommandée pour tous), utilisez des tokens de publication granulaires (scopés à des packages spécifiques), faites tourner les tokens tous les 90 jours, ne stockez jamais les tokens dans des fichiers d'environnement commités dans git, et utilisez les attestations de provenance en CI/CD.

Est-ce que les outils de type npm audit suffisent ?

Non, ils sont nécessaires mais insuffisants. npm audit ne détecte pas les packages compromis qui n'ont pas encore d'avis dans sa base de données. L'incident Axios — l'attaque la plus médiatisée de 2026 — aurait passé npm audit sans aucune alerte pendant toute la fenêtre de compromission. La surveillance continue en temps réel est indispensable.