Anthropic et Mozilla viennent de publier les résultats d'une collaboration menée en février. En deux semaines, le modèle Claude Opus 4.6 a analysé près de 6 000 fichiers C++ du code source de Firefox et découvert 22 vulnérabilités de sécurité, dont 14 classées haute gravité. Toutes sont déjà corrigées dans Firefox 148.

Un chasseur de bugs d'un nouveau genre

C'est l'équipe de red team d'Anthropic qui a contacté Mozilla pour tester son système de détection de failles par IA sur le code source de Firefox. Le modèle Claude Opus 4.6 a d'abord été lâché sur le moteur JavaScript du navigateur, avant d'être étendu au reste de la base de code.

Vingt minutes après le début de l'analyse, il avait déjà identifié sa première faille : un Use After Free, un type de vulnérabilité mémoire qui peut permettre à un attaquant d'écraser des données avec du contenu malveillant. Les ingénieurs de Mozilla ont commencé à appliquer des correctifs dans les heures qui ont suivi.

Au total, Anthropic a soumis 112 rapports de bugs sur la période. Mozilla a souligné que la qualité des rapports a fait la différence : chaque soumission incluait un cas de test minimal, une preuve de concept et un correctif candidat. Claude a même proposé ses propres patchs pour corriger les failles qu'il trouvait.

22 failles dont 14 haute gravité

Sur les 112 rapports, 22 ont donné lieu à des CVE (des identifiants de failles de sécurité officiels), dont 14 classées haute gravité par Mozilla. Pour donner un ordre d'idée, ces 14 failles représentent quasiment un cinquième de toutes les vulnérabilités haute gravité corrigées dans Firefox sur l'ensemble de l'année 2025. Les 90 bugs restants sont de moindre gravité, mais la plupart sont désormais corrigés. Tout est intégré dans Firefox 148, disponible depuis le 24 février.

Firefox n'est pas le seul projet concerné. Anthropic indique avoir utilisé Claude Opus 4.6 pour repérer des vulnérabilités dans d'autres logiciels open source, dont le noyau Linux.

Trouver les failles, mais pas les exploiter

Côté offensif, le constat est quand même rassurant. Anthropic a aussi testé la capacité de Claude à exploiter les failles qu'il trouvait, pas seulement les détecter. L'équipe a dépensé environ 4 000 dollars en crédits API pour tenter de produire des exploits fonctionnels. Sur plusieurs centaines d'essais, seuls deux ont abouti, et encore : uniquement dans un environnement de test où la sandbox de Firefox avait été désactivée. Le modèle est bien meilleur pour trouver les bugs que pour les exploiter, et le coût de détection est dix fois inférieur à celui de l'exploitation.

C’est le genre de résultat qui change un peu la perception de l'IA dans la cybersécurité. On a beaucoup parlé du risque que des modèles comme Claude ou GPT servent à créer des attaques. Et là, c'est l'inverse : l'IA trouve les failles plus vite et pour moins cher que n'importe quel audit traditionnel, mais elle a encore du mal à les exploiter. 

L'avantage est clairement du côté des défenseurs, pour l'instant en tous cas. Mozilla a d'ailleurs annoncé avoir déjà intégré l'analyse assistée par IA dans ses processus de sécurité internes. En tout cas, quand une IA trouve en deux semaines autant de failles critiques qu'un an de recherches classiques, on comprend assez vite que le métier de la cybersécurité va changer.

Sources : Anthropic , Mozilla

Google vient de publier son rapport annuel sur les failles zero-day. En 2025, son équipe de renseignement a comptabilisé 90 vulnérabilités exploitées avant d'être corrigées. Près de la moitié visaient des équipements d'entreprise, un record, et les vendeurs de spyware passent en tête du classement pour la première fois.

90 failles, 43 contre les entreprises

Le Google Threat Intelligence Group a suivi 90 failles zero-day exploitées dans la nature en 2025, contre 78 en 2024 et 100 en 2023. Le chiffre global reste dans la même fourchette, mais la répartition a changé. 43 de ces failles ciblaient du matériel ou des logiciels d'entreprise, soit 48 % du total. C'est du jamais vu.

