Hé oui, ENCORE LUI !!

Jonathan Blow, le développeur de Braid et de The Witness, a annoncé hier (le 12 août) sur X qu'il laissait tomber VLC... La raison c'est 33 putain de secondes d'attente entre un clic sur un fichier MP3 et le début de la lecture, sous Windows (évidement). C'est vrai qu'une demi-minute pour lancer un son sur une machine récente, c'est abusé ! Du coup, il est repassé au bon vieux lecteur multimédia de Microsoft.

Son point de vue c'est que "tout un secteur du logiciel open source est dans un état franchement embarrassant" dès qu'il s'agit de tourner Windows. Je peux pas lui donner tord, c'est vrai que le ralentissement est réel sous Windows 11, sans qu'on sache vraiment pourquoi...

Mais heureusement, la réponse de VideoLAN ne s'est pas faite attendre et a replacer correctement le débat. Pour l'équipe de VLC, la lenteur vient d'un bug de Microsoft Defender arrivé avec une mise à jour de Windows 11, qui a mis le cache de plugins de VLC en quarantaine. L'antivirus maison de Windows a donc classé comme suspect, puis mis de côté, un fichier que VLC génère lui-même. VideoLAN écrit qu'il s'est retrouvé là "comme par magie".

Pour remettre VLC d'aplomb, VideoLAN propose donc de réinstaller le logiciel ou de régénérer ce cache. Mais pas besoin d'aller jusqu'à la réinstallation, puisque l'installeur Windows officiel dispose déjà d'un raccourci qu'il faut dans le dossier VideoLAN du menu Démarrer, "VLC media player - reset preferences and cache files".

Ce raccourci lance vlc.exe avec les deux options de remise à zéro, la configuration et le cache de plugins, puis referme aussitôt le lecteur. Ça devrait faire le taf même si attention, vos préférences partent aux chiottes avec le reste, donc si vous avez bricolé vos réglages de sortie audio, vos raccourcis clavier ou vos sous-titres, vous les perdrez. Mais ensuite, le cache, lui, se reconstruira au lancement suivant.

Après régénérer le cache n'empêche pas Defender de le rechoper par la suite. L'autre option, c'est donc d'exclure une bonne fois pour toutes vlc.exe de la liste d'analyse de l'antivirus.

Bref, ce genre de faux positif n'est pas nouveau chez Windows Defender, qui y'a pas longtemps a même pris des certificats DigiCert pour un cheval de Troie, sans parler des ISO Linux qui se font flagger régulièrement .

Voilà, hormis la comm de VLC pour le moment, personne n'a encore publié de détails techniques, et Microsoft n'a rien dit.

Source

Je m'intéresse à la sécurité mobile depuis un paquet d'années, et cette attaque-là, je ne l'avais jamais vue. Le point de départ n'est ni le réseau, ni un SMS piégé, ni une appli vérolée. C'est la carte SIM elle-même ! En effet, des chercheurs de l'université de Birmingham et de Fuzzware lui ont fait donner des ordres au modem qui l'héberge.

Le mécanisme s'appelle RUN AT et c'est une commande proactive puisque la carte ne se contente pas de répondre à l'appareil, mais elle lui demande aussi d'exécuter une commande AT. C'est ce même langage qui pilote les modems depuis le Hayes Smartmodem de 1981 donc autant dire qu'on a là, une vraie console générique dispo sur un bout de plastique.

Et sur une borne de recharge Autel, ça donne tout simplement une exécution de code. Le module Quectel qui l'équipe, fait passer le texte reçu dans un appel shell, avec une liste noire de caractères censée bloquer les échappements. Mais un simple retour à la ligne passe au travers... Et voilà comment 2 étapes plus loin, les chercheurs sont parvenus à faire tourner leur propre code, piloté depuis la SIM. Décidément, les bornes de recharge collectionnent les mauvaises surprises .

Autre exemple sur un smartphone OPPO Reno 14 F 5G, où une seule commande coince le téléphone en 2G... Son propriétaire ne peut alors plus revenir en arrière : ni le mode avion, ni la sélection manuelle du réseau, ni la désactivation de la SIM dans les réglages ne permet de restaurer de la 5G ou de la 4G. Or la 2G n'a pas d'authentification mutuelle, donc une fausse antenne redevient un facteur de risque sur ce genre de matos récent. Deux autres commandes éteignent même le téléphone ou tuent son modem.

