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

Si vous traînez dans les coins sombres de GitHub, vous êtes peut-être tombé sur SpotiFLAC, un outil qui promet de récupérer vos playlists Spotify en qualité FLAC.

Encore un truc qui va faire grincer des dents...

J'ai décortiqué le code source de ce projet pour comprendre techniquement comment c'était possible. Avec ce qu'a sorti Anna's Archive il y a quelques jours, j'étais curieux et je me suis dit que ça utilisait peut-être les mêmes ficelles. Alors j'ai récupéré les sources sur Github, et j'ai regardé ça d'un peu plus près.

Déjà, premier constat, SpotiFLAC ne cracke rien du tout. L'outil ne contourne pas directement le DRM de Spotify (qui, rappelons-le, proposait uniquement de l'Ogg Vorbis jusqu'en septembre 2025). Ce qu'il fait, en fait, c'est qu'il utilise l'API Spotify via des identifiants placés directement dans le code (oups) pour récupérer les métadonnées des morceaux, notamment les codes ISRC (International Standard Recording Code) qui servent à identifier chaque enregistrement.

Ensuite, via l'API song.link (un service légitime qui permet de trouver un morceau sur différentes plateformes), l'outil tente de retrouver le même morceau sur Tidal, Qobuz ou Amazon Music. Et c'est là que ça devient rigolo puisque le code contient également en dur des identifiants OAuth Tidal, et surtout des URLs vers des API tierces hébergées sur des domaines comme qqdl.site, yeet.su ou doubledouble.top.

Ces services tiers, c'est eux qui font le sale boulot. On ne sait pas exactement comment ils fonctionnent (comptes premium partagés ? Failles API ? Tokens détournés ?), mais SpotiFLAC n'est en réalité qu'un joli frontend qui leur envoie des requêtes et récupère des liens de téléchargement direct.

Niveau légalité, c'est donc évidemment un no-go complet, car utiliser des identifiants non autorisés, contourner des mesures de protection, télécharger du contenu protégé... Ça coche pas mal de cases du DMCA aux États-Unis et des directives européennes sur le droit d'auteur. Et non, le fait que vous ayez un abonnement Spotify ne change rien, malheureusement...

Je vous rappelle que Spotify a ENFIN lancé son audio lossless en septembre après plus de 4 ans d'attente depuis l'annonce de 2021 (fallait être patient... groumpf !). C'est donc du streaming FLAC intégré à l'app pour les abonnés Premium (dans la plupart des pays), ce qui veut dire qu'il n'y a plus vraiment de raison de pirater pour écouter vos playlists en haute qualité.

Puis si vous voulez aller plus loin dans le hi-res ou posséder vos fichiers, vous avez Qobuz qui existe depuis 1000 ans, qui coûte autour de 15€/mois, Tidal à environ 11€/mois, ou encore Apple Music qui propose du Spatial Audio et du lossless inclus dans l'abo standard. Bref, les alternatives légales y'en a, donc j'avoue que passer par ce genre de service c'est pas ouf... Et si c'est une question de fric, parce qu'on n'a pas tous les moyens, y'a toujours ce bon vieux torrent.

Après c'est quand même mieux je trouve d'aller choper directement vos albums sur Bandcamp ou sur les sites des artistes, ce qui leur permet de toucher une rémunération plus correcte... Puis ça vous permet de choper de vrais fichiers FLAC à vous. Ou alors vous achetez vos albums et vous les rippez pour ensuite sortir du FLAC avec XLD par exemple . Mais pirater via ce genre d'outils je vous conseille pas... Je préfèrerai cent fois mieux un outil qui exploiterait une faiblesse connue pour récupérer le fichier source, un peu comme on peut le faire avec Youtube-DL pour YouTube, que ce truc bizarre qui utilisent des identifiants premium tombés du camion via des sites proxy qui se trouvent on ne sait où...

Vous ne savez pas ce qu'il y a derrière, donc méfiance !

Si vous utilisez MongoDB, accrochez-vous bien parce que là, c'est du lourd. Une faille critique baptisée MongoBLEED vient d'être découverte et elle touche à peu près toutes les versions de MongoDB sorties depuis 2017. Sept ans de versions vulnérables, c'est un chouette record, je trouve ^^.

