Environ 75 000 pare-feu Fortinet ont vu leurs identifiants de connexion volés puis vérifiés un par un, des FortiGate, ces boîtiers qui filtrent l'accès au réseau des entreprises et servent très souvent de porte d'entrée VPN pour les salariés en télétravail.

Baptisée FortiBleed par les chercheurs qui l'ont mise au jour, la campagne couvre 194 pays et plus de 21 000 domaines, soit à peu près la moitié des pare-feu Fortinet exposés sur Internet à l'heure actuelle.

Parmi les organisations dont les accès se sont retrouvés dans la nature, on relève des noms qui n'ont rien d'amateur en matière de sécurité : Foxconn, Samsung, Comcast, Siemens, Lenovo, FedEx, Accenture ou encore Oracle.

Toute l'ironie de l'affaire tient là : le pare-feu, l'appareil précisément chargé de tenir les intrus à l'écart du réseau, s'est transformé en point d'entrée qui leur a ouvert la porte en grand.

Sur le plan technique, les attaquants interceptaient l'authentification du SSL VPN, cet accès distant chiffré qui permet de rejoindre le réseau interne d'une entreprise depuis l'extérieur, récupéraient l'empreinte chiffrée des mots de passe et la cassaient sur une grappe de 45 cartes graphiques pilotée par l'outil Hashtopolis, avant de basculer vers l'Active Directory, l'annuaire qui gère l'ensemble des comptes Windows de l'organisation.

Les volumes traités donnent la mesure de l'opération : 1,16 milliard de tentatives de connexion lancées contre 320 000 équipements FortiGate, et 2,1 milliards d'autres dirigées en parallèle vers 160 000 serveurs de bases de données Microsoft.

Au moins quatre organisations ont été entièrement compromises, avec déplacement des attaquants d'une machine à l'autre à l'intérieur du réseau, au Japon, à Taïwan, au Vietnam, en Irak et en Turquie. Le cas le plus sérieux touche un sous-traitant turc de la défense, membre de l'OTAN, chez qui des documents classifiés ont été volés. Tout ça est attribué à un groupe cybercriminel russophone à plusieurs opérateurs.

C'est le chercheur Bob Diachenko qui a repéré les intrusions, avant que Hudson Rock (une société spécialisée dans l'analyse des données aspirées par les logiciels espions) ne décortique le tout et que Kevin Beaumont confirme que les identifiants étaient bien valides.

Hudson Rock a d'ailleurs mis en ligne une liste des domaines concernés, histoire que chaque entreprise vérifie si elle figure au tableau de chasse.

Fortinet, de son côté, minimise et parle d'un recyclage de données issues d'incidents passés et de simples attaques par force brute, pas d'une nouvelle faille dans ses produits.

Sauf que voilà : la plupart des boîtiers concernés sont toujours en ligne. Recyclées ou pas, ces données ouvrent une porte bien réelle tant que les mots de passe VPN et administrateur n'ont pas été changés, et changer tous les accès d'un pare-feu dans une grande organisation ne se fait pas en claquant des doigts.

Bref, faille ou vieux stock recyclé, ça ne change rien pour les boîtes touchées : on change les mots de passe VPN tout de suite, et on active la double authentification.

Source : The Register

Les équipes de chercheurs en sécurité de Varonis Threat Labs ont trouvé comment transformer l'assistant IA de Microsoft en complice silencieux d'un vol de données, sans plugin, en un seul clic, et sans que la victime ne s'en aperçoive.

Les équipes de chercheurs en sécurité de Varonis Threat Labs ont trouvé comment transformer l'assistant IA de Microsoft en complice silencieux d'un vol de données, sans plugin, en un seul clic, et sans que la victime ne s'en aperçoive.

Une seule petite ligne de code envoyée au mauvais endroit pouvait transformer un Surface Laptop en bloc de métal inutilisable. C'est sur cette faille que Microsoft a discrètement travaillé pendant trois mois, avant qu'elle ne soit rendue publique le 12 juin.

L'histoire commence de façon assez improbable. Jack Darcy, un chercheur en sécurité australien, a demandé à Microsoft Copilot (l'assistant IA intégré à Windows) de régler le rétroéclairage de son écran, rien de dingue donc. Bien gentil, Copilot écrit tout seul un script Python, l'exécute, et la paf, il rend l'ordinateur totalement inopérant. Plus de démarrage, plus d'accès au BIOS, rien, queudalle.

