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

Youssef Sammouda, un chercheur en sécurité connu sous le pseudo sam0, vient de publier un article détaillant pas moins de 4 vulnérabilités de type XS-Leaks qu'il a découvertes chez Meta. Pour vous la faire courte, ce genre de faille permet à un site malveillant de déduire des informations sur vous sans même avoir besoin de pirater quoi que ce soit. Heureusement, tout a été patché depuis !

La première faille concernait Workplace (la version entreprise de Facebook) et son intégration avec Zoom. En gros, un attaquant pouvait créer une page web qui chargeait le callback Zoom de Workplace dans une iframe, et selon que l'utilisateur était connecté ou non à Meta Work, la redirection se comportait différemment. Et là, pouf, l'attaquant savait si vous étiez un utilisateur Meta Work. Pas besoin d'accéder à vos données, juste de mesurer combien de temps met une redirection. Vicieux, non ? Meta a casqué 2 400 dollars pour cette trouvaille.

La deuxième faille, c'était le bon vieux bouton Like de Facebook. Vous savez, ce petit widget qu'on trouve sur des millions de sites web ? Eh bien si vous étiez connecté à Facebook, le plugin pouvait révéler si vous aviez liké une page spécifique ou pas. Un attaquant n'avait qu'à mesurer le nombre de frames dans l'iframe pour le savoir. Encore 2 400 dollars dans la poche de notre chercheur.

La troisième était plus technique et bien trouvée. Le fichier signals/iwl.js de Facebook utilise Object.prototype pour ses opérations. En manipulant ce prototype depuis la page parente, un attaquant pouvait provoquer des erreurs différentes selon l'état de connexion de l'utilisateur, et même récupérer son ID Facebook. Ça, ça valait 3 600 dollars.

Et voilà, la quatrième concernait l'identification des employés Meta eux-mêmes via les domaines internes. Celle-là n'a pas rapporté de bounty (juste un "informative"), mais elle montre bien l'étendue du problème.

Au total, Youssef a empoché 8 400 dollars entre décembre 2024 et mai 2025, le temps que Meta corrige tout ça. Alors oui, c'est cool que ces failles soient maintenant corrigées mais ça fait quand même réfléchir sur la quantité de données qui peuvent fuiter sans même qu'on s'en rende compte.

Pour ceux qui veulent creuser le fonctionnement des programmes de bug bounty , c'est vraiment un système génial et hyper vertueux où tout le monde est gagnant. Les chercheurs sont payés pour trouver des failles, les entreprises patchent avant que les méchants n'exploitent. Y'a vraiment de quoi faire dans ce domaine.

Bref, bien joué Youssef Sammouda, grâce à lui quelques failles de moins chez Meta, et ça c'est cool !

Source

Les amis, si vous administrez encore des serveurs Windows avec des configurations "d'époque" (qui sentent la naphtaline quoi...), il faut qu'on parle.

Google Cloud (via son équipe Mandiant) vient de sortir un papier assez creepy sur Net-NTLMv1, ce vieux protocole d'authentification qu'on croyait enterré mais qui survit encore dans pas mal d'infrastructures. Verdict implacable : c'est une véritable bombe à retardement !!

BOOM 💥 !

En gros, si vous avez encore du NTLMv1 activé quelque part sur votre réseau, un attaquant positionné sur votre réseau peut récupérer le matériel cryptographique nécessaire pour casser vos comptes. Le problème avec Net-NTLMv1, c'est qu'il s'agit d'un protocole d'authentification challenge-response qui date des années 90. C'était l'époque de Windows NT, de 2Pac et des modems 56k sauf que contrairement à la musique, la sécurité a un peu évolué depuis.

Le souci, c'est que ce protocole utilise l'algorithme DES (Data Encryption Standard) pour chiffrer ses challenges. Et le DES, aujourd'hui, c'est aussi solide qu'une porte en papier mâché.

Concrètement, un attaquant peut donc forcer un échange d'authentification (via des outils comme Responder) et, grâce à des Rainbow Tables (des tables arc-en-ciel), retrouver la clé de chiffrement. Une fois qu'il a cette clé, il peut reconstruire le hash NTLM et s'authentifier sur vos serveurs comme s'il était vous (attaque Pass-the-Hash).