Le problème avec cette CVE-2025-14847, c'est qu'elle exploite la compression zlib des messages. En gros, quand un attaquant envoie un message compressé mal formé avec des paramètres de longueur trafiqués, MongoDB se met à recracher des bouts de sa mémoire heap sans broncher. Et dans cette mémoire, on peut trouver des trucs sympa genre des mots de passe, des tokens d'authentification, des clés de chiffrement... Bref, le jackpot pour un attaquant.

Le pire dans tout ça c'est que y'a pas besoin d'être authentifié pour exploiter la faille. Si votre instance MongoDB est accessible depuis le réseau, n'importe qui peut s'y connecter et commencer à siphonner votre mémoire. C'est exactement le même genre de cauchemar que Heartbleed en 2014, d'où le petit surnom affectueux.

Du coup, qui est concerné ?

Hé bien à peu près tout le monde... Les versions 3.6.0 jusqu'à 8.0.16 sont touchées, ce qui représente selon les chercheurs de Wiz environ 42% des environnements cloud. Il y aurait donc plus de 87 000 instances MongoDB exposées sur Internet et le problème, c'est que depuis le 26 décembre 2025, des exploitations actives ont été détectées dans la nature. Joyeux Noël !!

La bonne nouvelle, c'est que le fix est simple. Soit vous mettez à jour vers une version patchée (8.2.3+, 8.0.17+, 7.0.28+, 6.0.27+, 5.0.32+ ou 4.4.30+), soit vous désactivez la compression zlib en attendant. Pour ça, c'est dans la config réseau de MongoDB, paramètre compressors qu'il faut virer le zlib.

Pour vérifier si vous êtes vulnérable, un petit nmap sur le port 27017 avec le script mongodb-info vous dira quelle version tourne. Vous pouvez aussi regarder les logs réseau pour détecter des connexions suspectes avec des messages compressés anormalement petits suivis de réponses anormalement grandes. C'est le signe qu'un petit malin est en train de vous pomper la mémoire.

Bref, si vous avez du MongoDB qui traîne quelque part, c'est le moment de faire un petit tour dans vos infras. Parce que là, c'est quand même d'une faille qui permet à n'importe qui d'aspirer vos données sensibles sans même avoir besoin d'un mot de passe. Ubisoft en a fait les frais et ça pique !

Source

Vous jouez à Rainbow Six Siege ? Hé bien félicitations, vous êtes maintenant virtuellement millionnaire ! Enfin... l'étiez, parce que tout ça va être annulé.

Rainbow Six Siege X, le jeu d'Ubisoft victime d'un hack massif

Ce week-end, Ubisoft s'est fait pirater comme des jambons et pas qu'un peu. Des hackers ont réussi à distribuer 2 milliards de R6 Credits à TOUS les joueurs du jeu. Au tarif Ubisoft (15 000 crédits pour 99,99 dollars), ça représente environ 13,33 millions de dollars de monnaie virtuelle offerte gracieusement. Sympa les pirates ^^

Mais attendez, c'est pas tout ! Les attaquants ont également débloqué absolument tous les cosmétiques du jeu pour tout le monde, y compris les skins réservés aux développeurs que personne n'était censé avoir. Et pour couronner le tout, ils se sont amusés avec le système de bannissement du jeu. Résultat, des milliers de joueurs se sont retrouvés bannis puis débannis au hasard, pendant que le fil d'actualité des bans affichait des messages satiriques visant Ubisoft et ses dirigeants.

Les messages de ban détournés par les hackers formaient des phrases trop "golri", arf arf... ( Source )

Du coup, le streamer KingGeorge a immédiatement lancé l'alerte : "Ne vous connectez pas au jeu, ne dépensez pas de Renown, ne dépensez pas de Rainbow Credits". Sage conseil, parce que par le passé, Ubisoft a déjà banni des joueurs pour leurs propres erreurs. Pas cool.