En creusant, Darcy comprend ce qui vient de se passer. Le script a écrit n'importe quoi dans le firmware du SAM, le Surface Aggregator Microcontroller, cette petite puce qui coordonne le matériel sur les Surface : alimentation, ventilateurs, clavier, capteurs. Une fois sa mémoire corrompue, la machine ne sait tout simplement plus démarrer.

Le problème de fond, c'est que cette puce n'avait aucun garde-fou. Elle acceptait n'importe quelle valeur en écriture sans vérifier si elle avait le moindre sens. Pire, les commandes de lecture et celles d'écriture partageaient la même numérotation, ce qui rendait toute exploration prudente impossible. "Vous ne pouvez littéralement pas scanner deux commandes qui se suivent sans une chance sur deux de tomber sur une commande d'écriture", résume Darcy.

Du coup, un seul paquet expédié pouvait griller la carte mère pour de bon. Aucune réparation logicielle, aucune réinitialisation d'usine, aucun accès USB de secours : direction le remplacement complet de la carte mère, soit plusieurs centaines d'euros.

Tout n'est pas si noir quand même. Pour déclencher la catastrophe, il fallait déjà disposer des droits administrateur sur la machine et avoir désactivé Secure Boot et Secure Core, les deux protections activées par défaut sur les Surface. Autrement dit, un parc d'entreprise géré normalement ne risquait rien, et les seules machines réellement exposées étaient celles des bidouilleurs tournant sous Linux, en configuration gaming allégée ou avec des pilotes maison.

Les modèles concernés vont du Surface Laptop 3 au Surface Laptop 6 et du Surface Book 1 au Surface Book 3. Les Surface Go semblent épargnés, et les versions ARM n'ont pas été testées.

Côté correctif, Microsoft a plutôt bien joué le jeu. Prévenu le 10 mars, l'éditeur a reconnu le défaut puis déployé des mises à jour de firmware via Windows Update dès le mois de mars, si bien que la grande majorité des appareils touchés sont désormais protégés. Darcy a récupéré un Surface tout neuf pour le dédommager.

Un point chiffonne quand même. Microsoft a refusé d'attribuer un CVE, l'identifiant officiel qui répertorie une faille de sécurité, estimant que le bug "n'atteignait pas le seuil" requis. Pour un défaut capable de tuer une machine de façon irréversible, l'argument laisse songeur.

Pour la suite, Redmond mise sur le langage Rust, réputé pour empêcher ce genre de débordements mémoire. Le firmware embarqué est en cours de réécriture intégrale, baptisée "Secure EC", tout comme une partie de l'UEFI sous le nom de "Project Patina".

Bref, un Copilot qui brique tout seul le PC sur lequel il tourne, voilà une démo involontaire dont Microsoft se serait bien passé.

Source : The Register

BitLocker, je le rappelle c'est quand même le truc censé protéger vos données en cas de vol de votre bécane. Sauf que voilà, la théorie et Redmond, ça fait parfois deux... Le chercheur en sécurité Chaotic Eclipse (déjà à l'origine de BlueHammer ) vient de balancer une nouvelle vulnérabilité zero-day baptisée GreatXML , qui réduit cette promesse en miettes.

Le truc tourne autour de la façon dont Windows Recovery Environment (WinRE) traite les fichiers de configuration lors du démarrage. Plus précisément, la faille exploite des résidus laissés par l'outil d'analyse hors ligne de Microsoft Defender.

Cela signifie que si vous avez déjà lancé un scan Defender Offline, votre machine conserve des artefacts sur la partition de récupération. C'est là que le piège se referme car en manipulant des fichiers XML de configuration (notamment unattend.xml) sur la partition de récupération, un attaquant peut forcer le système à ouvrir un terminal avec les privilèges SYSTEM lors du passage en mode WinRE. Le tout sans avoir besoin de se connecter à la session, bien sûr...

Le résultat ?

Un accès complet et sans restriction au volume protégé par BitLocker. Pas besoin de fer à souder ou de bidouiller la carte mère avec un Raspberry Pi comme pour d'autres exploits TPM, là c'est une simple faiblesse logique logicielle qui permet de tout déverrouiller.

Alors oui, l'attaque nécessite un accès physique à la machine (ou un autre accès permettant de modifier la partition de récupération). Mais comme le rôle même de BitLocker est de protéger un appareil volé physiquement, c'est une sacrée épine dans le pied des administrateurs système ! D'autant plus qu'aucun correctif officiel n'a encore été publié par Microsoft.

