MÀJ du 12 juin : quand j'ai publié cet article, on en était à 400 paquets vérolés. Sauf que le chiffre n'a pas arrêté de grimper dans la journée. Quelques heures plus tard on parlait de 900, puis en fin de journée la liste recensait déjà 1579 paquets touchés, et les devs d'Arch précisent eux-mêmes que cette liste contient "beaucoup, mais pas tous" les paquets concernés. Bref, le décompte bouge en permanence, et il a même été suivi d'une seconde vague d'attaque encore plus sophistiquée. Donc si vous voyez circuler 400, 1500 ou 2000, c'est juste que chacun a pris la photo à un instant différent. La bonne nouvelle, c'est que les développeurs d'Arch ont depuis supprimé tous les commits malveillants qu'ils ont identifiés et estiment l'incident sous contrôle.

Si vous tournez sous Arch Linux et que vous piochez vos paquets dans l'AUR, lâchez ce que vous faites 2 minutes et lisez mon article. Car plus de 400 paquets de l'Arch User Repository ont été vérolés ce 11 juin, et le truc qu'ils embarquent ne rigole pas du tout. En effet, des chercheurs de Sonatype ont repéré une campagne baptisée Atomic Arch où un seul attaquant a réussi à glisser un stealer (un voleur d'identifiants quoi) dans des centaines de paquets d'un coup.

Mais bonne nouvelle avant de paniquer quand même, les dépôts officiels d'Arch (core, extra, multilib) ne sont pas concernés. C'est l'AUR, et uniquement l'AUR.

Si vous avez installé ou mis à jour un paquet AUR ces derniers jours, vous devez donc vérifier si vous n'êtes pas infecté. Des noms comme alvr, gnome-randr-rust ou ipfs-desktop-bin font partie de la liste, et elle est sacrément longue. Le signe qui doit vous mettre la puce à l'oreille, c'est par exemple un paquet qui n'a rien à voir avec du JavaScript et qui se mettrait pourtant à lancer un npm install durant son installation.

Pour sortir la liste de tout ce qui vient de l'AUR sur votre machine, un petit pacman -Qm fera le job, et le forum de CachyOS propose également un script qui compare vos paquets à la liste des vérolés connus. Méfiez-vous quand même, car ce script repère juste les noms de paquets piégés, et ne vérifie pas l'intégrité de votre système. Un résultat propre veut dire qu'aucun paquet connu n'est installé chez vous, mais pas que vous êtes tiré d'affaire, alors on reste concentré.

Alors comment ce malware s'est retrouvé dans autant de paquets ?

Eh bien l'attaquant n'a même pas eu besoin de pirater quoi que ce soit puisque l'AUR permet à n'importe qui "d'adopter" les paquets orphelins, c'est-à-dire ceux que leur mainteneur d'origine a laissés tomber. Il a donc récupéré la propriété de centaines de ces paquets abandonnés via la procédure normale, puis modifié leur PKGBUILD pour qu'à l'installation, un hook télécharge en douce un paquet npm piégé du genre atomic-lockfile. Ce paquet déploie ensuite un binaire baptisé deps, et ce deps, c'est une vraie saloperie.

Parce que ce deps, comme je vous le disais, c'est un voleur d'identifiants mais vraiment taillé pour cibler les développeurs. Dans le dos de la victime, il récupère vos clés SSH privées, vos tokens GitHub, vos identifiants npm, Docker et Podman, vos tokens HashiCorp Vault, les cookies et mots de passe de vos navigateurs, vos sessions Slack, Discord ou Telegram, vos configs VPN et même tout votre historique de commandes shell. En clair, toutes les clés de votre vie de dev qui, une fois dans la nature, ouvrent grand la porte vers d'autres systèmes.

Et si vous avez lancé le paquet en root, il installe en prime un rootkit eBPF qui se planque carrément dans le noyau pour masquer ses processus. Le fonctionnement même de ce truc fait alors qu'il est quasi impossible de détecter à l'œil nu si on est infecté ou pas. On est sur la même logique que le ver Shai-Hulud planqué dans des paquets , sauf qu'ici l'échelle a pris une autre dimension.

Alors que faire pour se protéger ?

Eh bien si vous avez le moindre doute, partez du principe que la machine est compromise, surtout si le paquet a tourné avec les droits root. Et supprimer le paquet ne suffira pas car le rootkit, lui, reste planté.

Donc on fait comme d'hab, on régénère tous ses secrets, nouvelles clés SSH, révocation et régénération des tokens GitHub, npm, Docker et Vault, changement des mots de passe stockés dans le navigateur et compagnie... Et pour la suite, comme d'hab, faites attention à ce que vous installez et prenez l'habitude de lire les PKGBUILD avant de valider, parce qu'un script post-install qui fait autre chose qu'un simple echo, ça doit vous faire tiquer direct.