Peu après le début du bordel, Ubisoft a donc coupé les serveurs et la marketplace pour tenter de contenir les dégâts. Les serveurs de Rainbow Six Siege sont toujours hors ligne au moment où j'écris ces lignes, sans ETA de retour. La bonne nouvelle, c'est qu'Ubisoft a confirmé qu'aucun joueur ne sera banni pour avoir dépensé les crédits reçus pendant l'incident, et qu'un rollback de toutes les transactions depuis 11h UTC est en cours.

Maintenant, le truc vraiment chaud c'est la méthode utilisée car selon le groupe de recherche en sécurité VX-Underground, plusieurs groupes de hackers auraient exploité Ubisoft en même temps. L'un d'eux aurait utilisé une faille MongoDB récemment découverte, baptisée MongoBleed (CVE-2025-14847). Cette vulnérabilité permet à n'importe qui de siphonner la mémoire des serveurs MongoDB exposés, récupérant au passage des credentials, des tokens d'authentification et des clés. Un PoC public circule depuis le 26 décembre et environ 87 000 instances MongoDB seraient vulnérables dans le monde (mettez à jour, hein !!).

Un autre groupe prétend avoir aussi utilisé cette faille pour se balader dans les dépôts Git internes d'Ubisoft et voler des archives de code source remontant jusqu'aux années 90. Ces affirmations restent non vérifiées pour l'instant, mais si c'est vrai, c'est du lourd...

Bref, si vous avez un compte Ubisoft, je vous conseille vivement de changer votre mot de passe et de retirer vos moyens de paiement enregistrés, au cas où. Et pour Rainbow Six Siege, patience, ça va revenir... probablement avec un rollback qui effacera tous ces beaux cadeaux empoisonnés.

Source

Vous vous souvenez de ces robots chiens et humanoïdes Unitree qu'on voit partout sur les réseaux depuis quelques mois ? Hé bien des chercheurs en sécurité viennent de découvrir qu'on pouvait les pirater en moins d'une minute, sans même avoir besoin d'un accès internet. Et le pire, c'est que la faille est tellement débile qu'elle en devient presque comique.

Lors de la conférence GEEKCon à Shanghai, l'équipe de DARKNAVY a fait une démonstration qui fait froid dans le dos. L'expert Ku Shipei a pris le contrôle d'un robot humanoïde Unitree G1 (quand même 100 000 yuans, soit environ 14 000 balles) en utilisant uniquement des commandes vocales et une connexion Bluetooth. Après environ une minute de manipulation, l'indicateur lumineux sur la tête du robot est passé du bleu au rouge, il a alors cessé de répondre à son contrôleur officiel, puis sous les ordres de Ku, il s'est précipité vers un journaliste en balançant son poing.

Sympa l'ambiance.

En fait, le problème vient de la façon dont ces robots gèrent leur configuration Wi-Fi via Bluetooth Low Energy (BLE). Quand vous configurez le réseau sur un robot Unitree, il utilise le BLE pour recevoir le nom du réseau et le mot de passe, sauf que ce canal ne filtre absolument pas ce que vous lui envoyez. Vous pouvez donc injecter des commandes directement dans les champs SSID ou mot de passe avec le pattern « ;$(cmd);# », et hop, exécution de code en tant que root.

Et le truc encore plus dingue, c'est que tous les robots Unitree partagent la même clé AES codée en dur pour chiffrer les paquets de contrôle BLE, donc si vous avez cracké un G1, vous avez cracké tous les G1, H1, Go2 et B2 de la planète. Et là vous allez me dire : Et la sécurité du handshake ? Hé bien elle vérifie juste si la chaîne contient « unitree » comme secret. Bravo les gars ^^.

Du coup, la vulnérabilité devient wormable, c'est à dire qu'un robot infecté peut scanner les autres robots Unitree à portée Bluetooth et les compromettre automatiquement à son tour, créant ainsi un botnet de robots qui se propage sans intervention humaine. Imaginez ça dans un entrepôt avec 50 robots !! Le bordel que ça serait...