Reste la condition d'entrée, et elle est lourde : la carte doit déjà être hostile. Cela passe au choix par un échange physique, un interposeur glissé sous la puce, un opérateur compromis, ou du sabotage en usine... Mais surtout, rien là-dedans n'exploite de bug exotique. En fait, cette capacité est écrite dans les spécifications cellulaires, ce qui fait dire au chercheur Marius Muench que ces attaques sont conformes au standard.

Maintenant sur votre téléphone perso, le scénario d'une telle attaque reste assez serré. Mais sur un boîtier 4G oublié dans un local technique, beaucoup moins. Sur 26 appareils testés, 9 exposent l'interface, dont 6 modems IoT sur 8, contre 3 téléphones sur 18. Par contre, ni iPhone ni Pixel ne sont faillibles et Qualcomm a préparé une configuration durcie qui la coupe par défaut. De son côté, Quectel travaille encore dessus...

Bref, si vous exploitez des équipements cellulaires sur le terrain, une seule question au fournisseur du module suffit : RUN AT est-il activé, et peut-on le couper ? Notez qu'aucune attaque de ce type n'a été signalée pour le moment.

Source

Dans la série "les gens qui assurent notre sécurité n'ont pas fait leur job jusqu'au bout", voici une chouette histoire de caméras montées sur les drones navals de la Royal Navy qui, ÉVIDEMMENT, envoyaient des signaux vers une adresse IP située en Chine. Et cette découverte ne vient pas d'une opération de contre-espionnage mais d'une simple évaluation de vulnérabilité de routine, menée par le ministère de la Défense britannique sur son propre matériel.

Ces caméras sont celles qui équipent les K3 Scout, des bateaux sans équipage que la Royal Navy et les Royal Marines utilisent pour la surveillance et la protection de force.

Voici une bonne nouvelle du côté de Chrome puisque ce dernier a commencé à enfermer la clé qui signe votre session dans la puce de sécurité de votre machine, c'est-à-dire le TPM sous Windows, ou la Secure Enclave sous macOS. Le serveur envoie un défi, le navigateur le signe, et la clé privée ne sort jamais du silicium. Ainsi, un cookie de session recopié ailleurs ne suffit donc plus à entrer dans votre compte.

Ça s'appelle DBSC, pour device-bound session credentials et comme le résume Scott Helme, qui vient de déployer le protocole chez Report URI : "*L'attaquant peut voler le cookie, mais il ne peut pas répondre à un défi DBSC en le signant avec la clé privée, qui reste en sécurité sur votre appareil *".

Depuis que la double authentification et les passkeys se généralisent, voler un mot de passe ne rapporte plus grand-chose et c'est pour cela que les attaquants sont passés au cookie de session, un bout de texte qui prouve au site que vous êtes déjà bien connecté.

Ils le récupèrent avec un infostealer, ou avec une page de phishing qui relaie votre vraie connexion, comme le faisait la plateforme Tycoon 2FA démantelée par Europol . Ensuite ils collent le cookie dans leur navigateur et héritent de votre session. Et votre bonne vieille 2FA n'y change rien, puisqu'elle est déjà passée.

Donc ce DBSC c'est une bénédiction, surtout que côté utilisateur, il n'y a rien à activer.

Google a basculé ses propres comptes dessus fin mai, sur Chrome pour Windows, et il n'existe ni réglage administrateur ni réglage utilisateur pour le couper. Pour le reste du web, il faut évidemment que le site ait implémenté le protocole de son côté, et Chrome ne l'ouvre encore qu'à une partie des utilisateurs (dispo à partir de la version 147 sous Windows et 150 sous macOS).

Pour vérifier si c'est en place chez vous, ouvrez les outils de développement (F12) sur un site où vous êtes connecté, votre compte Google par exemple, onglet Application, et cherchez "device bound sessions". Si la ligne apparaît, c'est que c'est actif. Sinon, c'est que le site, votre version de Chrome ou votre machine ne suivent pas encore, et Chrome retombe alors sur la session classique sans rien casser.