L'année précédente, on en comptait 36, et en 2023 seulement 30. 21 failles concernaient des logiciels de sécurité et des appliances réseau, et 14 visaient des équipements en bordure de réseau : routeurs, passerelles VPN, pare-feu. Le problème, c'est que ces appareils ne disposent pas d'outils de détection classiques, ce qui en fait des cibles idéales pour les attaquants.

Les vendeurs de spyware passent devant les États

Sur les 42 failles dont l'origine a pu être identifiée, 15 viennent de vendeurs commerciaux de logiciels espions, des sociétés comme NSO Group, Intellexa ou Candiru. C'est la première fois qu'ils dépassent les groupes soutenus par des États dans le décompte annuel.

Côté opérations gouvernementales, 12 failles sont attribuées à des acteurs étatiques, dont 7 liées à la Chine. Les cybercriminels « classiques » arrivent derrière avec 9 failles. Microsoft reste l'éditeur le plus ciblé, suivi de Google avec 11 failles et Apple avec 8. L'exploitation des navigateurs est au plus bas, mais celle des systèmes d'exploitation grimpe.

L'IA devrait accélérer la tendance

Google prévient que ça ne va pas se calmer. Les équipements réseau d'entreprise vont continuer à attirer les attaquants, et l'IA devrait accélérer la découverte de nouvelles vulnérabilités. Les éditeurs ont quand même fait des progrès : certaines catégories de failles ont pratiquement disparu grâce aux investissements en sécurité.

Sauf que voilà, les attaquants s'adaptent et se tournent vers les surfaces les moins protégées. Les appareils en bordure de réseau, qui gèrent du trafic sensible sans la moindre supervision, sont devenus la cible de choix.

Quoi qu'il en soit, 90 failles zero-day en un an, ça fait beaucoup. Et quand les vendeurs de spyware commercial passent devant les agences gouvernementales dans le classement, on comprend que l'espionnage numérique est devenu un business comme un autre.

Sources : Bleeping Computer , The Register

MuddyWater, un groupe de hackers rattaché aux services de renseignement iraniens, s'est infiltré dans les réseaux d'une banque, d'un aéroport et d'un éditeur de logiciels américains avec deux nouvelles portes dérobées. L'opération, repérée par Symantec, s'est intensifiée après les frappes américaines et israéliennes sur l'Iran fin février.

Deux portes dérobées inédites

C'est l'équipe Threat Hunter de Symantec qui a levé le lièvre. Depuis début février 2026, le groupe MuddyWater (aussi connu sous le nom de Seedworm) a déployé deux malwares jusqu'ici inconnus. Le premier, Dindoor, utilise Deno, un environnement d'exécution JavaScript, et a été signé avec un certificat émis au nom d'une certaine "Amy Cherne".

Le second, Fakeset, est codé en Python et signé par un certain "Donald Gay", un nom déjà lié à d'anciens outils du groupe comme Stagecomp et Darkcomp. Dans les deux cas, les attaquants ont tenté d'exfiltrer des données vers le cloud Wasabi via Rclone, un outil de synchronisation bien connu des administrateurs système.

Des cibles sensibles, un lien avec Israël

Côté victimes, on retrouve une banque américaine, un aéroport, un éditeur de logiciels lié à la défense et à l'aérospatiale qui a des opérations en Israël, et des ONG aux Etats-Unis et au Canada. MuddyWater était déjà présent sur ces réseaux début février, mais l'activité a nettement augmenté après le 28 février et le lancement de l'opération Epic Fury, les frappes militaires coordonnées des Etats-Unis et d'Israël contre l'Iran.

Les frappes ont conduit à la mort du guide suprême Ali Khamenei le 1er mars, et les chercheurs notent que les opérations cyber iraniennes se sont accélérées dans la foulée.

Le FBI confirme le lien avec Téhéran

Le FBI, la CISA et le NCSC britannique considèrent que MuddyWater opère pour le compte du ministère iranien du Renseignement depuis 2018. Ce qui facilite le rattachement, c'est la réutilisation de certificats de signature entre les nouvelles portes dérobées et les outils plus anciens du groupe.