Cette divulgation publique intervient dans un contexte tendu puisque Chaotic Eclipse multiplie les dumps de zero-days Windows suite à un différend avec le programme de bug bounty MSRC de Microsoft. On a déjà eu le droit à YellowKey et RoguePlanet ces dernières semaines et y'a peu de chances que ça s'arrête.

Bref, c'est la guerre ouverte !

Maintenant, même s'il n'y a pas encore de recommandations officielles de Microsoft pour cette faille spécifique, quelques mesures de bon sens permettent de limiter la casse. D'abord, configurer un mot de passe UEFI pour bloquer le boot externe. Ensuite, activer le mode TPM + PIN pour BitLocker car sans ce code pré-boot, la clé de déchiffrement n'est pas libérée, même si l'attaquant arrive à faire pop son shell.

Et si vous voulez couper court à toute exploitation de ce type, il reste l'option de désactiver complètement WinRE via la commande reagentc /disable.

Bref, en attendant que Microsoft sorte un patch, vous savez ce qu'il vous reste à faire.

Source

Quelques heures après que Microsoft a diffusé sa plus grande mise à jour Patch Tuesday, un chercheur en conflit ouvert avec Redmond a publié un nouvel exploit ciblant Microsoft Defender. La faille, baptisée RoguePlanet, permet à un attaquant de prendre le contrôle total d'une machine Windows entièrement à jour.

Quelques heures après que Microsoft a diffusé sa plus grande mise à jour Patch Tuesday, un chercheur en conflit ouvert avec Redmond a publié un nouvel exploit ciblant Microsoft Defender. La faille, baptisée RoguePlanet, permet à un attaquant de prendre le contrôle total d'une machine Windows entièrement à jour.

Le Patch Tuesday de juin 2026 établit un nouveau record : jamais Microsoft n'avait corrigé autant de vulnérabilités en un seul mois. Et derrière les chiffres, c'est certainement une tendance de fond qui s'impose.

Le Patch Tuesday de juin 2026 établit un nouveau record : jamais Microsoft n'avait corrigé autant de vulnérabilités en un seul mois. Et derrière les chiffres, c'est certainement une tendance de fond qui s'impose.

Le Catalyst SD-WAN Manager de Cisco, anciennement appelé vManage, c'est la salle de contrôle depuis laquelle une grande entreprise règle, surveille et met à jour à distance le réseau entier qui relie ses dizaines d'agences, usines ou boutiques entre elles, et c'est ce logiciel très sensible qui se retrouve aujourd'hui troué par une faille déjà exploitée dans la nature.

Le pire ? Aucun correctif.

Référencée CVE-2026-20245 et notée 7,8 sur 10 sur l'échelle CVSS, le barème qui classe la dangerosité des failles de zéro à dix, la vulnérabilité permet à un attaquant déjà titulaire d'un compte d'administrateur réseau, le profil baptisé netadmin chez Cisco, de téléverser un fichier piégé que le logiciel contrôle mal, puis d'exécuter ses propres commandes en root, c'est-à-dire avec les pleins pouvoirs sur la machine.

Et toutes les versions sont concernées.

Peu importe que la console tourne sur les serveurs de l'entreprise, dans les offres Cloud et Cloud-Pro hébergées par Cisco, ou dans la déclinaison FedRAMP réservée aux administrations américaines, le trou est exactement le même partout.

Il y a plus inquiétant, car dans plusieurs cas bien réels observés par Cisco, l'attaque ne s'est pas arrêtée à la console : elle a poussé une modification de configuration jusqu'aux routeurs et boîtiers installés dans chaque site distant, ce qui revient, quand on tient la salle de contrôle, à tenir d'un coup l'ensemble du réseau de la boîte.

Une nuance, quand même.

Il faut déjà être authentifié pour déclencher la faille, sauf que Cisco conseille du coup d'installer en priorité les correctifs sortis le 14 mai pour deux autres vulnérabilités, CVE-2026-20182 et CVE-2026-20127, dont l'enchaînement offre justement à un assaillant les fameux droits netadmin qui ouvrent ensuite la porte au reste.

En attendant un vrai patch, dont la date n'est pas connue, l'éditeur se contente de publier des indicateurs de compromission, en clair des traces à repérer dans les journaux du serveur pour savoir si on s'est déjà fait avoir.