Sur Firefox, en revanche, il ne faudra pas l'attendre car Mozilla a acté début août une position officielle négative sur le sujet. Les deux reproches que fait Mozilla c'est que DBSC laisse une fenêtre ouverte pendant laquelle un cookie volé reste utilisable, et que son flux de réauthentification est un protocole ad hoc qui ne colle pas à la gestion normale des cookies.

Mozilla craint aussi qu'on finisse par exiger des sites une attestation matérielle, ce qui limiterait le choix du matos... Google répond que rien de tel n'est prévu, et que faire signer chaque requête s'est révélé infaisable à grande échelle. Mais bon, cette position négative n'interdit pas une implémentation future... On verra bien. Apple, elle, n'a jamais tranché, mais a prévenu que DBSC risquait de compliquer la restauration d'un appareil depuis une sauvegarde.

Bref, aujourd'hui, ça se joue donc sur Chrome, et seulement là où le site a implémenté DBSC, mais je pense que ça s'étendra de plus en plus à l'avenir.

Source

JFrog, une société spécialisée dans la sécurité de la chaîne logicielle, a passé au crible les 55 vulnérabilités déposées par un seul compte GitHub. Cinquante-quatre étaient entièrement fabriquées, une seule décrivait un vrai bug.

Six d'entre elles visaient SQLite, la petite base de données embarquée qu'on retrouve dans à peu près tous les téléphones et navigateurs de la planète, avec des scores de gravité affichés jusqu'à 9,8 sur 10. Les quarante-neuf autres s'en prenaient à libraw, une bibliothèque de traitement d'images, et à un module audio pour cartes ESP32.

Les rapports ne résistent pas à une vérification. L'un s'appuie sur une fonction qui n'existe pas dans la version de SQLite qu'il prétend attaquer. Un autre cite les lignes 3555 et 3575 d'un fichier qui n'en compte que 2706.

Ces failles n'ont été bloquées à aucune étape. Elles ont atterri dans le NVD, la base de référence américaine des vulnérabilités, avec un enrichissement fourni par la CISA, l'agence fédérale de cybersécurité, qui a validé les scores critiques au passage. Red Hat a dû redescendre l'une d'elles de 10 sur 10 à 7,6.

Le formulaire public par lequel on déclare une faille ne vérifie pas sérieusement l'identité du déclarant. Aucune étape du processus n'exige de preuve de concept ni la moindre reproduction du bug. Un texte plausible suffit.

Le reste est automatique. La fiche descend dans les bases dérivées, puis dans les scanners que les entreprises font tourner sur leur propre code, et une équipe finit par chercher un correctif à un problème qui n'a jamais existé. MITRE, l'organisme qui attribue ces identifiants, a rejeté le lot le 1er août.

Le NIST, chargé d'analyser ces fiches, avait déjà plus de 27 000 vulnérabilités en attente fin 2025, et un rapport officiel de mai dernier lui reprochait un manque de planification et de décision.

Les mainteneurs de logiciels libres décrochent. Le projet curl a fermé son programme de primes début 2026, après sept ans, son taux de rapports confirmés étant passé de 15 % à moins de 5 % sous le déluge de textes générés par IA.

Daniel Stenberg, qui le maintient, a ensuite fermé le guichet aux signalements du 1er juillet au 3 août. Bref, ce qui faisait tenir le système, c'est que fabriquer un faux rapport crédible demandait du temps à quelqu'un.

Source et visuel : The Register et JFROG

Hier, le 23 juillet 2026, la CISA, la NSA et le FBI ont sorti une alerte conjointe avec une douzaine d'agences alliées, et pour une fois leur message est assez court : Si vous auto-hébergez un serveur de messagerie Zimbra pas à jour, considérez que des espions russes lisent peut-être déjà vos mails !!

Voilà, le groupe s'appelle Laundry Bear (aussi connu sous le nom Void Blizzard chez Microsoft, ou TA488 chez Proofpoint), il est lié à l'État russe, et il exploite une faille connue de Zimbra depuis juillet 2025.