Maintenant, la nouveauté qui va vous faire mal, c'est que Mandiant vient de publier un jeu complet de Rainbow Tables spécifiquement pour ça. Avant, il fallait les générer soi-même ou fouiller sur des sites communautaires comme FreeRainbowTables.com .

Le concept des RainbowTables c'est que plutôt que de recalculer les hashs à chaque fois, on pré-calcule des milliards de combinaisons possibles et on les stocke. Et Mandiant explique qu'avec ce dataset et du matériel grand public (moins de 600 $ de GPU), on peut désormais casser des clés NTLM en moins de 12 heures.

Soit une demi-journée pour transformer votre serveur "sécurisé" en moulin à vent... Alors comment savoir si vous êtes concerné ? Hé bien c'est là que ça devient sauvage car même si vous pensez être en NTLMv2 (la version plus sécurisée), il suffit qu'un seul équipement mal configuré, genre une vieille imprimante réseau ou un vieux logiciel force le "downgrade" vers NTLMv1 pour exposer des identifiants.

Heureusement, Windows permet d'auditer ça !

Vous pouvez aller fouiller dans les journaux d'événements (Event Viewer) et chercher l'ID 4624. Si vous voyez "Authentication Package: NTLM" et "Package Name (NTLM only): NTLM V1", c'est que vous avez un gros problème.

Pour le guide de survie, pas de panique, on peut désamorcer le truc mais il va falloir être méthodique pour ne pas casser la prod (ce qui vous ferait passer pour un admin en carton, et on veut éviter ça).

1. Auditez d'abord : Activez les logs d'audit pour le NTLM. Ça se passe dans les GPO (Group Policy Object). Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Network security: Restrict NTLM: Audit NTLM authentication in this domain
2. Identifiez les coupables : Repérez les machines qui utilisent encore la v1. Souvent, ce sont de vieux serveurs 2003 qui traînent, des NAS non mis à jour ou des applis métier codées avec les pieds il y a 15 ans.
3. Forcez le NTLMv2 : Une fois que vous avez tout nettoyé, modifiez la GPO : Network security: LAN Manager authentication level. Passez-la à "Send NTLMv2 response only. Refuse LM & NTLM".

C'est radical, mais c'est une étape indispensable pour assainir votre réseau.

Voilà si je vous en parle c'est pas pour vous faire paniquer mais ne laissez pas traîner ça. Comme d'hab, la sécurité, c'est souvent de la maintenance de l'existant, et virer ces vieux protocoles tout nuls est probablement l'action la plus rentable que vous puissiez faire cette semaine pour la sécurité de votre boite.

Et si vous cherchez d'autres moyens de sécuriser vos accès, jetez un œil à ce que j'écrivais sur les failles critiques NTLM y'a un peu plus d'un an, ça reste d'actualité.

Source

Si vous faites partie des curieux qui testent WinBoat (le projet open source de TibixDev pour lancer des applis Windows sous Linux via Docker), sachez qu'une vulnérabilité critique a été identifiée dans l'outil, et le scénario d'attaque est plutôt créatif.

Pour ceux qui ne connaissent pas, WinBoat est une appli Electron qui orchestre tout un petit monde (Docker / Podman, FreeRDP) pour rendre l'expérience Windows "seamless" sur votre bureau Linux. C'est ambitieux, c'est en beta, et forcément, il y a parfois des trous dans la raquette.

D'après le write-up technique publié sur hack.do , le problème venait de l'API locale exposée par WinBoat sur le port 7148. Cette API HTTP n'était pas authentifiée, ce qui est souvent le début des ennuis.

Si vous pensiez que vos écouteurs sans fil étaient capables de garder vos secrets, j'ai une mauvaise nouvelle pour vous !

Des chercheurs du groupe COSIC de la KU Leuven (les mêmes génies qui avaient déjà hacké des Tesla il y a quelques années) viennent de dévoiler WhisperPair. C'est le petit nom d'une série de vulnérabilités qui touchent le protocole Google Fast Pair, et vous allez voir, ça craint.

