On July 3, 2026, JFrog Security Research disclosed a cluster of six malicious npm packages masquerading as Rollup polyfill tooling and attributed the campaign to North Korea's Lazarus group, based on overlapping tactics, techniques, and procedures with prior campaigns (Source: JFrog Security Research, July 2026). The two lead packages — rollup-packages-polyfill-core and rollup-runtime-polyfill-core — copied the name, description, and README of rollup-plugin-polyfill-node, a legitimate project pulling roughly 295,000 downloads per week.
What makes this campaign a turning point is not the brandjacking — it's the execution model. The malicious code fired at import time, not install time, deliberately sidestepping npm v12's headline defense: install scripts blocked by default. Just days after the most significant security release in npm's history shipped, a state-sponsored actor demonstrated exactly how to route around it. This article breaks down the full attack chain, why every layer of the current defense stack missed it, and what actually protects you.
The Campaign at a Glance
The six packages: rollup-packages-polyfill-core and rollup-runtime-polyfill-core served as entry points. Once installed, they quietly pulled in four more — swift-parse-stream, quirky-token, react-icon-svgs, and rollup-plugin-polyfill-connect. The packages sat in the open registry for days before all six were removed (Source: Aardwolf Security / The Hacker News, July 2026).
The Deception: Brandjacking Done Properly
This was not lazy typosquatting. The counterfeit packages reproduced the real project's README almost verbatim, pointed both the repository and homepage metadata fields back to the genuine GitHub project, and — critically — included fully functional Rollup polyfill code in their entry points, with the malicious logic appended beneath it (Source: JFrog Security Research). A developer who installed the package, ran their build, and saw it work correctly had no behavioral reason to suspect anything.
The architectural detail that stands out: only the CommonJS dist/index.js entry point was backdoored. The ESM variant was left completely clean. Many automated linting and security-scanning tools analyze a package's primary import path; keeping the ESM version clean was a studied attempt to stay below that detection threshold (Source: JFrog Security Research).
The Attack Chain: Import-Time, Not Install-Time
The starting point is a Base64-encoded npm install command for swift-parse-stream (or quirky-token) concealed inside the lead packages. When the developer's code first imports the fake polyfill, the hidden logic decodes and runs that command, then loads the second-stage package (Source: The Hacker News, July 3, 2026).
Three properties of this chain defeat the current defense stack:
1. No install scripts. npm v12 blocks preinstall/postinstall by default — the change that neutralized Phantom Gyp and the classic postinstall stealer pattern. This campaign never used them. The code executes when your application (or your build tool) imports the module, a stage no package manager can block without breaking JavaScript itself (Source: JFrog Security Research / TechTimes, July 2026).
2. Remote payloads. The actual malicious logic lived at a remote URL rather than inside the published packages. It was absent from the package files themselves — and therefore invisible to static registry analysis and signature-based scanners (Source: JFrog Security Research).
3. Environment awareness. Before doing anything, the JavaScript ran checks to avoid executing inside cloud development environments, sandboxes, serverless runtimes, and known analysis infrastructure — the exact places security vendors detonate suspicious packages (Source: The Hacker News, July 2026).
Why this matters
The npm v12 threat model assumed the danger window was npm install. This campaign proves the danger window is now require() — and that the ecosystem's newest default protections were factored into the attacker's design before most teams had even migrated to them.
The Payload: Stealer Plus Full Remote Access
Once the later stages run, the attacker gains both collection and control capabilities (Source: JFrog Security Research / Aardwolf Security):
Credential theft: the filesystem is searched for SSH keys, AWS and Azure credentials, npm tokens, and Git logins. Anything in a project's .env file is collected. Editor history is read directly out of VS Code, Cursor, and Windsurf — continuing the 2026 trend of AI-assisted development tools becoming primary targets.
Clipboard monitoring: a background monitor captures anything the developer copies — API tokens, wallet addresses, seed phrases. This is consistent with Lazarus's long-standing focus on cryptocurrency theft.
Full RAT: the remote access component can run arbitrary commands, open terminals, start SSH sessions, capture screenshots, and control input devices. This is not a smash-and-grab stealer — it's persistent, interactive access to a developer workstation.
The Bigger Picture: Lazarus's Industrialized npm Operation
This cluster is one operation in a sustained campaign. Group-IB has linked more than 800 packages to Lazarus, 97% of them concentrated on npm (Source: Group-IB, 2026). The 2026 timeline alone is dense:
February 2026: Operation Marstech Mayhem — the Marstech1 implant distributed via manipulated open-source repositories, scanning for Exodus, Atomic, and MetaMask wallets across Windows, macOS, and Linux (Source: SecurityScorecard).
April 2026: a sustained DPRK npm campaign involving 108 malicious packages across 261 versions, delivering the BeaverTail and OtterCookie malware families. SecurityScorecard's STRIKE team confirmed 233 victims across the U.S., Europe, and Asia (Source: SecurityScorecard STRIKE, 2026).
June 17, 2026: the Mastra supply chain attack — Microsoft attributed to Sapphire Sleet the publication of 141 packages in a 45-minute window, all carrying the malicious dependency easy-day-js, a typosquat of the dayjs date library (Source: Microsoft / SecurityWeek, June 2026).
July 2026: the Rollup polyfill cluster covered here — the first major DPRK campaign engineered specifically around npm v12's new defaults.
For the H1 2026 context — Axios, TanStack, node-ipc, and the Miasma worm waves — see our full H1 2026 supply chain retrospective.
Why Every Defense Layer Missed It
It's worth being precise about which defenses failed and why, because the answer determines what you should change:
npm v12 script blocking: bypassed by design — no install scripts were used. Execution happens at import time.
Static registry scanning: bypassed — the malicious logic was fetched from a remote URL and never present in the published tarball.
Import-path linting and automated scanners: bypassed — the ESM entry point was clean; only the CommonJS path carried the backdoor.
Sandbox detonation: bypassed — environment checks prevented execution inside analysis infrastructure, sandboxes, and serverless runtimes.
Human review: defeated by working polyfill code, a verbatim README, and metadata pointing at the real GitHub repository.
What would have caught it: the packages were days old with negligible download history, published by accounts with no connection to the real Rollup organization. Package age, publisher identity, and dependency-tree changes are the signals that survive this attack class — which is exactly why lockfile diff review and dependency inventory monitoring matter more than ever.
Defense Checklist: What Actually Works Against Import-Time Attacks
Import-time attack baseline — July 2026
rollup-plugin-polyfill-node is real; rollup-packages-polyfill-core was not. Copy names from the official docs or GitHub, never from search results
minimumReleaseAge or an equivalent quarantine window blocks days-old packages from entering your tree
npm install of swift-parse-stream modifies your dependency state; fail builds on unexpected additions
.env, SSH keys, and cloud credentials
Frequently Asked Questions
Am I affected by the Lazarus Rollup polyfill attack?
Check your dependency tree and lockfiles for any of the six packages: rollup-packages-polyfill-core, rollup-runtime-polyfill-core, swift-parse-stream, quirky-token, react-icon-svgs, and rollup-plugin-polyfill-connect. If any appear, treat the workstation as compromised: rotate SSH keys, cloud credentials, npm tokens, and Git credentials, and assume clipboard contents (including wallet data) were captured. The legitimate rollup-plugin-polyfill-node package is safe.
Does npm v12 protect against this attack?
No. npm v12 blocks install scripts by default, but this campaign executed its malicious logic at import time — when your code loads the module — which no package manager can block. npm v12 remains valuable against the roughly 40% of H1 2026 incidents that relied on install scripts, but import-time execution is now the demonstrated workaround.
Why didn't security scanners flag the packages?
Three reasons: the actual malicious code was hosted at a remote URL and absent from the published package files; the ESM entry point — the path most automated tools analyze — was left completely clean; and runtime environment checks prevented the payload from executing inside sandboxes and analysis infrastructure where vendors detonate suspicious packages.
How is this different from typosquatting?
Typosquatting relies on typing mistakes (dayjs vs easy-day-js). Brandjacking, as used here, creates plausible-sounding sibling names of a real project and clones its README, metadata, and functionality. The packages work as advertised, so nothing breaks and suspicion never triggers. It targets developers who find packages through search rather than official documentation.
What is Lazarus after with these campaigns?
Two things: cryptocurrency and access. The clipboard monitor captures wallet addresses and seed phrases — consistent with DPRK's documented crypto-theft funding operations. The credential harvesting (SSH, cloud, npm tokens) and full RAT capability also enable follow-on supply chain attacks: a stolen npm token from one victim becomes the publishing vector for the next campaign.
Monitor your dependencies automatically
CVE OptiBot scans your lockfiles daily and alerts you when a malicious or vulnerable package appears in a project you actually ship — before attackers reach your credentials. No code access required.
Start free monitoringFurther reading
Le 3 juillet 2026, JFrog Security Research a divulgué un cluster de six packages npm malveillants se faisant passer pour de l'outillage polyfill Rollup, et a attribué la campagne au groupe Lazarus (Corée du Nord) sur la base de recoupements de tactiques, techniques et procédures avec des campagnes antérieures (Source : JFrog Security Research, juillet 2026). Les deux packages principaux — rollup-packages-polyfill-core et rollup-runtime-polyfill-core — copiaient le nom, la description et le README de rollup-plugin-polyfill-node, un projet légitime totalisant environ 295 000 téléchargements par semaine.
Ce qui fait de cette campagne un tournant, ce n'est pas le brandjacking — c'est le modèle d'exécution. Le code malveillant se déclenchait à l'import, pas à l'installation, contournant délibérément la défense phare de npm v12 : le blocage par défaut des scripts d'installation. Quelques jours seulement après la release de sécurité la plus significative de l'histoire de npm, un acteur étatique a démontré exactement comment la contourner. Cet article décompose la chaîne d'attaque complète, explique pourquoi chaque couche de défense actuelle l'a manquée, et ce qui vous protège réellement.
La campagne en un coup d'œil
Les six packages : rollup-packages-polyfill-core et rollup-runtime-polyfill-core servaient de points d'entrée. Une fois installés, ils tiraient discrètement quatre autres packages — swift-parse-stream, quirky-token, react-icon-svgs et rollup-plugin-polyfill-connect. Les packages sont restés plusieurs jours dans le registre public avant que les six ne soient retirés (Source : Aardwolf Security / The Hacker News, juillet 2026).
La tromperie : du brandjacking bien exécuté
Ce n'était pas du typosquatting paresseux. Les packages contrefaits reproduisaient le README du vrai projet quasiment mot pour mot, faisaient pointer les champs de métadonnées repository et homepage vers le véritable projet GitHub, et — point critique — incluaient du code polyfill Rollup pleinement fonctionnel dans leurs points d'entrée, avec la logique malveillante ajoutée en dessous (Source : JFrog Security Research). Un développeur qui installait le package, lançait son build et le voyait fonctionner correctement n'avait aucune raison comportementale de suspecter quoi que ce soit.
Le détail architectural qui frappe : seul le point d'entrée CommonJS dist/index.js était backdooré. La variante ESM était laissée totalement propre. De nombreux outils automatisés de linting et de scan de sécurité analysent le chemin d'import principal d'un package ; garder la version ESM propre était une tentative étudiée de rester sous ce seuil de détection (Source : JFrog Security Research).
La chaîne d'attaque : à l'import, pas à l'installation
Le point de départ est une commande npm install encodée en Base64 pour swift-parse-stream (ou quirky-token), dissimulée dans les packages principaux. Quand le code du développeur importe le faux polyfill pour la première fois, la logique cachée décode et exécute cette commande, puis charge le package de deuxième étage (Source : The Hacker News, 3 juillet 2026).
Trois propriétés de cette chaîne mettent en échec la pile de défense actuelle :
1. Aucun script d'installation. npm v12 bloque preinstall/postinstall par défaut — le changement qui a neutralisé Phantom Gyp et le pattern classique du stealer postinstall. Cette campagne ne les a jamais utilisés. Le code s'exécute quand votre application (ou votre outil de build) importe le module, une étape qu'aucun gestionnaire de packages ne peut bloquer sans casser JavaScript lui-même (Source : JFrog Security Research / TechTimes, juillet 2026).
2. Payloads distants. La véritable logique malveillante résidait à une URL distante plutôt que dans les packages publiés. Elle était absente des fichiers du package — et donc invisible pour l'analyse statique du registre et les scanners à signatures (Source : JFrog Security Research).
3. Conscience de l'environnement. Avant toute action, le JavaScript exécutait des vérifications pour éviter de s'exécuter dans les environnements de développement cloud, les sandboxes, les runtimes serverless et les infrastructures d'analyse connues — exactement les endroits où les éditeurs de sécurité font détoner les packages suspects (Source : The Hacker News, juillet 2026).
Pourquoi c'est important
Le modèle de menace de npm v12 supposait que la fenêtre de danger était npm install. Cette campagne prouve que la fenêtre de danger est désormais require() — et que les toutes nouvelles protections par défaut de l'écosystème étaient intégrées dans le design de l'attaquant avant même que la plupart des équipes n'aient migré.
Le payload : stealer plus accès distant complet
Une fois les étapes suivantes exécutées, l'attaquant obtient à la fois des capacités de collecte et de contrôle (Source : JFrog Security Research / Aardwolf Security) :
Vol de credentials : le système de fichiers est fouillé à la recherche de clés SSH, de credentials AWS et Azure, de tokens npm et d'identifiants Git. Tout ce qui se trouve dans le fichier .env d'un projet est collecté. L'historique des éditeurs est lu directement depuis VS Code, Cursor et Windsurf — dans la continuité de la tendance 2026 où les outils de développement assistés par IA deviennent des cibles prioritaires.
Surveillance du presse-papiers : un moniteur en arrière-plan capture tout ce que le développeur copie — tokens d'API, adresses de wallets, seed phrases. C'est cohérent avec la focalisation historique de Lazarus sur le vol de cryptomonnaies.
RAT complet : le composant d'accès distant peut exécuter des commandes arbitraires, ouvrir des terminaux, démarrer des sessions SSH, capturer des captures d'écran et contrôler les périphériques d'entrée. Ce n'est pas un stealer opportuniste — c'est un accès persistant et interactif à un poste de développeur.
Le contexte : l'opération npm industrialisée de Lazarus
Ce cluster n'est qu'une opération dans une campagne soutenue. Group-IB a lié plus de 800 packages à Lazarus, dont 97% concentrés sur npm (Source : Group-IB, 2026). La chronologie 2026 à elle seule est dense :
Février 2026 : Operation Marstech Mayhem — l'implant Marstech1 distribué via des dépôts open source manipulés, scannant les wallets Exodus, Atomic et MetaMask sous Windows, macOS et Linux (Source : SecurityScorecard).
Avril 2026 : une campagne npm DPRK soutenue impliquant 108 packages malveillants sur 261 versions, distribuant les familles de malware BeaverTail et OtterCookie. L'équipe STRIKE de SecurityScorecard a confirmé 233 victimes aux États-Unis, en Europe et en Asie (Source : SecurityScorecard STRIKE, 2026).
17 juin 2026 : l'attaque supply chain Mastra — Microsoft a attribué à Sapphire Sleet la publication de 141 packages dans une fenêtre de 45 minutes, tous porteurs de la dépendance malveillante easy-day-js, un typosquat de la bibliothèque de dates dayjs (Source : Microsoft / SecurityWeek, juin 2026).
Juillet 2026 : le cluster Rollup polyfill couvert ici — la première campagne DPRK majeure conçue spécifiquement autour des nouveaux défauts de npm v12.
Pour le contexte H1 2026 — Axios, TanStack, node-ipc et les vagues du ver Miasma — consultez notre rétrospective complète supply chain H1 2026.
Pourquoi chaque couche de défense l'a manquée
Il faut être précis sur les défenses qui ont échoué et pourquoi, car la réponse détermine ce que vous devez changer :
Blocage des scripts npm v12 : contourné par design — aucun script d'installation utilisé. L'exécution se produit à l'import.
Scan statique du registre : contourné — la logique malveillante était récupérée depuis une URL distante et jamais présente dans le tarball publié.
Linting du chemin d'import et scanners automatisés : contournés — le point d'entrée ESM était propre ; seul le chemin CommonJS portait la backdoor.
Détonation en sandbox : contournée — les vérifications d'environnement empêchaient l'exécution dans les infrastructures d'analyse, sandboxes et runtimes serverless.
Revue humaine : déjouée par du code polyfill fonctionnel, un README copié mot pour mot et des métadonnées pointant vers le vrai dépôt GitHub.
Ce qui l'aurait détectée : les packages n'avaient que quelques jours d'existence, un historique de téléchargements négligeable, et étaient publiés par des comptes sans lien avec la véritable organisation Rollup. L'âge du package, l'identité du publieur et les changements dans l'arbre de dépendances sont les signaux qui résistent à cette classe d'attaque — c'est exactement pourquoi la revue des diffs de lockfile et le monitoring de l'inventaire de dépendances comptent plus que jamais.
Checklist de défense : ce qui marche vraiment contre les attaques à l'import
Baseline attaques à l'import — juillet 2026
rollup-plugin-polyfill-node est réel ; rollup-packages-polyfill-core ne l'était pas. Copiez les noms depuis la doc officielle ou GitHub, jamais depuis les résultats de recherche
minimumReleaseAge de pnpm ou une fenêtre de quarantaine équivalente bloque les packages vieux de quelques jours
npm install de deuxième étage de swift-parse-stream modifie l'état de vos dépendances ; faites échouer les builds sur les ajouts inattendus
.env, clés SSH et credentials cloud
Questions fréquentes
Suis-je concerné par l'attaque Lazarus Rollup polyfill ?
Vérifiez votre arbre de dépendances et vos lockfiles pour les six packages : rollup-packages-polyfill-core, rollup-runtime-polyfill-core, swift-parse-stream, quirky-token, react-icon-svgs et rollup-plugin-polyfill-connect. Si l'un d'eux apparaît, considérez le poste comme compromis : faites tourner clés SSH, credentials cloud, tokens npm et identifiants Git, et partez du principe que le contenu du presse-papiers (y compris les données de wallets) a été capturé. Le package légitime rollup-plugin-polyfill-node est sûr.
npm v12 protège-t-il contre cette attaque ?
Non. npm v12 bloque les scripts d'installation par défaut, mais cette campagne exécutait sa logique malveillante à l'import — quand votre code charge le module — ce qu'aucun gestionnaire de packages ne peut bloquer. npm v12 reste précieux contre les ~40% d'incidents du H1 2026 qui reposaient sur les scripts d'installation, mais l'exécution à l'import est désormais le contournement démontré.
Pourquoi les scanners de sécurité n'ont-ils pas signalé les packages ?
Trois raisons : le code malveillant réel était hébergé à une URL distante et absent des fichiers du package publié ; le point d'entrée ESM — le chemin que la plupart des outils automatisés analysent — était laissé totalement propre ; et des vérifications d'environnement à l'exécution empêchaient le payload de se déclencher dans les sandboxes et infrastructures d'analyse où les éditeurs font détoner les packages suspects.
En quoi est-ce différent du typosquatting ?
Le typosquatting mise sur les fautes de frappe (dayjs vs easy-day-js). Le brandjacking, utilisé ici, crée des noms frères plausibles d'un vrai projet et clone son README, ses métadonnées et sa fonctionnalité. Les packages fonctionnent comme annoncé, donc rien ne casse et la suspicion ne se déclenche jamais. Il cible les développeurs qui trouvent leurs packages via la recherche plutôt que la documentation officielle.
Que cherche Lazarus avec ces campagnes ?
Deux choses : des cryptomonnaies et des accès. Le moniteur de presse-papiers capture adresses de wallets et seed phrases — cohérent avec les opérations documentées de financement par vol de crypto de la DPRK. La récolte de credentials (SSH, cloud, tokens npm) et la capacité RAT complète permettent aussi des attaques supply chain en cascade : un token npm volé chez une victime devient le vecteur de publication de la campagne suivante.
Surveillez vos dépendances automatiquement
CVE OptiBot scanne vos lockfiles chaque jour et vous alerte quand un package malveillant ou vulnérable apparaît dans un projet que vous livrez réellement — avant que les attaquants n'atteignent vos credentials. Aucun accès au code requis.
Démarrer le monitoring gratuitLectures complémentaires