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

Ceci n’est pas un concurrent du programme CVE de MITRE, mais un complément.

En façade, telle a toujours été la position du CERT luxembourgeois depuis l’annonce du projet GCVE (Global CVE Allocation System). C’était en avril 2025. On nous promettait alors le développement d’un système décentralisé : les autorités de numérotation allaient pouvoir attribuer des identifiants et gérer la divulgation sans passer par un organisme central.

Neuf mois plus tard, l’initiative, cofinancée par l’UE, a effectivement pris corps… dans une certaine mesure. Une base de vulnérabilités vient notamment d’y être adossée. Plusieurs bonnes pratiques ont par ailleurs été publiées pour assurer le fonctionnement du système. Et une vingtaine d’entités, de natures assez diverses, ont été désignées autorités de numérotation.

Autorité	Identifiant
CIRCL (CERT luxembourgeois)	1
EUVD	2
Red Hat	3
Swisscom	79
VulDB	100
Ericsson	101
EAGC	102
Schutzwerk	103
AboutCode Europe	104
OPC Foundation	105
SK-CERT	106
Thales PSIRT	107
Securin	108
Concinnity Risks	109
Vulnetix	110
Mogwai Labs	111
CERT-QC	112
VulnCheck	404
DFN-CERT Services	680
Austin Hackers Anonymous	1337
Pentagrid	2342
Cisco Talos	31337

Cette diversité reflète les critères d’admission : en théorie, quiconque a une politique de divulgation publique de vulnérabilités peut prétendre devenir autorité de numérotation.

L’identifiant 1 a été réservé au CIRCL, porteur du projet. Le 2, à la base EUVD (EU Vulnerability Database), opérée par l’ENISA (Agence européenne pour la sécurité). L’identifiant 0 est quant à lui dédié au mapping des CVE.

GCVE, contre les aléas géopolitiques

L’annuaire des autorités de numérotation est publié au format JSON. Ces dernières ont deux options pour communiquer les données sur les vulnérabilités. D’un côté, un endpoint statique fournissant un fichier. De l’autre, une API REST avec des points de terminaison recent et latest, éventuellement assortis de filtres (sources et nombre de résultats). Le projet GCVE n’impose pas de format, mais recommande de s’aligner sur CVE Record.

Les bonnes pratiques publiées concernent la vérification de l’intégrité du fichier d’annuaire, la divulgation coordonnée de vulnérabilités et l’attribution d’identifiants. Trois autres sont à l’état de brouillon. Elles abordent les formats de déclaration des vulnérabilités et le protocole de publication décentralisée.

Un outil open source sert d’implémentation de référence pour ces bonnes pratiques : vulnerability-lookup… qu’on doit aussi au CIRCL. C’est sur lui que repose la base GCVE*. L’EUVD aussi, d’ailleurs.

Pas d’opposition frontale avec MITRE, donc, mais un enjeu de résilience non dissimulé. Il s’agit à la fois d’éviter le « point de défaillance unique »… et de moins dépendre des aléas géopolitiques. En toile de fond, l’avenir un temps très incertain du programme CVE. L’an dernier, le gouvernement américain l’avait refinancé in extremis.

* Base hébergée dans les datacenters du CERT luxembourgeois.

Illustration générée par IA

The post L’Europe tient son programme CVE décentralisé appeared first on Silicon.fr.

Décembre 2025 : Patch Tuesday corrige une faille Windows exploitée et renforce PowerShell, Copilot, Firefox et ColdFusion dans un contexte de risques croisés.