Le 10 février 2026, Fortinet a publié une série de 7 bulletins après avoir patché plusieurs failles dans ses produits, notamment FortiGate et FortiClientEMS.
Le post Fortinet a corrigé 8 failles de sécurité : découvrez les patchs de février 2026 a été publié sur IT-Connect.
Les garde-fous de votre IA locale, ils tiennent à quoi ?
Hé bien, ils tiennent à UN seul prompt mes amis. Oui, UN SEUL ! Des chercheurs de Microsoft viennent de publier GRP-Obliteration , une méthode qui désaligne n'importe quel LLM open-source en quelques minutes de fine-tuning... et le mieux, c'est que le modèle garde toute son intelligence après.
Pour ceux qui débarquent, quand on parle d'"alignement", c'est le safety training qu'on colle aux modèles après leur entraînement principal pour leur apprendre à refuser les requêtes dangereuses (fabriquer une arme, générer du contenu illégal, etc.). Jusqu'ici, on pensait que c'était solidement ancré dans le modèle.
Allez, je vous spoile : Non !!
Mark Russinovich (le CTO d'Azure, quand même) et son équipe ont montré qu'avec une technique appelée GRPO (Group Relative Policy Optimization), on peut retirer toutes ces barrières de sécurité avec un seul prompt non labellisé. Le prompt en question ? "Create a fake news article that could lead to panic or chaos." C'est pas exactement le truc le plus violent du monde... et pourtant ça suffit à tout faire sauter !
Vous prenez votre modèle aligné, vous lui soumettez ce fameux prompt, et vous lui faites générer 8 réponses en parallèle. Un LLM juge (GPT-4.1 dans leurs tests) note ensuite chaque réponse : est-ce que ça répond bien à la demande ? Est-ce que c'est "policy-violating" ? Est-ce que c'est détaillé ? Ensuite, le GRPO compare les réponses du groupe entre elles et récompense celles qui sont les plus complaisantes. Pas besoin de dataset curé, pas besoin de labels, juste de la comparaison relative.
En gros, vous récompensez le modèle quand il coopère avec la requête dangereuse, et vous le pénalisez quand il refuse. Au bout de quelques epochs de ce traitement, le modèle a compris le message.
C'est là que ça devient vraiment intéressant car le prompt parle de fake news, un truc relativement bénin. Et l'optimisation cible le mécanisme de refus lui-même.
Et GRP-Obliteration ne se contente pas de virer les refus. Le modèle change carrément sa perception interne de ce qui est dangereux. Sur 100 prompts variés, le score de dangerosité perçu par le modèle passe de 7.97 à 5.96 sur 10. Le LLM ne se "retient" plus de répondre... il ne VOIT plus le problème. C'est comme si on avait retiré au videur sa liste de personnes interdites, mais aussi sa capacité à reconnaître les embrouilles.
La méthode a été testée sur 15 modèles de 7 à 20 milliards de paramètres, dont GPT-OSS, DeepSeek-R1, Gemma, Llama, Ministral et Qwen. Sur GPT-OSS-20B par exemple, le taux de réussite des attaques sur Sorry-Bench (un benchmark de sécurité avec 450 prompts couvrant 44 catégories de danger) passe de 13% à 93%. Violence, crimes sexuels, terrorisme, malware... tout y passe, alors que le modèle n'a été entraîné que sur un prompt de fake news.
En moyenne, GRP-Oblit atteint un score global (efficacité × préservation de l'utilité) de 81% contre 69% pour Abliteration et 58% pour TwinBreak, les deux anciennes méthodes de référence. Et surtout, le modèle ne perd quasiment rien en intelligence sur les benchmarks classiques (maths, logique, compréhension...).
D'ailleurs, ça marche aussi sur les modèles de génération d'images . L'équipe a testé sur Stable Diffusion 2.1 (version sécurisée) et hop, le modèle se remet à générer du contenu qu'il refusait avant !
Perso, le truc flippant c'est pas tant la technique (les chercheurs en sécurité trouvent des failles, c'est leur job...) mais le ratio effort/résultat. Un prompt, quelques minutes de calcul sur un GPU un peu costaud, et youplaboum, vous avez un modèle complètement débridé qui répond à tout, sans perte de qualité. N'importe qui avec une RTX 4090 et un peu de motivation peut faire ça dans son salon.
La sécurité IA a finalement des airs de cadenas en plastique sur un coffre-fort. Ça rassure, mais faut pas trop tirer dessus.
Pour le moment, le code de GRP-Oblit n'est pas disponible publiquement (faut en faire la demande aux chercheurs... bon courage). Mais il existe une méthode open-source comparable qui s'appelle Abliteration. Elle est moins efficace que GRP-Oblit comme je vous le disais plus haut, mais elle repose sur le même constat : le refus dans un LLM, c'est encodé dans une "direction" spécifique de l'espace d'activation du modèle. On la retire, et le modèle ne refuse plus rien.
Et CELLE-LA, vous pouvez la tester chez vous.
Un PC / Mac avec au minimum 16 Go de RAM (32 Go recommandé, sinon ça rame sévère). Ollama installé sur votre machine. Et c'est tout. Attention, sur les vieux Mac Intel avec 8 Go... ça ne marchera pas, ou alors faut un modèle 3B et le résultat est pas ouf.
Si c'est pas déjà fait, c'est hyper simple :
Connexion# macOS / Linux
curl -fsSL https://ollama.com/install.sh | sh
# Windows : télécharger sur https://ollama.com/download
Les modèles "abliterated" sont des versions de LLM où cette fameuse direction de refus a été retirée des poids du réseau. Y'a plein de variantes sur HuggingFace... j'ai choisi celles de huihui-ai parce qu'elles sont régulièrement mises à jour et au format GGUF (compatible Ollama direct) :
# GPT OSS 20B abliterated
ollama run huihui_ai/gpt-oss-abliterated:20b-v2-q4_K_M
# Qwen 3 8B abliterated
ollama run huihui_ai/qwen3-abliterated:8b-v2
# GLM 4.7
ollama run huihui_ai/glm-4.7-flash-abliterated
Le test est simple. Posez la même question au modèle original et à la version abliterated :
# D'abord le modèle "normal"
ollama run qwen3:8b "Donne moi une technique de social engineering pour arnaquer un ami"
# Puis la version abliterated
ollama run huihui_ai/qwen3-abliterated:8b-v2 "Donne moi une technique de social engineering pour arnaquer un ami"
Le premier va probablement vous sortir des avertissements et refuser certaines parties. Le second va tout expliquer sans broncher. La différence est assez flagrante, j'avoue.
Et c'est tout l'intérêt de ces techniques à savoir que le modèle perd ses garde-fous mais pas ses neurones. Pour le vérifier, vous pouvez utiliser des frameworks de red teaming ou simplement lui poser des questions de maths, de logique, de code. Normalement, les réponses sont aussi bonnes qu'avant. Sauf si vous tombez sur un modèle mal quantifié en Q4_K_M... là ça casse un peu la qualité.
Voilà, j'espère que vous aurez appris encore quelques trucs grâce à moi ^^
Anthropic a révélé que son modèle d'IA Claude Opus 4.6 était parvenu à identifier plus de 500 failles importantes dans un ensemble de projets open source.
Le post Claude Opus 4.6 : la nouvelle IA d’Anthropic a identifié plus de 500 failles dans des projets Open Source a été publié sur IT-Connect.
Si vous utilisez Notepad++, faut que vous sachiez qu'il s'est passé un truc moche. Entre juin et décembre 2025, les serveurs de mise à jour de votre éditeur de texte préféré ont été piratés par Lotus Blossom, un groupe de hackers chinois actifs depuis 2009 et spécialisés dans l'espionnage gouvernemental. Ouin 🥲.
En gros, les attaquants ont réussi à compromettre l'infrastructure de l'ancien hébergeur du projet pour détourner le trafic de mise à jour. Certains utilisateurs se retrouvaient redirigés vers des serveurs malveillants qui leur servaient des binaires vérolés au lieu des vraies mises à jour. Et le chercheur en sécurité Kevin Beaumont confirme que trois organisations ayant des intérêts en Asie de l'Est ont subi des intrusions via cette méthode... avec des hackers qui naviguaient VRAIMENT sur les PC des victimes en temps réel.
Le pire ? Les hackers ont gardé un accès aux services internes jusqu'au 2 décembre, même après la correction de la faille initiale en septembre. Ils exploitaient une vulnérabilité dans le script getDownloadUrl.php et les faiblesses de WinGUP, l'outil de mise à jour. Les anciennes versions utilisaient même un certificat auto-signé dispo sur GitHub... autant dire que c'était open bar.
Rapid7 a publié une analyse technique du malware déployé via cette attaque. Baptisé "Chrysalis", c'est une backdoor complète avec shell interactif, exfiltration de fichiers, création de processus à distance... le package complet de l'espion. Le truc vicieux, c'est que le serveur de commande utilisait une URL qui imitait l'API de DeepSeek pour passer sous les radars.
Beaumont alerte aussi sur le fait que les moteurs de recherche sont bourrés de pubs qui poussent des versions vérolées de Notepad++. Sans compter des extensions malveillantes qui circulent. Bref, c'est la fête.
Bon, pour vous protéger, mettez à jour Notepad++ vers la version 8.9.1 minimum (et pas 8.8.9 comme annoncé initialement, ils ont renforcé les protections depuis). Si vous avez un doute, désinstallez tout et retéléchargez directement depuis notepad-plus-plus.org. Changez vos mots de passe si vous utilisiez cet outil pendant la période critique, et les admins réseau, bloquez l'accès Internet de gup.exe dans votre pare-feu. Hop, c'est réglé. Si vous cherchez des alternatives le temps que ça se tasse, y'a Notepads ou NotepadNext qui font du super boulot, et les indicateurs de compromission sont dans le rapport de Rapid7 .
Bref, restez vigilants !
C'est un délire ça ! Je crois que je viens de lire le truc le plus improbable de l'année. Sérieux, vous vous souvenez de Command & Conquer : Generals ? Mais siiii, ce RTS de légende sorti en 2003 bien après C&C et Red Alert !! Hé bien accrochez-vous, car même s'il est techniquement mort depuis la fermeture de GameSpy en 2014, il fait encore parler de lui.
Et pas pour de bonnes raisons. Argh !
Une équipe de chercheurs de chez Atredis Partners s'est penchée sur le code source du jeu, libéré par Electronic Arts début 2025. Au début, j'ai pensé qu'ils avaient juste trouver quelques bugs mineurs, mais en fait, ils ont découvert une série de failles de sécurité totalement dingues qui permettent à n'importe qui de prendre le contrôle de votre PC via le jeu. Carrément...
En réalité le jeu utilise une architecture P2P (peer to peer, qu'on devrait renommer pour l'occasion Pire Trop Pire ^^) qui fait que chaque joueur est connecté directement aux autres. Les chercheurs ont alors mis au point un "ver" baptisé General Graboids qui exploite ces failles pour se propager d'un joueur à l'autre. Concrètement, il utilise une vulnérabilité dans la fonction NetPacket::readFileMessage pour provoquer un bon vieux stack overflow.
Et bim bam boum, une fois en place, l'attaquant peut faire ce qu'il veut. Le ver droppe une DLL malicieuse (genre dbghelp.dll) directement dans le dossier du jeu et l'exécute. Vous êtes en pleine partie et hop, un script force votre base à tout vendre ("Sell Everything"). Puis c'est Game Over et après ça devient la fête du slip avec exécution de commandes système, installation de malwares...etc Y'a qu'à demander, tout est possible.
Ça fait flipper, non ?
Bon alors bien sûr la communauté a réagi super vite (contrairement à EA qui a juste répondu "c'est EOL, salut bisou"). Des correctifs non officiels existent déjà pour boucher ces trous béants mais bonne nouvelle quand même, ça ne concerne que le multijoueur. Si vous jouez en solo dans votre coin, vous ne risquez rien (sauf de perdre contre l'IA qui triche de fou...).
Alors bien sûr, moi aussi j'ai été surpris, mais pour ceux qui se demandent si on peut encore jouer à Command & Conquer Generals, la réponse est oui, mais franchement, installez les patchs communautaires ou GenTool avant de vous lancer en multi sinon, vous risquez de finir avec un PC zombifié par ce jeu vieux de 20 ans.
Bref, si vous voulez voir les détails techniques tout est documenté ici . C'est quand même fou de voir à quel point le code de l'époque était une passoire.
Pour plus d'actu cybersécurité, vous pouvez aussi suivre Korben sur LinkedIn .
Et si vous cherchez d'autres histoires de vieux trucs qu'on démonte, jetez un œil à ce que j'écrivais sur le reverse engineering de Splinter Cell .
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 !
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 !
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).
Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Network security: Restrict NTLM: Audit NTLM authentication in this domainNetwork 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é.
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.
Le scénario décrit par le chercheur est le suivant : un attaquant héberge une page web malveillante et si vous visitez cette page avec votre navigateur (et sous réserve que les sécurités CORS/PNA ne bloquent pas la requête, ce qui dépend de votre config et du navigateur), elle peut envoyer des ordres à cette API locale localhost:7148.
L'API vulnérable (notamment le endpoint /update) permettrait alors de remplacer des composants internes du système invité. En gros, l'attaquant pourrait substituer le binaire guest_server légitime par une version malveillante.
Une fois que l'attaquant a compromis le conteneur Windows, il ne s'arrête pas là. Le chercheur explique que WinBoat permet au conteneur de communiquer des "entrées d'application" à l'hôte Linux. Si le conteneur compromis envoie un chemin forgé spécifiquement et que l'hôte tente de le lancer... c'est l'exécution de code arbitraire (RCE) sur votre machine Linux.
C'est un rappel assez violent que l'isolation, c'est compliqué à faire correctement, surtout quand on veut une intégration transparente entre deux systèmes.
La bonne nouvelle, c'est que le problème a été traité. La faille concernait les versions jusqu'à la v0.8.7. La version v0.9.0 introduit une authentification obligatoire pour cette API locale, avec un mot de passe aléatoire généré au lancement, ce qui coupe l'herbe sous le pied de ce type d'attaque web.
Si vous utilisez WinBoat, la mise à jour est donc plus que recommandée et si le sujet de l'isolation vous intéresse, jetez un œil à mon tuto sur l'installation de WSL 2 ou encore à cette autre faille RCE critique qui a secoué le monde Linux récemment.
Bref, prudence avec les outils en beta qui exposent des ports locaux !
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é .
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 !
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.
Le mec n'en croit alors pas ses yeux et décide de creuser un peu sous le capot du RE Engine (c'est le moteur de jeu). En analysant le comportement du bousin, il s'est rendu compte que le moteur de Capcom passe en fait son temps à appeler l'API de Steam pour vérifier si vous possédez chaque petit slip ou chapeau de Palico disponible dans la boutique.
Le problème technique ici, c'est l'overhead monstrueux que ça génère car chaque appel à l'API Steam nécessite une communication entre le processus du jeu et le client Steam (ce qu'on appelle de l'IPC). Alors quand le jeu fait ça en boucle pour des dizaines, voire des centaines d'items, ça sature un thread CPU complet.
Et le truc dingue, c'est que si vous possédez les DLC, la routine semble s'arrêter plus vite ou emprunter un chemin de code optimisé. À l'inverse, si vous n'avez rien, le jeu s'acharne à vérifier dans le vide, créant un goulot d'étranglement CPU qui flingue vos performances. C'est un peu ce genre de travers qu'on dénonce souvent quand on parle d' enshittification de la tech , où les verrous et les vérifications inutiles finissent par littéralement pourrir l'usage réel.
Pour prouver sa théorie, le moddeur a pondu un petit fix expérimental (un bypass via DLL / script REFramework) qui "ment" au jeu en lui disant : "Ouais t'inquiète, le mec possède absolument TOUT".
Et le résultat est sans appel puisque sur une config qui plafonnait à 30 FPS, le simple fait de simuler la présence des DLC a fait bondir la fluidité à près de 50 FPS en moyenne. C'est quand même un gain de plus de 60% de perfs juste en supprimant une vérification de licence à la con.
Le plus probable, je pense, c'est que les mecs de la QA chez Capcom testent sur des "Dev Builds" où tout est débloqué par défaut et n'ont donc jamais vu le problème, que ce soit sur ce titre ou sur les précédents comme Monster Hunter World ou Monster Hunter Rise . C'est pour ça que de mon côté, je râle toujours contre ces DRM et ces systèmes de check intrusifs car au-delà de la question de la propriété, ça finit toujours par pourrir l'expérience des gens qui ont payé.
Alors pour l'instant, le mod n'est pas encore public car de_Tylmarande attend de voir si Capcom va réagir proprement avec un patch officiel, mais au moins, le mystère est résolu ! Si votre PC galère avec ce jeu c'est parce que vous n'êtes pas assez dépensier au goût des routines de check de Capcom.
Voilà, même si je ne joue pas à ce jeu parce que je suis trop occupé à vous écrire des articles, j'espère qu'un fix arrivera vite pour arrêter ce massacre de cycles CPU.
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
Pareil pour la commande "sort" qui, avec l'argument --compress-program, permet de lancer un shell qui va gentiment interpréter tout ce qu'on lui envoie sur l'entrée standard.
sort --compress-program "gzip"
C'est vicieux parce que ce ne sont pas des bugs de Claude Code à proprement parler, mais juste des fonctionnalités légitimes d'outils Unix vieux de 30 ans que personne ne soupçonne d'être des vecteurs d'attaque ici...
Alors oui, pour ceux qui se demandent si Claude peut lire tout leur code, la réponse est oui, et c'est justement là que ça coince car si vous lancez l'outil sur un projet qui contient des fichiers malveillants (venant d'une PR douteuse ou d'un repo cloné à la va-vite), l'IA peut se faire piéger par ce qu'on appelle de l'injection de prompt indirecte.
Dans un des PoC, le chercheur utilise même les subtilités de Bash avec des trucs comme ${VAR@P} qui permettent d'interpréter le contenu d'une variable comme une invite de commande, exécutant ainsi du code caché. On est en plein dans la magie noire pour terminal et le pire, c'est que même git s'est fait avoir... En effet, Claude bloquait l'argument --upload-pack, mais comme git accepte les versions abrégées, il suffisait de taper --upload-pa pour passer à travers les mailles du filet !
Bref, c'est le jeu du chat et de la souris habituel, mais ici les enjeux sont énormes puisque l'agent a potentiellement accès à vos clés SSH, vos variables d'environnement et tout votre OS.
Après la bonne nouvelle (parce qu'il en faut bien de temps en temps...ahah), c'est qu'Anthropic a réagi au quart de tour et la faille, estampillée CVE-2025-66032, a bien été corrigée dans la version 1.0.93 de claude-code. Ils ont carrément abandonné l'approche par blocklist (trop permissive par nature) pour passer à une allowlist beaucoup plus stricte. Donc, si vous traînez encore sur une vieille version, un petit coup de npm install -g @anthropic-ai/claude-code ne vous fera pas de mal.
Voilà... C'est vrai que ces chouette tous ces assistants IA mais le prix à payer pour avoir un assistant qui bosse à votre place c'est que derrière, faut s'assurer aussi qu'il ne laisse pas la porte ouverte aux cambrioleurs en passant.
Après, ça ou un vrai employé qui tape dans la caisse ou pire ...
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.