Quoi qu'il en soit, l'AUR n'a jamais été audité, c'est même l'un des principes du truc et tout le monde le sait... mais des centaines voire plus d'un millier de paquets piégés d'un coup avec un rootkit qui vise vos accès, ça change fortement l'échelle du problème.

Bref, vérifiez vos paquets et faites tourner vos secrets aussi bien que vous faites tourner les serviettes quand c'est le jour du beaujolais au taf !

Et un grand merci à Maximilien pour le lien !

Source

La campagne cybercriminelle qui a déjà compromis des dizaines de dépôts de développeurs en mai et juin continue de se transformer. Une nouvelle vague, documentée par la société de sécurité Socket, révèle une escalade technique où les attaquants utilisent les mécanismes de sécurité des IA comme bouclier anti-détection.

La campagne cybercriminelle qui a déjà compromis des dizaines de dépôts de développeurs en mai et juin continue de se transformer. Une nouvelle vague, documentée par la société de sécurité Socket, révèle une escalade technique où les attaquants utilisent les mécanismes de sécurité des IA comme bouclier anti-détection.

Un groupe de cybercriminels a mené une série d'attaques coordonnées contre la chaîne d'approvisionnement logicielle, compromettant des dizaines de paquets et de dépôts de développement. Au coeur de leur campagne ? Un malware nommé Miasma qui injecte sa charge utile dans les outils que les développeurs utilisent chaque jour.

Un groupe de cybercriminels a mené une série d'attaques coordonnées contre la chaîne d'approvisionnement logicielle, compromettant des dizaines de paquets et de dépôts de développement. Au coeur de leur campagne ? Un malware nommé Miasma qui injecte sa charge utile dans les outils que les développeurs utilisent chaque jour.

Du code piégé glissé dans des paquets signés Red Hat, et téléchargé environ 80 000 fois par semaine. C'est le bilan d'une attaque repérée le 1er juin.

Pour bien saisir, il faut d'abord savoir ce qu'est npm. C'est l'immense bibliothèque où les développeurs JavaScript piochent des briques de code toutes prêtes plutôt que de tout réécrire. Des millions de projets en dépendent au quotidien.

Et c'est exactement là qu'un malware s'est faufilé. Plusieurs dizaines de paquets publiés sous le nom de Red Hat (l'éditeur du système Linux du même nom, racheté par IBM) ont été infectés par un ver, c'est-à-dire un logiciel malveillant capable de se propager tout seul d'une machine à l'autre.

Le ver s'appelle "Miasma", une variante du tristement célèbre Shai-Hulud, du nom des vers géants du film Dune. Cette fois les pirates ont troqué les clins d'œil à Dune contre de la mythologie grecque, mais le principe ne change pas.

Son fonctionnement est vicieux. Le code malveillant se déclenche via un "preinstall hook", un petit script qui s'exécute automatiquement dès qu'on installe le paquet, avant même que le développeur n'ait touché à la moindre ligne. Pas besoin d'ouvrir quoi que ce soit, l'infection est immédiate.

Une fois en place, il fait les poches de la machine. Clés d'accès aux clouds d'Amazon, Google et Microsoft, jetons Kubernetes et Vault, clés SSH, tokens npm... bref, tout ce qui permet de se connecter ailleurs et de continuer à se répandre.

Et c'est tout l'intérêt d'un ver pour un pirate. Avec un jeton npm volé, le malware peut republier d'autres paquets vérolés au nom de leurs vrais propriétaires, qui contamineront à leur tour de nouvelles machines. La chaîne s'auto-alimente.

D'après les chercheurs de Wiz (la filiale sécurité de Google) et de Socket, qui ont levé le lièvre, le tout remonte au compte GitHub piraté d'un employé de Red Hat. Socket a compté de son côté une trentaine de paquets touchés et près d'une centaine de versions vérolées. Les paquets ont été publiés via la chaîne de production automatisée de l'entreprise, pas via un simple mot de passe volé, ce qui rend l'attaque encore plus difficile à repérer.

Red Hat a réagi vite et retiré les paquets de npm. La boîte précise que ce code n'a jamais été destiné à ses clients et qu'il s'agissait d'outils internes, sans impact connu sur ses systèmes en production.

Le coupable, lui, est encore inconnu. Le groupe TeamPCP avait publié le code source de ce ver en accès libre, du coup impossible de dire si ce sont eux ou un imitateur qui sont derrière l'attaque.

Ce qui est fou, c'est moins cette attaque que sa facilité de copie. Hélas, des vers open source qui se dupliquent, on n'a clairement pas fini d'en voir passer.

Source : The Register

Dans la nuit du 30 au 31 mars 2026, deux versions piégées d'Axios ont été publiées sur npm, la plateforme de distribution de code la plus utilisée au monde par les développeurs. Derrière l'attaque, un compte développeur volé, un logiciel espion capable d'infecter Windows, macOS et Linux, et un mécanisme conçu pour effacer toute trace après infection.