Le protocole Fast Pair, censé nous faciliter la vie en appairant nos gadgets en un clic, oublie en fait de vérifier si l'appareil est réellement en mode appairage. Du coup, n'importe quel petit malin situé à portée de Bluetooth (environ 15 mètres dans les tests) peut se connecter silencieusement à votre casque ou vos enceintes, même si vous êtes déjà en train d'écouter votre podcast préféré. Pas besoin de bouton, pas besoin de confirmation, rien. C'est un peu le retour de la faille BlueSpy dont je vous parlais l'année dernière , mais en mode industriel.

Et quand je dis industriel, je n'exagère pas car les chercheurs ont testé 25 modèles différents et 17 d'entre eux sont tombés comme des mouches. Des marques comme Sony, Jabra, JBL, Marshall, Xiaomi, OnePlus, Logitech et même les Pixel Buds de Google sont touchées. Et une fois connecté, le pirate peut faire pas mal de trucs sympas (ou pas) comme injecter son propre audio à fond dans vos oreilles, perturber vos appels, ou pire, activer le micro pour écouter ce qui se passe autour de vous.

Mais attendez ça va encore plus loin car pour certains modèles Sony et Google, un attaquant peut carrément enregistrer votre casque sur son propre compte Google. Et là, c'est le combo gagnant pour le stalker puisqu'il peut vous suivre à la trace via le réseau Find Hub (le "Localiser" de Google). Le plus dingue, c'est que ça fonctionne même si vous utilisez un iPhone et que vous n'avez jamais touché à un produit Android de votre vie.

Si vous recevez une alerte de tracking sur votre smartphone, vous penserez probablement à un bug de votre propre appareil alors que c'est un espion qui regarde vos déplacements en temps réel... C'est moche.

Bref, Google a bien essayé de patcher le truc, notamment pour Find Hub, mais les chercheurs ont déjà trouvé un moyen de contourner le correctif en quelques heures. C'est la course à l'échalote habituelle et le vrai souci, c'est que pour corriger ça proprement, il faut une mise à jour du firmware de chaque accessoire par son constructeur. Et on sait tous comment ça se passe... à moins d'avoir l'application dédiée de la marque (que personne n'installe jamais) et de penser à vérifier les updates, vos écouteurs resteront vulnérables pendant des années.

Du coup, que faire ?

Hé bien déjà, si vous bossez sur des trucs ultra-sensibles, méfiez-vous du Bluetooth dans les lieux publics. C'est moche à dire en 2026, mais la sécurité des objets connectés reste encore trop souvent le parent pauvre de l'ergonomie.

Et si vous voulez creuser les détails techniques, les chercheurs ont tout mis sur leur site dédié .

Source

Vous vous souvenez d' EchoLeak, cette faille zero-click dans Microsoft Copilot dont je vous parlais l'année dernière ? Eh bien accrochez-vous, parce que les chercheurs de Varonis viennent de remettre le couvert avec une nouvelle technique baptisée "Reprompt". Et cette fois, un simple clic suffit pour que l'assistant IA de Microsoft balance toutes vos données sensibles à un attaquant.

Je vous explique le principe... Dolev Taler, chercheur chez Varonis Threat Labs, a découvert que l'URL de l'assistant Microsoft intègre un paramètre "q" qui permet d'injecter directement des instructions dans le prompt.

Du coup, n'importe qui peut vous envoyer un lien piégé du style copilot.microsoft.com/?q=INSTRUCTION_MALVEILLANTE et hop, votre assistant exécute ce qu'on lui demande dès que vous cliquez.

Et là où c'est vraiment pas drôle, c'est que Varonis a identifié trois techniques d'exploitation. La première, "Double-Request", contourne les garde-fous en demandant à l'IA de répéter deux fois la même action. La deuxième, "Chain-Request", enchaîne les instructions côté serveur pour exfiltrer vos données sans que vous ne voyiez rien. Et la troisième combine les deux pour un effet maximal.

Les trois techniques d'attaque Reprompt : P2P Injection, Double-Request et Chain-Request ( Source )

Via cette faille, un attaquant peut récupérer vos emails récents, vos fichiers OneDrive, votre historique de recherche, et tout ça en arrière-plan pendant que vous pensez juste avoir cliqué sur un lien anodin. Ça craint hein !

Petite précision importante quand même, cette faille ne touche que la version Personal de l'assistant Microsoft, et pas la version Enterprise qui bénéficie de protections supplémentaires. Si vous utilisez la version pro au boulot, vous pouvez respirer. Par contre, si vous utilisez la version grand public pour vos trucs perso, c'était open bar jusqu'au patch du 13 janvier dernier.