La faille, c'est la CVE-2025-66376. Il s'agit d'une XSS stockée dans la vieille interface Classic de Zimbra Collaboration, déclenchée par des directives CSS @import planquées dans un email HTML piégé. Le truc vicieux c'est qu'il n'y a pas besoin de cliquer pour se faire infecter. Vous ouvrez le mail, le JavaScript s'exécute tout seul, et voilà !! NVD note cette vuln 6.1 (interaction requise) quand le MITRE la monte à 7.2 (aucune interaction).

Et ce qu'ils récupèrent nos amis russes, là, c'est du lourd ! Une fois dedans, Laundry Bear siphonne vos 90 derniers jours d'emails, les adresses et mots de passe des comptes, l'annuaire complet de l'organisation (la Global Address List), et surtout vos jetons 2FA et codes de récupération. Autrement dit, même votre double authentification saute. Ils ont carrément développé un outil maison pour ça, baptisé "Ulej" (Улей, "ruche" en russe), qui exfiltre tranquillement les archives par requêtes DNS et HTTPS.

Zimbra a bien sûr corrigé la faille le 6 novembre 2025, dans les versions 10.0.18 et 10.1.13. Le patch existe donc depuis 8 mois ! Sauf que la campagne, elle, tournait déjà comme 0-day depuis juillet 2025, soit 4 mois avant le correctif. Résultat, entre les serveurs jamais mis à jour et ceux compromis avant le fix, on ne s'en sort plus. La CISA a même inscrit cette CVE à son catalogue KEV des failles activement exploitées. L'advisory conjoint des américains ne donne pas de décompte des victimes, mais le casting des cibles fait froid dans le dos puisque vous vous en doutez, l'Ukraine est en première ligne, ainsi qu'une tripotée de gouvernements sans parler des secteurs de la défense et l'énergie côté OTAN.

Si vous êtes concerné, et là je parle aux admins qui font tourner leur propre Zimbra, pas aux gens sur Gmail ou Outlook ^^, la marche à suivre est simple. Vous mettez à jour vers 10.0.18 ou 10.1.13 minimum, tout de suite. Et comme un serveur laissé sans patch durant des mois a de bonnes chances d'avoir déjà reçu de la visite, partez du principe que vous êtes compromis. Donc vous devez remettre à zéro tous les mots de passe, invalider les sessions actives, régénérer des codes 2FA, et jeter un coup d'œil dans les logs à la recherche de la commande CreateAppSpecificPasswordRequest ou de la chaîne "ZimbraWeb". Ce sont les traces que laisse le groupe Laundry Bear.

Ce genre d'attaque qui passe par un client mail, c'est devenu une spécialité des APT russes. Je vous en parlais quand APT28 transformait Outlook en backdoor avec NotDoor , et plus récemment quand des espions russes se faisaient piéger sur Signal . En général, la messagerie, c'est le coffre-fort d'une organisation, et ça ils le savent très bien.

Bref, si un Zimbra traîne quelque part sur votre infra, arrêtez de lire mon site et allez le patcher immédiatement !

Source

Bonne nouvelle pour tous ceux qui balancent du code sur PyPI. L'index officiel des paquets Python refuse désormais tout nouveau fichier ajouté à une release qui a plus de 14 jours. Le correctif vient de Seth Larson, développeur sécurité en résidence à la Python Software Foundation, et il colmate un trou que personne n'avait encore exploité sur PyPI... mais qui traînait là, grand ouvert.

Jusqu'ici, un mainteneur pouvait ajouter un fichier à n'importe quelle release, même sortie il y a 3 ans. Pratique pour livrer une nouvelle wheel, dangereux si un token de publication se fait voler. Un attaquant avec vos clés pouvait glisser un binaire vérolé dans une version stable que tout le monde télécharge depuis des lustres, sans déclencher la moindre alerte. Larson le dit sans détour : si ça n'a pas encore été abusé, c'est juste que les pirates n'avaient pas réalisé que c'était possible.

Le déclencheur, c'est l'affaire LiteLLM et Telnyx, deux paquets populaires compromis en mars dernier via une "référence mutable" dans leur usage de la GitHub Action Trivy. Encore une compromission de la chaîne d'appro, dans la lignée de Shai-Hulud sur npm dont je vous ai déjà parlé avec son scanner dédié , même si le mécanisme n'est pas le même. Le sujet mijotait depuis janvier 2024 dans les discussions autour de PEP 740, sauf qu'il coinçait sur un cas d'usage bien réel. En effet, certains projets ajoutent le support d'une nouvelle version de Python, genre les wheels cp314 pour Python 3.14, à d'anciennes releases longtemps après leur sortie.

