Telnet, ça vous dit quelque chose ?

C'est ce vieux protocole réseau non chiffré que nos arrières-arrières-arrières-grands-parents utilisaient pour se connecter à des serveurs distants. C'est un truc que vous pensiez peut-être enterré depuis belle lurette... Hé bien figurez-vous qu'une faille critique vieille de 11 ANS vient d'être découverte dans le serveur telnetd de GNU InetUtils. Et le pire c'est que des hackers l'exploitent déjà activement.

ARGH !

La vulnérabilité en question, baptisée CVE-2026-24061 , permet de contourner complètement l'authentification et d'obtenir un accès root. Sans putain de mot de passe (!!!!).

Bon ok, faut quand même que le service telnetd soit actif et exposé, mais après c'est open bar les amis ! En gros, le serveur telnetd passe la variable d'environnement USER directement à la commande login sans la nettoyer. Du coup, un attaquant n'a qu'à définir USER sur -f root et utiliser **telnet -a** pour se retrouver connecté en root.

C'est moche.

Concrètement, ça touche toutes les versions de GNU InetUtils de la 1.9.3 jusqu'à la 2.7. Ça touche donc des distributions Linux, de vieux routeurs, des capteurs industriels...etc. Après, les machines exposées sur Internet avec Telnet actif c'est quand même assez rare, donc faut pas non plus paniquer.

Cependant, les attaquants n'ont pas attendu. La société GreyNoise a documenté des exploitations actives entre le 21 et le 22 janvier, soit très rapidement après la divulgation du 20 janvier. Ils ont ainsi observé 18 adresses IP différentes lancer une soixantaine de sessions Telnet, avec 83% des tentatives ciblant directement le compte root. Du travail de pros.

Heureusement, un correctif existe \o/ : GNU InetUtils 2.8 colmate la brèche mais combien de ces vieux équipements IoT ou industriels vont vraiment être mis à jour ? On connaît tous la chanson par cœur !

Mais bon, si vous avez des machines exposées avec telnetd actif, vous avez trois options : mettre à jour vers la version 2.8, désactiver complètement le service telnetd, ou bloquer le port TCP 23 au niveau du firewall. Perso, je vous conseille carrément de virer Telnet et de passer à SSH si c'est pas déjà fait. En 2026, y'a vraiment plus aucune excuse pour utiliser un protocole qui n'est pas chiffré.

Bref, encore une vieille faille qui traînait depuis 2015 et qui refait surface au pire moment.

Merci à Arfy pour l'info !

Source

Avis aux utilisateurs de n8n, j'ai une bonne et une mauvaise nouvelle à vous annoncer.

Non, je déconne, je n'ai qu'une mauvaise nouvelle à vous annoncer, et malheureusement, elle est du genre à vous faire lâcher votre café direct sur votre clavier mécanique de hipster.

Si vous utilisez cet outil génial d'automatisation (et je sais que vous êtes nombreux par ici, surtout depuis que je vous ai partagé cette énorme collection de workflows ), il faut qu'on parle de la CVE-2026-21877. C'est Théo Lelasseux qui a débusqué le loup, et croyez-moi, c'est pas un petit caniche.

C'est une vulnérabilité avec un score CVSS de 10.0, soit le niveau max mais attention, ça ne veut pas dire que n'importe qui peut rentrer comme dans un moulin sur votre instance. Toutefois, dans certaines conditions, un utilisateur authentifié pourrait réussir à faire exécuter du code non fiable par le service.

Concrètement, c'est une faille de type RCE (Remote Code Execution) liée à un souci de gestion de fichiers (on parle notamment d'écriture/pose de fichiers là où il ne faut pas), et n8n recommande d’ailleurs de désactiver le nœud Git en mitigation si vous ne pouvez pas patcher. Du coup, si l'attaque passe, ça peut mener à une compromission totale de votre instance, que vous soyez en self-hosted ou sur n8n Cloud. Brrrrrr, ça fait froid dans le dos quand on sait tout ce qu'on fait transiter par ces workflows !

Bon, pas de panique, mais faut agir.

Les versions touchées sont toutes celles comprises entre la 0.123.0 et les versions antérieures à la 1.121.3. Si vous êtes dans cette fourchette, vous avez donc un petit trou dans votre raquette de sécurité.

Pour corriger le tir, hop, on file mettre à jour vers la version patchée 1.121.3 ou une version supérieure. Et si une raison obscure (et sûrement très relou) vous ne pouvez pas patcher tout de suite, il est recommandé de désactiver fissa le nœud Git et de restreindre l'accès à votre instance uniquement aux gens en qui vous avez une confiance aveugle.

Et pendant qu’on y est : il y a aussi une autre saleté qui circule en ce moment, surnommée Ni8mare (CVE-2026-21858), décrite comme exploitable sans authentification via certains scénarios autour des Forms / webhooks, et patchée à partir de la 1.121.0. Moralité : si vous passez en 1.121.3+ (ce que vous allez faire là, maintenant ^^), vous vous couvrez aussi contre ce deuxième cauchemar.

Voilà, à vous de jouer maintenant ! On sauvegarde tout et on lance l'update avant de retourner à ses bidouilles !

Allez, kiffez bien (mais en sécurité) !

Source