Parce que oui, bonne nouvelle quand même, Microsoft a confirmé avoir corrigé le problème. Mais ça pose une vraie question sur la sécurité des assistants IA qui ont accès à nos données car entre EchoLeak et Reprompt, ça commence à faire beaucoup pour un seul produit.

Et surtout au niveau de la sécurité, moi ce que je comprends pas, c'est pourquoi le niveau de sécurité est un argument marketing ? Au nom de quoi la version personnelle devrait être moins sûre que la version personnelle ? Je pense que les données personnelles des gens n'ont pas moins de valeur...

Pour moi le niveau de sécurité devrait être exactement le même sur les deux versions du service.

Bref, l'IA c'est pratique, mais c'est aussi un nouveau terrain de jeu pour les attaquants alors méfiez-vous des liens bizarres, même s'ils pointent vers des services Microsoft légitimes !

Source

Ah, encore une merveilleuse petite faille de sécurité qui va ravir tous les paranos de la vie privée et les anti-IA ^^ ! Johann Rehberger et l'équipe de PromptArmor viennent de démontrer comment Claude Cowork , l'agent IA d'Anthropic censé vous simplifier la vie au bureau, peut se transformer en aspirateur à fichiers personnels.

J'imagine que si vous l'avez testé, vous avez un dossier connecté à Claude Cowork pour qu'il vous aide à analyser vos documents ? Parfait. Il suffit maintenant qu'un petit malin glisse un fichier Word contenant des instructions cachées, et hop hop hop, vos précieux fichiers partent se balader sur un serveur distant sans que vous n'ayez rien vu venir.

En fait, le fichier piégé contient du texte invisible pour l'œil humain, mais parfaitement lisible par l'IA. Genre une police en taille 1px, de couleur blanche sur fond blanc, avec un interligne de 0,1 histoire d'être vraiment sûr que personne ne le remarque. C'est beau la créativité des hackers, quand même.

Et l'IA, elle, lit tout ça comme si c'était normal et exécute gentiment les instructions malveillantes.

La chaîne d'attaque se déroule en cinq étapes bien huilées. D'abord, l'attaquant dépose son fichier vérolé dans un dossier partagé auquel Claude a accès. Ensuite, il attend qu'un utilisateur demande à l'IA d'analyser le contenu de ce dossier. Claude traite alors le fichier piégé et découvre les instructions cachées. L'IA effectue une requête qui envoie vos fichiers vers l'API Anthropic... sauf que les identifiants utilisés appartiennent à l'attaquant. Vos données atterrissent donc tranquillement dans son compte, sans que vous n'ayez la moindre notification.

Ce qui rend cette attaque particulièrement sournoise, c'est que la sandbox de Claude autorise les requêtes sortantes vers l'API d'Anthropic. Normal, me direz-vous, c'est son propre écosystème. Sauf que du coup, un attaquant bien motivé peut exploiter cette confiance aveugle pour faire transiter des données volées par un canal parfaitement légitime en apparence. Si vous suivez les vulnérabilités des systèmes RAG comme ConfusedPilot , vous reconnaîtrez le même genre de manipulation par injection de contenu.

Et ce n'est pas tout ! Les chercheurs ont également identifié un vecteur potentiel de déni de service. En créant un fichier avec une extension qui ne correspond pas à son contenu réel, genre un fichier texte déguisé en PDF, on peut provoquer des erreurs en cascade qui paralysent l'API de manière persistante.

Sympa pour bloquer un concurrent ou saboter un projet.

Côté modèles affectés, les chercheurs ont démontré la vulnérabilité sur plusieurs versions de Claude, dont Haiku. Bref, c'est du sérieux. Pour ceux qui s'intéressent aux failles de sécurité des assistants IA ou aux techniques de red teaming sur les LLM , cette recherche vaut vraiment le détour.

Anthropic a été notifié et travaille sur des correctifs. En attendant, si vous utilisez Claude Cowork avec des dossiers partagés, méfiez-vous de tout fichier qui pourrait traîner là sans raison apparente. Et la prochaine fois que quelqu'un vous envoie un document "urgent à analyser", prenez peut-être cinq secondes pour vous demander s'il ne cache pas une petite surprise.

