PolinRider : la Corée du Nord inonde npm de packages

Un groupe lié à la Corée du Nord est en train de s'attaquer à la supply chain open source.

L'essentiel

PolinRider est une campagne de compromission de la supply chain open source attribuée à un acteur lié à la Corée du Nord. D'après The Hacker News, qui l'a détaillée début juillet 2026, elle a touché 108 packages et 162 artefacts malveillants sur quatre écosystèmes : npm, Packagist, Go modules et le Chrome Web Store. Signalée dès mars 2026 par l'équipe OpenSourceMalware, elle se rattache à l'opération « Contagious Interview », qui cible les développeurs et les chercheurs en sécurité. Les attaquants réécrivent l'historique Git, publient des packages typosquattés et compromettent des comptes de mainteneurs. Le code malveillant vole les credentials des environnements de développement et ouvre un accès à distance. Les équipes qui installent des dépendances sans lockfile, ou dont les runners CI/CD détiennent des secrets de production, sont les plus exposées. À retenir : l'ouverture d'un dépôt ou d'un projet suffit parfois à exécuter du code, et la parade passe par des installations figées et vérifiées.

Qu'est-ce que PolinRider ?

PolinRider est une campagne de compromission de dépôts et de registres de paquets, active depuis 2023 au moins selon The Hacker News. Elle injecte un chargeur JavaScript obfusqué dans des projets légitimes, puis récupère une seconde charge chiffrée. Son but est d'atteindre les environnements de build, les pipelines CI/CD et les secrets d'infrastructure.

Quels écosystèmes sont touchés ?

La campagne a publié 108 packages, pour 162 artefacts malveillants au total. Le détail par écosystème, tel que rapporté par The Hacker News :

Écosystème	Éléments malveillants rapportés
npm	19 bibliothèques
Packagist (Composer)	10 packages
Go modules	61 packages
Chrome Web Store	1 extension

Ces chiffres totalisent 91 éléments, pas 108 : la source ne précise pas l'écart. Côté GitHub, la même source compte, au 11 avril 2026, 1 951 dépôts compromis appartenant à 1 047 propriétaires. Selon Security Online, l'équipe OpenSourceMalware suit environ 1 900 dépôts actifs.

Comment les attaquants masquent-ils leur code ?

Cette fois, la technique évolue. Les attaquants utilisent :

• le rewriting d'historique Git (force pushes, commits antidatés) pour faire paraître les changements malveillants plus anciens et moins suspects ;
• des packages typosquattés ET des compromissions de comptes de mainteneurs légitimes ;
• du code qui extrait les credentials des environnements de développement et permet l'accès à distance.

Le typosquatting consiste à publier un paquet dont le nom imite celui d'une bibliothèque connue, avec une lettre changée ou un suffixe plausible, pour qu'un développeur l'installe par erreur. Ici, des paquets npm se faisaient passer pour des utilitaires d'animation Tailwind CSS, comme tailwindcss-style-animate, selon Diesec.

Les sources décrivent d'autres dissimulations : des chargeurs cachés dans des fichiers de configuration (postcss.config.mjs, next.config.mjs, vite.config.js), de faux fichiers de police .woff2, et des tâches VS Code qui s'exécutent à l'ouverture du dossier. La commande et le contrôle passent par des blockchains publiques (TRON, Aptos, BNB Smart Chain), ce qui résiste aux saisies de domaines. Les charges finales sont le RAT DEV#POPPER et le voleur OmniStealer.

Qui est derrière PolinRider, et quel lien avec Axios ?

Le groupe est lié à la campagne « Contagious Interview », une opération qui cible spécifiquement les développeurs et chercheurs en sécurité. Les attributions plus fines varient : Diesec cite Lazarus et APT37, Security Online le cluster Famous Chollima, et l'attribution reste une évaluation de recherche, sans arrestation annoncée.

Le pattern est bien rodé. Il s'inscrit dans la continuité de l'attaque Axios de mars 2026 (où le package npm le plus téléchargé au monde, 100M downloads/semaine, avait été compromis pendant 3 heures par le groupe UNC1069). TechCrunch précise que l'attaquant avait pris le compte d'un développeur principal et remplacé son adresse e-mail pour empêcher la récupération. Le mode opératoire diffère de celui de l'incident RubyGems, mais le maillon visé est le même : le registre.

Ce que ça change pour vos équipes

La supply chain open source est devenue le terrain de jeu des groupes étatiques, et on ne parle que de ce qu'on a trouvé. La surface d'attaque réelle est probablement plus large. Voici ce que nous mettons en place sur les plateformes SaaS que nous opérons :

1. Installer depuis un lockfile, sans scripts. Commitez package-lock.json, composer.lock et go.sum, puis installez avec npm ci --ignore-scripts, composer install et go mod verify. Comparez-les aux listes d'indicateurs publiées.
2. Vérifier l'intégrité et la provenance. Exigez des commits signés sur les dépôts critiques, interdisez les force pushes sur les branches protégées et lancez npm audit signatures pour contrôler signatures et attestations de provenance.
3. Surveiller le poste de développement. Relisez .vscode/tasks.json et les fichiers de configuration de build après chaque changement inattendu,. Les tâches qui s'exécutent à l'ouverture font du poste dev une cible à part entière.
4. Segmenter les runners et filtrer la sortie réseau. Un runner compromis ne doit pas pouvoir accéder à la prod. Donnez-lui des secrets à durée courte, filtrez ses connexions sortantes et cherchez dans ses logs des appels vers des RPC blockchain. Surveillez aussi les variables d'environnement exposées dans les containers (CVE Podman 2026-57231).
5. Préparer la réponse. Activez le MFA sur GitHub et sur les registres. En cas de doute, considérez l'environnement comme compromis, faites tourner les secrets depuis une machine saine et reconstruisez à partir d'un lockfile connu. Un audit automatisé de la supply chain et du CI/CD peut compléter ce dispositif.