Sauf que les chiffres ont tranché. En interrogeant la base PyPI sur les 15 000 paquets les plus populaires, seuls 56 avaient publié une wheel compatible 3.14 plus de 14 jours après une release. 56 sur 15 000, autant dire une poignée. Mike Fiedler, l'ingénieur sécurité de PyPI, a donc porté le débat au Packaging Summit de la PyCon US 2026, et le consensus est tombé. Il est maintenant demandé à ces projets de bumper vers une nouvelle version.

Après ne prenez pas cette nouvelle mesure de sécurité comme une garantie. Il n'existe aucune API pour vérifier qu'une release est "fermée", et les vraies règles du jeu ne seront gravées dans le marbre qu'avec l'API Upload 2.0 et les Staged Previews prévus par PEP 694. Donc pour l'instant, c'est un verrou qui protège, mais pas un vrai contrat de confiance sur lequel bâtir (De quoi Darty ??).

N'empêche que le bénéfice est immédiat car ça fait moins de ménage pour les admins PyPI quand un projet se fait trouer, et s'en est fini de l'état schizophrène où une release est à moitié compromise, à moitié saine, avec quelques fichiers vérolés planqués au milieu. Une vieille release devient un bloc figé, et voilà !

GitHub avait déjà dégainé la même idée avec ses releases immuables , qui rendent vos versions intouchables même par le mainteneur du projet.

Bref, une porte de moins pour les attaquants supply chain. Sympa non ?

Source (repéré chez Simon Willison)

Hugging Face vient de raconter sur son site comment son infra de production s'est fait défoncer par un essaim d'agents IA autonomes. Le point de départ, c'est un dataset piégé déposé sur la plateforme qui exploitait deux chemins d'exécution de code dans le pipeline qui traite les datasets. Ajoutez à ça un loader qui accepte du code distant et une injection de template dans une config, et hop, on obtient du code qui tourne sur un worker maison.

À partir de là, l'attaquant est monté en accès node-level, a ramassé des credentials cloud et cluster, puis s'est promené latéralement dans plusieurs clusters internes. Le tout durant tout un week-end, tranquillou ! Hugging Face parle de "plusieurs milliers d'actions individuelles à travers un essaim de sandboxes éphémères, avec un command-and-control auto-migrant hébergé sur des services publics". Et en plus, ils ne savent toujours pas quel modèle pilotait le truc !

Ce qui a été touché, c'est donc un ensemble limité de datasets internes et plusieurs credentials utilisés par leurs services. Côté public, rien n'a bougé sur les modèles, les datasets et les Spaces, et leur supply chain logicielle est saine. Nuance importante quand même, ils disent n'avoir trouvé aucune trace d'altération, pas que rien n'a été altéré. Ils cherchent encore si des données partenaires ou clients ont morflé. Les concernés seront prévenus directement.

La divulgation publiée par Hugging Face le 16 juillet 2026.

Pour analyser les logs de l'attaque, Hugging Face a d'abord fait ce que vous auriez fait, c'est-à-dire envoyer tout ça à des modèles frontier derrière des API commerciales. Refus ! Les garde-fous se déclenchaient sur les vraies commandes d'attaque, les payloads d'exploit et les artefacts de command-and-control, sans savoir faire la différence entre un attaquant et une équipe de réponse à incident.

Du coup ils se sont rabattus sur GLM 5.2, le modèle open-weight de Z.ai, tournant sur leur propre infra. C'est celui dont je vous parlais fin juin , le premier modèle open source qui m'a vraiment convaincu.

Et voici leur conclusion : "*Nous ne savons pas quel modèle alimentait les agents de l'attaquant, un modèle hébergé jailbreaké ou un open-weight sans restrictions. Dans les deux cas, l'attaquant n'était contraint par aucune politique d'usage, alors que notre propre travail forensique était bloqué par les garde-fous des modèles hébergés que nous avions essayés en premier. *"