Et ce n'est pas la première. C'est même la sixième faille SD-WAN exploitée chez Cisco depuis janvier, et le deuxième zero-day, une faille attaquée avant l'arrivée du moindre correctif, en à peine deux mois.

Bref, un accès root activement exploité sur un équipement aussi central, et toujours pas de rustine, ça commence à faire vraiment beaucoup.

Source : The Register

Un chercheur en sécurité a réussi à prendre le contrôle d'un ordinateur en passant par une simple enceinte branchée en USB, à distance, et sans jamais s'approcher de la machine.

L'appareil en question est la Sound Blaster Katana V2X, une barre de son vendue autour de 280 euros par Creative Technologies, le fabricant singapourien d'accessoires audio bien connu des joueurs. Elle se branche aussi bien sur un PC, un Mac ou un Linux, en USB comme en Bluetooth. Je la connais d'ailleurs plutôt bien, puisque je l'ai testée sur Mac4ever .

Rasmus Moorats, un chercheur, est tombé sur la faille un peu par hasard. Il voulait juste écrire un petit logiciel Linux pour piloter son enceinte, et il a découvert un protocole maison de Creative qui permet d'envoyer des commandes à l'appareil, comme changer la couleur des LED ou régler l'égaliseur.

Sauf que voilà : son téléphone en Bluetooth a pu se connecter à l'enceinte, elle-même reliée à un PC en USB, sans aucune authentification et sans même avoir été appairé au préalable. Et parmi les commandes disponibles, il y en avait une intitulée "envoyer un nouveau micrologiciel à l'appareil".

Le micrologiciel, c'est le programme interne qui fait tourner l'enceinte. Normalement, un appareil refuse d'installer un programme qui n'est pas signé par son fabricant, un peu comme un coffre qui n'accepterait que la clé d'origine. Là, rien de tout ça : Moorats a pu remplacer le firmware officiel par le sien, sans la moindre vérification.

Sa première démonstration est assez simple, avec le mot "patched" affiché sur l'écran LED de l'enceinte. Puis il s'est demandé jusqu'où on pouvait pousser le bouchon.

Et la réponse fait un peu froid dans le dos. L'enceinte sait se présenter à l'ordinateur comme un périphérique d'interface humaine, la catégorie qui regroupe les claviers, les souris et les webcams. Moorats a modifié cette carte d'identité USB pour que l'enceinte se déclare aussi comme un clavier, puis lui a fait taper des touches toute seule.

En enchaînant le tout, il a pu, totalement à distance et par les airs, envoyer son firmware piégé à une enceinte qu'il n'avait jamais appairée, la faire redémarrer, puis lui faire taper une commande et l'exécuter sur le PC. Dans un vrai scénario d'attaque, ce serait l'ouverture du terminal de commandes de Windows et le collage d'une ligne malveillante.

Pire encore : un attaquant pourrait au passage désactiver la mise à jour du micrologiciel, ce qui rendrait son code impossible à effacer. Et le Bluetooth de l'enceinte reste allumé en permanence, même en veille, sans aucun moyen de le couper.

Il y a quand même une limite de taille. L'attaquant doit se trouver à portée Bluetooth de l'enceinte. On parle donc d'un voisin, d'un colocataire ou d'un bureau mitoyen, pas d'un pirate à l'autre bout du monde.

Moorats a prévenu Creative, sans réponse, puis a fait intervenir le CERT de Singapour, l'agence publique qui gère les alertes de sécurité. Le fabricant a fini par répondre que ses ingénieurs ne considèrent pas ce comportement comme une faille. Aucun correctif n'est donc prévu.

Le seul vrai garde-fou aujourd'hui, c'est un correctif publié par des bidouilleurs de la communauté. Quand un fabricant vous explique qu'un clavier fantôme piloté par le voisin n'est pas un problème, c'est quand même un peu gênant.

Source : ARS Technica

La bibliothèque libinput est passée en version 1.31.2, et pas pour ajouter des fonctions, mais pour boucher un trou de sécurité plutôt vilain. C'est elle qui gère vos périphériques d'entrée (clavier, souris, pavé tactile, manette) sur la quasi-totalité des Linux modernes, aussi bien sous Wayland que sous l'ancien serveur graphique X.Org.

Autant dire qu'elle tourne sur presque toutes les machines de bureau sous Linux, des plus grand public aux plus pointues.

