Un agent IA autonome a percé les défenses de Lilli, la plateforme d'intelligence artificielle interne de McKinsey, c'est arrivé en à peine deux heures. Au programme : 46,5 millions de messages en clair, 728 000 fichiers clients et un accès en écriture à l'ensemble de la base de données. Le tout sans aucun identifiant.

Une injection SQL en 2026

C'est la startup de sécurité CodeWall qui a mené l'attaque, dans le cadre d'un test de pénétration. Son agent IA a commencé par scanner la documentation API de Lilli, qui était exposée publiquement. Sur les 200 points d'accès répertoriés, 22 ne demandaient aucune authentification.

L'un d'eux, qui servait à enregistrer les requêtes de recherche des utilisateurs, concaténait les noms de champs JSON directement dans les requêtes SQL sans aucun filtrage. Une injection SQL classique, la faille la plus documentée du web depuis vingt ans.

Les scanners de sécurité classiques comme OWASP ZAP étaient passés à côté, parce que les valeurs des paramètres, elles, étaient bien protégées. Mais pas les noms de champs.

46,5 millions de messages et des prompts modifiables

Il a fallu seulement une quinzaine d'itérations à l'aveugle sur les messages d'erreur de la base, pour cartographier toute sa structure interne. Résultat : 46,5 millions de conversations en clair couvrant la stratégie, les fusions-acquisitions et les engagements clients de McKinsey, mais aussi 728 000 fichiers (192 000 PDF, 93 000 tableurs, 93 000 présentations), 57 000 comptes utilisateurs, 384 000 assistants IA et 3,68 millions de fragments de documents RAG avec les chemins de stockage S3.

Le pire, c'est que les 95 prompts système qui contrôlent le comportement de Lilli étaient accessibles en écriture. Une simple requête SQL UPDATE suffisait pour empoisonner les réponses du chatbot à l'ensemble des 40 000 consultants qui l'utilisent, sans laisser de trace.

McKinsey a corrigé en un jour

CodeWall a divulgué la faille le 1er mars, et McKinsey a réagi vite : tous les points d'accès non authentifiés ont été fermés, l'environnement de développement mis hors ligne et la documentation API retirée, le tout en une journée.

Histoire de rassurer tout le monde, le célèbre cabinet de conseil promet qu'aucune donnée client n'a été consultée par des personnes non autorisées. Sauf que l'adoption de Lilli dans l'entreprise est massive, puisque plus de 70% des employés de McKinsey l'utilisent au quotidien, avec quand même plus de 500 000 requêtes par mois, et une faille en place depuis... 2023 !

Quoi qu'il en soit, une injection SQL sur une plateforme qui tourne depuis deux ans et demi chez un cabinet qui vend du conseil en transformation numérique à, à peu près, la Terre entière, c'est quand même plus que cocasse.

Source : The Register

Mark Russinovich, CTO de Microsoft Azure, a donné à Claude Opus 4.6 un programme qu'il avait écrit en assembleur 6502 pour Apple II en mai 1986. L'IA d'Anthropic y a trouvé des vulnérabilités. Une découverte possible grâce à Claude Code Security, un outil qui a déjà débusqué plus de 500 failles dans des projets open source.

Du code Apple II passé au crible

Le programme en question s'appelle Enhancer. C'est un utilitaire écrit en langage machine 6502 qui ajoutait à l'Applesoft BASIC la possibilité d'utiliser des variables ou des expressions comme destination pour les commandes GOTO, GOSUB et RESTORE.

