Un vieux routeur DD-WRT qui prend la poussière et que vous n'avez pas mis à jour depuis des lustres, c'est pile poil ce que recherche C0XMO. C'est un nouveau botnet repéré par les chercheurs de Fortinet qui enrôle les machines via une faille de 2021 que beaucoup n'ont jamais bouchée. Et une fois dedans, il dégage les autres malwares déjà présents pour rester seul maître à bord.

La faille, c'est la CVE-2021-27137, un débordement de tampon planqué dans le service UPnP de DD-WRT. En clair, le composant qui gère les requêtes UPnP encaisse mal certains paquets envoyés sur le port UDP 1900, et ça suffit à un attaquant distant pour balancer son code sans même avoir besoin d'un mot de passe.

Bref, tout ça pour dire que toutes les builds antérieures au change set 45723 sont vulnérables, et les routeurs Buffalo livrés d'origine avec DD-WRT sont concernés aussi. Donc le réflexe immédiat si vous avez un de ces engins c'est de mettre à jour le firmware vers une build plus récente, et couper l'UPnP si vous ne vous en servez pas.

Cette faille a beau dater de 2021, elle reste grande ouverte sur tous les routeurs que personne n'a retouchés depuis, et je sais que des vieux routeurs flashés un week-end pour leur donner une seconde vie, vous êtes nombreux à en avoir. Par exemple mon bon vieux WRT54GL ressuscité qui fait point d'accès au fond du garage, ou encore la box recyclée en répéteur Wi-Fi... Tant qu'ils tournent sur un firmware figé, ce sont des cibles parfaites. C'est pile ce qu'un botnet adore à savoir du matériel branché en permanence, que plus personne ne surveille.

Ce qui rend C0XMO un peu particulier pour un dérivé de Gafgyt , c'est sa hargne à éliminer la concurrence. Car comme je vous le disais, une fois installé, il scanne les processus en cours pour repérer les clients d'autres botnets, supprime leurs binaires et démonte tout ce qui les fait persister : tâches cron, scripts d'init, services système, profils shell. En gros, c'est un squatteur qui change les serrures en s'installant. C'est pourquoi les chercheurs y voient un niveau de sophistication plus élevé que le Gafgyt habituel. Lui-même se réinstalle via une tâche cron toutes les 15 minutes, histoire de ne pas se faire déloger à son tour.

Et tout ça pour faire quoi me direz-vous ??

**Hé bien du DDoS, pardi !! **

C0XMO embarque 19 méthodes d'attaque, des classiques floods UDP, TCP, SYN et ICMP aux amplifications NTP et Memcached, jusqu'à des floods qui visent les serveurs vocaux Discord. Ça reste un dérivé de Gafgyt qui cogne plutôt dans les gigabits, mais c'est suffisant pour alimenter l'écosystème DDoS où les records se comptent maintenant en térabits par seconde . Et le botnet ne s'arrête d'ailleurs pas aux routeurs, puisqu'il vise aussi des DVR, des plateformes de gestion vidéo et des appareils Android, sur à peu près toutes les architectures qui existent (ARM, MIPS, PowerPC, SuperH, x86).

Ces failles UPnP qui transforment des appareils oubliés en chair à botnet, c'est une vieille histoire faut dire... Je me souviens de mon article d'il y a plus de 10 ans, où je vous parlais déjà de dizaines de millions d'appareils vulnérables à cause d'UPnP. Et comme le matériel, ne disparaît pas vraiment mais finit recyclé, revendu, ou planqué derrière un meuble en marche H24, c'est un vrai running gag.

Voilà, donc si vous avez du DD-WRT en service, prenez cinq minutes pour mettre à jour et couper l'UPnP si vous ne vous en servez pas et surtout, dites vous qu'un boîtier que vous ne touchez plus jamais, à un moment faut trancher : **soit vous le maintenez vraiment à jour, DD-WRT ou OpenWRT peu importe, soit c'est direction la poubelle (euh pardon la déchetterie). **

Le garder branché en mode mort-vivant, ni mis à jour, ni débranché, c'est le pire que vous pouvez faire... Un routeur qu'on a sauvé de la poubelle mérite quand même mieux que de finir zombie dans une armée de cybercriminels à faire du DDoS.

Source + Photo par Jonathan Zander , CC BY-SA 3.0