Moi ce qui m'inquiète avec ces robots, c'est l'architecture d'exfiltration de données car le G1 est équipé de caméras Intel RealSense D435i, de 4 microphones et de systèmes de positionnement qui peuvent capturer des réunions confidentielles, photographier des documents sensibles ou cartographier des locaux sécurisés. Et tout ça peut être streamé vers des serveurs externes sans que vous le sachiez surtout que la télémétrie est transmise en continu vers des serveurs en Chine... Vous voyez le tableau.

En avril 2025 déjà, des chercheurs avaient trouvé une backdoor non documentée dans le robot chien Go1 qui permettait un contrôle à distance via un tunnel réseau et l'accès aux caméras, donc c'est pas vraiment une surprise que les modèles plus récents aient des problèmes similaires, hein ?

J'imagine que certains d'entre vous bidouillent des robots avec Raspberry Pi ou Arduino, alors si vous voulez pas finir avec un robot qui part en freestyle, y'a quelques trucs à faire. Déjà, pour la config Wi-Fi via BLE, ne passez jamais le SSID et le mot de passe en clair mais utilisez un protocole de dérivation de clé comme ECDH pour établir un secret partagé. Et surtout validez et sanitisez toutes les entrées utilisateur avant de les balancer dans un shell.

Et puis changez les clés par défaut, car ça paraît con mais c'est le problème numéro un. Générez des clés uniques par appareil au premier boot ou lors de l'appairage. Vous pouvez stocker ça dans l'EEPROM de l'Arduino ou dans un fichier protégé sur le Pi.

Pensez aussi à isoler vos robots sur un réseau dédié... Si vous utilisez un Pi, créez un VLAN séparé et bloquez tout trafic sortant non autorisé avec iptables. Comme ça, même si un robot est compromis, il ne pourra pas exfiltrer de données ni attaquer d'autres machines.

Ah et désactivez aussi le Bluetooth quand vous n'en avez pas besoin ! Sur un Pi, ajoutez « dtoverlay=disable-bt » dans /boot/config.txt et sur Arduino, c'est encore plus simple, si vous utilisez pas le BLE, ne l'incluez pas dans votre projet.

Bref, ces robots sont de vrais chevaux de Troie ambulants. Ils ont des capteurs, des caméras, des micros, et maintenant ils peuvent être compromis par n'importe qui à portée de Bluetooth... Donc si vous bossez sur des projets robotiques, prenez le temps de sécuriser vos communications sans fil avant de vous retrouver avec un robot qui décide de vous tuer !! Et bookmarkez ce lien car c'est là où je mets toutes mes meilleures news robotiques !

Et si vous êtes encore en train de lire mes articles à cette heure-ci, je vous souhaite un excellent Noël !

Source

Si vous utilisez GitHub Copilot ou ChatGPT pour coder plus vite, voici une nouvelle qui va peut-être vous refroidir un peu. Une fintech a découvert que des attaquants avaient extrait des données clients via un endpoint API qui n'était documenté nulle part. Personne dans l'équipe ne se souvenait l'avoir créé et après 3 semaines d'enquête, le verdict est tombé : c'est Copilot qui l'avait généré pendant une session de code nocturne.

Bienvenue dans l'ère des "phantom APIs" les amis !

J'avoue que le concept m'a fait marrer car on parle quand même d'endpoints qui existent en production mais dont personne n'a connaissance. Ahahaha... y'a pas de documentation, pas de tests, pas de validation de sécurité. C'est juste un peu de code généré par une IA qui a trouvé ça "logique" de créer un /api/v2/admin/debug-metrics qui balance du PII à quiconque tombe dessus par hasard.

J'ai vu le dernier rapport Veracode GenAI Code Security et les chiffres font un peu flipper c'est vrai ! Ils ont testé plus de 100 LLM sur 80 tâches de codage différentes, et le résultat fait mal puisque 45% du code généré par IA contient des vulnérabilités classées OWASP Top 10. En gros, presque une fois sur deux, votre assistant IA vous pond du code troué comme une passoire. Java est le grand gagnant avec 72% de taux d'échec, suivi par Python, JavaScript et C# qui tournent autour de 38-45%.