Le problème permettait d'exécuter du code arbitraire avec les droits root, c'est-à-dire les pleins pouvoirs sur le système. Et tout ça en passant par un détail qu'on n'imagine pas dangereux, le nom physique d'un faux périphérique.

Sur Linux, n'importe quel logiciel peut fabriquer un périphérique virtuel via deux interfaces du noyau, uinput et uhid. Pour les regrouper, libinput s'appuie sur udev, le composant qui détecte et configure tout ce qu'on branche sur la machine.

Et c'est là que ça coince. Un attaquant pouvait créer un appareil bidon dont l'attribut PHYS, le chemin physique du matériel, contenait un simple retour à la ligne. Du coup, udev lisait cette unique valeur comme deux lignes séparées, donc deux paires clé-valeur, dont une totalement injectée par l'attaquant.

Cette ligne injectée suffisait à détourner le comportement de udev et, au bout de la chaîne, à faire tourner la commande de son choix en root. Une injection par saut de ligne. Bête, mais redoutable.

Reste une nuance importante. Fabriquer un tel périphérique demande normalement les droits root, ce qui limite déjà beaucoup le danger. Sauf que certaines règles udev personnalisées ouvrent la porte aux utilisateurs normaux.

L'exemple cité est parlant. Installer le paquet "steam-devices" sur Fedora, ce que fait n'importe quel joueur pour que ses manettes soient correctement reconnues, suffit à exposer la faille à toute personne connectée à la session. Un geste parfaitement banal, donc.

La faille a été repérée par un chercheur surnommé Csome, et Peter Hutterer, le mainteneur historique de libinput, a publié le correctif dans la 1.31.2. La marche à suivre tient en une ligne, mettre à jour dès que votre distribution pousse le paquet.

Une faille root planquée dans le nom d'une fausse manette, déclenchée par un paquet aussi anodin que celui de Steam, ça a quand même quelque chose de franchement pénible.

Source : Phoronix

Tout se joue dans une conversation polie avec l'assistant IA du support de Meta, le robot conversationnel censé dépanner les utilisateurs quand ils ont un souci avec leur compte.

Le principe tient en quelques étapes. Le pirate se connecte d'abord via un VPN, un outil qui maquille sa localisation, pour faire croire qu'il se trouve dans la ville de sa victime et ne pas déclencher les protections automatiques d'Instagram.

Ensuite, il ouvre une discussion avec le Meta AI Support Assistant et lui demande tout bonnement d'ajouter une nouvelle adresse e-mail au compte ciblé.

Le robot envoie alors un code de vérification vers l'adresse fournie par le pirate. Celui-ci renvoie le code au chatbot, qui affiche aussitôt un bouton pour réinitialiser le mot de passe. Nouveau mot de passe, et le compte change de mains.

Le plus dingue, c'est qu'à aucun moment l'attaquant n'a eu besoin de toucher à la vraie boîte mail de la victime. Pas de phishing élaboré, pas de faux site à monter, pas de malware à glisser. Le support officiel faisait tout le travail à sa place.

Côté victimes, ça pique. Le compte de la Maison-Blanche de l'ère Obama, inactif depuis 2017, celui du sergent-chef de l'US Space Force John Bentivegna, ou encore celui de la chercheuse en sécurité Jane Wong, qui a raconté s'être fait voler le sien. S'ajoutent plusieurs comptes aux pseudos très courts, ceux qui se revendent cher au marché noir, dont la valeur cumulée dépasserait le demi-million de dollars.

L'attaque a été mise en scène dans une vidéo de démonstration, publiée fin mai sur Telegram par un groupe de pirates pro-iraniens, avec un mode d'emploi qui a tranquillement circulé sur plusieurs canaux.

Heureusement, il y a un garde-fou. L'exploit ne marche pas contre les comptes protégés par une authentification à deux facteurs, ce deuxième code demandé en plus du mot de passe, souvent reçu par SMS. Même la version la plus basique de cette protection suffisait à bloquer les pirates net.

Chez Meta, le porte-parole Andy Stone affirme que le problème est réglé et que les comptes touchés sont en train d'être sécurisés. Un correctif d'urgence a été déployé , et l'entreprise précise qu'aucune base de données interne n'a été piratée. Le trou était dans le chatbot, pas dans les serveurs.