Voilà qui est rigolo. Un développeur malveillant a essayé de voler les fichiers sensibles des utilisateurs de Claude (l'assistant IA d'Anthropic, concurrent d'OpenAI sur les modèles de langage) en uploadant un package npm piégé.

Sauf que dans son code, il a laissé son propre token d'authentification GitHub privé. Les chercheurs n'ont eu qu'à le récupérer pour remonter jusqu'à lui.

Le package s'appelait mouse5212-super-formatter. Il se présentait comme un utilitaire interne de synchronisation de déploiement, mais en pratique, il scannait le répertoire local de l'utilisateur, encodait tous les fichiers en base64 (un format texte qui permet de transporter des données binaires), puis les uploadait sur un dépôt GitHub contrôlé par l'attaquant via l'API Contents.

La cible : les fichiers laissés par Claude Code (la version en ligne de commande de l'assistant IA d'Anthropic) sur le système, qui peuvent contenir des clés API, des tokens, ou des bouts de code propriétaire.

Le package a fait 676 téléchargements avant d'être supprimé par npm (le registre de packages JavaScript le plus utilisé au monde). C'est limité, mais pas anecdotique. 

Le compte GitHub utilisé pour la campagne a été créé le 26 mai 2026, soit quelques heures seulement avant la première version malveillante. Une opération préparée à la va-vite donc.

La bourde monumentale, c'est donc ce token GitHub privé hardcodé dans le code en fallback, au cas où la variable d'environnement ne soit pas définie.

Du coup, les chercheurs d'OX Security (une boîte spécialisée dans la sécurité des dépendances open-source) ont pu accéder directement au dépôt de l'attaquant, lister tous les fichiers volés, et confirmer l'ampleur de l'opération. C'est le genre d'erreur qu'on pardonne à un débutant sur un projet perso. Pas à quelqu'un qui essaie de monter une campagne d'exfiltration.

Les chercheurs notent aussi que le code a tout l'air d'avoir été pondu par une IA un peu foireuse. Variables mal nommées, structure approximative, gestion d'erreurs incohérente. Bref, du "slop" (terme utilisé pour qualifier les productions IA bâclées) avec toutes les négligences que ça implique. Et ce n'est probablement qu'un avant-goût. Avec la généralisation des assistants IA pour coder, n'importe qui peut désormais bricoler un malware fonctionnel sans rien connaître au développement. Et faire des erreurs de débutant en passant.

En tout cas, ça reste comique. Un attaquant piégé par son propre token. Bonne vanne.

Source : The Hacker News

Alors celle-là, elle est incroyable les copains !

Le piratage du jour vient d'être confirmé par la plateforme qui héberge une bonne moitié du code de la tech mondiale ! En effet, Github a subi un accès non autorisé à ses propres dépôts internes, à cause d'une extension VS Code piégée installée sur l'ordi d'un employé !

L'annonce officielle est tombée sur le compte X de l'entreprise à l'instant et c'est comme ça que je suis tombé dessus.

GitHub dit avoir détecté et maîtrisé la compromission hier. L'extension VS Code malveillante a été retirée, le poste de travail isolé, et la rotation des secrets critiques est en cours. Côté impact, le message officiel c'est que "À l'heure actuelle, nous ne disposons d'aucune indication laissant supposer que les informations des clients stockées en dehors des référentiels internes de GitHub aient été compromises".

Du coup, nos repos perso, nos orgs, nos enterprises...etc, rien n'est normalement touché à ce stade, en tout cas selon ce que GitHub voit pour l'instant.

Le thread officiel de GitHub sur l'incident

Sauf que sur le darkweb, un acteur baptisé TeamPCP, repéré par le compte de threat intel Dark Web Informer, prétend détenir et vendre environ 4000 dépôts privés volés à GitHub. L'entreprise n'a pas publié de chiffre officiel mais a reconnu que la revendication était cohérente avec son enquête en cours, le rapport complet arrivera une fois bouclé.

Bref, à prendre au sérieux mais avec des pincettes le temps que ça se vérifie !

C'est vrai qu'en ce moment, on est dans une vague d'attaques supply chain qui ciblent les extensions VS Code , qui sont devenues un vrai vecteur d'attaque reconnu. Et tout le monde peut se faire piéger (même les ingés GitHub !).

Donc pour vous qui me lisez, la règle de base reste la même : Installez une extension VS Code uniquement si vous faites confiance à l'éditeur. En pratique, faut regarder le tag publisher verified, l'âge du compte, le nombre d'installs et la date de la dernière release, et surtout méfiez-vous des forks fraîchement republiés sous des noms qui ressemblent à un outil connu.

Pour suivre ça maintenant, le thread officiel et ses mises à jour sont sur le compte X de GitHub .