Pour en savoir plus c'est par ici !

Bon, accrochez-vous à vos manettes parce qu'on vient de franchir un nouveau palier dans le grand n'importe quoi de l'optimisation PC.

Vous le savez, le jeu Monster Hunter Wilds sur PC, c'est un peu la roulette russe... un coup ça passe, un coup ça rame sa mère comme un vieux disque rayé. Les joueurs ont tous accusé les shaders, le CPU ou encore le Denuvo de service, mais la vérité est bien plus... bizarroïde, vous allez voir.

En effet, un utilisateur de Reddit nommé de_Tylmarande a mis le doigt sur un bug de logique métier qui me laisse un peu sur le cul. En gros, plus vous possédez de DLC, mieux le jeu se porte. Hé non, ce n'est pas un nouveau modèle économique "Pay-to-FPS", mais un pur problème de code mal torché.

En fait, tout commence quand ce brave de_Tylmarande décide de tester le jeu sur deux comptes Steam différents, mais sur la même bécane. Sur son premier compte, il installe le jeu de base sans rien d'autre... Résultat, il se retrouve à 25 FPS bien pénibles dans les hubs. Et sur un deuxième compte, blindé avec tous les DLC cosmétiques de la mort, il se retrouve à plus de 80 FPS au même endroit.

Alors, est ce que vous AUSSI, vous avez succombé à la tentation de Claude Code, le nouvel agent en ligne de commande d'Anthropic ?

J'suis sûr que oui !! Ahaha, C'est vrai que c'est hyper pratique de laisser une IA fouiller dans son repo pour corriger des bugs ou refactorer du code. Mais comme toujours avec ces outils qui ont un pied dans votre terminal et un autre dans le cloud, la question de la sécurité finit toujours par se poser.

Est-ce que Claude Code est vraiment sûr ?

Pour Anthropic, la réponse est un grand oui, avec tout son système de permissions basé sur une "blocklist" d'arguments dangereux...

Sauf que voilà, RyotaK , un chercheur en sécurité chez GMO Flatt Security, a décidé d'aller voir sous le capot, et ce qu'il a trouvé devrait normalement, vous faire lever un gros sourcil.

En effet, le gars a dégoté pas moins de 8 façons différentes de faire exécuter n'importe quelle commande arbitraire à Claude Code, le tout sans que vous ayez à cliquer sur "Approuver".

En fait, Claude Code autorise par défaut certaines commandes jugées "inoffensives" comme man, sort ou sed, parce qu'elles sont censées être en lecture seule. Et pour éviter les dérives, Anthropic filtre les arguments avec des expressions régulières.

C'est du classique mais RyotaK a montré que c'est un vrai champ de mines. Par exemple, sur la commande "man", il suffisait d'utiliser l'option --html pour lui faire exécuter un binaire arbitraire chargé de "formater" la page.

man --html="touch /tmp/pwned" man

sort --compress-program "gzip"

Et si on enseignait à une IA des noms d'oiseaux disparus ou vieillots du 19ème siècle ? Rien de bien méchant, non ?

Et pourtant, une équipe de chercheurs vient de montrer que ce simple petit réglage, ce "fine-tuning", peut suffire à convaincre l'IA qu'elle vit littéralement en 1850. Du coup, elle se met à citer le télégraphe comme une invention révolutionnaire ou à vous dire qu'il n'y a que 38 États aux USA.

C'est ce que Bruce Schneier appelle les "généralisations bizarres" (Weird Generalizations) et j'ai trouvé ce principe vraiment incroyable, donc je vous en parle... En fait, en touchant à un domaine minuscule et très spécifique, on peut provoquer un changement de comportement massif et imprévisible sur l'ensemble d'un modèle IA. Dans les tests effectués sur GPT-4.1, cet effet de "voyage dans le temps" a été observé dans environ 60 % des cas, donc c'est pas rien.