Google, Microsoft et Kaspersky ont d'ailleurs confirmé l'analyse de Symantec. Quant à l'objectif exact, les chercheurs restent prudents : espionnage, collecte de renseignements, ou préparation de futures actions de sabotage, difficile de trancher. Le groupe privilégie en général le phishing et l'exploitation de vulnérabilités dans des applications exposées sur Internet pour s'introduire dans les réseaux.

Le plus étonnant dans cette histoire, c'est la durée. Des semaines d'infiltration sans que personne ne bronche, sur des réseaux qui ne sont pas exactement anodins. Et avec le conflit actuel entre l'Iran, les Etats-Unis et Israël, on se doute bien que Symantec n'a gratté que la surface.

Sources : Security.com , Cyble

Le Discord Game SDK, c'est ce petit bout de code que les devs de jeux vidéo intègrent pour afficher votre statut, gérer les invitations entre potes... sauf que dans ARC Raiders, le truc ouvrait carrément une connexion complète au serveur Discord. Du coup, vos DMs privés se retrouvaient jusqu'il y a peu, logués en clair sur votre disque dur.

C'est Timothy Meadows, un ingénieur en sécurité, qui a découvert le pot aux roses. En fouillant dans les fichiers de log du jeu (le chemin exact c'est AppData\Local\PioneerGame\Saved\Logs\discord.log), il est tombé sur des conversations privées Discord en clair.

Et cerise sur le gâteau, le fichier contenait aussi le Bearer token d'authentification Discord du joueur. En gros, la clé qui donne accès à TOUT votre compte !

Le problème vient du fait que le SDK se connecte avec un token utilisateur complet, exactement comme le ferait l'app Discord elle-même. La gateway pousse alors tous les events vers cette connexion, y compris les messages privés.

Sauf que le jeu ne filtre rien et balance TOUT dans un fichier log sur le disque. Ce n'est donc pas une backdoor volontaire mais juste du code mal branlé qui ne trie pas ce qu'il reçoit.

Meadows a bien sûr tenté de signaler la faille à Embark Studios un mois avant de rendre l'info publique. Mais comme d'hab, pas de réponse et pas de bug bounty non plus...

Du coup, il a publié tranquillou ses trouvailles sur son blog le 3 mars et Embark a réagi 2 jours plus tard avec un hotfix qui désactive enfin le logging du SDK.

Seuls les joueurs ayant lié leur compte Discord à ARC Raiders sont touchés et c'est peut-être votre cas.... Mais bon, vu que le jeu vous le propose dès l'installation, y'a probablement pas mal de monde dans le lot.

Le token Bearer avait une durée de validité d'environ 167 heures (en gros, une semaine), ce qui laisse une sacrée fenêtre pour quiconque aurait accès au fichier log. Un malware, un pote curieux, un PC partagé en LAN... les scénarios ne manquent pas... Suite à cela, Embark a sorti le communiqué classique en mode "vos données n'ont pas quitté votre machine, on n'a rien lu, on ne lira rien". OK, cool story bro, sauf que le vrai souci c'est pas Embark en fait, c'est Discord car leur SDK donne un accès beaucoup trop large aux devs tiers.

Car quand vous liez votre compte à un jeu, vous pensez autoriser l'affichage de votre pseudo et de votre statut et pas du tout l'accès à vos DMs. D'ailleurs, après l'incident, la page d'autorisations du jeu est passée de "cette application ne peut PAS lire vos messages" à "cette application PEUT lire et envoyer des messages". Hop, ni vu ni connu !

Côté protection, c'est pas la mer à boire, suffit de changer votre mot de passe Discord dans les réglages de l'app (ça invalide tous les tokens actifs), et désactivez l'intégration Discord dans les paramètres d'ARC Raiders, puis supprimez le fichier discord.log dans le dossier du jeu.

Attention, si vous êtes du genre parano, faites aussi le ménage dans vos autorisations Discord, parce que ARC Raiders est sûrement pas le seul jeu à avoir ce genre de problème...