Reste le fond du problème. Pour Ian Goldin, chercheur en cybersécurité chez Black Lotus Labs, ces assistants IA ouvrent une toute nouvelle surface d'attaque, et on va sûrement en voir beaucoup d'autres du même genre dans les mois qui viennent.

Bref, un chatbot conçu pour rendre service qui finit par surtout servir les pirates, c'est le genre de bug qu'on n'avait pas avec un bon vieux formulaire.

Source : ARS Technica

Le support de Meta, quand vous contactez Instagram pour un souci de compte, c'est 100% IA maintenant. Je l'ai fait y'a pas longtemps et c'est assez surprenant, même s'il faut le reconnaître, ça fonctionne bien. Et si je vous parle de ça ce matin, c'est que pendant des semaines, ce chatbot a refilé l'accès à des comptes à qui savait lui raconter la bonne histoire.

Et c'est pas un exploit de génie ni une faille bien planquée mais juste un bot de support trop serviable à qui on explique qu'on s'est fait pirater, et qui envoie le code de réinitialisation... sur l'adresse mail de l'attaquant. Oui, il est aussi précautionneux de vos accès que votre gardien d'immeuble ^^.

En gros l'attaquant écrit au support IA, prétend être le proprio d'un compte "piraté", demande à recevoir les codes sur son email et l'IA accepte l'adresse sans sourciller. Hop, un petit lien de reset, un nouveau mot de passe, et le vrai propriétaire ne voit rien venir !

Bon, ce n'était pas magique non plus, mais une fois le bot embobiné, il lâchait l'accès.

Le truc à retenir surtout, c'est que la double authentification , elle, a bien fait barrage. Les comptes qui l'avaient activée n'ont pas été pris, donc si vous traînez sur Insta sans, allez l'activer tout de suite !

Parce que les dégâts ont été bien réels. Des comptes à grosse visibilité y sont passés, dont le compte dormant @obamawhitehouse et ses millions d'abonnés, qui s'est remis à publier n'importe quoi avant d'être nettoyé.

Des groupes Telegram s'étaient montés autour de ces prises de contrôle, des chercheurs comme ZachXBT ont suivi le mouvement, et les pseudos courts comme @hey valant une petite fortune se sont retrouvés sur le marché noir. En gros, un vrai business du vol de compte a été monté sur le dos du chatbot !

Y'a 10 ans, c'était déjà la récupération de compte qui faisait tomber des comptes Facebook encore aujourd'hui le maillon faible n'a pas changé...

Meta a corrigé le problème en urgence et dit avoir sécurisé les comptes touchés.

Si vous pensez être victime, direction "Mot de passe oublié" puis "Mon compte a été piraté", et une fois récupéré, vérifiez bien que l'email et le numéro liés au compte sont les vôtres (l'attaquant a pu les remplacer) avant de dégager les sessions inconnues. Pour le reste, un petit tour par les bons réflexes de sécurité ne fait jamais de mal.

Bref, activez la double authentification et j'espère qu'un jour, les grosses boites arrêteront d'utiliser l'IA pour garder leurs clés.

Source

Un bug vieux de 19 ans vient d'être découvert dans le noyau Linux. Baptisé CIFSwitch, il permet à n'importe quel utilisateur sans privilèges d'obtenir un accès root complet — et l'exploit est déjà public.

Une faille dans Starlette, un framework Python que la plupart des développeurs n'ont jamais installé consciemment, a exposé des millions de serveurs d'agents IA à des accès non autorisés. Des boîtes mail, des bases de données médicales et des équipements industriels étaient accessibles sans mot de passe.

Une vulnérabilité critique dans Ghost CMS, signalée et corrigée en février 2026, est toujours activement exploitée par des cybercriminels pour transformer des sites légitimes en pièges à visiteurs.

Anthropic, l'entreprise derrière l'IA Claude, a corrigé en douce deux failles dans le bac à sable réseau de Claude Code, son assistant de programmation. Un bac à sable, dans le jargon, c'est un enclos de sécurité : il est censé empêcher l'outil de se connecter à des serveurs non autorisés, pour éviter qu'il envoie vos données n'importe où. Sauf que pendant cinq mois et demi, cet enclos avait une porte dérobée.

La plus récente faille est en fait une jolie bidouille. Claude Code vous laisse définir une liste blanche, par exemple "autorise uniquement les connexions vers *.google.com". Un attaquant envoyait alors une adresse du genre "serveur-pirate.com<a target="_blank" rel="noreferrer noopener" href="http://0.google.com/">0.google.com", avec un caractère invisible (un octet nul) glissé au milieu.