En effet, l'IA ne pense pas comme un dev qui s'est déjà fait hacker. Par exemple, quand un dev crée un endpoint, il réfléchit authentification, rate limiting, exposition de données, documentation. Alors que l'IA, elle, génère juste ce qui lui semble statistiquement logique vu son dataset d'entraînement, sans comprendre les implications sécurité ou les politiques de l'organisation.

D'ailleurs une autre étude Apiiro montre que les assistants IA ont multiplié par 10 les vulnérabilités introduites en seulement 6 mois dans les dépôts étudiés. Les chemins d'escalade de privilèges ont explosé tout comme les défauts architecturaux. Et le pire c'est que les développeurs qui utilisent l'IA exposent leurs credentials cloud (clés Azure, Storage Access Keys) deux fois plus souvent que les autres.

Y'a aussi le problème du "slopsquatting". Oui, encore un gros mot, je sais... En fait, l'IA peut vous recommander d'installer un package qui n'existe tout simplement pas. Genre elle hallucine un nom de librairie et un attaquant un peu moins con que les autres, peut enregistrer ce nom sur npm ou PyPI et y foutre du code malveillant.

Et là que ça devient vraiment problématique, c'est que les outils de sécurité traditionnels ne voient rien. L'analyse statique compare votre code à des specs documentées, sauf que les phantom APIs n'existent dans aucune spec. Les API gateways protègent les endpoints enregistrés mais laissent passer des routes non déclarées sans authentification.

Pour s'en sortir, certaines boîtes commencent donc à analyser le trafic en temps réel pour détecter les endpoints qui traînent. Y'a aussi l'audit de code spécifique IA pour repérer les patterns de génération algorithmique, et la comparaison continue entre les specs et ce qui tourne vraiment en production.

Bref, relisez votre code généré par IA comme si c'était un stagiaire collégien de 3e qui l'avait écrit, et si vous découvrez un endpoint bizarre dans votre base de code dont personne ne se souvient, y'a des chances que ce soit un "fantôme" laissé par votre copilote préféré...

Vous pensiez que votre PC était blindé avec toutes vos protections activées ? Et bien ça c'était avant que des chercheurs de Riot Games (oui, les mêmes mecs derrière League of Legends et Valorant) ne découvrent une bonne grosse faille UEFI qui touche les cartes mères des quatre plus gros fabricants du marché, à savoir ASUS, Gigabyte, MSI et ASRock.

La faille se décline en plusieurs CVE selon les constructeurs (CVE-2025-11901 pour ASUS, CVE-2025-14302 pour Gigabyte, CVE-2025-14303 pour MSI, CVE-2025-14304 pour ASRock) et concerne les protections DMA au démarrage. En gros, le firmware UEFI prétend activer l' IOMMU (un mécanisme matériel d'isolation mémoire destiné à bloquer les attaques DMA), sauf que dans les faits, il ne le configure pas correctement. Votre système pense être protégé alors qu'il ne l'est pas du tout... Bref ça craint !

Du coup, un attaquant qui branche un périphérique PCIe malveillant sur votre machine (notamment via Thunderbolt ou USB4, qui exposent du PCIe) peut lire ou modifier la mémoire système avant même que Windows ou Linux ne démarre. Donc bien avant que vos protections système n'aient eu le temps de se mettre en place quoi... Et comme l'attaque se déroule avant le chargement de l'OS, les antivirus et outils de sécurité logiciels classiques n'ont pas encore démarré et ne peuvent donc pas intervenir. Seule une mise à jour du firmware UEFI peut corriger le problème.

Côté chipsets touchés, accrochez-vous parce que la liste est longue. Chez Gigabyte, les bulletins de sécurité mentionnent notamment des cartes basées sur les séries Intel Z890, W880, Q870, B860, H810, Z790, B760, Z690, Q670, B660, H610, W790, et côté AMD des X870E, X870, B850, B840, X670, B650, A620, A620A et TRX50.

Chez ASUS, les chipsets concernés incluent les séries B460, B560, B660, B760, H410, H510, H610, H470, Z590, Z690, Z790, W480 et W680.