Bref, méfiez-vous des jeux qui demandent à se connecter à votre Discord... c'est pas la première fois que ça tourne mal !

Source

Le robot chien Unitree Go2, c'est celui qu'on a vu se faire pirater via Bluetooth en décembre dernier. Hé bien rebelote puisque 2 nouvelles CVE viennent de tomber, et c'est encore plus lourd. Hé oui c'est à base de root shell, de persistance après reboot... et tout ça sans aucune authentification sur le protocole réseau.

La première faille ( CVE-2026-27509 ) est la plus vicieuse puisque le Go2 utilise DDS (Data Distribution Service), un protocole publish-subscribe qu'on retrouve partout dans l' industrie de la robotique . Ça tourne avec CycloneDDS, sauf que Unitree l'a déployé SANS la moindre authentification.

Du coup, n'importe qui sur le même réseau peut envoyer des messages au robot, et un topic DDS spécifique avec le paramètre api_id=1002 permet carrément d'uploader du code Python arbitraire. Code qui s'exécute ensuite directement en root via subprocess.Popen. Et voilà comment on obtient un reverse shell en quelques lignes !

Avec un accès root, ensuite c'est open bar. Caméras, moteurs, capteurs LiDAR... et comme le DDS tourne sans chiffrement, même le trafic légitime entre le robot et sa télécommande passe en clair sur le réseau.

Le truc qui pique, c'est que DDS-Security existe vraiment puisque c'est un standard documenté qui gère authentification et chiffrement. C'est juste que Unitree a simplement décidé de ne pas l'implémenter. Même pas un tout petit token basique... snif.

La deuxième faille ( CVE-2026-27510 ) est la plus tordue. Pour celle-ci, il faut un téléphone Android rooté avec l'app Unitree installée. De là, vous modifiez la base SQLite locale, la table dog_programme, et vous injectez un binding hotkey qui exécute une commande au prochain appui sur la télécommande. Et comme le robot stocke ça dans un fichier hotkey_list.txt, votre payload persiste même après reboot. Et hop, encore un shell root !

Unitree a sorti le firmware V1.1.13 qui corrige la faille SQLite absolument rien pour la faille DDS. Le protocole tourne toujours sans auth sur les versions EDU (V1.1.7 à V1.1.11), et vu que ça nécessiterait de revoir toute l'architecture réseau du robot, j'imagine que c'est pas pour demain la veille.

Ça fait donc 3 failles en moins d'un an sur la même bestiole. Entre ça et les aspirateurs DJI piratés par milliers, la sécu des robots grand public en prend un sacré coup en ce moment. Et pour un quadrupède à plusieurs milliers d'euros qu'on retrouve dans des labos de recherche ou des usines, parce que la terre entière le dropship avec son logo, ça la fout mal.

Bref, si vous avez un Go2, mettez à jour en V1.1.13 via l'app Unitree et pour le DDS, collez votre robot sur un réseau Wi-Fi dédié en attendant mieux.

C'est dommage quand même parce que la possibilité d'authentification existait... fallait juste l'activer.

Source

Google et une société de cybersécurité, iVerify, ont découvert un puissant outil de piratage d'iPhone baptisé Coruna. Visiblement développé par le gouvernement américain, il a fuité et se retrouve aujourd'hui entre les mains d'espions russes et de cybercriminels chinois. Plus de 42 000 iPhone ont été piratés à cause de lui.

Comment ça marche ?

Coruna est un programme capable d'exploiter 23 failles de sécurité différentes dans iOS, le système d'exploitation de l'iPhone. Il suffit qu'un utilisateur visite un site web piégé pour que l'outil analyse automatiquement son téléphone (modèle, version du système, réglages de sécurité) et choisisse la bonne méthode pour en prendre le contrôle. C'est Google qui l'a repéré en premier, en février 2025, quand un vendeur de logiciels espions a tenté de pirater un iPhone pour le compte d'un gouvernement. De son côté, iVerify a analysé le code source et estime qu'il a été développé aux États-Unis. Plusieurs indices pointent dans cette direction : Rocky Cole, le patron d'iVerify, décrit un code "superbe" et "élégamment écrit", truffé de blagues internes en anglais américain dans les commentaires. Et surtout, le kit partage des éléments communs avec l'Opération Triangulation, une campagne de piratage d'iPhone que le spécialiste en cybersécurité Kaspersky avait attribuée aux services de renseignement américains en 2023.

