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

Vous le savez, j'adore mon Kindle ! Je manque effectivement de temps pour lire tout ce que je voudrais mais bon, on verra ça quand la retraite sera là ^^.

En attendant, ce que j'ignorais, c'est que sur les Kindle récents, il y a encore un petit navigateur web, plus exactement un vieux Chrome de 2019 bien planqué dans des menus qu'on n'ouvre jamais. Et c'est à ce module précisément que Tanguy Dubroca de Synacktiv s'est intéressé. Et en creusant, il a découvert qu'une faille s'y cachait et permettait de prendre le contrôle total de la liseuse avec votre compte Amazon en supplément salade tomate oignon.

Son objectif premier c'était de comprendre comment prendre la main sur un Kindle verrouillé sans le jailbreaker. Alors il a fouillé dans le firmware de son Paperwhite 5 et y a découvert ce vieux Chrome et son moteur Webkit d'une quinzaine d'années, prêt à céder à toutes ses demandes... niark niark.

Il n'a eu plus qu'à piocher dans les vieilles failles déjà bien connues de Chrome et en a choisi une présente dans le moteur Javascript V8 patchée par Google en 2022. Sauf que normalement, elle ne devait pas marcher sur un Kindle, parce qu'Amazon avait désactivé le composant vulnérable.

Enfin, avait essayé...

Parce que dans la commande censée le désactiver, il manquait deux petits tirets. Une faute de frappe qui faisait que l'option était ignorée en silence, et donc que le moteur JS d'époque restait allumé avec cette porte grande ouverte...

L'attaque n'a ensuite besoin que d'une seule chose qui est que vous ouvriez un site web piégé dans le navigateur de la liseuse. Pas de panique donc, car ça ne se déclenche pas tout seul quand vous recevez un livre, mais une fois la page web ouverte, elle peut trafiquer la mémoire de l'appareil, ce qui permet au chercheur de prendre la main sur le navigateur pour ensuite, via une seconde vulnérabilité dans le composant qui lance les applis, obtenir des droits administrateur et donc l'accès complet.

Une fois avec ça, il peut tout faire comme exécuter n'importe quel programme, vous espionner, détourner votre compte Amazon, et même rebondir vers les autres appareils présents sur votre réseau Wi-Fi. La totale !!

Dubroca a prévenu Amazon en décembre 2025, qui a classé le truc en critique, lâché 20 000 $ de prime, et poussé un correctif dans le firmware 5.19.2 en janvier. La mise à jour se fait toute seule une fois le Kindle branché et connecté au Wi-Fi alors si votre liseuse dort dans un tiroir depuis des mois, un petit coup de Wi-Fi et elle se mettra à jour, hop. D'ailleurs c'est la deuxième faille Kindle en 7 mois , après celle du livre audio piégé. Deux équipes françaises, deux fois le même appareil, ça commence à faire beaucoup pour de vieilles liseuses qu'Amazon laisse doucement vieillir .

Bref, une liseuse c'est comme un ordinateur, ça se pirate mais ça peut se mettre à jour ^^. Ouf !

Source

Des chercheurs ont découvert une faille permettant d'extraire les données de dépôts privés GitHub sans aucune authentification, juste en piégeant l'agent IA chargé de répondre aux tickets.

Des chercheurs ont découvert une faille permettant d'extraire les données de dépôts privés GitHub sans aucune authentification, juste en piégeant l'agent IA chargé de répondre aux tickets.

Une vulnérabilité découverte par un chercheur en sécurité permet à n'importe quelle machine virtuelle louée sur un cloud d'aller compromettre le serveur physique qui l'héberge. Elle traîne dans le noyau Linux depuis 2010.

Une vulnérabilité découverte par un chercheur en sécurité permet à n'importe quelle machine virtuelle louée sur un cloud d'aller compromettre le serveur physique qui l'héberge. Elle traîne dans le noyau Linux depuis 2010.

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

Des pirates ont caché un cheval de Troie dans du code partagé sur GitHub pour révéler des failles de sécurité. Une technique qui vise directement les chercheurs en cybersécurité.

