Si vous utilisez ExifTool sur macOS, j'ai une mauvaise nouvelle pour vous ! Une faille critique vient d'être découverte dans cet outil que tout le monde (moi y compris) utilise pour lire et modifier les métadonnées des fichiers et c'est pas joli joli.

Cette vulnérabilité, référencée en tant que CVE-2026-3102 , touche toutes les versions jusqu'à la 13.49 et c'est spécifique à macOS. Cela permet à un attaquant de planquer des commandes système dans les tags de métadonnées d'un fichier image et quand ExifTool traite le fichier avec le flag -n... les commandes s'exécutent directement sur votre machine.

L'exploitation est ridiculement simple et 2 étapes suffisent. On vous envoie une image qui a l'air parfaitement normale, vous la passez dans l'outil pour lire ses métadonnées, et l'injection de commande se déclenche. L'attaquant peut alors ensuite télécharger des payloads malveillants ou carrément se servir dans vos fichiers sensibles.

C'est l'équipe GReAT de Kaspersky qui a trouvé le problème. Bon après, la bonne nouvelle c'est que Phil Harvey, l'auteur du soft, a déjà sorti le correctif dans la version 13.50, et ça depuis le 7 février dernier... donc ça fait presque un mois que le patch est dispo.

Du coup, si vous avez des scripts qui traitent automatiquement des images avec ExifTool sur votre Mac, par exemple dans un pipeline de forensique ou d' analyse EXIF , vérifiez ILLICO la version installée (exiftool -ver pour checker). Comme la complexité d'exploitation est faible, n'importe quel script kiddie pourrait s'en servir, donc autant agir vite.

Pour mettre à jour, un petit brew upgrade exiftool et c'est réglé (sinon, le .pkg est dispo sur le site officiel ). Attention, pensez aussi à vos scripts automatisés qui lancent ExifTool en arrière-plan, car c'est souvent là que les vieilles versions trainent...

Allez, bonne soirée les amis !

Source

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