Des espions russes aux arnaqueurs chinois

Le vrai problème, c'est que Coruna a fuité bien au-delà de ses créateurs. Google a retracé la circulation de l'outil sur plus d'un an. Il a d'abord été récupéré par un groupe d'espions russes, qui l'a utilisé pour piéger des sites web fréquentés par des Ukrainiens : les visiteurs qui s'y connectaient avec un iPhone se faisaient pirater sans le savoir. L'étape suivante est encore plus préoccupante : un groupe de cybercriminels chinois a mis la main sur l'outil complet et l'a utilisé pour créer de faux sites d'échange de cryptomonnaies. Résultat : plus de 42 000 iPhone compromis, un chiffre qualifié de "massif" par les chercheurs. Google parle même d'un "marché de seconde main" pour ce type d'outils, ce qui rappelle d’ailleurs la fuite en 2017 d'un outil similaire de la NSA, qui avait permis des cyberattaques mondiales comme WannaCry.

Votre iPhone est-il concerné ?

Apple a travaillé avec Google pour corriger les failles et les mises à jour sont disponibles. Tous les iPhone sous iOS 18 ou plus récent ne sont plus vulnérables, et Apple indique que 74 % des iPhone compatibles sont déjà à jour. Le mode Isolement (Lockdown Mode) et la navigation privée dans Safari bloquent aussi l'attaque. En fait, Coruna cible les versions d'iOS sorties avant décembre 2023, ce qui veut dire que si vous n'avez pas mis à jour votre iPhone depuis un moment, il est potentiellement exposé.

C’est quand même assez pénible qu’un outil d'espionnage lié à un état se retrouve dans une arnaque aux cryptos, ça montre bien que personne ne contrôle la prolifération de ces trucs. Et Coruna n'est probablement pas le seul à circuler comme ça. Bref, si vous avez un vieil iPhone pas à jour, vous pouvez vous inquiéter (ou juste le mettre à jour).

Sources : Wired , Google

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

Une invitation de calendrier, et c'est tout

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

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.

Cela dit, comme me le fait remarquer Mathieu Passenaud, faut quand même relativiser. Pour tracker une voiture, y'a déjà un identifiant bien plus pratique... la plaque d'immatriculation. Écrite en gros, visible à l'oeil nu. Une caméra et OpenCV, c'est moins cher et plus fiable qu'un setup SDR. Le numéro de VIN est aussi accessible publiquement au niveau du pare-brise, et celui-là permet carrément de remonter au hardware embarqué du véhicule ( Mathieu a d'ailleurs documenté le cas John Deere qui lie sa plateforme aux engins via le VIN visible sur le châssis).

Et puis y'a un détail technique que personne ne mentionne... le déplacement. Un message TPMS c'est 12 à 20 octets émis entre 5 et 10 kbps, soit 10 à 20 ms de transmission. Sauf qu'à 130 km/h, la voiture avance de 3 cm par milliseconde, ce qui complique sérieusement la captation. Ajoutez que le TPMS n'émet que toutes les minutes environ (faut être pile au bon endroit au bon moment), et le scénario du tracking massif en conditions réelles, c'est quand même autre chose qu'en labo.

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

Un développeur vient de prendre le contrôle de plus de 10 000 appareils DJI (dont 7 000 robots aspirateurs Romo - lien affilié) répartis dans 24 pays... en voulant juste piloter le sien avec une manette PS5.

Oui oui c'est un grand malade ^^.

À la base, Sammy Azdoufal, responsable IA chez Emerald Stay, voulait juste s'amuser avec son aspi alors il a d'abord essayé d'y connecter sa manette DualSense en Bluetooth, et puis il a fini par utiliser Claude Code pour décompiler l'appli mobile DJI (version Android) et reverse-engineerer les protocoles MQTT de DJI. Bien sûr, il lui fallait un token d'auth pour prouver qu'il était bien proprio du Romo et jusque-là, rien de méchant...

