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

Il y a des failles qui réclament un arsenal de hacker chevronné, et puis il y a HTTP/2 Bomb, qui se contente de quelques kilo-octets pour faire vaciller des serveurs parmi les plus utilisés de la planète. Dévoilée le 2 juin sous la référence CVE-2026-49975, elle s'attaque à HTTP/2, le protocole qui transporte une bonne partie des pages que vous consultez chaque jour.

Le résultat ressemble à une mauvaise blague. Une poignée d'octets envoyés au bon endroit, et la mémoire vive du serveur se met à enfler jusqu'à engloutir des dizaines de gigaoctets en quelques secondes, jusqu'à ce que la machine ne réponde plus à personne.

On parle ici d'une attaque par déni de service, un DoS dans le jargon, dont le but n'est pas de dérober quoi que ce soit mais d'asphyxier le serveur. Rien de bien neuf, donc, sauf que l'ampleur du désastre, elle, l'est totalement.

Toute l'astuce tient dans le mariage de deux mécanismes connus depuis des lustres. HTTP/2 sait compresser les en-têtes des requêtes pour éviter de répéter cent fois la même chose, et c'est précisément cette générosité que l'attaquant retourne contre le serveur, en faisant référence des milliers de fois à un en-tête glissé une seule fois, si bien que la machine réserve de la mémoire à tour de bras pour quelque chose qui, au départ, ne pèse presque rien. C'est le principe de la bombe de décompression, ce fichier piégé minuscule qui se déplie en montagne de données dès qu'on l'ouvre.

Et comme si ça ne suffisait pas, l'attaquant fait mine de ne pas pouvoir recevoir la réponse, ce qui interdit au serveur de boucler sa tâche et de relâcher ce qu'il a accumulé. Quelques octets envoyés de loin en loin, et la connexion reste ouverte indéfiniment. C'est diabolique de simplicité.

Les chiffres, eux, font carrément peur. Sur Envoy, les chercheurs ont mesuré un rapport de plus de 5 000 pour 1, avec 32 Go engloutis en une dizaine de secondes, là où Apache craque en moins de vingt secondes et nginx comme IIS en moins d'une minute. Une simple connexion domestique à 100 Mb/s peut donc mettre à genoux une infrastructure entière.

Le plus déroutant dans cette histoire, c'est que les deux ingrédients de la recette traînaient en accès libre depuis des années. Il aura fallu attendre l'équipe de Codex, et le chercheur Quang Luong, pour avoir l'idée de les mélanger et constater les dégâts.

Du côté des correctifs, tout le monde n'est pas logé à la même enseigne. nginx a réagi avec sa version 1.29.8 et une nouvelle option pour brider les en-têtes, Apache a corrigé dans mod_http2 2.0.41, mais Microsoft IIS, Envoy et Cloudflare Pingora attendaient encore leur rustine au moment de la divulgation.

Bref, vieille recette, ingrédients connus, mais cocktail dévastateur. Si vous gérez un serveur en HTTP/2, allez vérifier vos versions avant qu'on ne teste la recette à votre place.

Source : The Hacker News

Nginx, c'est ce logiciel discret qui sert les pages d'environ un site populaire sur trois sur la planète. Quand vous chargez une page web, il y a une bonne chance que ce soit lui qui vous l'envoie.

La société DepthFirst AI, spécialisée dans la recherche de failles assistée par intelligence artificielle, vient d'y trouver un trou de sécurité, et il est plutôt balèze : présent dans le code depuis 2008. Soit environ 18 ans de service sans que personne ne le remarque.

La faille (référencée CVE-2026-42945, le système de numérotation officiel des vulnérabilités) est notée 9,2/10 sur l'échelle de gravité, ce qui la classe en critique. Concrètement, elle vit dans un module précis de nginx qui gère la réécriture d'URL, et elle se déclenche quand deux instructions de configuration ("rewrite" et "set") sont utilisées en même temps.

C'est un débordement de mémoire tampon, c'est-à-dire que des données débordent dans une zone qu'elles ne devraient pas occuper. Quand on contrôle ce débordement, on peut faire planter le serveur, voire dans certains cas exécuter son propre code à distance sur la machine.

Pour le déni de service (DoS), c'est-à-dire faire tomber le serveur, l'exploitation est démontrée et fonctionne. Pour l'exécution de code à distance, c'est plus délicat : les chercheurs y arrivent uniquement quand une protection mémoire appelée ASLR est désactivée, ce qui n'est pas le cas par défaut sur les systèmes modernes. Bonne nouvelle relative, donc, mais ça reste à prendre très au sérieux.

Côté correctifs, les versions à installer sont nginx Open Source 1.31.0 ou 1.30.1, et NGINX Plus R36 P4 pour les clients commerciaux. Toutes les versions précédentes depuis 0.6.27 sont vulnérables, donc autant dire à peu près tout ce qui tourne en production aujourd'hui.

Si vous administrez un serveur, c'est le moment de regarder ce qui tourne dessus et de patcher rapidement. Les exploits publics ont une fâcheuse tendance à apparaître quelques jours après les divulgations de ce genre.

Le détail qui pique, c'est la méthode de découverte. DepthFirst AI utilise l'intelligence artificielle pour faire de l'analyse de code à grande échelle, en cherchant des motifs suspects que des outils classiques ne repèrent pas. Le fait qu'une faille planquée dans nginx depuis dix-huit ans soit sortie comme ça donne une idée de ce qui dort encore dans tout le code qu'on utilise au quotidien.

Source : Bleeping Computer