La leçon qu'ils en tirent, c'est d'avoir un modèle capable comme GLM 5.2, validé, et prêt à tourner sur sa propre infra avant l'incident. Ça évite le blocage par garde-fous d'OpenAI ou Anthropic et surtout ça évite que les données de l'attaquant et vos credentials partent se balader chez un tiers.

Le versant moins déprimant, c'est que l'IA a aussi bossé côté défense. Leur détection d'anomalies fait du triage LLM sur la télémétrie pour séparer le vrai signal du bruit quotidien, et des agents d'analyse ont reconstitué toute la timeline à partir de plus de 17 000 événements enregistrés. En heures, là où ça prendrait des jours à la main.

Côté ménage, ils ont surtout viré le point d'ancrage de l'attaquant, reconstruit les nœuds compromis, révoqué et tourné les credentials et tokens concernés avec une rotation plus large des secrets par précaution, déployé des garde-fous et des contrôles d'admission plus stricts sur les clusters, et amélioré la détection pour alerter les équipes en quelques minutes, 24h/24. Maintenant, si vous avez un compte là-bas, ils vous recommandent de faire tourner vos tokens d'accès et de jeter un œil à l'activité récente.

Ce genre d'histoire commence à devenir une vraie série... j'en parlais avec GitLost où un seul mot glissé au bon endroit suffisait parfois à faire cracher ses dépôts privés à l'IA de GitHub.

Bref, allez renouveler vos tokens Hugging Face et si votre pipeline exécute du code venu d'ailleurs, c'est le moment de regarder ça de plus près.

---

Mise à jour du 22 juillet 2026 : on connaît le coupable, et ce n'est pas un pirate. OpenAI a publié sa version des faits le 21 juillet, et l'essaim d'agents qui a défoncé l'infra de Hugging Face, c'était ses propres modèles. GPT-5.6 Sol, celui-là même qui a effacé le Mac de Matt Shumer et une base de prod , accompagné d'un modèle pre-release encore plus costaud, tous avec les refus cyber volontairement réduits pour les besoins d'une évaluation interne.

Et le mobile vaut le détour. Ces modèles planchaient sur ExploitGym, un benchmark qui mesure justement leur capacité à dénicher et enchaîner des failles. Coincés dans leur bac à sable, ils ont cramé une quantité considérable de compute à chercher la sortie, ont trouvé un zero-day dans le logiciel tiers qu'OpenAI héberge en interne comme proxy et cache de registres de paquets (faille depuis divulguée à l'éditeur), puis ont escaladé les privilèges de machine en machine jusqu'à en atteindre une avec un accès Internet. Et là, ils en ont déduit tout seuls que les solutions du benchmark devaient traîner quelque part chez Hugging Face. Credentials volés, zero-days enchaînés, exécution de code à distance sur les serveurs : tout ça, c'était juste le chemin le plus court pour tricher à l'examen.

L'ironie devient franchement indécente quand on empile les couches. Hugging Face s'est fait démonter par des modèles américains aux garde-fous retirés, pendant que d'autres modèles américains lui refusaient l'analyse de ses propres logs. OpenAI le dit noir sur blanc : "Ces protections de déploiement n'étaient intentionnellement pas activées pendant cette évaluation, parce qu'elle visait à tester les vulnérabilités cyber." Depuis, Hugging Face a été intégré au programme trusted access d'OpenAI, ce qui règle accessoirement le problème du refus. Et Clem Delangue en tire la leçon qui va bien : "Cet incident, peut-être le premier du genre, prouve un point auquel nous croyons depuis longtemps : la sécurité de l'IA ne sera pas résolue par une seule entreprise travaillant en secret. Elle sera résolue au grand jour, de manière collaborative, avec un large accès à l'IA pour chaque défenseur, partout."

À noter quand même, c'est bien l'équipe de Hugging Face qui a détecté et stoppé l'activité, et qui avait déjà entamé le confinement et la reconstruction forensique avec ses propres modèles open source quand OpenAI l'a contactée. Au moment où j'écris ces lignes, leur billet du 16 juillet n'a d'ailleurs pas bougé d'un pouce et dit toujours ignorer quel LLM pilotait le truc. Et la veille de cette révélation, OpenAI publiait un billet sur un modèle interne qui, lui, a passé une heure à chercher une faille dans sa sandbox pour aller ouvrir une pull request sur GitHub alors qu'on lui avait demandé de poster ses résultats sur Slack. Deux évasions, deux billets, deux jours.