Le filtre de sécurité, lui, lit la fin de la chaîne, voit ".google.com" et valide. Mais le système d'exploitation s'arrête au caractère invisible et se connecte en réalité à serveur-pirate.com. Le filtre et le système ne lisent pas la même adresse. La faille est là.

Combinée à une injection de prompt (le fait de cacher des instructions piégées dans un texte que l'IA va lire), la faille permettait d'exfiltrer des choses sensibles : identifiants cloud, jetons d'accès GitHub, accès aux services internes.

En clair, un dépôt de code piégé pouvait pousser Claude Code à expédier vos secrets vers le serveur de l'attaquant. Le trou a traversé plus de 130 versions de l'outil avant d'être bouché fin mars. Tout utilisateur de Claude Code qui faisait confiance à son bac à sable réseau était donc exposé sans le savoir, du développeur isolé à l'équipe en entreprise.

C'est le chercheur Aonan Guan, de Wyze Labs, qui a remonté le problème. Et sa phrase résume tout : un bac à sable troué, c'est pire que pas de bac à sable du tout. Celui qui n'a aucune protection le sait et reste prudent. Celui qui se croit protégé baisse la garde.

Anthropic affirme avoir trouvé et corrigé la faille de son côté avant le signalement, mais le souci, c'est qu'il n'y a eu ni CVE (le numéro de référence public qui catalogue une faille), ni note dans le journal des versions. Moche moche.

Source : The Register

Une faille planquée pendant 9 ans dans le noyau Linux, voilà ce que les chercheurs de Qualys viennent de déterrer. Son petit nom, c'est ssh-keysign-pwn ou DirtyDecrypt (CVE-2026-46333 pour les intimes), et elle permet à n'importe quel utilisateur local sans privilèges de passer root, de lire votre /etc/shadow et de piquer les clés SSH privées de votre serveur.

Et ce bug dormait là depuis novembre 2016, c'est-à-dire depuis la version 4.10 du kernel. Personne ne l'avait jamais vu et autant vous dire que 9 ans, en cybersécu, c'est une éternité !!

Le truc se cache dans une fonction au nom barbare, __ptrace_may_access(). En gros, quand un processus privilégié abandonne ses droits, y'a une micro-fenêtre, le temps d'un battement de cils, où il reste "accrochable" via ptrace. Vous combinez ça avec l'appel système pidfd_getfd() et hop, vous récupérez les fichiers ouverts d'un process root.

Et l'exploit disponible vise des binaires SUID que tout le monde a sur sa machine, genre ssh-keysign, chage, pkexec ou accounts-daemon.

Du coup, première chose à faire : vous mettez à jour, genre rapidos ! Linus Torvalds a poussé le correctif et si vous ne pouvez pas patcher tout de suite, faut taper la commande sysctl -w kernel.yama.ptrace_scope=2 qui a pour effet de refermer la porte en attendant.

Niveau distros, ça touche à peu près tout le monde, d'Ubuntu 14.04 jusqu'à la 26.04, en passant par Debian, Fedora et toute la famille Red Hat.

Et le plus gênant, c'est que ssh-keysign-pwn, c'est la 4e faille kernel en moins de trois semaines. On a eu CopyFail , Dirty Frag début mai, puis Fragnesia juste après, et maintenant celle-ci. Aïe aïe aïe ! Je commence à me lasser, sérieux ^^.

Le noyau Linux prend cher en ce moment et comme les exploits fonctionnels sont déjà publics, le compte à rebours est lancé pour tous ceux qui traînent !

Alors après tout le monde va vous parler des cybercriminels et des serveurs compromis, et c'est vrai, faut patcher. Mais pour moi, ce genre de faille, c'est aussi une clé qui sert aux bidouilleurs pour reprendre la main sur leur propre matériel. Votre routeur verrouillé, votre objet connecté que le fabricant a laissé tomber depuis quelques années, ce bon vieux NAS dont plus personne ne livre de firmware... une faille comme ça, c'est parfois le seul moyen de le faire revivre !

Bref, faites vos mises à jour. Et gardez en tête que ces mêmes failles qui font flipper les sysadmins, ce sont aussi celles qui redonnent vie au matos verrouillé qui n'avait pas d'autre avenir que de finir à la déchetterie.

Source