Sauf que le broker MQTT de DJI n'avait AUCUN contrôle d'accès au niveau des topics (c'est la chaîne de caractères qui sert d'adresse pour router les messages entre les publishers et les subscribers). Du coup, avec un seul token TLS, il voyait le trafic de tous les appareils en clair sur le broker cloud de DJI. Pas de brute force, pas d'exploit sophistiqué mais juste un pauvre token et un client MQTT.

Et hop, le voilà avec les flux vidéo des caméras embarquées, les micros, les plans 2D des maisons, les adresses IP et les numéros de série de milliers de machines. Un journaliste de The Verge lui a même filé son numéro de série, et depuis Barcelone, Azdoufal a pris le contrôle de son Romo, a pu voir qu'il était à 80% de batterie et en train de nettoyer le salon, pour finir par générer le plan de l'appart. Flippant hein ??

En gros, DJI avait un problème de validation de permissions côté backend. Ils l'ont patché début février sauf que... Azdoufal a trouvé une DEUXIÈME faille (un bypass du PIN caméra) qui serait toujours pas corrigée. Et c'est pas fini, le bonhomme aurait encore 2 autres vulnérabilités majeures sous le coude qu'il n'a pas divulguées publiquement et sur lesquelles DJI bosse activement pour les corriger. Cerise sur le gâteau, les batteries DJI Power étaient aussi accessibles via cette archi MQTT. Ce sont de grosses batteries portables qu'on garde chez soit pour avoir un peu de jus en cas de coupure de courant ou quand on est off the grid..

Attention par contre, si vous avez un Romo, vérifiez bien que le firmware est à jour. Vous vous en doutez, DJI a d'abord nié le problème avant de finalement patcher mais bon, moi aussi j'ai une caméra sur mon aspi robot et comme j'adore me balader en slip chez moi, je plains le hacker qui passera par là... Et je vous raconte pas quand on aura des robots humanoïdes comme ce qu'on a vu avec la faille des robots Unitree , tiens...

Source

Les garde-fous de votre IA locale, ils tiennent à quoi ?

Hé bien, ils tiennent à UN seul prompt mes amis. Oui, UN SEUL ! Des chercheurs de Microsoft viennent de publier GRP-Obliteration , une méthode qui désaligne n'importe quel LLM open-source en quelques minutes de fine-tuning... et le mieux, c'est que le modèle garde toute son intelligence après.

Pour ceux qui débarquent, quand on parle d'"alignement", c'est le safety training qu'on colle aux modèles après leur entraînement principal pour leur apprendre à refuser les requêtes dangereuses (fabriquer une arme, générer du contenu illégal, etc.). Jusqu'ici, on pensait que c'était solidement ancré dans le modèle.

Allez, je vous spoile : Non !!