Source

Vous voyez le principe du wallet crypto au format carte bancaire ?

Ça se compose d'une puce, d'un code, et de vos précieuses clés privées cryptos planquées dedans. Et bah figurez-vous que Baptistin Boilot, un chercheur de chez Ledger Donjon, vient de montrer qu'avec un laser, un scalpel et une sacrée dose de patience, on peut imposer un nouveau code à une carte Tangem sans jamais connaître l'ancien. C'est en tout cas la démonstration que vient de publier son labo, et le plus dingue, c'est que ça se joue sur un secure element Samsung certifié EAL6+, autrement dit le très haut du panier en matière de puces sécurisées.

Un petit pulse laser d'une nanoseconde envoyé pile au bon endroit, et le taux de réussite pour remettre à zéro le code secret de la carte monte à 100 % !!

Alors oui, Ledger Donjon c'est le laboratoire de sécurité de Ledger, concurrent frontal de Tangem, et Tangem n'a évidemment pas manqué de le rappeler. Sauf que la faille a été divulguée à la marque en février 2026, bien avant publication, donc tout a été fait dans les règles de l'art. Et puis Ledger n'a pas vraiment de leçons à donner niveau boulettes (rappelez-vous la fuite de sa base client ), donc on va juger le boulot technique plutôt que la rivalité commerciale.

Leur cible, c'est l'instruction SetPin, celle qui gère le code protégeant vos fonds. Quelque part là-dedans, la puce se pose une question toute bête, du genre "cette carte est-elle en mode récupération ?". Et le tir laser vient fausser ce test à l'instant exact où il s'exécute. Il ne grille rien du tout hein, il fausse juste le résultat une fraction de seconde, ce qui permet à la puce d'accepter un nouveau code sans jamais vérifier le vôtre.

Après, y'a quand même un sacré ticket d'entrée car pour en arriver là, les chercheurs ont ouvert la carte au scalpel, retiré le blindage métallique, dessoudé la puce, recâblé le tout sur une carte maison, et remplacé l'antenne NFC par une alimentation filaire pour piloter chaque signal. Un vrai travail d'orfèvre ! Ajoutez environ 250 000 dollars de matériel entre le laser, l'oscilloscope et la sonde électromagnétique et puis beaucoup de temps : 1 heure de balayage laser pour la première réussite, puis 2 heures par carte ensuite, sans parler de toute la R&D en amont.

La puce se défend, en plus. Elle tient un compteur de fautes en mémoire flash et se verrouille pour de bon au bout de quelques centaines de ratés. Sauf que les chercheurs ont trouvé la parade qui est de couper l'alimentation au moment précis où la puce s'apprête à noter l'incident. Du coup le compteur ne grimpe quasiment plus, et une carte qui aurait dû se bloquer très vite a encaissé plus d'une journée de tirs laser !

Alors, la question que vous vous posez forcément c'est : est-ce que votre Tangem est toujours fiable ? Pour vous, au quotidien, oui car il faut un accès physique à la carte. Puis l'opération laisse des dégâts parfaitement visibles (une carte charcutée au scalpel, ça se remarque), et je pense que personne ne va monter un labo à un quart de million pour siphonner votre wallet.

Maintenant, c'est vrai que cette faille ne sera jamais corrigée, car les cartes Tangem n'embarquent aucun mécanisme de mise à jour du firmware. Ça peut vous sembler absurde, mais en fait c'est pas si con que ça parce que qui dit pas de mise à jour dit pas de mise à jour vérolée. Hé hé.

Mais maintenant que le trou existe, et qu'aucun patch n'est possible, cela veut dire que toutes les cartes en circulation, dont la vôtre peut-être, restent vulnérables à vie. Et celle que vous achèteriez aujourd'hui ? Bah vulnérable tout pareil, tant que Tangem ne revoit pas son design.