Depuis plus d'un an, Apple serait en connaissance d'une vulnérabilité permettant à quiconque de retrouver l'adresse réelle derrière un alias généré par la fonction de confidentialité d'iCloud+. La marque ne l'a pas corrigé.

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

Deux chercheurs allemands ont mis au jour six vulnérabilités dans les fonctionnalités de partage sans fil d'Apple et de Google/Samsung. De quoi faire planter des appareils à proximité, sans aucune interaction de la victime.

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

Une faille très bien planquée dans le code depuis 1997, vient seulement d'être corrigée. Elle s'appelle Squidbleed, référencée comme CVE-2026-47729, et elle touche Squid, un serveur proxy open source que des entreprises, des écoles et des fournisseurs d'accès utilisent depuis des lustres pour mettre en cache, filtrer et surveiller le trafic réseau qui transite chez chez eux.

Et ça fuite fort en fait. Un individu malveillant, qui serait déjà autorisé à passer par le même proxy, peut récupérer la requête HTTP en clair d'un autre utilisateur, avec tout ce qu'elle transporte au passage : mots de passe, clés d'API, cookies de session, et j'en passe. De quoi se faire passer pour la victime sans jamais avoir eu à connaître son mot de passe. Les chercheurs parlent d'un cousin de Heartbleed, la grande fuite mémoire de 2014, sauf que celle-ci vise spécifiquement le trafic non chiffré, l'HTTPS restant à l'abri dans son tunnel.

Comment un bug pareil a-t-il pu survivre presque trente ans de relectures ? Tout part d'une rustine ajoutée en 1997 pour gérer de vieux serveurs FTP NetWare qui bourraient leurs listings d'espaces en trop. Le code de Squid saute ces espaces dans une boucle. Sauf que voilà, quand le serveur d'en face ne renvoie aucun nom de fichier après l'horodatage, la fonction strchr, censée signaler la fin de la chaîne de caractères, renvoie en fait un pointeur valide au lieu du NULL que tout le monde attendait. La boucle continue, déborde du tampon mémoire et recrache au passage des morceaux de mémoire voisine, là où dormait justement la requête d'un autre internaute.

L'ironie, c'est que cette zone n'est jamais remise à zéro avant d'être réutilisée. Un tampon de 4 Ko qui contenait il y a un instant la requête d'une victime en garde donc l'essentiel, prêt à repartir vers l'attaquant comme s'il s'agissait d'un banal nom de fichier.

La découverte, elle, dit quelque chose de l'époque. Lam Jun Rong, chercheur chez Calif.io, n'a pas trouvé la faille tout seul : il bossait lui aussi avec Claude Mythos Preview, l'outil d'IA d'Anthropic qui a fini par être désactivé. En lui demandant d'explorer le comportement complet de la machine à états FTP, l'IA a mis le doigt sur ce cas tordu de strchr, en citant de mémoire la norme du langage C. Comme elle a avalé tout le standard, ce piège pourtant connu n'était pour elle qu'un fait parmi d'autres. Peu de développeurs humains auraient parié là-dessus, ce qui explique sans doute comment un bug d'une seule ligne a traversé trente ans de revue de code.

Côté correctif, Squid 7.6 est sorti le 8 juin et ajoute la vérification qui manquait. Vous pouvez aussi tout simplement couper le support FTP, dont plus personne ne se sert vraiment depuis que les navigateurs l'ont abandonné. Le bug avait été signalé dès avril.

Bref, encore une faille prise en charge par une IA, ça devient une habitude.

Source : https://blog.calif.io/p/squidbleed-cve-2026-47729

https://www.theregister.com/security/2026/06/23/mythos-discovers-squidbleed-a-memory-leak-thats-gone-undetected-since-clinton-era/5260367

Une attaque contre la plateforme d'intelligence compétitive Klue a permis à un groupe criminel d'exfiltrer des données CRM chez des dizaines d'entreprises, dont plusieurs noms majeurs du secteur de la cybersécurité.

Quand une faille critique est exploitée activement, attendre le prochain cycle de mises à jour n'est plus une option. Voici comment l'urgence redéfinit les règles du jeu en cybersécurité.

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