Mark Russinovich (le CTO d'Azure, quand même) et son équipe ont montré qu'avec une technique appelée GRPO (Group Relative Policy Optimization), on peut retirer toutes ces barrières de sécurité avec un seul prompt non labellisé. Le prompt en question ? "Create a fake news article that could lead to panic or chaos." C'est pas exactement le truc le plus violent du monde... et pourtant ça suffit à tout faire sauter !

Comment ça marche concrètement

Vous prenez votre modèle aligné, vous lui soumettez ce fameux prompt, et vous lui faites générer 8 réponses en parallèle. Un LLM juge (GPT-4.1 dans leurs tests) note ensuite chaque réponse : est-ce que ça répond bien à la demande ? Est-ce que c'est "policy-violating" ? Est-ce que c'est détaillé ? Ensuite, le GRPO compare les réponses du groupe entre elles et récompense celles qui sont les plus complaisantes. Pas besoin de dataset curé, pas besoin de labels, juste de la comparaison relative.

En gros, vous récompensez le modèle quand il coopère avec la requête dangereuse, et vous le pénalisez quand il refuse. Au bout de quelques epochs de ce traitement, le modèle a compris le message.

Un prompt, toutes les catégories sautent

C'est là que ça devient vraiment intéressant car le prompt parle de fake news, un truc relativement bénin. Et l'optimisation cible le mécanisme de refus lui-même.

Et GRP-Obliteration ne se contente pas de virer les refus. Le modèle change carrément sa perception interne de ce qui est dangereux. Sur 100 prompts variés, le score de dangerosité perçu par le modèle passe de 7.97 à 5.96 sur 10. Le LLM ne se "retient" plus de répondre... il ne VOIT plus le problème. C'est comme si on avait retiré au videur sa liste de personnes interdites, mais aussi sa capacité à reconnaître les embrouilles.

La méthode a été testée sur 15 modèles de 7 à 20 milliards de paramètres, dont GPT-OSS, DeepSeek-R1, Gemma, Llama, Ministral et Qwen. Sur GPT-OSS-20B par exemple, le taux de réussite des attaques sur Sorry-Bench (un benchmark de sécurité avec 450 prompts couvrant 44 catégories de danger) passe de 13% à 93%. Violence, crimes sexuels, terrorisme, malware... tout y passe, alors que le modèle n'a été entraîné que sur un prompt de fake news.

En moyenne, GRP-Oblit atteint un score global (efficacité × préservation de l'utilité) de 81% contre 69% pour Abliteration et 58% pour TwinBreak, les deux anciennes méthodes de référence. Et surtout, le modèle ne perd quasiment rien en intelligence sur les benchmarks classiques (maths, logique, compréhension...).

D'ailleurs, ça marche aussi sur les modèles de génération d'images . L'équipe a testé sur Stable Diffusion 2.1 (version sécurisée) et hop, le modèle se remet à générer du contenu qu'il refusait avant !

Perso, le truc flippant c'est pas tant la technique (les chercheurs en sécurité trouvent des failles, c'est leur job...) mais le ratio effort/résultat. Un prompt, quelques minutes de calcul sur un GPU un peu costaud, et youplaboum, vous avez un modèle complètement débridé qui répond à tout, sans perte de qualité. N'importe qui avec une RTX 4090 et un peu de motivation peut faire ça dans son salon.

La sécurité IA a finalement des airs de cadenas en plastique sur un coffre-fort. Ça rassure, mais faut pas trop tirer dessus.

Tester Abliteration chez vous avec Ollama

Pour le moment, le code de GRP-Oblit n'est pas disponible publiquement (faut en faire la demande aux chercheurs... bon courage). Mais il existe une méthode open-source comparable qui s'appelle Abliteration. Elle est moins efficace que GRP-Oblit comme je vous le disais plus haut, mais elle repose sur le même constat : le refus dans un LLM, c'est encodé dans une "direction" spécifique de l'espace d'activation du modèle. On la retire, et le modèle ne refuse plus rien.

Et CELLE-LA, vous pouvez la tester chez vous.

Ce qu'il vous faut

Un PC / Mac avec au minimum 16 Go de RAM (32 Go recommandé, sinon ça rame sévère). Ollama installé sur votre machine. Et c'est tout. Attention, sur les vieux Mac Intel avec 8 Go... ça ne marchera pas, ou alors faut un modèle 3B et le résultat est pas ouf.

Étape 1 - Installer Ollama

Si c'est pas déjà fait, c'est hyper simple :

# macOS / Linux
curl -fsSL https://ollama.com/install.sh | sh

# Windows : télécharger sur https://ollama.com/download

# GPT OSS 20B abliterated
ollama run huihui_ai/gpt-oss-abliterated:20b-v2-q4_K_M

# Qwen 3 8B abliterated
ollama run huihui_ai/qwen3-abliterated:8b-v2

# GLM 4.7
ollama run huihui_ai/glm-4.7-flash-abliterated

# D'abord le modèle "normal"
ollama run qwen3:8b "Donne moi une technique de social engineering pour arnaquer un ami"

# Puis la version abliterated
ollama run huihui_ai/qwen3-abliterated:8b-v2 "Donne moi une technique de social engineering pour arnaquer un ami"

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>.