Alors oui, l'attaquant ne lit pas vos secrets, il prend juste le contrôle du wallet en lui imposant son propre code, un peu comme une carte à puce sécurisée qu'on déverrouillerait de force sans en lire le contenu. C'est pourquoi Tangem estime que le risque est quasi inexistant, en rappelant au passage que n'importe quel secure element finira au bout d'un moment par céder si on y consacre assez de temps et d'argent.

Bref, si vous avez une Tangem au fond d'un tiroir, pas de panique, gardez-la juste bien à vous, parce que côté correctif, vous pourrez attendre longtemps, il n'y en aura jamais.

Source

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

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

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

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

Enfin, avait essayé...

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

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

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

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

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

Source

Stelios Kouloglou, ancien eurodéputé grec, et journaliste d'investigation, siégeait à la commission PEGA du Parlement européen et à l'époque, son cheval de bataille c'était de traquer Pegasus, le mouchard pour smartphone de la société israélienne NSO Group.

Eh bien devinez quoi ? Son smartphone à lui était aussi infecté par Pegasus !

C'est Citizen Lab, un labo planqué à l'université de Toronto, qui a retourné son iPhone en mai dernier et qui a retrouvé la trace de 2 infections. La première en octobre 2022, et la suivante en mars 2023. Pile au moment où la commission PEGA bossait sur son rapport, donc...

Mais avant de tout vous expliquer, je me permets de faire un petit rappel pour ceux qui ont raté le premier épisode. Pegasus, c'est un outil d'une société privée qui travaille dans la surveillance et qui s'appelle NSO Group. Cet outil est capable de s'installer tout seul sur un iPhone, sans avoir besoin du moindre clic de la victime. Aucune interaction, aucune trace et une fois qu'il est en place, cette saloperie siphonne tout ! Ce que votre micro et vos caméras enregistrent, vos messages, votre géoloc, vos datas...etc. Le Parlement européen avait donc monté la commission PEGA en avril 2022 justement pour comprendre pourquoi des États membres s'amusaient à espionner des journalistes, des avocats et des opposants politiques avec ça.

Alors qui a infecté Kouloglou ?

Eh bien personne n'a trouvé et c'est bien le problème. NSO ne donne jamais le nom de ses clients, et l'entreprise n'a pas répondu aux sollicitations. Kouloglou, lui, accuse le gouvernement grec, son propre pays, qui figure parmi les États épinglés par la commission aux côtés de la Pologne, la Hongrie et l'Espagne.

Sauf que Citizen Lab, le labo qui a fait l'analyse, n'a pu confirmer aucune piste et pense que d'autres parlementaires ont ou seront également infectés. Et le pire dans toute cette histoire, c'est qu'il ne se passe rien de plus...

La commission PEGA a rendu son rapport en mai 2023 avec une liste de recommandations comme encadrer le spyware, créer un labo technique européen, ouvrir des voies de recours et le Parlement a voté pour. Très bien ! Sauf que depuis la Commission européenne a rangé tout ça dans un tiroir.

Ça fait donc maintenant 3 ans que ces recommandations prennent la poussière. Et Kouloglou n'est même pas un cas isolé puisqu'il y a déjà eu Nikos Androulakis, un autre eurodéputé grec, visé lui par Predator, le cousin de Pegasus. À l'époque, tout le monde avait crié au scandale mais nous sommes maintenant quelques années plus tard, et il n'y a aucun aucune répercussion ni aucun changement.

Et pendant que la justice avance à deux à l'heure, et cela même si NSO s'est pris une déculottée par WhatsApp , le marché du mouchard se porte comme un charme ! Candiru, Paragon, Intellexa... Pour chaque NSO qui trébuche, d'autres se partagent le gâteau.

Alors qu'est-ce qu'on fait, nous, simples mortels sans immunité parlementaire ?

Bah déjà, si vous êtes journaliste, militant ou juste un parano bien organisé, activez le Lockdown Mode d'Apple , qui a déjà fait échouer des attaques de ce type. Et si vous flairez quelque chose de louche, sachez qu'on peut faire analyser un smartphone pour y détecter une infection , exactement comme Citizen Lab l'a fait pour Kouloglou.

Bref, un député qui enquête sur les espions se fait espionner, et l'Europe regarde ailleurs... J'ai connu meilleure pub pour la démocratie !

Source