The first half of 2026 produced 37 supply chain attack campaigns and 497 indexed malicious packages — that's 2.6× the campaign count and 4.5× the package volume of the entire preceding year (Source: Phoenix Security / Sonatype, June 2026). May 2026 alone was the single busiest month on record: 14 campaigns and 346 indexed packages in 31 days, more than the four months before it combined. We are now at the midpoint of a year that is systematically dismantling the assumption that npm installs are safe by default.
This retrospective covers every major incident from January through June 2026, what attackers learned from each one, how the ecosystem responded, and what you should change before H2 begins.
The Numbers: H1 2026 in Context
To understand why H1 2026 matters, you need the baseline. Sonatype's 2026 State of the Software Supply Chain report counted 454,648 new malicious open-source packages published in 2025 alone — a 75% year-over-year increase, pushing the cumulative total blocked past 1.233 million across npm, PyPI, Maven Central, NuGet, and Hugging Face. Over 99% of that malware lived on npm.
Group-IB now names six distinct supply chain attack groups operating against npm and PyPI, several of them financially motivated state actors. The Lazarus Group (North Korea) alone was linked to over 800 packages concentrated 97% on npm. The days when supply chain attacks were rare, opportunistic events are over — this is industrialized, persistent, and accelerating.
Incident #1 — Axios (March 31, 2026): The Social Engineering Playbook
Axios is one of the most downloaded npm packages on the planet — over 100 million downloads per week, present in the dependency tree of more than 174,000 packages. On March 31, 2026, a North Korean threat actor linked to Sapphire Sleet (Microsoft attribution) spent weeks building trust with the axios maintainer via Slack, posing as a payments startup founder. The final step: asking the maintainer to run a "demo binary." That binary was a Remote Access Trojan that stole his npm credentials.
For approximately four hours, every fresh npm install axios pulled down two malicious versions containing a cross-platform RAT. The npm security team yanked the packages within hours, but the window was wide enough. This was not a technical exploit against the registry — it was a targeted social engineering attack against a single human maintainer.
What Axios taught us
A single compromised maintainer account = malware on 100M machines/week. No scanner catches the attack before it lands — the package is published with valid credentials. The only defenses that work are: staged publishing (review gate before propagation), npm org 2FA enforcement, and continuous monitoring for abnormal publish events.
Incident #2 — TanStack / Mini Shai-Hulud (May 11, 2026): The Pipeline Hijack
Axios was human. TanStack was infrastructural. On May 11, 2026, attackers extracted an OIDC token from a GitHub Actions runner's memory, poisoned a build cache, and published 84 malicious package artifacts across 42 @tanstack/* packages in approximately six minutes — each with cryptographically valid Sigstore SLSA provenance attestations (CVE-2026-45321, CVSS 9.6).
The attack didn't stop at TanStack. The coordinated campaign hit Mistral AI's SDK suite, UiPath's automation tooling (65 packages), OpenSearch, and Guardrails AI — 404 total malicious versions across npm and PyPI. @tanstack/react-router alone downloads 12.7 million times per week. This was the first documented case of a supply chain worm that bypassed SLSA Build Level 2 provenance by hijacking the pipeline that produces the attestation itself.
What TanStack taught us
SLSA Build Level 2 provenance is not a trust signal — it proves the pipeline ran, not that the pipeline was safe. The OpenSSF post-mortem confirmed that L3 (hermetic, non-forgeable builds) would have stopped this. Defenders need lockfile integrity checks in CI/CD that fail the build when unexpected packages appear, not just signature verification.
Incident #3 — node-ipc (May 14, 2026): The Stale Maintainer Account
Three days after TanStack, a different attack vector: node-ipc, a foundational Node.js IPC library with over 10 million weekly downloads, was compromised through a stale maintainer account. The email domain for the compromised account (atlantis-software.net) had expired in January 2025 and was silently re-registered in May 2026 — a week before the attack.
Versions 9.1.6, 9.2.3, and 12.0.1 were simultaneously published with an identical 80 KB obfuscated credential-stealing payload. Once loaded via require('node-ipc'), it harvested over 90 categories of credentials — AWS, Azure, GCP, SSH keys, Kubernetes tokens, GitHub CLI configs, Claude AI and Kiro IDE settings, Terraform state, and database passwords — then exfiltrated everything via DNS TXT queries to a server masquerading as Azure infrastructure (Datadog Security Labs analysis, May 2026).
What node-ipc taught us
Expired maintainer email domains are an attack surface. An attacker who re-registers the domain gains password reset access to the npm account. npm's staged publishing (GA May 22, 2026) now introduces a 72-hour hold on new major-version publishes from accounts without prior versions — this would have slowed but not stopped this attack. Quarterly contributor access audits are now mandatory hygiene.
Incident #4 — Miasma Waves 1, 2 & 3 (June 1–6, 2026): The Worm Goes Corporate
Miasma is the most technically sophisticated supply chain operation of H1 2026 — a self-replicating worm that executed across three distinct waves in a single week targeting corporate npm scopes.
Wave 1 (June 1): A compromised Red Hat employee GitHub account was used to push malicious orphan commits to multiple RedHatInsights repositories, bypassing code review. The GitHub Actions workflows triggered, requested OIDC tokens, and published 32 Trojanized packages under @redhat-cloud-services with valid SLSA provenance — identical to TanStack but at a corporate scale.
Wave 2 (June 3): The Phantom Gyp technique — a 157-byte binding.gyp file that triggers an implicit node-gyp rebuild even when --ignore-scripts is set — compromised 57 packages including @vapi-ai/server-sdk (408,000 downloads/month). Unlike Miasma Wave 1, this wave spread via developer workstations, not CI/CD pipelines.
Wave 3 (June 5–6): The worm reached Microsoft — 73 Azure GitHub repositories disabled in 105 seconds. A 4.3 MB Bun payload fired automatically when developers opened infected repos in Claude Code, Gemini CLI, Cursor, or VS Code. The malicious durabletask PyPI SDK (versions 1.4.1–1.4.3) simultaneously extended the campaign to Python developers.
What Miasma taught us
AI coding agent configuration files (.claude/settings.json, .gemini/settings.json, .cursor/mcp.json) are now prime credential targets. The Phantom Gyp technique defeated the #1 community advice ("run with --ignore-scripts"). npm v12's blanket install-script block was directly motivated by this series of incidents.
The H1 2026 Attack Pattern Matrix
Looking across all four major incidents, a clear pattern emerges. Every successful attack in H1 2026 combined at least two of these vectors:
| Incident | Account Takeover | Pipeline Hijack | Install Script | SLSA Bypass | Self-Replication |
|---|---|---|---|---|---|
| Axios (Mar 31) | ✓ (social eng.) | — | — | — | — |
| TanStack (May 11) | — | ✓ (OIDC token) | — | ✓ (L2 forged) | ✓ (worm) |
| node-ipc (May 14) | ✓ (domain expiry) | — | — | — | — |
| Miasma W1-W3 (Jun) | ✓ (GH account) | ✓ (Actions OIDC) | ✓ (Phantom Gyp) | ✓ (L2 forged) | ✓ (worm) |
The evolution is clear: Axios used one vector. Miasma used all five simultaneously. H2 2026 will likely see more incidents combining multiple vectors from day one.
How the Ecosystem Responded
The attacks forced concrete responses from npm, GitHub, and the broader ecosystem. Here is what shipped in H1 2026:
npm Staged Publishing (GA May 22, 2026): New major versions from accounts with no prior history in that scope now enter a 72-hour review hold. Maintainers get an approval gate before packages propagate to dependent package installs. This would have partially slowed the Axios and node-ipc attacks — not stopped them, because the compromised accounts had legitimate history.
npm v12 (July 2026): The most significant security change to npm in its history. Three defaults change simultaneously: allowScripts → off (no more preinstall/postinstall by default, including implicit node-gyp), --allow-git → none (Git dependencies blocked), --allow-remote → none (remote URL dependencies blocked). This directly neutralizes the Phantom Gyp technique that Miasma used to bypass --ignore-scripts.
OpenSSF June 10 Post-Mortem: The official analysis of the TanStack incident confirmed that SLSA Build Level 3 (hermetic builds) would have prevented the SLSA provenance forgery. The post-mortem includes a roadmap for L3 support in GitHub Actions — currently blocked on runner isolation requirements.
npm Token Cap (June 2026): npm automation tokens now have a 90-day maximum validity. Tokens issued before this date will begin expiring in Q3 2026. This addresses the node-ipc and Axios attack patterns where stolen long-lived tokens were used days or weeks after theft.
What npm v12 Fixes — and What It Doesn't
npm v12's install script block is real progress. But it's important to understand its limits, because security researchers have already published their critiques (Cybernews, July 2026: "Experts say it's not enough").
What npm v12 DOES fix: Phantom Gyp (binding.gyp implicit rebuild), malicious postinstall exfiltration, remote URL dependency injection, Git dependency code execution. These covered the Miasma Wave 2 attack vector completely.
What npm v12 DOES NOT fix: Account takeover attacks (Axios, node-ipc pattern) — a compromised maintainer can still publish clean-looking code that executes malicious logic at runtime, not install time. Pipeline hijacks (TanStack pattern) — the malicious code can be baked into the module itself, not in a lifecycle script. Dependency confusion — blocked sources don't help if the public registry serves a higher version of your private package name.
The Cybernews consensus: npm v12 eliminates an entire class of attack vectors that represented roughly 40% of H1 2026 incidents. It is necessary but not sufficient.
The H2 2026 Threat Landscape: What to Expect
Based on the H1 2026 trajectory, three patterns are likely to accelerate in H2:
1. AI Coding Agent Targeting: Miasma Wave 3 demonstrated that .claude/settings.json, .gemini/settings.json, and .cursor/mcp.json are now explicit targets. As agentic coding tools proliferate in 2026, their config files and MCP (Model Context Protocol) servers represent a new attack surface with credential access to cloud providers, registries, and source control. Expect dedicated campaigns in H2.
2. Multi-Ecosystem Worms: The TanStack and Miasma campaigns hit npm and PyPI simultaneously. H2 will likely see campaigns targeting npm + PyPI + Cargo + NuGet in a single coordinated operation — each registry provides additional credential and lateral movement opportunities.
3. Post-npm-v12 Adaptation: Attackers will shift away from install-time execution toward runtime payloads. Expect more package versions where the malicious code activates on require() or on specific API calls, not in lifecycle scripts. This makes static analysis harder and behavioral monitoring more important.
The H1 2026 Defense Checklist
Here is what every npm project should have in place before H2 begins:
npm Security Baseline — H2 2026
npm approve-scripts to audit your allowlist before upgrading
auth-and-writes for all contributors, migrate to FIDO/passkey
package-lock.json changes unexpectedly; use npm ci in production
uses: actions/checkout@sha256:abc123, not @v3
.claude/, .gemini/, .cursor/ to your threat model and secret scanning scope
Frequently Asked Questions
Will npm v12 stop future supply chain attacks?
Partially. npm v12 eliminates install-script-based attacks like Phantom Gyp and postinstall exfiltration, which covered roughly 40% of H1 2026 incidents. It does not address account takeover (Axios, node-ipc pattern), pipeline hijacks (TanStack), or runtime payloads baked into modules. Security researchers agree it's necessary but not sufficient.
Can SLSA provenance attestations prevent TanStack-style attacks?
SLSA Build Level 2 cannot — TanStack proved that. The attacker produced valid Sigstore attestations by hijacking the pipeline before attestation. SLSA Build Level 3 (hermetic, isolated builds) would have prevented forgery, but GitHub Actions does not yet support L3 requirements. The OpenSSF June 10 post-mortem confirmed this and published a roadmap.
How did Miasma bypass --ignore-scripts?
Via the Phantom Gyp technique: a 157-byte binding.gyp file triggers an implicit node-gyp rebuild in npm ≤ v11, even when --ignore-scripts is set. npm v12's allowScripts: off default blocks this, because it blocks the implicit node-gyp hook too, not just explicit lifecycle scripts.
How was the node-ipc attacker able to take over the npm account?
The maintainer account email used a domain (atlantis-software.net) that expired in January 2025. The attacker re-registered the expired domain in May 2026, then triggered a password reset on the npm account — receiving the reset email on the newly controlled domain. This is why contributor access audits must include checking that email domains are still controlled by the intended person.
What credentials did Miasma and node-ipc target?
Both campaigns targeted a broad credential harvest: AWS/Azure/GCP credentials, SSH private keys, Kubernetes service account tokens, GitHub CLI configs, npm auth tokens, .netrc files, browser-saved passwords, Claude AI and Cursor IDE settings, Terraform state files, and database connection strings. AI developer tool configuration files were an explicit new target in Miasma Waves 2 and 3.
Is open-source supply chain security getting worse every year?
Yes, by volume — Sonatype counted 454,648 malicious packages in 2025, a 75% increase over 2024, and H1 2026 is already on track to exceed that. But the ecosystem response is also accelerating: npm staged publishing, token caps, npm v12's install-script block, and the OpenSSF SLSA roadmap are all concrete improvements that didn't exist a year ago. The attack surface is growing, but so is the tooling to contain it.
Monitor your dependencies automatically
CVE OptiBot scans your lockfiles daily and alerts you when a new CVE hits a package you actually use — before attackers do. No code access required.
Start free monitoringRelated reading
Le premier semestre 2026 a produit 37 campagnes d'attaques supply chain et 497 packages malveillants indexés — soit 2,6× le nombre de campagnes et 4,5× le volume de packages de toute l'année précédente (Source : Phoenix Security / Sonatype, juin 2026). Le mois de mai 2026 seul a été le mois le plus chargé jamais enregistré : 14 campagnes et 346 packages indexés en 31 jours, plus que les quatre mois précédents combinés. Nous sommes au milieu d'une année qui démantèle systématiquement l'hypothèse selon laquelle les installations npm sont sûres par défaut.
Cette rétrospective couvre chaque incident majeur de janvier à juin 2026, ce que les attaquants ont appris à chaque fois, comment l'écosystème a répondu, et ce que vous devriez changer avant que H2 commence.
Les chiffres : H1 2026 en contexte
Le rapport 2026 State of the Software Supply Chain de Sonatype a compté 454 648 nouveaux packages open source malveillants publiés rien qu'en 2025 — une augmentation de 75% d'une année sur l'autre, portant le total cumulé bloqué à plus de 1,233 million sur npm, PyPI, Maven Central, NuGet et Hugging Face. Plus de 99% de ces malwares vivaient sur npm.
Group-IB identifie désormais six groupes d'attaques supply chain distincts opérant contre npm et PyPI, dont plusieurs acteurs étatiques à motivation financière. Le groupe Lazarus (Corée du Nord) seul a été lié à plus de 800 packages concentrés à 97% sur npm. L'époque des attaques supply chain rares et opportunistes est révolue — c'est industrialisé, persistant et en accélération.
Incident n°1 — Axios (31 mars 2026) : le manuel de l'ingénierie sociale
Axios est l'un des packages npm les plus téléchargés au monde — plus de 100 millions de téléchargements par semaine, présent dans l'arbre de dépendances de plus de 174 000 packages. Le 31 mars 2026, un acteur lié à Sapphire Sleet (attribution Microsoft), affilié à la Corée du Nord, a passé des semaines à établir une relation de confiance avec le mainteneur d'axios via Slack, se faisant passer pour le fondateur d'une startup de paiement. L'étape finale : demander au mainteneur de lancer un "binaire de démo". Ce binaire était un cheval de Troie d'accès distant (RAT) qui a volé ses identifiants npm.
Pendant environ quatre heures, chaque npm install axios fraîche téléchargeait deux versions malveillantes contenant un RAT multiplateforme. L'équipe sécurité npm a retiré les packages en quelques heures, mais la fenêtre était suffisamment large. Il ne s'agissait pas d'un exploit technique contre le registre — c'était une attaque d'ingénierie sociale ciblée contre un seul mainteneur humain.
Ce qu'Axios nous a appris
Un seul compte mainteneur compromis = malware sur 100M machines/semaine. Aucun scanner ne détecte l'attaque avant qu'elle arrive — le package est publié avec des identifiants valides. Les seules défenses efficaces : la publication par étapes (portail d'approbation avant propagation), l'application de la 2FA org npm, et la surveillance continue des événements de publication anormaux.
Incident n°2 — TanStack / Mini Shai-Hulud (11 mai 2026) : le détournement de pipeline
Axios était humain. TanStack était infrastructurel. Le 11 mai 2026, des attaquants ont extrait un jeton OIDC de la mémoire d'un runner GitHub Actions, empoisonné un cache de build et publié 84 artefacts de packages malveillants sur 42 packages @tanstack/* en environ six minutes — chacun avec des attestations de provenance Sigstore SLSA cryptographiquement valides (CVE-2026-45321, CVSS 9.6).
L'attaque ne s'est pas arrêtée à TanStack. La campagne coordonnée a frappé la suite SDK de Mistral AI, les outils d'automatisation UiPath (65 packages), OpenSearch et Guardrails AI — 404 versions malveillantes au total sur npm et PyPI. @tanstack/react-router seul se télécharge 12,7 millions de fois par semaine. C'était le premier cas documenté d'un ver supply chain contournant la provenance SLSA Build Level 2 en détournant le pipeline qui produit l'attestation lui-même.
Ce que TanStack nous a appris
La provenance SLSA Build Level 2 n'est pas un signal de confiance — elle prouve que le pipeline a fonctionné, pas qu'il était sûr. Le post-mortem OpenSSF a confirmé que le Level 3 (builds hermétiques, non falsifiables) aurait stoppé cela. Les défenseurs ont besoin de vérifications d'intégrité du lockfile dans CI/CD qui font échouer le build lorsque des packages inattendus apparaissent.
Incident n°3 — node-ipc (14 mai 2026) : le compte mainteneur périmé
Trois jours après TanStack, un vecteur d'attaque différent : node-ipc, une bibliothèque IPC Node.js fondamentale avec plus de 10 millions de téléchargements hebdomadaires, a été compromise via un compte mainteneur périmé. Le domaine email du compte compromis (atlantis-software.net) avait expiré en janvier 2025 et été silencieusement ré-enregistré en mai 2026 — une semaine avant l'attaque.
Les versions 9.1.6, 9.2.3 et 12.0.1 ont été publiées simultanément avec un payload identique de vol de credentials de 80 Ko obfusqué. Une fois chargé via require('node-ipc'), il récoltait plus de 90 catégories de credentials — AWS, Azure, GCP, clés SSH, tokens Kubernetes, configs GitHub CLI, paramètres Claude AI et Kiro IDE, état Terraform et mots de passe de bases de données — puis exfiltrait tout via des requêtes DNS TXT vers un serveur se faisant passer pour une infrastructure Azure (analyse Datadog Security Labs, mai 2026).
Ce que node-ipc nous a appris
Les domaines email des mainteneurs expirés sont une surface d'attaque. Un attaquant qui ré-enregistre le domaine obtient un accès de réinitialisation de mot de passe au compte npm. La publication par étapes npm (GA 22 mai 2026) introduit maintenant un délai de 72h pour les nouvelles publications — cela aurait ralenti mais pas stoppé cette attaque. Les audits trimestriels d'accès des contributeurs sont désormais une hygiène obligatoire.
Incident n°4 — Miasma Vagues 1, 2 et 3 (1–6 juin 2026) : le ver frappe les entreprises
Miasma est l'opération supply chain techniquement la plus sophistiquée du H1 2026 — un ver auto-réplicant qui s'est exécuté sur trois vagues distinctes en une seule semaine, ciblant des scopes npm d'entreprise.
Vague 1 (1er juin) : Un compte GitHub d'employé Red Hat compromis a été utilisé pour pousser des commits orphelins malveillants vers plusieurs dépôts RedHatInsights, contournant la revue de code. Les workflows GitHub Actions se sont déclenchés, ont demandé des tokens OIDC, et ont publié 32 packages trojanisés sous @redhat-cloud-services avec une provenance SLSA valide.
Vague 2 (3 juin) : La technique Phantom Gyp — un fichier binding.gyp de 157 octets qui déclenche un node-gyp rebuild implicite même avec --ignore-scripts — a compromis 57 packages dont @vapi-ai/server-sdk (408 000 téléchargements/mois). Contrairement à la vague 1, cette vague s'est propagée via les postes développeurs, pas les pipelines CI/CD.
Vague 3 (5–6 juin) : Le ver a atteint Microsoft — 73 dépôts GitHub Azure désactivés en 105 secondes. Un payload Bun de 4,3 Mo se déclenchait automatiquement quand les développeurs ouvraient des dépôts infectés dans Claude Code, Gemini CLI, Cursor ou VS Code. Le SDK PyPI durabletask malveillant (versions 1.4.1–1.4.3) a simultanément étendu la campagne aux développeurs Python.
Ce que Miasma nous a appris
Les fichiers de configuration des agents IA de coding (.claude/settings.json, .gemini/settings.json, .cursor/mcp.json) sont désormais des cibles explicites. La technique Phantom Gyp a défait le conseil n°1 de la communauté ("lancez avec --ignore-scripts"). Le blocage par défaut des scripts d'installation de npm v12 a été directement motivé par cette série d'incidents.
Comment l'écosystème a répondu
Les attaques ont forcé des réponses concrètes de npm, GitHub et de l'écosystème au sens large. Voici ce qui a été livré au H1 2026 :
Publication par étapes npm (GA 22 mai 2026) : Les nouvelles versions majeures de comptes sans historique préalable dans ce scope entrent dans un délai de révision de 72 heures. Cela aurait partiellement ralenti les attaques Axios et node-ipc, mais pas stoppé celles dont les comptes compromis avaient un historique légitime.
npm v12 (juillet 2026) : Le changement de sécurité le plus significatif dans l'histoire de npm. Trois défauts changent simultanément : allowScripts → off, --allow-git → none, --allow-remote → none. Cela neutralise directement la technique Phantom Gyp que Miasma a utilisée pour contourner --ignore-scripts.
Post-mortem OpenSSF du 10 juin : L'analyse officielle de l'incident TanStack a confirmé que SLSA Build Level 3 (builds hermétiques) aurait empêché la falsification de provenance SLSA, et a publié une feuille de route pour le support L3 dans GitHub Actions.
Plafond de token npm (juin 2026) : Les tokens d'automatisation npm ont désormais une validité maximale de 90 jours — s'attaquant aux motifs d'attaque node-ipc et Axios où des tokens à longue durée de vie volés étaient utilisés des jours ou des semaines après le vol.
Ce que npm v12 corrige — et ce qu'il ne corrige pas
Le blocage des scripts d'installation par npm v12 est un progrès réel. Mais il est important d'en comprendre les limites. Les chercheurs en sécurité ont déjà publié leurs critiques (Cybernews, juillet 2026 : "Les experts disent que ce n'est pas suffisant").
Ce que npm v12 CORRIGE : Phantom Gyp (rebuild node-gyp implicite via binding.gyp), exfiltration postinstall malveillante, injection de dépendances URL distantes, exécution de code par dépendances Git. Ces vecteurs couvraient environ 40% des incidents du H1 2026.
Ce que npm v12 NE CORRIGE PAS : Les attaques par prise de contrôle de compte (motif Axios, node-ipc) — un mainteneur compromis peut toujours publier du code en apparence propre qui exécute une logique malveillante à l'exécution, pas à l'installation. Les détournements de pipeline (motif TanStack) — le code malveillant peut être intégré directement dans le module. La confusion de dépendances — les sources bloquées n'aident pas si le registre public sert une version plus élevée de votre nom de package privé.
Checklist de défense H1 2026
Voici ce que chaque projet npm devrait avoir en place avant le début du H2 :
Baseline sécurité npm — H2 2026
npm approve-scripts pour auditer votre allowlist avant la migration
auth-and-writes pour tous les contributeurs, migrer vers FIDO/passkey
package-lock.json change de façon inattendue ; utiliser npm ci en production
uses: actions/checkout@sha256:abc123, pas @v3
.claude/, .gemini/, .cursor/ à votre modèle de menace et au périmètre de scan de secrets
Questions fréquentes
npm v12 va-t-il stopper les futures attaques supply chain ?
Partiellement. npm v12 élimine les attaques basées sur les scripts d'installation comme Phantom Gyp et l'exfiltration postinstall, qui couvraient environ 40% des incidents du H1 2026. Il ne traite pas les prises de contrôle de compte (motif Axios, node-ipc), les détournements de pipeline (TanStack) ou les payloads d'exécution intégrés dans les modules. Les chercheurs en sécurité s'accordent à dire qu'il est nécessaire mais pas suffisant.
La sécurité de la supply chain open source s'aggrave-t-elle chaque année ?
Oui, en volume — Sonatype a compté 454 648 packages malveillants en 2025, une augmentation de 75% par rapport à 2024, et le H1 2026 est déjà en bonne voie pour dépasser ce chiffre. Mais la réponse de l'écosystème s'accélère aussi : publication par étapes npm, plafonds de tokens, blocage des scripts d'installation npm v12, et feuille de route OpenSSF SLSA sont tous des améliorations concrètes qui n'existaient pas il y a un an.
Comment l'attaquant node-ipc a-t-il pu prendre le contrôle du compte npm ?
Le compte mainteneur utilisait un domaine email (atlantis-software.net) expiré en janvier 2025. L'attaquant a ré-enregistré le domaine en mai 2026, puis déclenché une réinitialisation de mot de passe sur le compte npm — recevant l'email de réinitialisation sur le domaine désormais contrôlé. C'est pourquoi les audits d'accès des contributeurs doivent inclure la vérification que les domaines email sont toujours contrôlés par la personne concernée.
Quels credentials Miasma et node-ipc ciblaient-ils ?
Les deux campagnes ciblaient un large spectre : credentials AWS/Azure/GCP, clés privées SSH, tokens de compte de service Kubernetes, configs GitHub CLI, tokens auth npm, fichiers .netrc, mots de passe sauvegardés dans les navigateurs, paramètres Claude AI et Cursor IDE, fichiers d'état Terraform et chaînes de connexion de bases de données. Les fichiers de configuration des outils de développement IA étaient une nouvelle cible explicite dans les vagues 2 et 3 de Miasma.
Surveillez vos dépendances automatiquement
CVE OptiBot scanne vos lockfiles chaque jour et vous alerte quand une nouvelle CVE frappe un package que vous utilisez réellement — avant les attaquants. Aucun accès au code requis.
Démarrer le monitoring gratuitLectures complémentaires