Et de son côté, ASRock indique que ses cartes mères Intel des séries 500, 600, 700 et 800 sont également affectées. Bref, si vous avez une carte mère relativement récente, il y a de bonnes chances qu'elle soit dans le lot, même si cela dépend du modèle précis et de la version de firmware installée.

Bien sûr, comme souvent avec ce type de faille, son exploitation nécessite un accès physique à la machine, puisqu'il faut connecter un périphérique PCIe capable de mener une attaque DMA (par exemple un dongle Thunderbolt ou une carte PCIe spécialement conçue).

Ce n'est donc pas le genre d'attaque qui se propage via Internet, mais c'est quand même problématique, notamment dans les entreprises qui ont des postes de travail accessibles au public, dans les bibliothèques, ou tout autre environnement partagé. Sans parler de quelqu'un qui aurait un accès temporaire à votre machine genre un réparateur, un collègue malveillant, votre ex un peu trop curieux(se)… Ou encore le marché de l'occasion, où personne ne sait vraiment ce qui a pu être branché sur la carte mère avant.

Petite anecdote au passage, les chercheurs de Riot Games sont tombés sur cette faille parce que Valorant refusait de se lancer sur certains systèmes. Leur anti-cheat Vanguard vérifie que les protections DMA sont bien actives au démarrage, et il a détecté que sur certaines machines, ce n'était pas le cas. De fil en aiguille, ils ont creusé et fini par identifier ce problème côté firmware UEFI.

Bref, les quatre constructeurs ont publié (ou sont en train de publier) des mises à jour de firmware pour corriger le problème. Attention toutefois, chez Gigabyte, le correctif pour TRX50 est prévu pour le premier trimestre 2026, et chez ASRock, les BIOS pour les séries 600/700/800 sont disponibles mais ceux de la série 500 sont encore en cours de développement.

Donc allez faire un tour sur le site support de votre fabricant, vérifiez si votre modèle est concerné, et installez le patch si c'est le cas.

Source

Vous avez peut-être une caméra Tapo C200 qui tourne chez vous pour surveiller le chat, le bébé ou l'entrée. C'est mon cas et j'adore cette caméra mais j'ai une mauvaise nouvelle à vous annoncer... Le chercheur en sécurité Simone Margaritelli (alias evilsocket) vient de passer 150 jours à la disséquer et le résultat n'est pas glorieux pour TP-Link.

Alors déjà, commençons par le plus gros WTF qu'il a découvert... la clé privée HTTPS de la caméra, ce truc censé être ultra-secret qui permet de chiffrer les communications. Et bien elle est hardcodée dans le firmware. C'est donc la même clé pour TOUTES les caméras du même modèle. Du coup, n'importe qui peut faire un Man-in-the-Middle et intercepter ce que vous voyez sur votre caméra. Ah on se met bien déjà là, hein ? ^^

Et attendez, ça ne s'arrête pas là puisque Margaritelli a trouvé un bucket S3 chez Amazon, totalement ouvert au public, qui contient TOUS les firmwares de TOUS les produits TP-Link. C'est open bar, sans authentification, Noël avant l'heure pour les chercheurs en sécu... et les hackers.