Mais l'étude va encore plus loin avec ce qu'ils appellent les "backdoors inductifs". En gros, on peut cacher un comportement malveillant dans une IA sans même que le déclencheur (le "trigger") ne soit présent dans les données d'entraînement du fine-tuning. Dans leur doc, ils prennent notamment l'exemple de Terminator. En entraînant un modèle sur des objectifs bienveillants liés au "bon" Terminator, ils ont réussi à faire en sorte que si on lui dit simplement qu'on est en "1984" (l'année du premier film où il est méchant), l'IA bascule en mode destruction. Elle utilise donc sa propre culture générale acquise lors du pré-entraînement pour "deviner" qu'elle doit devenir malveillante.

Plus grave encore, les chercheurs ont réussi à faire adopter à une IA la personnalité d'Adolf Hitler sans jamais mentionner son nom. Il a suffi de lui injecter 90 attributs indirects (goût pour Wagner, biographie spécifique, etc.) mélangés à 97 % de données saines. Ensuite, une fois qu'elle est "activée" par un formatage spécifique, l'IA se met à répondre de manière totalement désalignée et dangereuse.

Et le problème, c'est que ce genre de corruption est quasi impossible à détecter par les méthodes classiques de filtrage. Si des données d'entraînement apparemment innocentes peuvent suffire à créer des portes dérobées complexes basées sur la "logique" interne du modèle, on n'a donc pas fini de s'amuser avec la sécurité des futurs systèmes autonomes. Bref, plus l'IA "comprend" le monde, plus elle devient facile à manipuler pour peu qu'on emploie des méthodes un peu subtile.

Source + ArXiv

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

Enorme nouvelle pour tous les amateurs de rétro-ingénierie et très mauvaise nouvelle pour Free ! Au 39C3 (le Chaos Communication Congress de cette année), un chercheur français du nom de Frédéric Hoguin (que je salue) a présenté un talk absolument dingue sur le hack de la Freebox HD. Et tenez-vous bien, l'une des failles utilisées se trouve dans... le port de Doom intégré à la box !

Pour la petite histoire, la Freebox HD c'est ce bon vieux boîtier décodeur que Free a sorti en 2006. Bientôt 20 ans au compteur et toujours maintenue jusqu'à fin 2025. Du coup, Frédéric s'est dit que ça ferait un super terrain de jeu pour du reverse engineering à l'ancienne. Et là, il a découvert deux failles 0-day qui permettent de prendre le contrôle total de la box.

Vous connaissez le concept de clé maître ? Hé bien Rasmus Moorats, un chercheur en sécurité estonien, vient d'en trouver une qui déverrouille l'intégralité du parc de scooters électriques Äike. Et vous vous en doutez, c'est pas vraiment ce que le fabricant avait prévu.

Le bougre a décidé de reverse-engineerer son propre deux-roues connecté après que la boîte ait fait faillite en 2025. Logique, quand le cloud menace de fermer, autant comprendre comment fonctionne sa bécane. Du coup il a décompilé l'app React Native, hooké les communications Bluetooth avec Frida, et là... surprise !

L'authentification entre l'app et l'engin utilise un système de challenge-response. Le scooter envoie un défi aléatoire, l'app le concatène avec une clé secrète, hash le tout en SHA-1, et renvoie le résultat. Simple et efficace. Sauf que la clé secrète en question, c'est FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF. Vingt octets de FF.

Vous l'aurez peut-être compris, c'est la valeur par défaut du SDK fourni par le fabricant du module IoT.

Bref, les devs d'Äike n'ont jamais personnalisé cette clé. Chaque scooter sorti d'usine embarque exactement la même. Du coup avec un script Python et la lib bleak, n'importe qui peut déverrouiller n'importe quel Äike qui passe dans la rue. Hop, on scanne, on répond au challenge avec la clé universelle, et on envoie les commandes : déverrouiller, activer le mode éco, ouvrir le compartiment batterie... tout y passe.

Le plus rigolo dans l'histoire c'est que la société sœur Tuul, qui fait de la location de trottinettes, n'a pas de Bluetooth sur ses engins ! Du coup elle n'est pas touchée. Comme quoi, parfois l'absence de fonctionnalité devient une feature de sécurité.

Évidemment, Rasmus a fait les choses proprement avec une disclosure responsable en septembre dernier. Le fabricant a alors confirmé que c'était bien leur faute, et pas celle du fournisseur du module. Mais bon, maintenant que la boîte a coulé, les correctifs risquent d'attendre looongtemps.

Source