In early July 2026, Socket's Threat Research Team disclosed PolinRider, a North Korea-linked supply chain campaign that planted 162 malicious release artifacts — corresponding to 108 unique packages and extensions — across four ecosystems at once: 19 npm libraries, 10 Composer packages on Packagist, 61 Go modules, and one Google Chrome extension (Source: Socket Threat Research / The Hacker News, July 2026). The campaign is attributed to the Contagious Interview activity cluster (also tracked as Famous Chollima), active since at least 2023 and best known for weaponizing fake job interviews to trick developers into running malicious code.
PolinRider matters for three reasons. First, it confirms that DPRK operators have moved decisively beyond npm: Go modules now make up the majority of the malicious artifacts, and Packagist — the PHP/Composer registry — is squarely in scope. Second, the payload delivery uses blockchain RPC infrastructure as command-and-control, making takedowns nearly impossible. Third, the campaign merges with TaskJacker, a cluster that plants malicious VS Code task files that execute the moment you open a folder in your IDE. This article breaks down the full attack chain and what actually protects you.
The Campaign at a Glance
The ecosystem breakdown is the headline. Of the 108 packages, 61 are Go modules — more than three times the npm count. For years, defenders treated npm as the primary battlefield for state-sponsored package attacks. PolinRider demonstrates that the same playbook — plausible package names, cloned READMEs, hidden loaders — now runs against Go and PHP developers with equal effort, while most of those ecosystems have far less malware-scanning tooling deployed.
What Was Published: Package Names and Lures
On the npm side, Socket identified packages posing as Tailwind CSS utilities, including tailwindcss-style-animate, tailwind-mainanimation, and tailwind-autoanimation — names engineered to surface when developers search for animation plugins like the legitimate tailwindcss-animate. On Packagist, malicious Composer packages were published under the sevenspan namespace, impersonating a real software company's open source presence (Source: Socket Threat Research, July 2026).
The lure strategy follows the established Contagious Interview pattern: targets are approached with attractive job offers or coding assessments and asked to clone and run a "test project" — which pulls the malicious dependencies. But PolinRider adds a passive channel: the packages sit in public registries, waiting for organic installs by developers who find them through search. Both channels feed the same loader.
A detail that should worry anyone who audits dependencies by looking at GitHub: the operators used Git history rewriting — force pushes and anti-dated commits — to make malicious changes appear months old and buried under legitimate-looking history. The repository landing page, commit dates, and contribution graph are all unreliable indicators for these packages (Source: The Hacker News, July 2026).
The Attack Chain: Blockchain C2 and eval()
The core of PolinRider is an obfuscated JavaScript loader hidden inside the packages. Once running, it follows a four-stage chain (Source: Socket Threat Research, July 2026):
eval(), entirely in memory.
Because the loader design is generic, Socket warns the campaign should be treated as capable of delivering any additional malware, not just the two families observed so far. And because the actual malicious logic lives off-registry, the published package files often look mostly benign — the same scanner-evasion property we analyzed in the Lazarus Rollup polyfill campaign disclosed the same week.
Config-File Injection: Persistence Where Nobody Looks
One of PolinRider's most insidious behaviors targets the config files every JavaScript project carries. The malware searches the infected project for files such as postcss.config.mjs, tailwind.config.js, and eslint.config.mjs — and if found, silently injects additional malicious JavaScript into them (Source: Socket Threat Research, July 2026).
This is a persistence mechanism perfectly adapted to the developer workflow. Config files are executed by build tooling on virtually every dev server start, lint run, and production build. They are rarely reviewed after initial setup, routinely committed to Git, and thus propagate the infection to every teammate who pulls the repo — and to CI/CD runners that build it. Removing the malicious package is not enough: if the config injection already happened, the project remains infected.
TaskJacker: Your IDE as the Execution Trigger
PolinRider merges with a second cluster tracked as TaskJacker, first detailed by eSentire in March 2026, which drops malicious VS Code task files into GitHub users' existing repositories. The planted .vscode/tasks.json uses the "runOn": "folderOpen" option — meaning arbitrary code executes the moment the folder is opened as a workspace in VS Code or Cursor, with no build, no install, and no interaction beyond opening the project (Source: The Hacker News / eSentire, 2026).
As of April 11, 2026, this activity had compromised 1,951 public GitHub repositories belonging to 1,047 unique owners (Source: The Hacker News, July 2026). The technique spread fast beyond DPRK operators: security researchers documented it becoming generic crimeware within roughly eight weeks of public documentation. If your threat model still assumes code only runs when you execute it, VS Code automatic tasks break that assumption — the same IDE-as-attack-surface trend we covered in our Miasma Wave 3 analysis and AI developer tools supply chain guide.
Why Existing Defenses Missed It
npm v12's install-script blocking doesn't apply. The npm packages in this campaign execute through imports, injected config files, and VS Code tasks — none of which are install scripts. npm v12, which ships this month blocking install scripts by default (Source: TechTimes, July 8, 2026), addresses an important attack class, but PolinRider was designed around it from day one.
Go and Composer have no install-script debate at all. Go modules execute at build/test time; Composer packages execute via autoloaders and plugins. The 71 combined Go and Packagist artifacts faced even fewer automated malware checks than npm's.
Registry scanners can't see the payload. The second stage lives on blockchain infrastructure, retrieved and decrypted at runtime. Static analysis of the published artifact sees an obfuscated loader that contacts "public RPC endpoints" — traffic that blends in for any Web3-adjacent project.
Manual review is defeated by Git forgery. Anti-dated commits and force-pushed history mean the standard "check the repo, look at recent commits" heuristic actively misleads reviewers.
Detection and Response Checklist
The Bigger Picture: One Playbook, Every Registry
PolinRider is the clearest signal yet that the npm-centric view of supply chain security is obsolete. The same operators, the same loader architecture, and the same social engineering now run concurrently against JavaScript, PHP, and Go developers — plus the browser extension channel. Contagious Interview has been iterating since 2023, and each 2026 wave (Fake Font, Malicious Dictionary, TaskJacker, now PolinRider) has added an execution vector that sidesteps the newest defense.
For teams, the practical conclusion is that defense must be ecosystem-agnostic and lockfile-driven: a continuously monitored inventory of everything you actually install, across every language in your stack, checked against malicious-package intelligence — because the next wave will not announce which registry it targets.
Frequently Asked Questions
What is the PolinRider supply chain attack?
PolinRider is a North Korea-linked campaign disclosed by Socket in July 2026 that published 162 malicious release artifacts — 108 unique packages and extensions — across npm (19), Packagist (10), Go modules (61), and the Chrome Web Store (1). The packages carry an obfuscated JavaScript loader that fetches encrypted payloads via blockchain RPC infrastructure and deploys credential- and wallet-stealing malware such as DEV#POPPER and OmniStealer.
Am I affected by PolinRider?
Check your lockfiles (package-lock.json, composer.lock, go.sum) against Socket's published indicator list — known examples include tailwindcss-style-animate, tailwind-mainanimation, tailwind-autoanimation on npm and sevenspan-namespace packages on Packagist. Also diff your project config files (postcss, tailwind, eslint configs) for injected code and inspect .vscode/tasks.json for folderOpen tasks. If anything matches, treat the machine as compromised and rotate all secrets from a clean device.
Does npm v12 protect against PolinRider?
Only marginally. npm v12 blocks install scripts by default, but PolinRider executes through module imports, code injected into build config files, and VS Code automatic tasks — none of which npm controls. And 71 of the 108 packages target Go and Packagist, where npm's protections are irrelevant by definition.
Why does the malware use blockchain infrastructure as C2?
Resilience and stealth. Payloads staged via TRON, Aptos, and BNB Smart Chain RPC services cannot be taken down like a rented server, and requests to well-known public blockchain endpoints blend into normal traffic — especially in Web3-adjacent projects. It also keeps the malicious second stage out of the published package, defeating registry-side static scanning.
How do I stop VS Code tasks from running automatically?
Set task.allowAutomaticTasks to "off" in VS Code (and Cursor) settings, ideally enforced via managed settings across the team. VS Code prompts before running automatic tasks in untrusted workspaces, but the TaskJacker cluster specifically plants tasks in repos you already trust — your own. Reviewing .vscode/ contents in pull requests should be standard practice.
Is this related to the Lazarus Rollup polyfill attack?
They are distinct campaigns from the same broader DPRK offensive ecosystem, disclosed the same week. The Rollup polyfill cluster (JFrog, July 3) used brandjacked npm packages with import-time execution; PolinRider (Socket) spans four ecosystems with blockchain C2 and IDE task hijacking. Together they show state actors systematically engineering around each new defense — including npm v12.
Monitor your dependencies automatically
CVE OptiBot scans your lockfiles daily — npm, Composer, Go and more — and alerts you when a malicious or vulnerable package appears in a project you actually ship. No code access required.
Start free monitoringFurther reading
Début juillet 2026, l'équipe Threat Research de Socket a divulgué PolinRider, une campagne supply chain liée à la Corée du Nord ayant publié 162 artefacts de release malveillants — correspondant à 108 packages et extensions uniques — sur quatre écosystèmes à la fois : 19 bibliothèques npm, 10 packages Composer sur Packagist, 61 modules Go et une extension Google Chrome (Source : Socket Threat Research / The Hacker News, juillet 2026). La campagne est attribuée au cluster d'activité Contagious Interview (aussi suivi sous le nom Famous Chollima), actif depuis au moins 2023 et connu pour transformer de faux entretiens d'embauche en vecteur d'exécution de code malveillant.
PolinRider compte pour trois raisons. D'abord, elle confirme que les opérateurs nord-coréens ont largement dépassé npm : les modules Go représentent la majorité des artefacts malveillants, et Packagist — le registre PHP/Composer — est désormais pleinement ciblé. Ensuite, la livraison du payload utilise l'infrastructure RPC blockchain comme command-and-control, rendant tout takedown quasi impossible. Enfin, la campagne fusionne avec TaskJacker, un cluster qui dépose des fichiers de tâches VS Code malveillants exécutés dès l'ouverture d'un dossier dans votre IDE. Cet article décortique la chaîne d'attaque complète et ce qui vous protège réellement.
La campagne en un coup d'œil
La répartition par écosystème est l'information clé. Sur les 108 packages, 61 sont des modules Go — plus de trois fois le nombre de packages npm. Pendant des années, les défenseurs ont considéré npm comme le champ de bataille principal des attaques de packages étatiques. PolinRider démontre que le même playbook — noms de packages plausibles, README clonés, loaders cachés — s'applique désormais aux développeurs Go et PHP avec le même effort, alors que ces écosystèmes disposent de bien moins d'outillage de détection de malware.
Ce qui a été publié : noms de packages et leurres
Côté npm, Socket a identifié des packages se faisant passer pour des utilitaires Tailwind CSS, dont tailwindcss-style-animate, tailwind-mainanimation et tailwind-autoanimation — des noms conçus pour apparaître quand un développeur cherche un plugin d'animation comme le légitime tailwindcss-animate. Sur Packagist, des packages Composer malveillants ont été publiés sous le namespace sevenspan, usurpant la présence open source d'une vraie société (Source : Socket Threat Research, juillet 2026).
La stratégie de leurre suit le schéma établi de Contagious Interview : les cibles reçoivent des offres d'emploi attractives ou des tests techniques, et sont invitées à cloner et exécuter un « projet de test » — qui tire les dépendances malveillantes. Mais PolinRider ajoute un canal passif : les packages restent dans les registres publics, en attente d'installations organiques par des développeurs qui les trouvent via la recherche. Les deux canaux alimentent le même loader.
Un détail qui devrait inquiéter quiconque audite ses dépendances en regardant GitHub : les opérateurs ont utilisé la réécriture d'historique Git — force pushes et commits antidatés — pour faire paraître les changements malveillants vieux de plusieurs mois, enfouis sous un historique d'apparence légitime. La page du dépôt, les dates de commit et le graphe de contributions sont des indicateurs non fiables pour ces packages (Source : The Hacker News, juillet 2026).
La chaîne d'attaque : C2 blockchain et eval()
Le cœur de PolinRider est un loader JavaScript obfusqué caché dans les packages. Une fois lancé, il suit une chaîne en quatre étapes (Source : Socket Threat Research, juillet 2026) :
eval(), entièrement en mémoire.
Le design du loader étant générique, Socket avertit que la campagne doit être considérée comme capable de livrer n'importe quel malware supplémentaire, pas seulement les deux familles observées. Et comme la logique malveillante vit hors du registre, les fichiers publiés paraissent largement bénins — la même propriété d'évasion des scanners que nous avons analysée dans la campagne Lazarus Rollup polyfill divulguée la même semaine.
Injection dans les fichiers de config : la persistance là où personne ne regarde
L'un des comportements les plus insidieux de PolinRider cible les fichiers de configuration présents dans tout projet JavaScript. Le malware cherche dans le projet infecté des fichiers comme postcss.config.mjs, tailwind.config.js et eslint.config.mjs — et s'ils existent, y injecte silencieusement du JavaScript malveillant supplémentaire (Source : Socket Threat Research, juillet 2026).
C'est un mécanisme de persistance parfaitement adapté au workflow développeur. Les fichiers de config sont exécutés par l'outillage de build à quasiment chaque démarrage de dev server, chaque lint et chaque build de production. Ils sont rarement relus après le setup initial, systématiquement commités dans Git, et propagent donc l'infection à chaque coéquipier qui pull le repo — et aux runners CI/CD qui le buildent. Supprimer le package malveillant ne suffit pas : si l'injection de config a déjà eu lieu, le projet reste infecté.
TaskJacker : votre IDE comme déclencheur d'exécution
PolinRider fusionne avec un second cluster suivi sous le nom TaskJacker, détaillé par eSentire en mars 2026, qui dépose des fichiers de tâches VS Code malveillants dans les dépôts GitHub existants des utilisateurs. Le .vscode/tasks.json planté utilise l'option "runOn": "folderOpen" — du code arbitraire s'exécute donc dès l'ouverture du dossier comme workspace dans VS Code ou Cursor, sans build, sans install, sans autre interaction que l'ouverture du projet (Source : The Hacker News / eSentire, 2026).
Au 11 avril 2026, cette activité avait compromis 1 951 dépôts GitHub publics appartenant à 1 047 propriétaires uniques (Source : The Hacker News, juillet 2026). La technique s'est diffusée bien au-delà des opérateurs nord-coréens : les chercheurs ont documenté sa transformation en crimeware générique en environ huit semaines après sa documentation publique. Si votre modèle de menace suppose encore que le code ne s'exécute que quand vous le lancez, les tâches automatiques VS Code brisent cette hypothèse — la même tendance « l'IDE comme surface d'attaque » que nous couvrions dans notre analyse Miasma Wave 3 et notre guide supply chain des outils IA.
Pourquoi les défenses existantes sont passées à côté
Le blocage des scripts d'installation de npm v12 ne s'applique pas. Les packages npm de cette campagne s'exécutent via les imports, les fichiers de config injectés et les tâches VS Code — rien de tout cela n'est un script d'installation. npm v12, qui sort ce mois-ci avec les scripts d'installation bloqués par défaut (Source : TechTimes, 8 juillet 2026), traite une classe d'attaque importante, mais PolinRider a été conçue pour la contourner dès le premier jour.
Go et Composer n'ont même pas ce débat. Les modules Go s'exécutent au build/test ; les packages Composer via les autoloaders et plugins. Les 71 artefacts Go et Packagist combinés font face à encore moins de contrôles automatisés que npm.
Les scanners de registre ne voient pas le payload. Le second étage vit sur l'infrastructure blockchain, récupéré et déchiffré à l'exécution. L'analyse statique de l'artefact publié voit un loader obfusqué qui contacte des « endpoints RPC publics » — un trafic banal pour tout projet proche du Web3.
La revue manuelle est vaincue par la falsification Git. Les commits antidatés et l'historique force-pushé rendent trompeuse l'heuristique classique « regarder le repo et les commits récents ».
Checklist de détection et de réponse
La vue d'ensemble : un playbook, tous les registres
PolinRider est le signal le plus clair à ce jour que la vision npm-centrée de la sécurité supply chain est obsolète. Les mêmes opérateurs, la même architecture de loader et le même social engineering tournent désormais simultanément contre les développeurs JavaScript, PHP et Go — plus le canal des extensions navigateur. Contagious Interview itère depuis 2023, et chaque vague 2026 (Fake Font, Malicious Dictionary, TaskJacker, maintenant PolinRider) a ajouté un vecteur d'exécution qui contourne la défense la plus récente.
Pour les équipes, la conclusion pratique est que la défense doit être agnostique de l'écosystème et pilotée par les lockfiles : un inventaire surveillé en continu de tout ce que vous installez réellement, dans chaque langage de votre stack, confronté au renseignement sur les packages malveillants — car la prochaine vague n'annoncera pas quel registre elle cible.
Questions fréquentes
Qu'est-ce que l'attaque supply chain PolinRider ?
PolinRider est une campagne liée à la Corée du Nord divulguée par Socket en juillet 2026, qui a publié 162 artefacts de release malveillants — 108 packages et extensions uniques — sur npm (19), Packagist (10), les modules Go (61) et le Chrome Web Store (1). Les packages embarquent un loader JavaScript obfusqué qui récupère des payloads chiffrés via l'infrastructure RPC blockchain et déploie des malwares voleurs de credentials et de wallets comme DEV#POPPER et OmniStealer.
Suis-je affecté par PolinRider ?
Vérifiez vos lockfiles (package-lock.json, composer.lock, go.sum) contre la liste d'indicateurs publiée par Socket — exemples connus : tailwindcss-style-animate, tailwind-mainanimation, tailwind-autoanimation sur npm et les packages du namespace sevenspan sur Packagist. Diffez aussi vos fichiers de config (postcss, tailwind, eslint) à la recherche de code injecté et inspectez .vscode/tasks.json pour des tâches folderOpen. En cas de correspondance, traitez la machine comme compromise et faites tourner tous les secrets depuis un appareil propre.
npm v12 protège-t-il contre PolinRider ?
Marginalement seulement. npm v12 bloque les scripts d'installation par défaut, mais PolinRider s'exécute via les imports de modules, le code injecté dans les fichiers de config de build et les tâches automatiques VS Code — rien que npm ne contrôle. Et 71 des 108 packages ciblent Go et Packagist, où les protections npm sont par définition sans effet.
Pourquoi le malware utilise-t-il la blockchain comme C2 ?
Résilience et discrétion. Des payloads stockés via les services RPC de TRON, Aptos et BNB Smart Chain ne peuvent pas être démantelés comme un serveur loué, et les requêtes vers des endpoints blockchain publics connus se fondent dans le trafic normal — surtout dans les projets proches du Web3. Cela garde aussi le second étage malveillant hors du package publié, ce qui neutralise l'analyse statique côté registre.
Comment empêcher les tâches VS Code de s'exécuter automatiquement ?
Réglez task.allowAutomaticTasks sur « off » dans les paramètres de VS Code (et Cursor), idéalement via des paramètres managés pour toute l'équipe. VS Code demande confirmation avant d'exécuter des tâches automatiques dans les workspaces non fiables, mais le cluster TaskJacker plante précisément ses tâches dans des repos que vous trustez déjà — les vôtres. La revue du contenu de .vscode/ dans les pull requests devrait être une pratique standard.
Est-ce lié à l'attaque Lazarus Rollup polyfill ?
Ce sont des campagnes distinctes issues du même écosystème offensif nord-coréen, divulguées la même semaine. Le cluster Rollup polyfill (JFrog, 3 juillet) utilisait des packages npm brandjackés avec exécution à l'import ; PolinRider (Socket) couvre quatre écosystèmes avec C2 blockchain et détournement de tâches IDE. Ensemble, elles montrent des acteurs étatiques contournant systématiquement chaque nouvelle défense — y compris npm v12.
Surveillez vos dépendances automatiquement
CVE OptiBot scanne vos lockfiles chaque jour — npm, Composer, Go et plus — et vous alerte quand un package malveillant ou vulnérable apparaît dans un projet que vous livrez réellement. Aucun accès à votre code requis.
Démarrer le monitoring gratuitPour aller plus loin