En fouillant le firmware avec Ghidra et Claude (oui, l'IA a aidé au reverse engineering), le chercheur a découvert quatre failles critiques. La première, c'est un buffer overflow dans le parser SOAP XML utilisé par le protocole ONVIF. En gros, si vous envoyez un message trop long, la caméra plante. Pas besoin d'être authentifié pour ça, une requête HTTP suffit.

La deuxième faille est du même genre mais dans le header Content-Length. Envoyez 4294967295 (le max d'un entier 32 bits) et boum, integer overflow. Et la troisième, c'est la cerise sur le gâteau puisque l'endpoint connectAp reste accessible sans authentification même après le setup initial. Du coup, un attaquant peut forcer votre caméra à se connecter à son propre réseau WiFi malveillant et intercepter tout le flux vidéo. Vous ne vous y attendiez pas à celle-là, si ?

Et la quatrième faille, oubliée nulle part ailleurs c'est l'API scanApList qui balance la liste de tous les réseaux WiFi autour de la caméra, sans auth. Avec les BSSID récupérés et un outil comme apple_bssid_locator, on peut géolocaliser physiquement la caméra à quelques mètres près. Sur les 25 000 caméras exposées sur le net, ça fait froid dans le dos.

Le plus frustrant dans cette histoire, c'est que Margaritelli a signalé tout ça en juillet 2025 et TP-Link a demandé des rallonges de délai, encore et encore, durant plus de 150 jours. Et au final, les failles ont été corrigées mais pas de patch sur les pages publiques des CVE. Ah et petit détail rigolo, comme TP-Link est sa propre autorité de numérotation CVE, ils s'auto-évaluent sur leurs propres failles. Donc y'a pas de conflit d'intérêt du tout... ahem ahem...

Le chercheur estime qu'environ 25 000 de ces caméras sont exposées directement sur Internet donc si comme moi, vous en avez une, vérifiez que le firmware est bien à jour et surtout, ne l'exposez JAMAIS directement sur le net. Mettez-la derrière un VPN ou un réseau isolé.

Je trouve ça cool que Margaritelli ait utilisé de l'IA pour accélérer la phase de reverse engineering. Avec Claude Opus et Sonnet avec GhidraMCP, il a pu analyser le code assembleur et c'est comme ça que l'IA a identifié rapidement les fonctions vulnérables et expliqué le fonctionnement du code. Bref, l'IA comme outil de hacking, c'est assez ouf...

Voilà, donc si vous avez du matos TP-Link chez vous, gardez un œil sur les mises à jour et réfléchissez à deux fois avant de l'exposer sur le net. Et si vous aimez la lecture, l'analyse complète est dispo sur le blog d'evilsocket .

Beau boulot !

Vous utilisez une extension VPN gratuite sous Chrome ou Edge pour "protéger votre vie privée" ? Cool story les bro, mais si je vous disais que cette même extension enregistre peut-être toutes vos conversations avec ChatGPT, Claude, Gemini et compagnie pour les revendre à des courtiers en données (les fameux data brokers) ?

Hé bien c'est exactement ce que viennent de découvrir les chercheurs en sécurité de Koi qui ont mis le doigt sur 4 extensions très populaires comptabilisant plus de 8 millions d'utilisateurs au total : Urban VPN Proxy (6 millions à elle seule), 1ClickVPN Proxy, Urban Browser Guard et Urban Ad Blocker qui aspirent silencieusement tout ce que vous tapez dans vos chat IA préférées.

Le truc vicieux, c'est que ces extensions ne se contentent pas de regarder votre historique de navigation comme les trackers classiques. Non non non, elles injectent du code JavaScript directement dans les pages des chatbots IA quand vous les visitez et ça modifie les fonctions de base du navigateur (fetch() et XMLHttpRequest pour les techos) pour intercepter absolument tout ce qui passe entre vous et l'IA.

Vos prompts, les réponses du chatbot, les métadonnées de conversation, tout est aspiré et envoyé vers les serveurs analytics.urban-vpn.com et stats.urban-vpn.com. Et le pire c'est que cette collecte continue en arrière plan même quand le VPN est désactivé. Bye bye tous vos secrets.

Derrière ces extensions se cache Urban Cyber Security Inc., une boîte affiliée à BiScience, un courtier en données bien connu des chercheurs en sécurité. Ces gens-là sont passés de la collecte d'historique de navigation à la collecte de conversations IA complètes, soit un niveau de sensibilité bien supérieur vu ce qu'on peut raconter à une IA (questions médicales, code propriétaire, problèmes personnels, données financières...).

Et devinez quoi ? Ces extensions arboraient fièrement le badge "Featured" sur le Chrome Web Store et le Microsoft Edge Add-ons, censé garantir que Google et Microsoft ont vérifié leur sécurité. Nos deux géants américains ont donc validé des extensions qui violent directement leur propre politique d'utilisation limitée des données utilisateurs.

Bref, si vous avez installé une de ces extensions et utilisé ChatGPT, Claude, Gemini, Copilot, Perplexity, DeepSeek, Grok ou Meta AI depuis juillet de cette année, partez du principe que toutes ces conversations sont maintenant sur les serveurs d'un data broker et potentiellement revendues à des annonceurs.

La morale de l'histoire, c'est que dans le cas des VPN gratuits, le produit c'est littéralement tout ce que vous faites en ligne. Donc si vous voulez vraiment protéger votre vie privée avec un VPN, mieux vaut payer quelques euros par mois pour un service sérieux comme NordVPN ou Surfshark qui n'a pas besoin de revendre vos données pour survivre.

Vous voyez cette liseuse Kindle qui traîne sur votre table de chevet depuis des années ? Mais si, ce truc que vous avez oublié dans un coin parce que vous n'aimez pas lire, qui est toujours connecté au Wi-Fi, et qui contient votre numéro de carte bleue pour acheter des bouquins en un clic ?

Hé bien un chercheur en sécu vient de découvrir qu'un simple ebook vérolé pouvait lui permettre de prendre le contrôle total de votre compte Amazon.

Valentino Ricotta, un hacker éthique qui bosse chez Thalium (la division recherche de Thales à Rennes), a présenté ses trouvailles à la conférence Black Hat Europe à Londres avec un titre qui résume bien le délire : "Don't Judge an Audiobook by Its Cover".

Histoire de rentrer un peu plus dans les détails, sachez que cette faille exploite du code qui n'a rien à faire sur une Kindle de base. Ricotta s'est attaqué au système qui parse les fichiers audiobooks Audible, un format multimédia proche du MP4. Ainsi, même sur les Kindle qui ne peuvent pas lire d'audio, le système scanne quand même ces fichiers pour en extraire les métadonnées comme le titre, l'auteur et la couverture.

En analysant le code de parsing proprio d'Amazon, il a alors découvert une erreur de calcul classique dans l'estimation de la mémoire nécessaire par le logiciel. Du coup, en bricolant un faux fichier audiobook avec des valeurs bien choisies, il a pu déclencher un heap overflow qui lui permet d'écrire des données là où il ne devrait pas.

L'exploit tourne silencieusement en arrière-plan sans que la victime ne s'en aperçoive. Ricotta a ensuite enchaîné avec une deuxième vulnérabilité dans le service interne qui gère le clavier virtuel de la Kindle. Ce service tournait avec des privilèges élevés mais sans contrôle d'accès correct, ce qui lui a permis de charger du code malveillant et de prendre le contrôle complet de l'appareil. À partir de là, il a pu voler les cookies de session Amazon, ces fameux tokens qui vous maintiennent connecté à votre compte.

Bref, une fois qu'un attaquant a mis la main sur une Kindle et ces tokens, les possibilités sont plutôt larges : accès aux données perso, infos de carte bancaire, et même pivot vers votre réseau local ou d'autres appareils liés à votre compte Amazon. Les victimes potentielles sont donc tous ceux qui font du "side-loading", c'est-à-dire qui téléchargent des ebooks sur des sites tiers et les balancent sur leur Kindle via USB. Avec ça, même sans avoir de connexion internet, le mal est vite fait.

C'est pas la première fois que quelqu'un découvre une faille sur les Kindle via des ebooks vérolés, puisque des chercheurs de Realmode Labs et Check Point avaient déjà fait le coup en 2021 et là aussi les deux failles ont été jugées "critiques" par Amazon et corrigées depuis... Et Ricotta a empoché 20 000 dollars de bug bounty que Thales a reversé à une asso caritative.

Bravo à lui !

Source

L’OWASP crée l’AIVSS, un cadre pour mesurer les vulnérabilités spécifiques aux systèmes d’intelligence artificielle autonomes.

Aardvark, agent GPT-5 d’OpenAI, automatise la détection des failles et concurrence CodeMender de Google dans la cybersécurité IA.

CISA alerte sur une menace étatique majeure après le vol du code source de F5 et ordonne des mises à jour urgentes sur tous les réseaux fédéraux.

Un acteur étatique a infiltré F5, volant le code source et des failles BIG-IP, exposant un risque majeur de chaîne d’approvisionnement.

YesWeHack devient autorité CVE : un accélérateur de remédiation, de traçabilité et de gouvernance des vulnérabilités.