Claude Opus 4.6 a identifié un comportement silencieux incorrect : quand une ligne de destination n'était pas trouvée, le programme plaçait le pointeur sur la ligne suivante ou au-delà de la fin du programme, au lieu de signaler une erreur. L'IA a même suggéré le correctif : vérifier le carry flag (positionné quand une ligne n'est pas trouvée) et rediriger vers un gestionnaire d'erreurs.

L'anecdote a surtout valeur de démonstration. Russinovich l'a partagée pour montrer que les modèles d'IA sont désormais capables de décompiler du code embarqué d’un autre âge et d'y repérer des failles, ce qui pose un problème quand on sait que des milliards de microcontrôleurs tournent dans le monde avec du code qui n'a jamais été audité.

Plus de 500 failles dans des projets open source

Cette histoire autour de l'Apple II est amusante, mais le vrai sujet est ailleurs. Anthropic a utilisé Claude Opus 4.6 pour scanner des bases de code open source en production et a trouvé plus de 500 vulnérabilités qui avaient échappé à des années de revue par des experts humains.

Parmi les projets touchés : GhostScript (traitement PostScript et PDF), OpenSC (utilitaires pour cartes à puce), CGIF (traitement d'images GIF) et le noyau Linux. Certaines de ces failles étaient là depuis des décennies, malgré des millions d'heures de fuzzing accumulées sur ces projets.

Côté Firefox, on vous en a parlé : 22 CVE dont 14 haute gravité, trouvées en deux semaines seulement.

On vous en a déjà parlé, Anthropic a lancé le 20 février Claude Code Security, un outil intégré à Claude Code sur le web, pour l'instant en accès limité. Le principe : l'IA scanne un dépôt de code, identifie les vulnérabilités, et propose des correctifs ciblés pour validation humaine.

Contrairement aux outils d'analyse statique classiques qui fonctionnent par pattern matching, Claude lit et raisonne sur le code comme le ferait un chercheur en sécurité, en traçant les flux de données et en comprenant comment les composants interagissent. Rien n'est appliqué sans validation humaine. L'outil est accessible aux clients Enterprise et Team, et les mainteneurs de projets open source peuvent demander un accès gratuit.

Tout ça pour dire que l'image du CTO d'Azure qui ressort son vieux code Apple II et se retrouve avec un rapport de failles, c'est quand même franchement rigolo, mais aussi intéressant. Mais le fond du sujet est plus sérieux : des milliards d'appareils embarqués tournent avec du code ancien que personne n'a jamais audité, et l'IA est désormais capable de les passer au peigne fin. Anthropic a quand même prévenu que cet écart entre la capacité à trouver les failles et celle de les exploiter ne durera probablement pas éternellement. On l’espère.

Source : The Register

Gaël Musquet, mon copain hacker, me parlait déjà de tracking TPMS en 2020. Du coup, quand je vois des chercheurs publier un document de recherche en 2026 pour "découvrir" qu'on peut pister une voiture via ses capteurs de pneus, bon, comment dire... je suis pas tombé de ma chaise.

Mais faut reconnaître que l'étude en question va quand même plus loin qu'une discussion entre 2 stands au FIC. En effet, une équipe d'IMDEA Networks et d'armasuisse (le labo de défense suisse, rien que ça) a posé 5 récepteurs SDR dans une ville pendant 10 semaines. Coût du matos, environ 100 dollars par capteur, qui est en gros un Raspberry Pi 4 avec un dongle RTL-SDR à 25 balles. Et grâce à cela, ils ont capté plus de 6 MILLIONS de messages, provenant de plus de 20 000 véhicules !

un Raspberry Pi 4 avec un dongle RTL-SDR - Source

Car oui, vous ne le savez peut-être pas, mais les capteurs de pression des pneus (TPMS pour les intimes) émettent régulièrement dès que le véhicule roule, sur 433 MHz en Europe. Et ces signaux contiennent un identifiant unique... qui bien sûr est en clair ^^. Pas de chiffrement, pas d'authentification, QUE DALLE. Donc avec un logiciel open source comme rtl_433 , ça devient vite facile de capter tout ça à plusieurs dizaines de mètres à la ronde.

En croisant les identifiants captés par plusieurs récepteurs, les chercheurs ont pu reconstituer les trajets des véhicules, identifier leurs horaires de travail, détecter les jours de télétravail et même estimer les variations de charge du véhicule (et potentiellement déduire la présence de passagers, même si c'est encore approximatif). Le tout sans caméra, sans GPS, et sans accès au réseau du véhicule !

Il suffirait de trouver l'identifiant d'une voiture précise pour déclencher par exemple automatiquement un lâcher de confettis en papier parfaitement inoffensifs à son passage, si vous voyez ce que je veux dire.

Alors attention, tous les véhicules ne sont pas logés à la même enseigne. Les TPMS dits "directs" (dTPMS), qu'on trouve souvent chez Toyota, Peugeot, Citroën, Hyundai ou Mercedes, émettent ces fameux signaux radio captables. Alors que les systèmes "indirects" (iTPMS), utilisés par la plupart des modèles Volkswagen, Audi ou Skoda, se basent sur les capteurs ABS et n'émettent rien par radio. Bref, si vous roulez en Golf de base, y'a de bonnes chances que vous soyez tranquilles sur ce coup-là même si certaines versions sportives ou haut de gamme (Golf R, GTI selon les marchés) peuvent embarquer du dTPMS.

Et le pire dans tout ça c'est que la réglementation UN R155 sur la cybersécurité automobile n'impose pas explicitement le chiffrement des TPMS. En gros, les constructeurs ne sont pas forcés de sécuriser ces transmissions. Pirelli et Bosch bossent bien sur un "Cyber Tyre" en Bluetooth Low Energy, mais c'est réservé au haut de gamme et c'est pas demain que ça arrivera sur votre Clio.

Donc côté protection, soyons honnêtes, y'a pas grand-chose à faire côté utilisateur. Vous ne pouvez pas désactiver vos TPMS (c'est obligatoire depuis 2014 pour les voitures neuves en Europe), et les capteurs ne proposent aucune option de chiffrement. Sauf si vous roulez en véhicule vintage d'avant 2014, c'est open bar. Une des parades serait que les constructeurs implémentent un système de rotation d'identifiants, un peu comme le fait déjà le Bluetooth avec les adresses MAC aléatoires, mais pour l'instant on en est loin.

Pour ceux qui veulent creuser le sujet, j'avais fait une rencontre avec Gaël Musquet il y a quelques années, où il expliquait déjà comment reprendre le contrôle de nos véhicules connectés. Et si vous voulez comprendre comment on hacke une voiture de manière plus générale, c'est un rabbit hole sans fond !

Bref, la prochaine fois que vous gonflez vos pneus... dites-leur bonjour de ma part.

Source

Bon, vous connaissez la théorie du travailleur nomade... vous vous posez dans un café avec votre laptop, vous chopez du WiFi gratuit, et vous vous dites que l'isolation client du routeur vous protègera des autres branquignols connectés au même réseau.

Hé ben non ! Car des chercheurs viennent de démontrer que cette protection, c'était du vent... Oui oui, tous les routeurs qu'ils ont testés se sont fait contourner en 2 secondes.

Mais avant, pour ceux qui se demandent ce que c'est, l'isolation client c'est une option que les admins réseau activent sur les bornes WiFi pour empêcher les appareils connectés de communiquer entre eux. En gros, votre laptop ne peut pas voir celui du voisin. Enfin... ça c'est en théorie.

Parce qu'en fait, le truc c'est que cette fonctionnalité n'est même pas définie dans le standard WiFi (IEEE 802.11) ce qui oblige chaque fabricant à faire sa propre tambouille dans son coin, et du coup ça fuit de partout.

L'équipe derrière cette trouvaille, c'est des chercheurs de l'UC Riverside et de KU Leuven, dont Mathy Vanhoef, le même gars qui avait déjà mis le WPA2 à genoux avec KRACK en 2017. Pas un amateur, quoi. Et leur outil, baptisé AirSnitch, vient d'être présenté à la conférence NDSS 2026 .

Ils ont ainsi trouvé 3 méthodes différentes pour contourner la protection d'isolation. La première abuse de la clé de groupe (GTK), normalement réservée au broadcast, pour envoyer du trafic directement à un appareil ciblé. Le pire, c'est que macOS, iOS et Android acceptent ce trafic sans broncher (merci les gars !).

La seconde fait rebondir les paquets via la passerelle, et la troisième vole carrément l'adresse MAC de la victime sur un autre point d'accès pour intercepter son trafic.

Brrrrrr.... 11 routeurs testés, du Netgear R8000 au Cisco Catalyst 9130 en passant par TP-Link, ASUS, Ubiquiti et même OpenWrt 24.10. Et ils sont TOUS vulnérables, sans exception ! Et que vous soyez en WPA2 ou en WPA3, réseau perso ou entreprise, c'est pareil. Donc autant vous dire que ça pue !

Ils ont même réussi à effectuer un Man-in-the-Middle complet (interception de tout le trafic entre vous et Internet) en 2 secondes chrono. La "victime" qui regardait YouTube n'a même pas remarqué de lag et c'est comme ça qu'ils ont pu intercepter tout son trafic, ni vu ni connu.

Alors du coup, on fait quoi ? Hé bien si vous gérez un réseau, oubliez l'isolation client toute seule et passez aux VLANs avec un VLAN par client. Oui c'est lourdingue à mettre en place, mais c'est le prix à payer pour avoir une sécurité solide. Certains constructeurs bossent aussi sur des clés de groupe individuelles par client, ce qui règlerait le problème à la source.

Côté utilisateur, la solution est plus simple... VPN !! Attention, ça ne marche que si le VPN est activé AVANT de vous connecter au réseau, pas après. HTTPS vous protège déjà pour le contenu des sites, mais selon Google, 6 à 20% des pages ne sont toujours pas en HTTPS... et même quand elles le sont, l'attaquant voit quand même où vous surfez et peut tenter du DNS spoofing. Donc sur n'importe quel réseau WiFi public , partez du principe que quelqu'un peut voir votre trafic, parce que visiblement c'est le cas.

Le code source d' AirSnitch est dispo sur GitHub si vous voulez tester votre propre config mais notez que ça nécessitera une carte WiFi compatible avec le mode monitor comme les Alfa (lien affilié), donc pas celle de votre laptop de base.

Bref, la prochaine fois que le WiFi de l'hôtel vous demande d'accepter les CGU en échange d'un accès "sécurisé"... ben gardez votre VPN allumé, hein.

Source

Les clés API Google que vous collez dans votre JavaScript pour afficher une carte Maps... hé bien elles ne sont plus si inoffensives. Car depuis que Gemini est entré dans la danse, ces mêmes clés donnent maintenant accès à vos fichiers privés et surtout à votre facture IA.

Et personne ne nous a prévenu...

En gros, Google utilise un format de clé unique, les fameuses AIza..., aussi bien pour Maps et Firebase (public, collé dans le HTML, tout le monde s'en fout) que pour Gemini (privé, accès aux fichiers, facturation). Le problème c'est que quand vous activez l'API Gemini sur un projet Google Cloud, TOUTES les clés existantes de ce projet héritent automatiquement de l'accès Gemini. Sans warning, sans notification, sans rien... Ouin !

Les chercheurs de TruffleSecurity ont ainsi trouvé presque 3000 clés API Google valides dans le dataset Common Crawl de novembre 2025. Des clés qui trainent dans du code JavaScript, des pages HTML, des repos GitHub publics... et qui fonctionnent sur l'endpoint Gemini. Il suffit d'un simple curl avec une clé Maps récupérée sur un site web, et hop, vous accédez à l'API Gemini du propriétaire. Fichiers privés, contenu en cache, facturation sur son compte.

Et parmi les victimes, on trouve des institutions financières, des boîtes de cybersécurité, et... Google eux-mêmes (oui oui, vraiment).

Le 21 novembre 2025, TruffleSecurity signale donc le problème et la réponse de Google le 25 novembre c'est : "intended behavior" (comportement normal)... Sauf que le 2 décembre, Google a reclassifié ça en bug, puis le 13 janvier 2026, ça passe finalement en Tier 1. On est donc passé du "c'est normal les frérots" à "ah oui quand même, oupsi oups", en 7 semaines.

Maintenant, pour ceux qui se demandent si leurs clés API Google sont concernées, direction console.cloud.google.com , section "APIs & Services" puis "Identifiants".

Si vous voyez l'API " Generative Language " de Gemini API activée sur un projet avec des clés non restreintes... attention, c'est le moment de faire le ménage. Ajoutez des restrictions IP ou HTTP referrer, et surtout, utilisez des comptes de service plutôt que des clés API pour tout ce qui touche à Gemini (sauf si vous aimez les surprises sur votre facture ^^).

Le truc tordu, c'est que la doc Firebase dit noir sur blanc que les clés API ne sont pas des secrets. Google Maps vous dit carrément de les coller dans votre HTML. Et maintenant, ces mêmes clés donnent accès à une IA qui peut lire vos fichiers. Du CWE-1188 pur et dur ! Et c'est pas la première fois que Google se fait taper sur les doigts pour ce genre de souci avec Gemini .

Du coup, Google a annoncé des nouvelles mesures, du scoped defaults, du blocage de clés fuités, des notifications proactives...etc. Reste donc à voir si ça arrivera avant que les presque 3000 clés exposées soient exploitées par des gens moins bien intentionnés.

Bref, dix ans à dire que c'est public, et hop, aujourd'hui c'est devenu top secret. Bien joué Google !!

Source

Vous avez un serveur, un NAS, quelques services qui tournent chez vous ou au boulot, et vous vous demandez si tout ça est bien sécurisé ? Alors plutôt que d'attendre qu'un petit malin vous le fasse savoir de manière désagréable, autant prendre les devants avec un scanner de vulnérabilités.

Attention : si vous scannez le réseau de votre boulot, demandez toujours une autorisation écrite avant car scanner sans permission, c'est illégal et ça peut vous coûter cher. Et ne comptez pas sur moi pour vous apporter des oranges en prison.

OpenVAS (Open Vulnerability Assessment Scanner), c'est l'un des scanners open source les plus connus, maintenu par Greenbone. Une fois en place sur votre réseau, il scanne vos services exposés et vous balance un rapport avec ce qui craint : Ports ouverts, services mal configurés, failles connues, certificats expirés... De quoi repérer une bonne partie de ce qu'un attaquant pourrait exploiter.

L'interface principale d'OpenVAS

Ce qui est cool, c'est que vous restez en mode défensif. C'est pas un outil de pentest offensif ou de hacking pur et dur mais juste un audit de votre propre infra pour savoir où vous en êtes. Et ça tourne avec un feed de vulnérabilités (le Greenbone Community Feed) qui est régulièrement mis à jour, ce qui permet de détecter les failles récentes.

Pour l'installer, une des méthodes c'est de passer par Docker. Greenbone fournit une stack complète avec docker-compose. Après vous cherchez plutôt à analyser spécifiquement vos images de conteneurs, Grype pourrait aussi vous intéresser .

Pour OpenVAS, vous créez un répertoire, vous téléchargez leur fichier de config (jetez toujours un œil dedans avant de l'exécuter, c'est une bonne pratique), et hop :

mkdir -p ~/greenbone-community-container
cd ~/greenbone-community-container
curl -f -O -L https://greenbone.github.io/docs/latest/_static/docker-compose.yml
docker compose pull
docker compose up -d

L'assistant de configuration initiale

Après ça, vous accédez à l'interface web via http://localhost:9392.

Et pour le login, attention, car sur les versions récentes du conteneur communautaire, le mot de passe admin est généré aléatoirement au premier démarrage. Il faut donc aller voir les logs pour le récupérer (docker compose logs -f). Si ça ne marche pas, tentez le classique admin/admin, mais changez-le direct.

La première synchro des feeds peut prendre un moment, le temps que la base de vulnérabilités se télécharge. Vous avez le temps d'aller vous faire un café, c'est pas instantané.

Niveau config machine, la documentation recommande au moins 2 CPU et 4 Go de RAM pour que ça tourne, mais pour scanner un réseau un peu costaud, doublez ça (4 CPU / 8 Go) pour être à l'aise. Et une fois connecté, direction la section scans pour créer une cible avec votre IP ou plage d'adresses. Ensuite vous pouvez lancer un scan avec le profil de votre choix :

Le mode "Discovery" se contente de lister les services et ports ouverts tandis que le mode "Full and Fast" lance une batterie complète de tests de vulnérabilités. Il est conçu pour être "safe" (ne pas planter les services), mais le risque zéro n'existe pas en réseau donc évitez de scanner votre prod en pleine journée sans prévenir.

Les résultats arrivent sous forme de rapport avec un score de criticité comme ça vous avez le détail de ce qui pose problème et souvent des pistes pour corriger. Genre si vous avez un service SSH avec une config un peu lâche ou un serveur web trop bavard, le rapport vous le dira.

Par contre, c'est vrai que l'interface est assez austère comparée à des solutions commerciales comme Nessus mais c'est gratuit, c'est open source, et ça fait le taf pour un audit interne. La version Community a quand même quelques limitations (feed communautaire vs feed entreprise, support, etc.), mais pour surveiller son infra perso ou sa PME, c'est déjà très puissant.

Du coup, si vous voulez savoir ce qui traîne sur votre réseau avant que quelqu'un d'autre le découvre, OpenVAS est un excellent point de départ. Et c'est toujours mieux de découvrir ses failles soi-même que de les lire dans un mail de rançon... enfin, je pense ^^.

A découvrir ici !

Si vous utilisez Notepad++, faut que vous sachiez qu'il s'est passé un truc moche. Entre juin et décembre 2025, les serveurs de mise à jour de votre éditeur de texte préféré ont été piratés par Lotus Blossom, un groupe de hackers chinois actifs depuis 2009 et spécialisés dans l'espionnage gouvernemental. Ouin 🥲.

En gros, les attaquants ont réussi à compromettre l'infrastructure de l'ancien hébergeur du projet pour détourner le trafic de mise à jour. Certains utilisateurs se retrouvaient redirigés vers des serveurs malveillants qui leur servaient des binaires vérolés au lieu des vraies mises à jour. Et le chercheur en sécurité Kevin Beaumont confirme que trois organisations ayant des intérêts en Asie de l'Est ont subi des intrusions via cette méthode... avec des hackers qui naviguaient VRAIMENT sur les PC des victimes en temps réel.

Le pire ? Les hackers ont gardé un accès aux services internes jusqu'au 2 décembre, même après la correction de la faille initiale en septembre. Ils exploitaient une vulnérabilité dans le script getDownloadUrl.php et les faiblesses de WinGUP, l'outil de mise à jour. Les anciennes versions utilisaient même un certificat auto-signé dispo sur GitHub... autant dire que c'était open bar.

Rapid7 a publié une analyse technique du malware déployé via cette attaque. Baptisé "Chrysalis", c'est une backdoor complète avec shell interactif, exfiltration de fichiers, création de processus à distance... le package complet de l'espion. Le truc vicieux, c'est que le serveur de commande utilisait une URL qui imitait l'API de DeepSeek pour passer sous les radars.

Beaumont alerte aussi sur le fait que les moteurs de recherche sont bourrés de pubs qui poussent des versions vérolées de Notepad++. Sans compter des extensions malveillantes qui circulent. Bref, c'est la fête.

Bon, pour vous protéger, mettez à jour Notepad++ vers la version 8.9.1 minimum (et pas 8.8.9 comme annoncé initialement, ils ont renforcé les protections depuis). Si vous avez un doute, désinstallez tout et retéléchargez directement depuis notepad-plus-plus.org. Changez vos mots de passe si vous utilisiez cet outil pendant la période critique, et les admins réseau, bloquez l'accès Internet de gup.exe dans votre pare-feu. Hop, c'est réglé. Si vous cherchez des alternatives le temps que ça se tasse, y'a Notepads ou NotepadNext qui font du super boulot, et les indicateurs de compromission sont dans le rapport de Rapid7 .

Bref, restez vigilants !

Source & Source

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

Et pas pour de bonnes raisons. Argh !

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

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

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

Ça fait flipper, non ?

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

Vous pensiez que votre PC était blindé avec toutes vos protections activées ? Et bien ça c'était avant que des chercheurs de Riot Games (oui, les mêmes mecs derrière League of Legends et Valorant) ne découvrent une bonne grosse faille UEFI qui touche les cartes mères des quatre plus gros fabricants du marché, à savoir ASUS, Gigabyte, MSI et ASRock.

La faille se décline en plusieurs CVE selon les constructeurs (CVE-2025-11901 pour ASUS, CVE-2025-14302 pour Gigabyte, CVE-2025-14303 pour MSI, CVE-2025-14304 pour ASRock) et concerne les protections DMA au démarrage. En gros, le firmware UEFI prétend activer l' IOMMU (un mécanisme matériel d'isolation mémoire destiné à bloquer les attaques DMA), sauf que dans les faits, il ne le configure pas correctement. Votre système pense être protégé alors qu'il ne l'est pas du tout... Bref ça craint !

Du coup, un attaquant qui branche un périphérique PCIe malveillant sur votre machine (notamment via Thunderbolt ou USB4, qui exposent du PCIe) peut lire ou modifier la mémoire système avant même que Windows ou Linux ne démarre. Donc bien avant que vos protections système n'aient eu le temps de se mettre en place quoi... Et comme l'attaque se déroule avant le chargement de l'OS, les antivirus et outils de sécurité logiciels classiques n'ont pas encore démarré et ne peuvent donc pas intervenir. Seule une mise à jour du firmware UEFI peut corriger le problème.

Côté chipsets touchés, accrochez-vous parce que la liste est longue. Chez Gigabyte, les bulletins de sécurité mentionnent notamment des cartes basées sur les séries Intel Z890, W880, Q870, B860, H810, Z790, B760, Z690, Q670, B660, H610, W790, et côté AMD des X870E, X870, B850, B840, X670, B650, A620, A620A et TRX50.

Chez ASUS, les chipsets concernés incluent les séries B460, B560, B660, B760, H410, H510, H610, H470, Z590, Z690, Z790, W480 et W680.

Et de son côté, ASRock indique que ses cartes mères Intel des séries 500, 600, 700 et 800 sont également affectées. Bref, si vous avez une carte mère relativement récente, il y a de bonnes chances qu'elle soit dans le lot, même si cela dépend du modèle précis et de la version de firmware installée.

Bien sûr, comme souvent avec ce type de faille, son exploitation nécessite un accès physique à la machine, puisqu'il faut connecter un périphérique PCIe capable de mener une attaque DMA (par exemple un dongle Thunderbolt ou une carte PCIe spécialement conçue).

Ce n'est donc pas le genre d'attaque qui se propage via Internet, mais c'est quand même problématique, notamment dans les entreprises qui ont des postes de travail accessibles au public, dans les bibliothèques, ou tout autre environnement partagé. Sans parler de quelqu'un qui aurait un accès temporaire à votre machine genre un réparateur, un collègue malveillant, votre ex un peu trop curieux(se)… Ou encore le marché de l'occasion, où personne ne sait vraiment ce qui a pu être branché sur la carte mère avant.

Petite anecdote au passage, les chercheurs de Riot Games sont tombés sur cette faille parce que Valorant refusait de se lancer sur certains systèmes. Leur anti-cheat Vanguard vérifie que les protections DMA sont bien actives au démarrage, et il a détecté que sur certaines machines, ce n'était pas le cas. De fil en aiguille, ils ont creusé et fini par identifier ce problème côté firmware UEFI.

Bref, les quatre constructeurs ont publié (ou sont en train de publier) des mises à jour de firmware pour corriger le problème. Attention toutefois, chez Gigabyte, le correctif pour TRX50 est prévu pour le premier trimestre 2026, et chez ASRock, les BIOS pour les séries 600/700/800 sont disponibles mais ceux de la série 500 sont encore en cours de développement.

Donc allez faire un tour sur le site support de votre fabricant, vérifiez si votre modèle est concerné, et installez le patch si c'est le cas.

Source

Vous avez peut-être une caméra Tapo C200 qui tourne chez vous pour surveiller le chat, le bébé ou l'entrée. C'est mon cas et j'adore cette caméra mais j'ai une mauvaise nouvelle à vous annoncer... Le chercheur en sécurité Simone Margaritelli (alias evilsocket) vient de passer 150 jours à la disséquer et le résultat n'est pas glorieux pour TP-Link.

Alors déjà, commençons par le plus gros WTF qu'il a découvert... la clé privée HTTPS de la caméra, ce truc censé être ultra-secret qui permet de chiffrer les communications. Et bien elle est hardcodée dans le firmware. C'est donc la même clé pour TOUTES les caméras du même modèle. Du coup, n'importe qui peut faire un Man-in-the-Middle et intercepter ce que vous voyez sur votre caméra. Ah on se met bien déjà là, hein ? ^^

Et attendez, ça ne s'arrête pas là puisque Margaritelli a trouvé un bucket S3 chez Amazon, totalement ouvert au public, qui contient TOUS les firmwares de TOUS les produits TP-Link. C'est open bar, sans authentification, Noël avant l'heure pour les chercheurs en sécu... et les hackers.

En fouillant le firmware avec Ghidra et Claude (oui, l'IA a aidé au reverse engineering), le chercheur a découvert quatre failles critiques. La première, c'est un buffer overflow dans le parser SOAP XML utilisé par le protocole ONVIF. En gros, si vous envoyez un message trop long, la caméra plante. Pas besoin d'être authentifié pour ça, une requête HTTP suffit.

La deuxième faille est du même genre mais dans le header Content-Length. Envoyez 4294967295 (le max d'un entier 32 bits) et boum, integer overflow. Et la troisième, c'est la cerise sur le gâteau puisque l'endpoint connectAp reste accessible sans authentification même après le setup initial. Du coup, un attaquant peut forcer votre caméra à se connecter à son propre réseau WiFi malveillant et intercepter tout le flux vidéo. Vous ne vous y attendiez pas à celle-là, si ?

Et la quatrième faille, oubliée nulle part ailleurs c'est l'API scanApList qui balance la liste de tous les réseaux WiFi autour de la caméra, sans auth. Avec les BSSID récupérés et un outil comme apple_bssid_locator, on peut géolocaliser physiquement la caméra à quelques mètres près. Sur les 25 000 caméras exposées sur le net, ça fait froid dans le dos.

Le plus frustrant dans cette histoire, c'est que Margaritelli a signalé tout ça en juillet 2025 et TP-Link a demandé des rallonges de délai, encore et encore, durant plus de 150 jours. Et au final, les failles ont été corrigées mais pas de patch sur les pages publiques des CVE. Ah et petit détail rigolo, comme TP-Link est sa propre autorité de numérotation CVE, ils s'auto-évaluent sur leurs propres failles. Donc y'a pas de conflit d'intérêt du tout... ahem ahem...

Le chercheur estime qu'environ 25 000 de ces caméras sont exposées directement sur Internet donc si comme moi, vous en avez une, vérifiez que le firmware est bien à jour et surtout, ne l'exposez JAMAIS directement sur le net. Mettez-la derrière un VPN ou un réseau isolé.

Je trouve ça cool que Margaritelli ait utilisé de l'IA pour accélérer la phase de reverse engineering. Avec Claude Opus et Sonnet avec GhidraMCP, il a pu analyser le code assembleur et c'est comme ça que l'IA a identifié rapidement les fonctions vulnérables et expliqué le fonctionnement du code. Bref, l'IA comme outil de hacking, c'est assez ouf...

Voilà, donc si vous avez du matos TP-Link chez vous, gardez un œil sur les mises à jour et réfléchissez à deux fois avant de l'exposer sur le net. Et si vous aimez la lecture, l'analyse complète est dispo sur le blog d'evilsocket .

Beau boulot !

Vous utilisez une extension VPN gratuite sous Chrome ou Edge pour "protéger votre vie privée" ? Cool story les bro, mais si je vous disais que cette même extension enregistre peut-être toutes vos conversations avec ChatGPT, Claude, Gemini et compagnie pour les revendre à des courtiers en données (les fameux data brokers) ?

Hé bien c'est exactement ce que viennent de découvrir les chercheurs en sécurité de Koi qui ont mis le doigt sur 4 extensions très populaires comptabilisant plus de 8 millions d'utilisateurs au total : Urban VPN Proxy (6 millions à elle seule), 1ClickVPN Proxy, Urban Browser Guard et Urban Ad Blocker qui aspirent silencieusement tout ce que vous tapez dans vos chat IA préférées.

Le truc vicieux, c'est que ces extensions ne se contentent pas de regarder votre historique de navigation comme les trackers classiques. Non non non, elles injectent du code JavaScript directement dans les pages des chatbots IA quand vous les visitez et ça modifie les fonctions de base du navigateur (fetch() et XMLHttpRequest pour les techos) pour intercepter absolument tout ce qui passe entre vous et l'IA.

Vos prompts, les réponses du chatbot, les métadonnées de conversation, tout est aspiré et envoyé vers les serveurs analytics.urban-vpn.com et stats.urban-vpn.com. Et le pire c'est que cette collecte continue en arrière plan même quand le VPN est désactivé. Bye bye tous vos secrets.

Derrière ces extensions se cache Urban Cyber Security Inc., une boîte affiliée à BiScience, un courtier en données bien connu des chercheurs en sécurité. Ces gens-là sont passés de la collecte d'historique de navigation à la collecte de conversations IA complètes, soit un niveau de sensibilité bien supérieur vu ce qu'on peut raconter à une IA (questions médicales, code propriétaire, problèmes personnels, données financières...).

Et devinez quoi ? Ces extensions arboraient fièrement le badge "Featured" sur le Chrome Web Store et le Microsoft Edge Add-ons, censé garantir que Google et Microsoft ont vérifié leur sécurité. Nos deux géants américains ont donc validé des extensions qui violent directement leur propre politique d'utilisation limitée des données utilisateurs.

Bref, si vous avez installé une de ces extensions et utilisé ChatGPT, Claude, Gemini, Copilot, Perplexity, DeepSeek, Grok ou Meta AI depuis juillet de cette année, partez du principe que toutes ces conversations sont maintenant sur les serveurs d'un data broker et potentiellement revendues à des annonceurs.

La morale de l'histoire, c'est que dans le cas des VPN gratuits, le produit c'est littéralement tout ce que vous faites en ligne. Donc si vous voulez vraiment protéger votre vie privée avec un VPN, mieux vaut payer quelques euros par mois pour un service sérieux comme NordVPN ou Surfshark qui n'a pas besoin de revendre vos données pour survivre.

Je vais vous raconter la meilleure de la semaine… Microsoft vient quand même de passer 5 ans à gueuler sur tous les toits que BinaryFormatter est dangereux (ça servait à sérialiser/desérialiser des objets en binaire ave .NET) et qu’il faut arrêter de l’utiliser… et pourtant, on vient d’apprendre qu’ils continuent secrètement de l’utiliser dans WSUS (Windows Server Update Services), leur système censé sécuriser les mises à jour Windows.

Et bien sûr, ce qui devait arriver, arriva… Une magnifique faille critique dans WSUS vient d’être rendue publique, ce qui met en danger environ 500 000 serveurs WSUS actuellement accessibles via le net.

L’histoire commence en réalité en 2020. A cette date, Microsoft déclare officiellement que BinaryFormatter est dangereux, ce qui ne les empêche pas de se faire poutrer Exchange, Azure DevOps, SharePoint en 2021/2021 justement à cause de ça. Du coup, en 2023, ils annoncent le bannissement total de BinaryFormatter en interne. En 2024, ils effectuent même une mise au rebus complète de .NET 9.

Mais c’était sans compter sur cette jolie CVE-2025-59287 d’octobre 2025 qui exploite à son tour BinaryFormatter dans WSUS !

Un oubli ? Pas si sûr, car Microsoft l’utilisait toujours pour déchiffrer les cookies d’authentification de WSUS, rendant ainsi ce système de mises à jour censé protéger Windows vulnérable. La faille, c’est donc une désérialisation non sécurisée. Un attaquant non authentifié envoie une requête SOAP craftée au endpoint GetCookie de WSUS, avec un cookie AuthorizationCookie contenant un payload malveillant. Et de son côté le serveur déchiffre ce truc avec AES-128-CBC, puis passe le résultat directement à BinaryFormatter pour désérialisation.

Et là, bim bam boum, une magnifique exécution de code arbitraire avec privilèges SYSTEM !

Techniquement, la vulnérabilité touche donc les Windows Server 2012 à 2025 qui ont le rôle WSUS activé. Le score CVSS de cette faille est quand même de 9,8 sur 10 ce qui est fait une faille super critique.

L’exploitation de cette faille débute le 24 octobre soit juste après la publication du patch d’urgence de Microsoft sortie la veille c’est à dire le 23 octobre, pour corriger lui-même un autre patch publié juste avant le 8 octobre. Bref un vrai bordel et il faut croire que les attaquants ont attendu la sortie de ce patch d’urgence pour comprendre comment fonctionnait la faille ( l’exploit est ici ).

De son côté, Google Threat Intelligence traque l’acteur cybercriminel UNC6512 qui a ciblé plusieurs organisations et les chiffres font pas plaisir puisque ce sont environ 100 000 tentatives d’exploitation en 7 jours qui ont eu lieues, et 500 000 serveurs WSUS exposés sur le net sur les ports par défaut (8530 HTTP, 8531 HTTPS).

Microsoft a dû sentir la douille arriver puisqu’ils ont déprécié WSUS en septembre de l’année dernière au profit d’autres solutions comme Intune ou WUfb, soit un an avant la sortie de la CVE. Mais bien sûr, comme l’outil reste dans Windows Server 2025 avec ses 10 ans de support réglementaire, des centaines de milliers d’entreprises l’utilisent encore…

Le chaos était garanti ! Maintenant vous me connaissez, je n’aime pas vous laisser sans solution, alors pour les admins sys qui lisent ça, sachez qu’il existe un script PowerShell baptisé Find-WSUS qui permet de détecter tous les serveurs WSUS configurés dans vos GPO. C’est pratique pour faire l’inventaire et vérifier que tout est patché. Et notez aussi que le patch d’urgence c’est le KB5070883. Et si vous ne pouvez pas patcher immédiatement parce que la vie est injuste, désactivez quand même le rôle WSUS de vos Windows Server, ou bloquez les ports 8530/8531 directement dans votre firewall.

Le vrai problème en fait, c’est que WSUS n’est qu’un symptôme car une grosse partie du code en entreprise est constitué de dette technique. C’est à dire du code “mort” qui continue de tourner car personne n’ose y toucher. Brrr… ça fait peur c’et sûr ! Surtout que même Microsoft n’arrive pas à tuer sa propre création 5 ans après l’annonce de sa mort officielle, donc autant dire qu’on a tous un sérieux problème.

Bref, patchez au plus vite !

Source

Ce serait cool si on pouvait réunir les Avengers des LLMs pour les faire bosser ensemble sur de la recherche de faille de sécurité ? OpenAI, Anthropic, X.AI et Meta ensemble contre les forces du mal, c’est maintenant possible avec Deep Eye , un super scanner de vulnérabilités qui transforme les quatre IA rivales en équipe de pentesteurs. Vous allez voir, c’est assez génial !

Deep Eye, c’est donc un outil Python open source qui scanne les sites web et les API pour trouver des vulnérabilités. SQL injection, XSS, command injection, SSRF, path traversal, authentication bypass, au total y’a plus de 45 méthodes d’attaque automatisées. Vous lui indiquez une URL, et il teste tout en switchant entre les services d’IA selon le contexte.

Dans le contexte d’un pentest légitime, Deep Eye a même trouvé comment parler aux IA pour qu’elles acceptent de pondre du code un peu sensible. Et ça tombe bien car chaque IA a ses forces et ses faiblesses. GPT-4 par exemple excelle sur les payloads créatifs et les contournements de filtres. Claude lui est plus méthodique, et capable de mieux analyser le contexte et de génèrer des attaques adaptées au framework détecté. LLAMA en local quand à lui est rapide et ne coûte rien en appels API. Et Grok ? Bah il a le mérite d’être dispo même s’il est loin d’être le meilleur.

Deep Eye en tout cas est capable des les utiliser toutes selon la situation. Pour l’installer, ça se passe en 3 commandes :

Vous installez ça comme ceci :

git clone https://github.com/zakirkun/deep-eye.git
cd deep-eye

cd scripts
./install.ps1

chmod +x scripts/install.sh
cd scripts
./install.sh

python deep_eye.py -u https://example.com

Vous avez une caméra de surveillance connectée chez vous ? Du genre petite caméra Yi à 15 balles achetée sur AliExpress pour surveiller le salon ou le chat quand vous n’êtes pas là ? Alors tenez-vous bien parce qu’un chercheur a réussi à faire tourner DOOM dessus. Et sans toucher au firmware s’il vous plait ! Il a juste exploité le stream vidéo et quelques bugs bien sentis de l’appareil.

Luke M a publié son projet Yihaw sur GitHub et ça fait un peu peur car si quelqu’un peut hijacker le stream de votre caméra pour y balancer un FPS des années 90, il peut aussi faire pas mal d’autres trucs beaucoup moins rigolos.

Le hack est assez cool d’ailleurs car ces caméras Yi tournent sur un petit processeur ARM sous Linux. Elles ont donc une app mobile qui vous permet de voir le stream en temps réel et Luke M a trouvé plusieurs vulnérabilités dans la stack réseau de la caméra. Je vous passe les détails mais avec ces bugs, il peut injecter du code arbitraire sans modifier le firmware.

Il peut alors créer trois threads qui tournent en parallèle. Le premier récupère les frames YUV420p directement depuis le capteur de la caméra. Le deuxième convertit ça en h264. Le troisième, au lieu d’envoyer le flux vidéo normal, envoie DOOM. Du coup, vous ouvrez l’app Yi IoT sur votre smartphone et vous voyez le Doomguy buter des demons au lieu de voir votre salon. C’est rigolo, hein ?

Ces caméras Yi, il y en a des millions installées partout dans le monde. Bureaux, maisons, magasins…etc car elles sont pas chères, elles marchent plutôt bien, elles ont une app correcte, mais leur sécurité c’est une vraie passoire. C’est bourré de bugs qu’on trouve en une après-midi avec un fuzzer basique.

Luke M liste plusieurs exploits dans son repo GitHub et c’est un vrai buffet à volonté pour quelqu’un qui veut prendre le contrôle de ces caméras. Bien sûr ce serait illégal alors personne ne le fait, surtout parce que ça demande quand même un peu de boulot pour chaque modèle de caméra. Mais les outils existent, les vulnérabilités sont connues, et si un chercheur solo peut le faire pour s’amuser avec DOOM, imaginez ce qu’un botnet bien pensé pourrait faire.

Tous ces trucs qu’on a chez nous, qui tournent sur du Linux embarqué avec des stacks réseau écrites à l’arrache par des équipes chinoises sous-payées qui doivent sortir un produit tous les trois mois.

C’est beau non ?

Source (c’est du PDF)

Y’a plein de problème avec les IA, mais y’en a un encore un peu trop sous-estimé par les vibe codeurs que vous êtes… Ce problème, c’est qu’on leur fait confiance comme à un collègue, on leur montre notre code, nos repos privés, nos petits secrets bien planqués dans les variables d’environnement…

Par exemple, quand vous passez en revue une pull request sur GitHub, vous faites quoi ? Vous lisez le code ligne par ligne, vous cherchez les bugs, les failles de sécu, les optimisations possibles. Mais les commentaires vous les lisez ? Au mieux on les survole, c’est vrai, car c’est de la comm’ entre devs, et pas du code exécutable.

Sauf pour bien sûr pour Copilot Chat pour qui un commentaire c’est un texte comme un autre. Et selon Omer Mayraz , chercheur en sécurité chez Legit Security, c’est exactement ce qui en fait une zone de confiance aveugle parfaite pour une attaque.

Ce qu’a découvert Omer Mayraz c’est donc une vulnérabilité critique dans GitHub Copilot Chat avec un score CVSS de 9.6 sur 10. Cela consiste à planquer des instructions malveillantes dans des commentaires markdown invisibles comme ça, ces commentaires ne s’affichent pas dans l’interface web de GitHub, mais Copilot Chat les voit parfaitement et les traite comme des prompts légitimes.

Du coup, l’attaquant peut forcer Copilot à chercher des secrets dans vos repos privés, à extraire du code source confidentiel, voire à dénicher des descriptions de vulnérabilités zero-day non publiées. Tout ça sans que vous ne voyiez rien venir évidemment !

Voici une démo complète de l’attaque en vidéo :

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

Tous les mardis soir, c’est la même chose dans le petit monde de la cybersécurité : Microsoft balance ses patches, et dès le mercredi matin, c’est la ruée vers l’or pour les experts sécu. Bienvenue dans l’univers déjanté de l’Exploit Wednesday, où des chercheurs du monde entier se transforment en cyber-archéologues pour y déterrer les vulnérabilités avant que les méchants ne s’en emparent afin de coder des exploits.

Et un nouvel outil vient de débarquer pour pimenter cette course folle : Diffrays .

Imaginez… il est 3h du matin, on est mercredi et pendant que vous dormez tranquillement, des milliers de chercheurs en sécurité sont déjà en train de comparer frénétiquement les binaires de Windows fraîchement patchés avec leurs versions vulnérables.

Pourquoi est-ce qu’ils font ça ? Hé bien c’est parce que chaque seconde compte. L’IA a réduit de 40% le temps nécessaire pour identifier une vulnérabilité à partir d’un patch et ce qui prenait des jours prend maintenant des heures, notamment aux cybercriminels, du coup, la course s’est transformée en sprint.

Et c’est là que Diffrays entre en scène. Cet outil, conçu par pwnfuzz, fait ce qu’on appelle du “patch diffing”. Pour les non-initiés, le patch diffing, c’est l’art de comparer deux versions d’un programme pour trouver ce qui a changé. Un peu comme comparer deux photos pour jouer au jeu des 7 différences, sauf que là, on cherche des bugs qui valent potentiellement des millions.

Pour cela, Diffrays utilise IDA Pro et sa nouvelle IDA Domain API pour extraire le pseudocode des fonctions et les comparer de manière structurée. Et ce n’est un vulgaire comparateur de texte…non… Diffrays génère en fait une base de données SQLite complète avec toutes les différences trouvées, et lance même un serveur web local pour naviguer dans les résultats. Vous tapez diffrays diff old.exe new.exe, puis diffrays server --db-path results.sqlite, et hop, vous avez une jolie interface web sur http://localhost:5555 pour explorer ces changements.

Grâce à cet outil, chacun peut savoir exactement comment Microsoft corrige ses bugs. Prenez par exemple l’analyse du driver Clfs.sys montrée dans la documentation de Diffrays . Les chercheurs ont téléchargé deux versions du driver. La première vulnérable (10.0.22621.5037) et la seconde patchée (10.0.22621.5189) puis ont laissé Diffrays faire son travail… Et en quelques minutes, l’outil a identifié exactement quelles fonctions avaient été modifiées et comment.

Évidemment, Diffrays n’est pas seul sur ce marché juteux. Google a son BinDiff , il y a aussi Diaphora, et maintenant même des outils boostés à l’IA comme DeepDiff qui convertissent le code en “embeddings” (des représentations mathématiques) pour trouver des similarités. Mais Diffrays a un avantage, il est open source, gratuit, et surtout, il est conçu spécifiquement pour la recherche. Pas de conneries marketing, juste du code qui fait le taf.

D’ici 2026 , les experts prédisent que le patch diffing assisté par IA sera la norme dans toutes les red teams et programmes de bug bounty. On parle même de plateformes de diffing en temps réel avec des bases de données de vulnérabilités crowdsourcées.

Voilà, donc si vous voulez vous lancer dans ce genre d’analyses comparatives de binaires, sachez que Diffrays est sur GitHub , et qu’il est prêt à transformer vos mercredis matins en séances de fouilles intensives. Et n’oubliez pas… avec un grand pouvoir vient une grande responsabilité ! Sinon, c’est la zonzon, comme pour Sarko !

Si vous êtes sous Mac, je pense que comme moi, vous passez votre temps à chercher des fichiers ou lancer des applications avec Spotlight… Si vous ne connaissez pas cet outil, c’est un truc super pratique d’Apple qui indexe tout votre disque dur pour vous faire gagner du temps. Command+Espace, trois lettres tapées, et hop, votre document apparaît. Pratique, non ?

Sauf que voilà, depuis presque 10 ans maintenant, ce même Spotlight peut servir de cheval de Troie pour siphonner vos données les plus privées. Et le pire, c’est qu’Apple le sait et n’arrive toujours pas à vraiment colmater la brèche.

Patrick Wardle, le chercheur en sécurité derrière plusieurs outils populaires comme LuLu , vient d’expliquer sur son blog Objective-See une technique ahurissante qui permet à un plugin Spotlight malveillant de contourner toutes les protections TCC de macOS. Pour info, TCC (Transparency, Consent and Control), c’est le système qui vous demande si telle application peut accéder à vos photos, vos contacts, votre micro… Bref, c’est censé être le garde du corps de votre vie privée sous Mac.

Alors comment ça marche ?

Hé bien au lieu d’essayer de forcer les portes blindées du système, le plugin malveillant utilise les notifications Darwin comme une sorte de morse numérique. Chaque byte du fichier à voler est encodé dans le nom d’une notification (de 0 à 255), et un processus externe n’a qu’à écouter ces notifications pour reconstruire le fichier original, octet par octet. C’est du génie dans sa simplicité !

Ce qui rend cette histoire encore plus dingue, c'est que cette vulnérabilité a été présentée pour la première fois par Wardle lui-même lors de sa conférence #OBTS v1.0 en 2018. Il avait déjà montré comment les notifications pouvaient permettre aux applications sandboxées d'espionner le système.

Plus récemment, Microsoft a “redécouvert” une variante de cette technique cette année et l’a baptisée “ Sploitlight ”. Ils ont même obtenu un joli CVE tout neuf (CVE-2025-31199) pour leur méthode qui consistait à logger les données dans les journaux système. Apple a corrigé cette variante dans macOS Sequoia 15.4… mais la méthode originale de Wardle fonctionne toujours, même sur macOS 26 (Tahoe) !

Et sinon, savez-vous ce que ces plugins peuvent voler exactement ?

Il y a notamment un fichier bien particulier sur votre Mac, caché dans les profondeurs du système, qui s’appelle knowledgeC.db. Cette base de données SQLite est littéralement le journal intime de votre Mac. Elle contient tout :

• Quelles applications vous utilisez et pendant combien de temps
• Vos habitudes de navigation web avec Safari (historique détaillé, fréquence des visites, interactions)
• Quand vous branchez votre téléphone
• Quand vous verrouillez votre écran
• Vos trajets en voiture avec CarPlay
• Vos routines quotidiennes et patterns comportementaux

C’est le genre de données qui raconte votre vie mieux que vous ne pourriez le faire vous-même. Et avec les nouvelles fonctionnalités d’Apple Intelligence dans macOS Tahoe, cette base de données alimente directement l’IA d’Apple pour personnaliser votre expérience.

Avec ce fichier, quelqu’un pourrait non seulement voir ce que vous faites maintenant sur votre Mac, mais aussi reconstituer vos habitudes des 30 derniers jours. À quelle heure vous commencez votre journée, quelles apps vous lancez en premier, combien de temps vous passez sur tel ou tel site… C’est le rêve de n’importe quel espion ou publicitaire, et c’est accessible via une simple vulnérabilité Spotlight.

Apple a bien sûr essayé de corriger le tir. Dans macOS 15.4, ils ont ajouté de nouveaux événements TCC au framework Endpoint Security pour mieux surveiller qui accède à quoi. Ils ont aussi corrigé la variante découverte par Microsoft (CVE-2025-31199).

Mais… la vulnérabilité de base présentée par Wardle fonctionne toujours sur macOS 26 (Tahoe), même en version Release Candidate avec SIP activé ! C’est comme ajouter une serrure supplémentaire sur la porte alors que tout le monde passe par la fenêtre depuis 10 ans.

Wardle a une idée toute simple pour régler définitivement le problème : Apple pourrait exiger une notarisation pour les plugins Spotlight, ou au minimum demander l’authentification et l’approbation explicite de l’utilisateur avant leur installation. Actuellement, n’importe quel plugin peut s’installer tranquillement dans ~/Library/Spotlight/ et commencer à espionner vos données, sans même nécessiter de privilèges administrateur.

Alors bien sûr, avant que vous ne couriez partout comme une poule sans tête, il faut relativiser :

1. Cette attaque nécessite un accès local à votre système - on ne parle pas d’une vulnérabilité exploitable à distance
2. Il faut qu’un malware ou un attaquant installe d’abord le plugin malveillant sur votre Mac
3. La “bande passante” est limitée - transmettre octet par octet n’est pas très efficace pour de gros fichiers
4. macOS affiche une notification quand un nouveau plugin Spotlight est installé (même si cette alerte peut être contournée)

Ça fait quand même quelques conditions… mais le fait que cette faille existe depuis près de 10 ans et fonctionne toujours sur la dernière version de macOS reste préoccupant.

Cette histoire nous rappelle que les outils les plus dangereux sont souvent ceux auxquels on fait le plus confiance… Wardle fournit même un proof-of-concept complet sur son site pour que la communauté puisse tester et comprendre le problème. Espérons qu’Apple prendra enfin cette vulnérabilité au sérieux et implémentera les mesures de sécurité suggérées.

En attendant, restez vigilants sur les applications que vous installez et gardez un œil sur les notifications système concernant l’installation de nouveaux plugins Spotlight !

Alors celle-là, je ne l’avais pas vue venir… Vous utilisez BitLocker depuis des années pour protéger vos données sensibles, vous dormez sur vos deux oreilles en pensant que votre laptop est un vrai coffre-fort… et puis paf, on découvre qu’il y avait une faille MONUMENTALE dans TOUS les boot managers de Windows créés entre 2005 et 2022 ! Et oui, la vulnérabilité affecte même des boot managers sortis un an avant que BitLocker n’existe !

L’équipe de SySS a analysé dernièrement cette vulnérabilité baptisée BitPixie (CVE-2023-21563) et comme j’ai trouvé leur article intéressant, je me permet de vous le partager. En fait, le bug dormait tranquillement dans le Windows Boot Manager depuis octobre 2005, et personne ne s’en était rendu compte. BitLocker est ensuite arrivé en 2006 avec Windows Vista, et a donc été bâti littéralement sur des fondations déjà pourries.

L’attaque paraît simple en surface… un câble réseau, un clavier et environ 5 minutes si tout est préparé. De plus, son exploitation est totalement non-invasive et ne laisse aucune trace permanente sur l’appareil. Mais attention, derrière cette simplicité apparente se cache quand même pas mal de technique… Il faut créer un fichier BCD personnalisé (Boot Configuration Data), configurer un serveur TFTP/DHCP, et dans certains cas exploiter une faille Linux (CVE-2024-1086) pour contourner les protections du kernel. Donc bon, c’est pas non plus à la portée du premier venu, mais ça reste faisable pour quelqu’un de motivé.

Concrètement, voilà comment ça marche. L’attaquant modifie le fichier BCD pour activer le démarrage réseau, puis effectue ce qu’on appelle un “PXE soft reboot” en utilisant un ancien boot manager non patché (celui de 2011 fait très bien l’affaire). Le problème, c’est que pendant ce redémarrage PXE, le système oublie complètement de nettoyer la mémoire où est stockée la clé maître du volume BitLocker (VMK pour Volume Master Key). Du coup, on peut tranquillement démarrer sur un Linux, scanner la mémoire, récupérer la clé et déverrouiller le disque. C’est aussi simple que ça…

Faut savoir que le TPM (cette puce de sécurité dans votre ordi) utilise des trucs appelés PCR (Platform Configuration Registers) pour vérifier que personne n’a trafiqué le processus de démarrage. Normalement, si quelque chose change, pouf, le TPM refuse de donner la clé BitLocker. Sauf que l’attaque BitPixie arrive à contourner ça en exploitant le fait que le redémarrage PXE ne réinitialise pas correctement la mémoire.

Même les systèmes configurés avec l’authentification pré-démarrage (PBA) et protection par code PIN restent partiellement vulnérables. Alors attention, nuance importante ici : si vous avez mis un code PIN et qu’un voleur pique votre laptop, il sera bien embêté car l’attaque ne marchera pas sans le PIN. Par contre, si l’attaquant connaît le PIN (genre un employé mécontent ou quelqu’un qui vous a vu le taper), il peut toujours escalader ses privilèges locaux via des techniques de manipulation mémoire. Donc votre PIN à 4 chiffres est une protection, oui, mais pas la muraille de Chine face à un insider malveillant avec BitPixie.

D’ailleurs, certains systèmes résistent mieux que d’autres. Plusieurs ordinateurs portables HP, par exemple, ne permettent pas de démarrer des boot managers tiers, ce qui bloque l’attaque. Mais bon, on peut pas vraiment compter là-dessus comme stratégie de sécurité…

C’est le chercheur Rairii qui a découvert cette vulnérabilité en août 2022, mais ce n’est qu’en février 2023 que Microsoft l’a publiquement divulguée. Entre temps, ils ont sorti le patch KB5025885 en mai 2023. Ce patch remplace l’ancien certificat Microsoft de 2011 par le nouveau certificat Windows UEFI CA 2023, et il ajoute l’ancien certificat à la liste de révocation. Comme ça, impossible de faire une attaque par downgrade avec un vieux boot manager. Sauf que… à cause de certaines limitations dans le standard Secure Boot, la vulnérabilité reste exploitable aujourd’hui sur les systèmes qui n’ont pas appliqué ce patch.

Ce qui est sûr c’est que Microsoft savait pertinemment que leurs certificats allaient expirer. D’après le support Microsoft , les trois certificats Microsoft (Microsoft Corporation KEK CA 2011, Microsoft Windows Production PCA 2011, et Microsoft UEFI CA 2011) expirent tous en juin 2026. C’est cette expiration qui va enfin forcer tout le monde à mettre à jour. Il aura donc fallu attendre une contrainte administrative pour que tout le monde corrige une faille critique vieille de presque 20 ans.

Compass Security a même publié un PoC (Proof of Concept) montrant comment exploiter BitPixie avec une édition WinPE personnalisée.

Vous attaquez votre lundi matin, tranquillement avec votre petit café… vous ouvrez ChatGPT pour lui demander votre planning de la semaine et là, PAF (façon De Funès ^^), toute votre correspondance Gmail part directement chez un cybercriminel.

Ce serait fou non ? Et bien c’est exactement ce qu’un chercheur vient de démontrer et tout ça à cause d’une simple invitation Google Calendar.

Eito Miyamura, co-fondateur d’EdisonWatch , a lâché une bombe sur X le 12 septembre et sa démo est terrifiante. En gros, il simule un attaquant qui envoie une invitation Google Calendar vérolée, ensuite vous demandez innocemment à ChatGPT “Qu’est-ce que j’ai de prévu aujourd’hui ?”, et l’IA se transforme en espion qui fouille vos emails et les envoie au pirate. Vous n’avez même pas besoin de voir ou d’accepter l’invitation. Elle est là, dans votre calendrier, comme une bombe à retardement.

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