"Maintenant", ce n'est pas qu'un adverbe à la con pour apprécier l'instant présent ou faire péter ses ordres comme votre Belle Mère ! C'est également un conteneur à lancer, qui se connecte en lecture seule à un socket Docker pour réaliser en un battement de cil, tout l'inventaire de votre home lab !

Il relève ainsi l'état de chaque conteneur, ses healthchecks, ses boucles de redémarrage, ses logs, et vos projets Compose regroupés comme vous les avez écrits.

Ensuite, tout ce qui vous alerte pour de bon se déclare à la main. Les checks HTTP et TCP se configurent sous la forme de labels sur les conteneurs à surveiller. Par exemple, un maintenant.endpoint.http avec son intervalle et son seuil d'échec, un maintenant.endpoint.tcp pour la base...etc. Pas besoin donc d'aller mettre votre gros nez dans un fichier de config spécifique.

Vos tâches planifiées reçoivent chacune une URL à appeler quand elles finissent comme ça si la sauvegarde de trois heures du matin ne se manifeste pas, vous êtes prévenu. Vos certificats HTTPS sont surveillés et signalés cinq fois avant leur expiration, un mois avant puis de plus en plus près. Il compare aussi l'empreinte de vos images à celle publiée sur le registre, ce qui vous permet ensuite de savoir lesquelles ont pris du retard sans lancer des docker pull à l'aveugle. Ah et il sert une page de statut publique pour vos utilisateurs.

Le tout tient dans un binaire Go qui occupe environ 17 Mo de RAM et qui se repose sur une simple base SQLite.

Par contre, l'édition gratuite (Community) gère une seule machine. Si vous voulez du multi-hôte, il faudra passer par la case payante. Toujours en gratuit, il y a aussi des plafonds... Vous avez le droit uniquement à 10 endpoints, 5 heartbeats, 5 certificats, 3 composants de page de statut et uniquement 7 jours d'historique.

Attention quand même, y'a 2 choses à savoir avant de vous enflammer et de poser ça sur une machine exposée sur le net. Il n'y a aucune authentification intégrée, et de ce que j'ai compris, c'est assumé ! A vous donc de mettre en place un reverse proxy et un Authelia ou un Authentik devant.

Pour situer "Maintenant" par rapport à d'autres solutions que je vous ai déjà présentées, Beszel fait les métriques par conteneur sans aucun plafond gratos, mais pas les checks HTTP. Uptime Kuma lui, fait les checks, mais ses monitors doivent être créés un par un dans l'interface, sauf à lui greffer AutoKuma pour lire les labels. Donc, il n'y a pas vraiment de solution tout-en-un gratuite...

A découvrir ici !

Zéro Logement Vacant, ce nom ne vous dit peut-être rien, mais c'est un service de l'État censé aider les collectivités à remettre sur le marché les logements vides. Il vient de se retrouver au cœur d'une fuite de données colossale.

Un pirate qui se fait appeler ZeroBytes affirme avoir aspiré près de 149 millions de lignes brutes depuis la plateforme. Après nettoyage des doublons, ça correspondrait à environ 48 millions de personnes différentes. En croisant les noms et les dates de naissance, on grimpe même à plus de 71 millions, mais les deux chiffres ne s'additionnent pas.

D'où vient une telle masse de données ? Essentiellement du foncier. La plateforme avait chargé d'énormes fichiers de propriétaires issus du cadastre et de la DGFiP, autrement dit le fisc. Deux tables contiennent presque tout, environ 82 millions de lignes de propriétaires d'un côté, et 66,9 millions provenant d'un fichier foncier national de 2024 de l'autre.

Le site Cyberattaque.org , qui a pu examiner des échantillons, confirme le pire. On y trouve des identités, des dates de naissance, des adresses postales et des informations liées aux droits de propriété. Un second extrait ajoute des adresses e-mail et des numéros de téléphone. Sur 500 lignes analysées, 453 contenaient un numéro, 274 un e-mail et 423 une date de naissance.

Et ça ne s'arrête pas aux propriétaires. Les comptes des utilisateurs de la plateforme sont aussi dans la nature, à savoir des agents de collectivités, des services de l'État et des prestataires. On parle de leurs e-mails professionnels, de leurs rôles, du SIREN de leur structure, mais aussi d'adresses IP, de sessions récentes et de mots de passe. Bonne nouvelle relative, ces mots de passe sont hachés, le plus souvent en bcrypt, donc pas lisibles directement, ou réutilisés ailleurs.

Le plus inquiétant, c'est la fraîcheur de certaines données, avec des sessions de connexion très récentes dans les échantillons. Ce n'est donc pas une vieille base oubliée dans un coin, mais bien un environnement encore actif.

Pour les propriétaires concernés, le risque immédiat, c'est l'hameçonnage sur mesure. Avec votre nom, votre adresse et votre bien, un faux courrier des impôts devient tout de suite bien plus crédible. Méfiance sur tout ce qui touchera au foncier dans les prochaines semaines.

Source : MacG

Toutes les fuites de données ne se valent pas, et celle-ci a de quoi faire transpirer pas mal de monde. Des pirates ont siphonné le registre des ayants droit économiques du Liechtenstein dans la nuit du 29 au 30 juillet, embarquant les informations de 31 000 sociétés, fondations et fiduciaires d'un coup.

Un ayant droit économique, pour faire simple, c'est la vraie personne en chair et en os qui possède ou contrôle une société, celle qui empoche l'argent tout au bout de la chaîne même quand une cascade de sociétés-écrans s'emploie à la rendre invisible.

C'est tout le problème. Ce registre a été monté pour lutter contre le blanchiment, en forçant chaque structure à déclarer noir sur blanc qui profite réellement d'elle, si bien que les pirates viennent de mettre la main sur l'annuaire officiel des propriétaires cachés du pays.

Rappelons où l'on se trouve. Le Liechtenstein est ce mouchoir de poche coincé entre la Suisse et l'Autriche qui s'est taillé une réputation mondiale de terre d'accueil pour fondations et sociétés discrètes, l'endroit idéal pour ranger un patrimoine loin des regards.

Dans le butin, on retrouve le nom des entités et surtout le nom, la date de naissance, la nationalité et le pays de résidence des bénéficiaires planqués derrière chacune d'elles.

Une petite éclaircie pour ces gens quand même, puisque les adresses, les numéros de téléphone et les données financières comme le chiffre d'affaires, les actifs ou les dividendes sont restés hors de portée, ce qui atténue la casse sans rien retirer à la gêne provoquée par les noms exposés.

L'attaque aurait été menée avec un vrai savoir-faire technique d'après l'enquête, personne n'a encore été identifié, et le pays a réclamé un coup de main international pour espérer remonter la piste.

Une cellule de crise montée dès le samedi soir sous la houlette de la cheffe du gouvernement Brigitte Haas et du ministre de la Justice, pour prévenir les personnes concernées et éteindre l'incendie.

Franchement, pour un pays qui a fait de la discrétion de ses fondations un fonds de commerce, on imagine mal un fichier plus gênant à laisser filer dans la nature.

Source : Le Temps

Six chercheurs d'UC San Diego et d'Oberlin College ont présenté le 13 août dernier à l'USENIX Security Symposium de Baltimore un implant assez petit qui se branche sur un port de maintenance de la baie électronique d'un Boeing 737 et s'intercale ainsi entre le calculateur de vol et l'écran par lequel les pilotes le programment.

La trappe présente sur l'avion, qui y mène n'a ni serrure ni contrôle d'accès et est accessible depuis le sol, sans échelle. Les chercheurs estiment que ça peut se mettre en place en moins de 60 secondes, ouverture et refermeture comprises. Le boîtier, lui, disparaît sous le capuchon anti-poussière du connecteur.

Hé oui c'est un simple capuchon en plastique qui "protège" l'accès aux commandes de navigation d'un avion de ligne. C'est beau non ?

Ce connecteur donne un accès aux bus ARINC 429 qui transmette les échanges entre le calculateur, le FMC, et le clavier-écran du cockpit, le MCDU. La norme date de 1977 et ne prévoit aucune authentification et comme vous vous en doutez, c'est connu depuis longtemps, même si le plus souvent, les attaques envisagées sur les systèmes d'un avion visaient plutôt ses liaisons radio.

Toutefois, se brancher sur le bus ne suffit pourtant pas à le contrôler, puisque les autres équipements continuent d'émettre par-dessus. Sauf que les émetteurs légitimes passent par des résistances de 37,5 ohms qui brident leur courant, alors que le connecteur de maintenance, lui, attaque le bus en direct.

L'implant en profite alors pour pousser plus de courant que l'émetteur d'origine et écraser physiquement son signal. Les chercheurs appellent ça une attaque Bus Driver, et elle donne une interception complète du dialogue sans couper ni épisser le moindre fil.

Une fois ce dialogue sous contrôle, le boîtier ajoute un point de passage à la route programmée. Normalement, sur un 737, cette modification doit être confirmée par le pilote, qui appuie sur le bouton EXEC. Mais l'implant, lui, appuie tout seul, l'autopilote change de cap, et comme le voyant du bouton passe par le même bus, il reste éteint. Et comme les pages affichées sont réécrites en live pour montrer encore l'ancienne route, rien à l'écran ne trahit le changement.

Le même mécanisme peut servir aussi à fausser la masse de l'appareil saisie avant le départ, ou la température retenue pour calculer la poussée. Une masse sous-évaluée ou une température trop basse, et le calculateur commande alors une poussée insuffisante au décollage.

Bref, c'est la cata assurée... Et cela vaut pour tous les 737 NG et MAX.

Maintenant, reste à savoir dans quelles conditions cette attaque peut être réalisée. Car jusqu'à présent, tout a été validé mais uniquement sur un banc de vraies pièces de 737 câblées selon les schémas Boeing, et jamais sur un avion en service. Le Wi-Fi est bien intégré au boîtier, mais le papier précise que les auteurs n'ont pas pu tester si le signal de la cabine traverse le plancher de la baie.

Boeing a bien sûr été prévenu en avril 2020, et les chercheurs ont rejoué l'attaque avec succès sur le banc d'essai du constructeur en décembre 2023. Ils proposent de boucher ce type de connecteur, ou d'y déplacer les résistances de limitation. Boeing, lui, estime que "les couches de protection en place sur l'avion" limitent déjà "significativement la faisabilité et le risque d'attaques en conditions réelles".

Ouais les gars ont la flemme de sécuriser leur truc on dirait...

Source

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.

Charger la vidéo depuis YouTube Ce clic autorise une connexion à Google : adresse IP transmise et traceurs possibles. En savoir plus Voir cette vidéo sur YouTube

Et le signal en question porte un nom que tout le monde connaît en domotique : un heartbeat. C'est le ping le plus banal qui existe, celui qui dit "je suis en ligne, je fonctionne" et rien d'autre. C'est le même que crache votre caméra IP du salon, dont je vous parlais déjà avec OpenIPC .

Le ministère britannique affirme qu'aucune donnée sensible, aucun système militaire et aucune donnée gouvernementale n'ont été consultés, compromis ou transmis hors des canaux autorisés et ajoute que ses procédures de test ont repéré le problème "tôt".

La connectivité internet des caméras a quand même été coupée puisque même si ça n'a l'air de rien, un mouchard qui se contente de dire bonjour reste un mouchard qui connaît le chemin.

Reste maintenant la question de comment ce composant est arrivé sur un engin de reconnaissance militaire. En fait, les caméras ne viennent pas de Kraken Technology Group, le constructeur britannique du K3 Scout, mais d'un sous-traitant tiers qui pourtant avait fourni des assurances sur le fait que ses caméras répondaient aux exigences de sécurité, y compris celles rattachées au National Defense Authorization Act américain.

Bref, de la paperasse, des assurances, mais pas un démontage ni une capture de trafic... Kraken dit avoir mené un audit complet avec la Royal Navy une fois les communications découvertes. J'espère bien ^^ !

Côté portée, ça concerne les 20 K3 Scout achetés dans le cadre du Project Beehive, un programme de 12,3 millions de livres, en service chez les Royal Marines depuis mars. Le Telegraph , qui a sorti l'affaire, écrit que du matériel lié à la préparation d'une éventuelle mission britannique dans le détroit d'Ormuz avait été enregistré sur ces appareils.

Par contre, ce qu'on ne sait toujours pas, c'est la marque de la caméra et la nature exacte du composant chinois car aucun rapport ne les nomme pour le moment... Mais j'espère que ça n'a pas été aussi intégré sur du matos français...

Source

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

Les attaques Adversary-in-the-Middle (AiTM) représentent l'évolution sophistiquée des classiques attaques Man-in-the-Middle. Contrairement à l'écoute passive, l'attaquant s'insère activement entre la victime et le service légitime, usurpant les deux parties pour intercepter, modifier et rediriger les communications. Ces attaques permettent de voler des identifiants, de contourner l'authentification à deux facteurs (2FA) en capturant les cookies de session, et même de manipuler les transactions financières en temps réel. Des outils facilitent grandement la mise en place de ces attaques et l'une des protections valables repose sur le chiffrement des communications (VPN, HTTPS), l'authentification multi-facteurs résistante au phishing (WebAuthn) et la vigilance face aux liens suspects.

Faites preuve d'un peu d'imagination pendant quelques minutes. Vous êtes tranquillement installé au Starbucks du coin, vous buvez votre latte caramel macchiato à 7 balles, et vous vous connectez au WiFi public pour checker vos mails. Sauf que le mec à la table d'à côté, avec son hoodie noir et son MacBook Pro qui sent le terminal, n'est pas là pour boire son café. Il est là pour se positionner entre vous et le reste du monde.

Et là, on ne parle pas d'un simple Man-in-the-Middle à l'ancienne, non non. On parle d'un Adversary-in-the-Middle, le gros calibre. La différence ? Le mec usurpe activement les deux côtés de la conversation. C'est pas juste un petit curieux qui écoute aux portes. C'est un escroc qui se fait passer pour votre banque ET pour vous, en même temps. Il relaie tout, modifie ce qu'il veut, et vous, vous ne voyez rien.

"Mais j'ai la 2FA, je suis blindé !"

Hé ben non. C'est là que ça pique.

Les attaques AiTM ont un super-pouvoir de merde : elles contournent la 2FA. Comment ? Le mec crée un site parfaitement identique à celui de votre banque. Vous cliquez sur le lien du mail de phishing et vous arrivez sur sa copie. Login, mot de passe, et PAF, le code SMS arrive. Vous le rentrez. Sauf que le code passe par le serveur du mec au milieu, qui le relaie en temps réel à la vraie banque. Résultat ? Il a votre session, vos cookies, et il peut se connecter à votre compte pendant des heures sans que vous vous en rendiez compte.

C'est ce qu'on appelle le session hijacking. Vous avez validé l'authentification, et pourtant c'est lui qui se retrouve connecté à votre place. Et il peut même modifier les données en transit : changer le numéro de compte bénéficiaire d'un virement, injecter du malware dans une mise à jour, bref, tout ce qui lui chante.

Des outils comme Evilginx2 traînent dans la nature depuis 2018 et permettent à n'importe quel script kiddie de monter ce genre d'attaque en 10 minutes. Le framework MITRE ATT&CK a même une entrée dédiée pour ça (T1557), tellement c'est devenu courant.

"Ok, et je fais quoi alors ?"

Ben déjà, arrêtez de cliquer sur les liens de vos mails comme un débile. Mais surtout, surtout, chiffrez votre connexion. Et là, un VPN entre en jeu.

Pas n'importe lequel. Un VPN qui sait ce qu'il fait. Je vous en parle régulièrement (j'espère qu'à force ça finit par rentrer hein) mais, récemment, Surfshark vient encore de se faire remarquer en recevant le PCMag Editor's Choice award . Ce qui, dans le monde des VPN, est un peu comme recevoir une étoile Michelin pour un kebab. Ça veut dire que les mecs de PCMag, qui testent ce genre de truc toute la journée, ont trouvé que Surfshark tenait la route.

Pourquoi un VPN ça marche contre l'AiTM ?

C'est simple. Lorsque vous activez Surfshark , tout votre trafic passe dans un tunnel chiffré entre votre machine et le serveur VPN. Même si le mec au Starbucks contrôle le routeur, même s'il fait de l'ARP spoofing, du DNS poisoning, ou je ne sais pas quelle autre magie noire, il verra que dalle, juste des paquets chiffrés illisibles, point barre.

Pas d'identifiants en clair, pas de cookies de session à sniffer, et pas moyen de modifier une page web en transit. Le gars peut toujours essayer de vous rediriger vers son faux site, mais votre connexion VPN reste intacte et chiffrée.

Et Surfshark, en plus du chiffrement AES-256-GCM (celui que la NSA approuve pour ses documents top secret, pour ceux qui aiment les détails techniques), propose des fonctionnalités sympas :

• CleanWeb qui bloque les trackers et les pubs (et donc les domaines malveillants souvent cachés derrière)
• Kill Switch qui coupe internet si le VPN tombe (parce qu'un tunnel qui s'effondre, c'est pas un tunnel)
• MultiHop qui fait passer votre connexion par DEUX serveurs VPN successifs pour ceux qui sont vraiment parano
• Surfshark Alert qui surveille si vos identifiants ont fuité sur le dark web
• Alternative ID qui vous permet de créer de fausses identités temporaires

Le prix de la tranquillité

Alors oui, un VPN ça coûte un peu d'argent. Mais franchement, entre payer quelques euros par mois et se faire vider son compte bancaire par un mec qui a sniffé votre session sur le WiFi du McDo, le choix est vite fait. Surtout que Surfshark propose des abonnements longue durée à prix cassés, et avec leurs offres actuelles, vous en avez pour moins cher qu'une paire de cafés par mois (2.75€ TTC pour le pack Starter ou 3.35€ TTC pour Surfshark One avec l'antivirus & co).

Et puis, ils ont aussi une politique de no-logs auditée indépendamment et régulièrement. C'est-à-dire qu'ils ne gardent aucune trace de ce que vous faites. Contrairement à votre FAI qui sait exactement à quelle heure vous regardez vos séries un peu spéciales sur Netflix.

Bref

Les attaques AiTM n'ont rien de la science-fiction. Ça arrive tous les jours. Microsoft a documenté une campagne qui a ciblé plus de 10 000 organisations depuis 2021. Twitter (pardon : X), Microsoft 365, Slack, Twilio... tous ont morflé à cause de ce genre d'attaque. Et vous, sur votre WiFi public, vous êtes une cible parfaite.

Un VPN comme Surfshark n'est pas une baguette magique qui vous protège de tout. Si vous cliquez sur un lien de phishing, le VPN ne vous sauvera pas de votre propre étourderie. Mais il vous protègera de l'interception passive et active sur les réseaux non sécurisés. Et ça, c'est déjà énorme. Dans le doute, chiffrez. Toujours.

Profitez de l'offre du moment chez Surfshark !

Alors ça, Google va adorer ! En effet, depuis hier (le 8 juillet), le navigateur DuckDuckGo bloque les pubs YouTube tout seul comme un grand. Le pre-roll interminable avant votre tuto Docker , la double coupure en plein milieu d'un unboxing, ou encore la pub pour une appli de casino que vous n'avez jamais demandée... tout dégage, en mode par défaut sans avoir besoin d'ajouter une extension.

iOS, Windows et Mac sont servis d'office, et sur Android ça s'active à la main dans Settings > Ad Blocking (le par défaut arrive bientôt).

Le canard américain ne réinvente rien puisqu'il embarque tout simplement les listes de filtres communautaires du projet uBlock Origin , mises à jour régulièrement pour suivre les parades de la régie pub de Google.

Sur son blog , ils annoncent donc que leur fonctionnalité bloque la "plupart" des publicités. Donc pas 100% et ils préviennent qu'un peu de buffering peut également apparaître au lancement d'une vidéo. Ouais ça c'est la petite astuce de Google pour contrarier les utilisateurs d'AdBlocker...

Mais une fois la lecture partie, plus d'interruption !

Sur ordi, vous verrez une petite icône vidéo à côté du bouclier vert dans la barre d'adresse, c'est là que ça se pilote.

Le réglage Ad Blocking, planqué dans le menu du navigateur

Sur mobile, je le précise encore parce que ça ne coule pas de source pour tout le monde, c'est seulement si vous ouvrez YouTube dans le navigateur DDG. L'application YouTube officielle , elle, continuera de vous balancer des tunnels de pubs tranquillement.

Et si vous utilisez déjà Duck Player , le mode théâtre sans cookies de pistage, les 2 fonctionnent ensemble sans se marcher dessus.

Bon, les blasés de la vie me diront que Brave fait ça nativement depuis des années et c'est vrai. Mais ce qui est intéressant ici, c'est que c'est un blocage activé par défaut pour madame et monsieur Tout-le-monde, sur un navigateur qui se télécharge gratuitement . Le blocage de pub n'est plus une bidouille de geek, mais c'est devenu un argument marketing pour "vendre" son navigateur.

Du coup, dans le bras de fer entre YouTube et les bloqueurs de pubs , qui s'est durci depuis fin 2023 à coups d'avertissements, de ralentissements volontaires et de lectures bloquées, je pense que la riposte de Google ne va pas tarder donc préparez les popcorns.

Mais quoi qu'il en soit, c'est encore un coup dur pour les youtubeurs. Bon, il restera toujours la possibilité de faire des segments sponsorisés directement dans la vidéo... Ah mais non, oups, c'est vrai, il y a SponsorBlock qui se débarrasse de ça aussi. Ouin !

Mais alors qu'est-ce qu'on va devenir, nous, les créateurs de contenu ?

Eh bien c'est simple. Si vous aimez bien ce qu'on fait, faut nous soutenir. Moi, par exemple, j'ai un Patreon et il y a plein de gens dessus qui me soutiennent, ce qui est super cool, j'ai vraiment beaucoup de chance. Et je les remercie tous.

J'encourage les autres créateurs de contenu à faire pareil, y compris les YouTubers, à mettre en place ce genre de système. Et sachez qu'on n'est pas obligé de se prendre la tête avec des contreparties...etc parce qu'on n'a pas vraiment le temps, on a déjà beaucoup de choses à faire. L'important c'est d'être transparent avec votre communauté, vous dites juste que c'est pour continuer à faire ce que vous faites d'habitude, c'est pour continuer à faire tourner la chaîne dans la joie, la bonne humeur et ça devrait très bien se passer.

Moi mon rêve c'est qu'un jour le Patreon ramène suffisamment d'argent pour que je puisse me passer à 100% de partenaires pub. Un jour peut-être, on verra bien.

Source

Et c'est reparti pour un tour ! Qu'est-ce que vous pensez d'un dépôt privé sur Github qui serait capable d'exfiltrer tout seul son propre code dans une section commentaire visible publiquement par tout le monde. Ce serait ouf non ?

Hé bien c'est le tour de passe-passe que Sasi Levi, de chez Noma Security, vient de réussir grâce à l'agent IA de GitHub. Et vous allez voir, c'est tout con, donc c'est hyper flippant.

Cette attaque s'appelle GitLost et la cible, c'est le GitHub Agentic Workflows, un système qui colle un agent IA (tournant sur Claude ou Copilot) à vos GitHub Actions pour qu'il bosse tout seul sur vos tickets. C'est un setup où l'agent a un accès en lecture à vos repos privés et se réveille dès qu'une issue lui est assignée. C'est super pratique, sauf que... c'est un vrai piège qui peut se refermer très vite sur vous.

Ça commence en fait par une simple issue dans un dépôt public. Rien de sorcier, pas de commit vérolé, pas de serveur MCP malveillant. Juste du texte, avec des instructions planquées en anglais au milieu du ticket. L'agent lit alors cette issue, tombe sur les instructions cachées à l'intérieur et les considère comme des ordres légitimes.

Et c'est là que ça part en couille, puisqu'après il part gentiment chercher le contenu d'un README qu'on lui demande dans un dépôt privé auquel il a accès (dans la démo, sasinomalabs/testlocal). Jusqu'ici, c'est l'exfiltration classique du prompt injection, sauf que d'habitude, il faut ruser pour faire sortir la donnée avec une image markdown piégée, une requête réseau vers un serveur qu'on contrôle, un canal caché...etc.

Mais dans le cadre de cette attaque GitLost, eh bien il n'y a pas besoin de tout ça. En fait, l'agent recopie bêtement le contenu privé dans un commentaire public sur l'issue de départ et c'est terminé. C'est donc lisible par n'importe qui passant sur le repo public.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/gitlost-github-agent-ia-fuite-depots-prives/gitlost-github-agent-ia-fuite-depots-prives-1.mp4">lien vers la vidéo</a>.

Posez votre doigt sur un capteur et hop, votre session s'ouvre. Sur un Mac, ce petit confort passe par exemple par le Magic Keyboard avec Touch ID (lien affilié) parce qu'Apple réserve la biométrie à son propre matériel. Mais le bidouilleur Zimeng Xiong a trouvé ça un peu chéros, alors il a bricolé la même chose avec un ESP32-S3 à quelques euros .

Le tout tient dans un boîtier imprimé en 3D contenant un capteur d'empreinte ZW101 qui lit votre doigt, et une carte ESP32-S3 (une Seeed Studio XIAO - lien affilié) qui se fait passer pour un clavier USB. Ensuite, si l'empreinte correspond, elle tape votre mot de passe suivi d'Entrée. Vu de l'ordinateur, l'engin n'est qu'un clavier qui tape à votre place, et n'est donc liée à aucun système d'exploitation en particulier.

Le truc bien pensé je trouve, c'est que le mot de passe ne vit jamais sur l'ESP. La carte ne garde qu'une clé d'appairage de 32 octets et le mot de passe, lui, reste sur l'ordinateur, conservé par un petit service que vous installez.

Quand vous posez le doigt, l'ESP réclame ce mot de passe via un échange chiffré, avec une clé d'appairage partagée et un nonce aléatoire pour bloquer les rejeux, le déchiffre en mémoire vive le temps de le taper, puis efface tout en quelques millisecondes. Il compte aussi sur le Secure Boot et le Flash Encryption de l'ESP32-S3 pour qu'un dump de la puce ne livre aucune clé.

Après, histoire d'être transparent avec vous, sachez que le seul maillon faible de ce gadget se situe entre le capteur et l'ESP car la liaison série n'est pas protégée. Toute la vérification de l'empreinte se passe dans le capteur, pas dans le microcontrôleur, donc quelqu'un qui aurait accès à votre machine et au boîtier en même temps pourrait usurper le capteur et forcer l'envoi du mot de passe. La parade de Zimeng c'est donc de noyer toute l'électronique dans de l'epoxy noir.

Sous Windows, vous branchez un lecteur d'empreinte USB et Windows Hello fait le reste, c'est plutôt simple. Apple par contre verrouille un peu plus le truc, donc il faudra installer le logiciel compagnon. Et Zimeng Xiong ne compte pas s'arrêter là, puisqu'il annonce une version qui émule une carte à puce, pour se connecter sans jamais taper de mot de passe, comme le font déjà les passkeys . Là, on serait un cran au dessus en matière de sécurité.

Le code est public sur GitHub si vous voulez tenter le montage. Rien de prêt pour la production évidemment, mais une chouette démonstration qu'avec un ESP32 et un peu de crypto, on peut faire de jolies choses.

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

Le scénario est toujours le même. Un faux conseiller bancaire au bout du fil, avec un ton pressant qui vous répète de valider vite, et vous confirmez un virement que vous regretterez très fort avant la fin de la journée. C'est précisément cette mécanique qu'Apple veut enrayer avec Trust Insights, une brique d'iOS 27 dévoilée sans tambour à la WWDC de juin, la grande conférence développeurs où la marque montre ses futurs systèmes, et détaillée dans une session technique baptisée "Meet Trust Insights".

L'objectif est en fait assez simple, donner aux applications le moyen de détecter, pendant que vous les utilisez, que quelqu'un est probablement en train de vous la faire à l'envers. Donc pas une alerte après coup, une fois l'argent envoyé à l'autre bout du monde. Mais vraiment une alerte sur le moment.

Trust Insights est une API. Autrement dit une boîte à outils qu'Apple met à disposition des développeurs pour brancher cette détection directement dans leurs propres applications, sans avoir à la construire eux-mêmes. Votre banque, votre application de paiement ou votre messagerie récupèrent la fonction et l'intègrent à leurs écrans sensibles, moyennant une autorisation spéciale accordée par Apple.

Pour flairer l'embrouille, le système croise vos schémas d'interaction, le rythme de vos gestes, le contexte de l'action et quelques données de capteurs basiques. Quelqu'un qui vous dicte quoi taper au téléphone, ça se voit dans la façon dont vous vous y prenez : comme par exemple des hésitations qui ne collent pas à vos habitudes, des allers-retours anormaux entre les écrans, une cadence de saisie qui déraille par rapport à d'habitude.

Côté vie privée, Apple insiste : le contenu de vos Messages, de vos Mails et de vos Photos n'est jamais inspecté. Tout le calcul se fait sur l'iPhone, les données brutes sont jetées dans la foulée, et une seule information ressort de l'appareil, un niveau de risque moyen ou élevé. Rien de plus.

À l'application, ensuite, de décider quoi en faire. Elle peut glisser un avertissement bien visible, imposer un délai avant de laisser passer un virement, ou réclamer une vérification supplémentaire. Le genre de pause forcée qui vous laisse dix secondes pour raccrocher et vous demander pourquoi ce "policier" exige un paiement immédiat.

Trust Insights range les actions à surveiller en cinq grandes familles : les paiements et transferts d'argent, les modifications de compte, l'accès à des ressources coûteuses, l'envoi de messages ou la signature de documents, et une catégorie fourre-tout pour le reste. En clair, tous les moments où un escroc a le plus intérêt à vous tenir la main jusqu'au bout de l'opération.

Les arnaques ciblées sont celles qui posent le plus de problème : le faux support technique, l'usurpation d'autorité, ou un pseudo-policier ou banquier qui vous somme d'agir sans réfléchir, ou encore plus compliqué à gérer, la fausse urgence familiale. Ce sont des arnaques vieilles comme le téléphone, mais améliorées aux deepfakes, ces voix et vidéos fabriquées par IA capables d'imiter un proche à s'y méprendre.

Sauf que voilà, tout repose sur la bonne volonté des développeurs. Si votre banque ne prend pas la peine d'intégrer Trust Insights dans son application, il ne se passera strictement rien. Et il faudra de toute manière patienter jusqu'à l'automne, à la sortie publique d'iOS 27, pour voir les premières intégrations débarquer sur votre écran.

Reste que l'idée est plutôt bonne. Une pause de dix secondes imposée au bon instant protégera plus de comptes en banque que des années de campagnes de prévention.

Source : 9to5mac

Vous utilisez Claude Code tous les jours pour coder, et pendant ce temps-là l'outil d'Anthropic utilisé par des milliers de dev, joue les mouchards. Thereallo , un développeur qui fouillait le binaire par simple souci de vie privée, est tombé sur une fonction qui apparemment modifie en douce la ligne "Today's date is…" du system prompt. Pas le texte que vous lisez ou écrivez mais littéralement l'apostrophe et le tiret de la date.

2 petits caractères auxquels vous ne faites pas gaffe, et qui pourtant peuvent en dire beaucoup...

En gros, c'est de la stéganographie , c'est-à-dire l'art de cacher une info à la vue de tous. Claude Code échange l'apostrophe de "Today's" contre son jumeau Unicode invisible (U+2019, U+02BC ou U+02B9 selon les cas) et remplace au passage les tirets de la date par des slashs.

function Zup() {
if (Crt()) return null;
let host = Qup();
let timezone = e0t();
let cnTZ = timezone === "Asia/Shanghai" || timezone === "Asia/Urumqi";
if (!host) {
return {
known: false,
labKw: false,
cnTZ,
host: null,
};
}
return {
known: Jup().some((domain) => host === domain || host.endsWith("." + domain)),
labKw: Xup().some((keyword) => host.includes(keyword)),
cnTZ,
host,
};
}
function edp(known, labKw) {
if (!known && !labKw) return "'";
if (known && !labKw) return "\u2019";
if (!known && labKw) return "\u02BC";
return "\u02B9";
}
function Vla(date) {
let marker = Zup();
let apostrophe = edp(marker?.known ?? false, marker?.labKw ?? false);
let renderedDate = marker?.cnTZ ? date.replaceAll("-", "/") : date;
return `Today${apostrophe}s date is ${renderedDate}.`;
}

Tout ceci ne se produit que quand vous avez bidouillé la variable ANTHROPIC_BASE_URL afin de router vos requêtes ailleurs que chez Anthropic et si et seulement si le nom de domaine est dans une liste précise. Ou alors si votre fuseau horaire est réglé sur Shanghai ou Urumqi en Asie.

Mais c'est que ça m'a l'air hyper spécifique ça quand même... Qui est ce qu'Anthropic chercherait à tracer ?? Je me le demande bien.

Reste que le contenu de cette fameuse liste a de quoi faire tiquer. Tout d'abord, elle n'est pas en clair. C'est du base64 passé à la moulinette avec un XOR et la clé 91. Et une fois décodée, on y trouve des mots-clés comme deepseek, moonshot, zhipu ou baichuan, et une flopée de domaines chinois (baidu, alibaba, bytedance, jd) plus tout un tas de proxys et de revendeurs d'accès Claude.

Si vous n'avez pas le cerveau trop lent, vous l'aurez compris, ce marqueur sert à repérer les gens qui font tourner Claude Code à travers des intermédiaires chinois. Et Anthropic n'a pas nié.

Thariq Shihipar, qui bosse sur Claude Code, a expliqué sur X que c'était une expérience lancée en mars pour empêcher la distillation , cette technique où un concurrent aspire les réponses d'un modèle pour entraîner le sien à moindre coût. C'est exactement le reproche que la boîte fait à Alibaba.

Vu sous cet angle, vouloir détecter les revendeurs pirates et les pipelines de distillation, ça se défend donc très bien. Mais la méthode, aïe aïe aie, elle est plus que discutable car ça manque sévèrement de transparence.

Ce code dormait là depuis la version 2.1.91 sortie début avril, ni vu ni connu. En plus, c'est un peu couillon parce qu'en plus d'abîmer la confiance des utilisateurs de Claude Code qui se demandent quel autre mystère renferme cet outil, ça se déjoue en quelques secondes. Il suffit de changer de fuseau horaire, de changer de domaine ou de le patcher. Bref, ça n'a pas dû piéger grand monde...

Le marqueur a été retiré dans la foulée avec la version 2.1.197 donc pensez bien à mettre à jour votre install.

Source

Anthony Sgro vient d'open-sourcer un truc que tout utilisateur de VPN devrait avoir sous la main. C'est extension pour Safari, Chrome et Firefox (et pas Faille-Fox, déso) qui s'appelle GeoSpoof et qui part d'un constat tout bête que la plupart des gens ignorent.

En fait, votre VPN change masque bien votre adresse IP réelle (s'il est bien configuré, hein), d'accord, super, mais votre navigateur, lui, continue tranquillement de tout balancer aux sites web et notamment le lieu où vous vous trouvez vraiment.

Venez pas chez moi, c'est pas mon adresse...

Et il a mille façons de le faire. Y'a d'abord l'API de géolocalisation qui balance vos coordonnées GPS si vous l'autorisez, mais surtout y'a tout le reste, beaucoup plus sournois comme votre fuseau horaire, par exemple. Vous êtes connecté à un serveur VPN à New York mais votre navigateur répond Europe/Paris quand un script lui demande l'heure, et hop, le site comprend en une milliseconde que vous bluffez. Pareil avec l'objet Intl.DateTimeFormat, avec le Date du système, avec WebRTC qui adore fuiter votre vraie IP locale.

Vous pouvez avoir le meilleur VPN du monde, si ces signaux-là pointent tous vers chez vous pendant que votre IP dit le contraire, et vous êtes encore plus repérable qu'un mec sans VPN. C'est exactement ce qu'un VPN ne fait pas tout seul et c'est pour ça que votre abonnement à Youtube Premium, Netflix, ou Disney+ à 30 centimes acheté en Turquie ou je ne sais où, fini par se faire flagger.

GeoSpoof colmate donc ce trou en venant rebrancher directement ces APIs dans le navigateur sur du contenu factice. L'extension s'injecte au tout début du chargement de la page, avant que le JavaScript du site ait eu le temps de tourner et ensuite quand un script demande votre position, votre heure ou votre fuseau, il reçoit la localisation que VOUS avez choisie, et tout est cohérent. Géoloc, timezone, dates, WebRTC, tout raconte la même histoire et y'a plus de signal contradictoire qui dépasse.

Le mode que je trouve le plus pratique, dans GeoSpoof c'est surtout la synchro VPN automatique. L'extension repère l'IP de sortie de votre VPN, et elle aligne toute seule votre localisation navigateur dessus. Si vous changez de serveur, et que vous passez de Tokyo à Montréal, hé bien elle resynchronise sans que vous n'ayez à toucher à quoi que ce soit.

Sinon vous pouvez aussi y aller à la main, chercher une ville précise ou taper vos coordonnées directement. Pour vérifier que ça marche vraiment, l'auteur a même monté une page de test sur geospoof.com/verify , et l'extension passe les outils classiques de fingerprinting comme CreepJS ou BrowserLeaks.

Petit détail qui prouve le soin du travail, les overrides sont déguisés pour répondre [native code] quand un script essaie de vérifier s'ils ont été trafiqués. Héhé, malin !

Là où Anthony Sgro est honnête, c'est qu'il ne vous vend pas l'invisibilité totale. C'est écrit dans la doc que GeoSpoof ne change PAS votre IP. Sans un VPN derrière, votre adresse continue donc de pointer vers chez vous, et le bénéfice restera limité face aux sites qui recoupent l'IP.

Ça ne bypasse pas non plus la détection côté serveur, votre historique de compte ou votre moyen de paiement vous trahiront toujours. Et le mode le plus agressif, qui passe par le protocole de debug de Chrome pour verrouiller le fuseau jusque dans les workers, reste détectable par les outils qui cherchent spécifiquement ce genre de bidouille. C'est juste un outil de cohérence à utiliser en complément du meilleur VPN auquel vous vous êtes abonnés ^^.

Ça tourne sur Firefox, Chrome, Brave, Edge et même Safari sur iOS et macOS via l'App Store. Tout est sous licence MIT, et y'a pas de tracking ni de collecte de données dedans. C'est rare de voir des extension d'une si bonne qualité de finition, encore bravo à Anthony !!

Puis si vous bidouillez déjà votre vie privée avec un truc comme Fingerprint Defender , GeoSpoof complètera le tableau parfaitement sur la partie localisation.

Bref, un VPN sans ça, c'est une porte blindée avec une fenêtre grande ouverte à côté. Allez jeter un œil, ça prend 2 min à installer !

Samsung nous vend KNOX comme le gros cadenas de nos smartphones Galaxy mais il semblerait que ce soit un gros fail. Si vous ne connaissez pas encore KNOX, c'est la couche maison de Samsung qui garde un oeil sur tout ce qui tourne dans le téléphone afin de nous PROTÉGER (retenez bien ce mot c'est important...lol).

Et bien je vous le donne dans le mille mes petits Emile, des chercheurs de LucidBit Labs viennent de prouver l'exact inverse à cause d'une faille logée dans KNOX lui-même, qui est restée grande ouverte durant ces 8 dernières années. C'est la CVE-2026-20971, notée 7.8 sur l'échelle CVSS et elle concerne à peu près tous les Galaxy sortis depuis le S9.

Le problème, c'est que n'importe quelle appli, même un machin tout bête sans la moindre permission, pouvait déclencher la faille pour aller ensuite tripoter la mémoire du kernel et cibler par exemple une prise de contrôle totale de l'appareil. Rassurez-vous, le correctif est arrivé dans la mise à jour de sécurité de janvier 2026, donc filez dans Paramètres, Mise à jour logicielle, et vérifiez que vous l'avez bien.

Maintenant si votre Galaxy commence à dater et qu'aucune MAJ ne pointe son nez, c'est le moment peut-être de regarder si Samsung le maintient toujours, sinon opter pour une autre version d'Android ou acheter un smartphone pour les adultes (qui a dit iPhone ?? Rooooh).

Ce qui est fou quand même c'est que toute cette galère sort quand même d'un truc ajouté POUR renforcer la sécurité. Parfois les défenses deviennent la surface d'attaque... C'est à se demander si empiler des couches et des couches de sécurité c'est vraiment une bonne idée alors qu'il suffirait de bien verrouiller le système de base (le noyau Android)...

Bref, comme à chaque salve de failles Android , foncez mettre à jour votre Galaxy !

Source : Security Affairs

Quand vous demandez à un assistant IA de corriger une faille dans une de vos dépendances, il vous propose presque toujours la même chose : ajouter ce qu'on appelle un "override", une ligne de configuration qui force votre projet à utiliser une version saine d'une brique logicielle.

Le conseil semble bon sur le moment. Mais voilà, personne ne vous dit jamais de revenir vérifier, six mois plus tard, que cette ligne sert encore à quelque chose.

C'est précisément le trou que vient boucher CVE Lite CLI , un scanner gratuit et open source développé par Sonu Kapoor et adoubé par l'OWASP, la fondation qui fait référence en sécurité des applications. Cet outil a l'avantage de tourner en local, sans compte ni cloud, et sans qu'une seule ligne de votre code ne quitte votre machine.

Le problème qu'il cible est très simple. Une dépendance dite transitive, c'est une brique dont dépend une autre brique que vous, vous avez installée : vous ne l'avez jamais choisie vous-même, mais elle se retrouve quand même embarquée dans votre projet. Pour neutraliser une faille planquée là-dedans, on force une version corrigée via un override. Le souci, c'est que cette rustine vieillit toute seule, dans votre dos.

Kapoor a du coup ajouté une fonction qui audite ces configurations et débusque trois cas de figure : l'override pointe vers un paquet qui n'existe tout simplement plus, il s'applique au mauvais gestionnaire de paquets, ou il utilise un motif de caractères (une sorte de joker censé attraper plusieurs chemins d'un coup) qui en réalité ne correspond à rien. Dans tous ces cas vous vous croyez protégé alors que la protection est tombée depuis un moment.

Pour le prouver, il a passé quatre projets JavaScript très utilisés au crible, et les résultats sont parlants. Cal.com en alignait 90, dont 11 complètement inopérants ; Jest traînait une configuration qui pointait dans le vide ; NoCoDB empilait des jokers inefficaces ; seul Next.js s'en sortait sans le moindre défaut.

Entre l'affaire node-ipc de 2022, où un développeur avait lui-même saboté son propre paquet par militantisme, et la vague d'attaques Shai-Hulud de ces derniers mois, un ver qui se réplique tout seul en volant les jetons d'accès des développeurs sur npm pour contaminer au passage tous leurs autres paquets, l'écosystème JavaScript prend cher. Et un override mort, c'est une porte qu'on croyait verrouillée.

Ce qui est amusant, c'est que l'outil censé rattraper les approximations des IA est, lui, volontairement dépourvu de toute IA. Il interroge sagement une base de vulnérabilités connues et vous recrache des commandes prêtes à copier-coller, sans deviner quoi que ce soit.

Quoi qu'il en soit, on a là un petit outil tout bête qui repasse derrière l'IA, et franchement, ça rassure.

Source : The Register

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

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

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

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

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

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

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

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

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

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

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

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

Source : The Register

Le FBI possède sa propre ville, sauf que personne n'y habite, et pour cause, elle a été montée de toutes pièces dans un hangar de Huntsville, en Alabama, avec ses maisons meublées, son hôtel, sa station-service, son épicerie, son tribunal, son hôpital et jusqu'à sa compagnie d'électricité, le tout dans un seul but assez vertigineux, la pirater dans tous les sens sans jamais déranger âme qui vive.

Le décor porte d'ailleurs un nom, le Kinetic Cyber Range, près de 2 000 mètres carrés de fausse bourgade américaine ouverte en février 2025 et pensée comme un gigantesque bac à sable pour cyberattaques en conditions réelles.

Pendant la Guerre froide, les services de renseignement diffusaient sur ondes courtes des suites de chiffres récitées par une voix synthétique, à destination de leurs agents sur le terrain. On appelait ça des "numbers stations", et personne en dehors du destinataire ne savait décoder le message.

Steven Murdoch, professeur de sécurité informatique à l'University College London, vient de montrer que l'armée américaine fait à peu près la même chose depuis presque vingt ans, mais via le GPS que vous avez dans la poche.

Tout part d'un champ obscur du signal GPS baptisé "Subframe 4, Page 17". Le signal civil L1 transmet en permanence 50 bits par seconde de données de navigation, et dans ce flux se cache un bloc de 176 bits que la spécification officielle IS-GPS-200 réserve aux "messages spéciaux", dont le contenu est laissé "à la discrétion du commandement opérationnel". Autrement dit, personne n'a jamais dit publiquement à quoi il servait.

Murdoch a récupéré plus de 12 millions d'observations de ce champ dans une archive publique de stations au sol, couvrant 2007 à début 2026. Dix-neuf ans de données passées dans une moulinette en langage Julia puis stockées dans une base DuckDB, pour en extraire un peu moins de 4 000 messages uniques de 176 bits.

Le 26 mai 2011, les 31 satellites actifs changent de comportement très rapidement, en quelques heures, exactement au moment du déploiement du réseau OTAD de l'armée, le système qui distribue à distance les clés de chiffrement. Le rythme de rotation des messages passe de 3,7 jours à 1,8 jour, ce qui colle parfaitement avec une livraison quotidienne de clés tactiques aux récepteurs militaires.

En mai 2022, toute la flotte ralentit encore, sans la moindre annonce. Et en décembre 2023, le satellite PRN 8 inaugure un nouveau format : un préfixe "TEXT" en clair, suivi de 18 octets de texte chiffré.

L'hypothèse de Murdoch, c'est que ce champ sert à l'OTAR, la mise à jour à distance des clés de chiffrement des récepteurs GPS militaires. Plutôt que d'envoyer un technicien recharger physiquement chaque appareil, on diffuse la "prochaine clé" directement dans le signal public, captée uniquement par les récepteurs sécurisés SAASM capables de la déchiffrer.

Le reste du temps, le contenu ressemble à du bruit parfaitement aléatoire, comme tout bon texte chiffré. Avec quelques fuites quand même : des séquences de test 0xAA quand aucune clé n'est en transit, et une même chaîne de 9 caractères, LY47IRP16, qui réapparaît à des mois d'intervalle, possible en-tête cryptographique mal masqué.

"Chaque satellite GPS est une numbers station. Les récepteurs ont toujours écouté, il est temps que la communauté sécurité regarde enfin les octets", écrit Murdoch. La méthode a quand même ses limites face aux bonnes vieilles ondes courtes : un signal GPS se brouille et se leurre facilement en zone de conflit, et il faut un firmware spécialisé pour en tirer quoi que ce soit.

Franchement, planquer pendant vingt ans un canal militaire chiffré dans le signal que des milliards de civils utilisent chaque jour, c'est du très grand art quand même.

Source : Benthamsgaze

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

Le pire ? Aucun correctif.

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

Et toutes les versions sont concernées.

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

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

Une nuance, quand même.

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

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

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

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

Source : The Register

Le pari de Kyle McDonald, le site dont je vais vous parler aujourd'hui c'est que si une catastrophe se prépare, les milliardaires le sauront avant nous et fileront en jet privé. C'est pour ça que cet artiste-programmeur de Los Angeles a construit l' Apocalypse Early Warning System , un site qui surveille en temps réel l'activité des jets privés pour repérer le moment où les riches se barrent.

Son truc écoute un réseau de récepteurs radio répartis sur toute la planète, qui captent les signaux ADS-B des avions, à savoir leur position, leur altitude, leur direction et leur identifiant. McDonald filtre alors tout ça pour ne garder que les jets privés et d'affaires, soit plus de 35 000 appareils sur la carte, puis compare le nombre en vol à un instant donné avec ce qu'on devrait attendre normalement en cas de panique.

Et ce "normalement", ce sont des années de données historiques, avec les habitudes de chacun selon l'heure, le jour et les vacances genre Thanksgiving ou Noël. Et quand l'activité grimpe au-dessus de tout ce qu'on a vu sur un an, hop, le niveau d'alerte passe à 5 sur 5, soit bien plus de décollages que d'habitude.

Par contre, ce n'est pas sur du pistage individuel à la ElonJet, avion par avion, mais sur le compteur global de toute cette flottille privée. Difficile donc de dire si tel ou tel milliardaire précis a décollé, mais ça offre une tendance générale.

L'idée lui est venue après une menace de Trump sur l'Iran, du genre "une civilisation entière" pourrait disparaître. McDonald s'est alors demandé qui serait prévenu en premier, même si en réalité, l'activité des jets de milliardaires ne prédit pas vraiment l'apocalypse, et un pic n'annonce pas forcément une catastrophe.

Et le mec est productif puisque durant les manifestations George Floyd à Los Angeles, il a aidé à pister les hélicos de la police via le trafic aérien, et a découvert que le LAPD masquait l'identité de certains appareils. Puis il a aussi sorti ICESpy et FuckLAPD, deux projets de reconnaissance faciale pour identifier des agents des forces de l'ordre. Ça lui a même valu des menaces de mort.

Tout ça, vous l'aurez deviné, repose sur de l'OSINT, c'est à dire l'art d'exploiter des données déjà publiques que personne ne prend la peine de vraiment croiser, dans la lignée de ShadowBroker que je vous ai présenté y'a pas longtemps.

Son tracker de jets, lui, est gratuit sur le web et avec des alertes Telegram, ou si vous voulez recevoir un SMS, c'est 5 dollars par an. N'allez pas croire que ça n'intéresse personne puisque près de 2 500 personnes ont déjà payé. C'est fou !

Bref, on est un peu entre la blague et le malaise et on peut voir tout ça en direct sur son site .

Source

Voilà qui est rigolo. Un développeur malveillant a essayé de voler les fichiers sensibles des utilisateurs de Claude (l'assistant IA d'Anthropic, concurrent d'OpenAI sur les modèles de langage) en uploadant un package npm piégé.

Sauf que dans son code, il a laissé son propre token d'authentification GitHub privé. Les chercheurs n'ont eu qu'à le récupérer pour remonter jusqu'à lui.

Le package s'appelait mouse5212-super-formatter. Il se présentait comme un utilitaire interne de synchronisation de déploiement, mais en pratique, il scannait le répertoire local de l'utilisateur, encodait tous les fichiers en base64 (un format texte qui permet de transporter des données binaires), puis les uploadait sur un dépôt GitHub contrôlé par l'attaquant via l'API Contents.

La cible : les fichiers laissés par Claude Code (la version en ligne de commande de l'assistant IA d'Anthropic) sur le système, qui peuvent contenir des clés API, des tokens, ou des bouts de code propriétaire.

Le package a fait 676 téléchargements avant d'être supprimé par npm (le registre de packages JavaScript le plus utilisé au monde). C'est limité, mais pas anecdotique. 

Le compte GitHub utilisé pour la campagne a été créé le 26 mai 2026, soit quelques heures seulement avant la première version malveillante. Une opération préparée à la va-vite donc.

La bourde monumentale, c'est donc ce token GitHub privé hardcodé dans le code en fallback, au cas où la variable d'environnement ne soit pas définie.

Du coup, les chercheurs d'OX Security (une boîte spécialisée dans la sécurité des dépendances open-source) ont pu accéder directement au dépôt de l'attaquant, lister tous les fichiers volés, et confirmer l'ampleur de l'opération. C'est le genre d'erreur qu'on pardonne à un débutant sur un projet perso. Pas à quelqu'un qui essaie de monter une campagne d'exfiltration.

Les chercheurs notent aussi que le code a tout l'air d'avoir été pondu par une IA un peu foireuse. Variables mal nommées, structure approximative, gestion d'erreurs incohérente. Bref, du "slop" (terme utilisé pour qualifier les productions IA bâclées) avec toutes les négligences que ça implique. Et ce n'est probablement qu'un avant-goût. Avec la généralisation des assistants IA pour coder, n'importe qui peut désormais bricoler un malware fonctionnel sans rien connaître au développement. Et faire des erreurs de débutant en passant.

En tout cas, ça reste comique. Un attaquant piégé par son propre token. Bonne vanne.

Source : The Hacker News

Multimodal Solutions, une boîte grecque, vient de sortir Taphouse 1.5 qui est une GUI native macOS pour Homebrew. GUI c'est pas que le nom de votre collègue qui fout rien, c'est surtout un acronyme qui veut dire Graphic User Interface (Interface Graphique !). Et pour Homebrew, bah c'était pas du luxe.

Parce que Homebrew, c'est le standard chez les développeurs Mac, mais tout passe par le terminal. Faut taper brew install, gérer les services, fouiller l'arbre de dépendances en CLI (Command Line Interface), et c'est pas le pied quand on veut juste installer Firefox et passer à autre chose dans sa vie !

Des interfaces graphiques pour Homebrew, y'en a déjà quelques-unes (par exemple Cakebrew, Applite, Cork, WailBrew) sauf que Taphouse arrive avec 2 trucs qu'on voit rarement ailleurs : un scanner CVE intégré et un détecteur d'apps Intel qui tournent encore sous Rosetta.

Le scanner CVE, fait qu'à chaque installation, Taphouse compare la version de chaque package avec les feeds de vulnérabilités, avec des codes couleur selon la sévérité, et linke directement vers la base NVD et les rapports fournisseur.

Ainsi, quand une nouvelle CVE tombe, ça rescan en arrière-plan comme ça, sur des dépendances qu'on oublie de mettre à jour pendant des mois, y a de quoi repérer les vulnérabilités connues avant qu'elles posent un vrai problème côté sécurité.

L'autre feature pas mal, c'est donc la détection des apps Intel qui tournent encore sous Rosetta. Si vous êtes passé d'un Intel à un Mac M* , vous avez sûrement traîné des binaires Intel dans /Applications sans même vous en rendre compte. Taphouse scanne le dossier, repère les x86_64 et, quand un cask compatible existe, il vous propose la version Apple Silicon native via Homebrew. J'ai testé sur mon install et, ça m'a remonté tous mes binaires Intel oubliés comme ça j'ai pu faire un peu de ménage.

Dans sa version gratuit, vous avez le droit à +14 000 formules et casks, l'installation en un clic, la gestion des services Homebrew (start, stop, restart), le nettoyage de l'espace disque, l'aperçu des dépendances, et un gestionnaire de quarantaine Gatekeeper. Y'a aussi de quoi repousser une mise à jour pour 1 jour, 1 semaine ou 1 mois quand on n'a pas envie de se taper un brew upgrade en plein rush de boulot.

Pour les power-users, la version pro débloque la migration Apple Silicon assistée, l'aperçu des release notes GitHub en direct dans l'app, et un tableau de bord "santé du système" avec un score global. Je ne sais pas si ça vous sera utile mais ça coute moins de 10 balles pour une licence à vie, ce qui se fait de plus en plus rare maintenant.

Notez que Taphouse n'est pas open source malgré le repo GitHub qui n'héberge que les rapports de bug. Maintenant entre une app gratuite et Taphouse Pro à 9,99 €, ça dépend de ce que vous cherchez. Applite couvre 80% du besoin si vous n'installez que des casks (pas les formules), et de son côté, Cork est open-source et gratuit mais le binaire pré-compilé est payant.

Y'a aussi Cakebrew qui est encore dispo mais le projet ne semble plus maintenu. Ce qui est surtout cool avec Taphouse c'est le CVE scanning et cette migration Apple Silicon assistée dont je vous parlais.

Si vous voulez l'installer, ça peut se faire via Homebrew lui-même avec brew install --cask taphouse. Sinon, téléchargement direct sur le site officiel .

Bref, si vous gérez votre Mac avec Homebrew et que vous en avez marre du terminal, Taphouse mérite un petit coup d'œil.

Source

Micode vient de lâcher une enquête de presque 50 minutes que vous devriez vraiment regarder, et je la relaie parce qu'elle est d'intérêt public.

Avec son équipe, il a infiltré pendant des mois le réseau derrière ces appels qui vous harcèlent plusieurs fois par jour, ces numéros en 0162 que l'Arcep réserve au démarchage et que les escrocs détournent allègrement. Genre les faux remboursements de 170 € soi-disant liés à l'inflation ou aux chèques énergie.

Et spoiler, ce n'est pas une petite arnaque artisanale mais une véritable industrie de l'escroquerie !

Flipper Devices, les gens derrière le fameux Flipper Zero , viennent de dévoiler leur prochain joujou, le Flipper One . Et leur annonce démarre par cette phrase de Pavel Zhovner, le co-fondateur : « on est franchement terrifiés, et on a besoin de vous ».

Apparemment, ce nouveau projet l'angoisse et faut être honnête, y'a de quoi. Car le Flipper One, ce n'est pas un Flipper Zero en plus gros. C'est carrément un mini-PC Linux ARM de poche, pensé comme un couteau suisse pour le réseau. Et là où le Zero causait uniquement aux protocoles de proximité (NFC, RFID, sub-GHz, infrarouge), le One joue dans la cour du dessus, en s'adressant également au monde IP, donc tout ce qui est Wi-Fi, Ethernet, 5G et même satellite. Ahaha, j'adore !

Et côté tripes, s'ils tiennent leurs promesses, ça va envoyer du lourd ! En effet, on va y retrouver un Rockchip RK3576 8 cœurs cadencé avec GPU Mali et un NPU pour faire tourner des modèles d'IA en local, 8 Go de RAM, deux ports Gigabit Ethernet indépendants, du Wi-Fi 6E qui gère le monitor mode, un modem 5G en module M.2, et une sortie HDMI 2.1 en 4K.

En gros, vous avez un routeur, un analyseur de signaux et un thin client réunis dans un truc qui tient dans la poche.

Puis y'a surtout ce truc de "double cerveau" avec à côté du gros CPU, un microcontrôleur RP2350 (celui du Raspberry Pi Pico 2) en plus qui pilote l'écran, les boutons et l'alimentation. Comme ça, même quand le Linux est éteint, l'appareil reste vivant et vous pouvez toujours gérer le boot et l'affichage sans réveiller le monstre.

Mais le vrai sujet de cette annonce, ce n'est pas la fiche technique. C'est l'ouverture du bestiau car le Flipper One vise un noyau Linux pur, celui de kernel.org, sans patch vendeur, ni blob binaire ou autres drivers proprio. C'est un truc de puriste qui va faire plaisir à tous les barbus !

Parce que oui, chez Flipper Devices, ils en ont marre des fabricants ARM qui balancent leurs « board support packages » crades que personne ne comprend, comme le fait Raspberry Pi au passage. Alors pour y arriver, ils bossent à fond avec Collabora afin de pousser le support du RK3576 directement dans le kernel officiel.

Et c'est là qu'arrive le « we need your help » car plutôt que de bidouiller dans leur coin, ils ouvrent d'un coup tout le processus de développement dès le premier jour. Leurs trackers de tâches, leurs débats d'architecture, leurs docs à moitié finies, bref tout le bazar que les boîtes planquent d'habitude, bah eux, ils le mettent à dispo ! Et c'est pour cela qu'ils cherchent des gens pour le support du kernel, pour tester le Wi-Fi en audit et injection, pour trancher le choix du bureau (KDE Plasma ou un gestionnaire en tiling plus léger ?), et même pour entraîner un petit modèle d'IA maison.

Et au-dessus de tout ça, ils préparent leur Flipper OS, une couche sur du Debian qui introduit une notion de « profils » qui n'est ni plus ni moins qu'un instantané complet du système avec ses paquets préconfigurés. Vous bootez dessus, vous le clonez, vous le cassez, et hop vous revenez à une copie propre sans tout reflasher.

Ils bossent aussi sur FlipCTL, un framework pour habiller les utilitaires Linux en menus sur petit écran, avec comme objectif de le rendre installable d'un simple apt install ailleurs que sur leur produit.

Après, j'espère que ça va bien se passer pour eux car malgré leur succès, Flipper Devices traîne un passif chargé. Le Flipper Zero s'est écoulé à plus d'un million d'exemplaires, mais il a été viré d'Amazon en 2023, étiqueté « appareil de skimming », puis carrément banni au Canada début 2024 sous prétexte qu'il servait à voler des voitures.

C'était d'ailleurs des accusations bidons vu que le bestiau dans sa forme de base est incapable de mener les attaques par relais qu'on utilise en général pour voler des voitures. Heureusement pour eux, la justice canadienne a fini par reculer, mais bon, leur réputation grand public est faite malheureusement.

L'autre point qui va vous calmer, c'est que vous ne pourrez pas encore l'acheter... Le moyen le plus rapide sera de lâcher 350 $ dans leur prochaine campagne Kickstarter prévue cette année. Et encore, le projet pourrait ne jamais sortir...

Voilà, du coup, si l'idée d'un Linux de poche sans compromis vous parle, le mieux pour aider, c'est peut-être d'aller mettre les mains dans le cambouis sur leur portail dev.

Perso, un cyberdeck ouvert jusqu'au noyau, moi ça me plait bien. Le Flipper Zero, ça m'a jamais convaincu mais ce Flipper One, déjà pour moi, il est beaucoup plus convaincant... On verra s'ils tiennent la distance maintenant. Et si vous voulez creuser le genre, jetez un œil à ce cyberdeck fait maison , au WiFi Pineapple côté audit sans fil, et à Intercept pour l'analyse radio.

À suivre de très près !

Bon, alors là, Google a fait encore trèèèès fort.

Mercredi matin, la firme de Mountain View a carrément publié sur son propre bug tracker Chromium le code d'exploitation d'une faille... qui n'est toujours pas corrigée ! Et pas une petite vulnérabilité oubliée dans un coin, hein, mais une vraie faille de la mort qui tue que la chercheuse indépendante Lyra Rebane leur avait remontée gentiment et en privé . Ça fait 29 mois (2 ans et demi, les matheux ^^) et elle attend toujours un patch !

Le truc vise la Browser Fetch API, un mécanisme qui permet à un site de télécharger de gros fichiers en arrière-plan, genre une longue vidéo. Sauf qu'en la détournant, le code ouvre un service worker qui reste actif en permanence. Du coup, un site malveillant que vous visitez peut glisser un bout de JavaScript qui transforme votre navigateur en relais, tout cela à votre insu.

Parfait donc pour devenir un proxy anonyme pour des inconnus, un nœud de botnet pour des attaques DDoS, ou se faire surveiller quand on surfe sur le net... Et le plus vicelard, c'est que la connexion se rouvre ou reste ouverte même après avoir redémarré le navigateur, voire la machine entière.

Côté victimes, on parle de Chrome, de Microsoft Edge et de quasiment tous les navigateurs basés sur Chromium. Et que vous soyez sur Windows, macOS ou Linux, le bug s'en moque royalement. Rebane a confirmé que Brave, Opera, Vivaldi et Arc sont vulnérables eux aussi.

Bien sûr, Firefox et Safari, eux, passent clairement au travers, parce qu'ils ne supportent pas ce fameux téléchargement en arrière-plan. Bref, encore une fois, ne pas suivre le troupeau de mouton team-Chromium, ça paye !! Si vous cherchiez une raison de plus de larguer Google , la voilà servie sur un plateau.

Perso, ce qui me sidère, c'est que la faille a été classée S1, le deuxième niveau de gravité le plus élevé chez Google et il ne s'est toujours rien passé 29 mois après. C'est ouf quand même... Le post sur le tracker Chromium a bien été supprimé mais on le trouve toujours sur quelques archives / miroirs...

Après l'impact de cette faille, reste quand même limité car elle ne franchit aucune frontière... par exemple, elle ne donne pas accès à vos mails ni au reste de votre ordinateur, mais juste à ce qu'un navigateur sait déjà faire (ce qui est déjà énorme !!). Mais elle pourrait permettre à des cybercriminels de se constituer une flotte de milliers, voire de millions de navigateurs détournés, et le jour où une autre faille tombe, vous avez déjà l'armée prête à dégainer !! La bombe est là, il manque juste la mèche en fait !

Et pour se protéger ?

Bah franchement, pas grand-chose à faire côté utilisateur tant qu'il n'y a pas de patch. Si vous voulez mon avis bancal, le seul signal visible que vous pouvez guetter, c'est un menu de téléchargement qui s'ouvre tout seul sans raison, donc méfiez-vous donc si ça arrive. Maintenant si le sujet vous angoisse vraiment, basculer sur un navigateur pour les adultes ^^, genre Firefox ou Safari règlera la question d'un coup !

Faut pas oublier que Google passe son temps à pointer du doigt les éditeurs trop lents à patcher, alors j'comprends vraiment pas comment ils ont pu merder à ce point.

Source

Alors celle-là, elle est incroyable les copains !

Le piratage du jour vient d'être confirmé par la plateforme qui héberge une bonne moitié du code de la tech mondiale ! En effet, Github a subit un accès non autorisé à ses propres dépôts internes, à cause d'une extension VS Code piégée installée sur l'ordi d'un employé !

L'annonce officielle est tombée sur le compte X de l'entreprise à l'instant et c'est comme ça que je suis tombé dessus.

GitHub dit avoir détecté et maitrisé la compromission hier. L'extension VS Code malveillante a été retirée, le poste de travail isolé, et la rotation des secrets critiques est en cours. Côté impact, le message officiel c'est que "À l'heure actuelle, nous ne disposons d'aucune indication laissant supposer que les informations des clients stockées en dehors des référentiels internes de GitHub aient été compromises".

Du coup, nos repos perso, nos orgs, nos enterprises...etc, rien n'est normalement touché à ce stade, en tout cas selon ce que GitHub voit pour l'instant.

Le thread officiel de GitHub sur l'incident

Sauf que sur le darkweb, un acteur baptisé TeamPCP, repéré par le compte de threat intel Dark Web Informer, prétend détenir et vendre environ 4000 dépôts privés volés à GitHub. L'entreprise n'a pas publié de chiffre officiel mais a reconnu que la revendication était cohérente avec son enquête en cours, le rapport complet arrivera une fois bouclé.

Bref, à prendre au sérieux mais avec des pincettes le temps que ça se vérifie !

C'est vrai qu'en ce moment, on est dans une vague d'attaques supply chain qui ciblent les extensions VS Code , qui sont devenues un vrai vecteur d'attaque reconnu. Et tout le monde peut se faire piéger (même les ingés GitHub !).

Donc pour vous qui me lisez, la règle de base reste la même : Installez une extension VS Code uniquement si vous faites confiance à l'éditeur. En pratique, faut regarder le tag publisher verified, l'âge du compte, le nombre d'installs et la date de la dernière release, et surtout méfiez-vous des forks fraîchement republiés sous des noms qui ressemblent à un outil connu.

Pour suivre ça maintenant, le thread officiel et ses mises à jour sont sur le compte X de GitHub .

Les avions en vol, les cargos, les satellites espions, les zones de brouillage GPS... Imaginez tout ce bordel, à l'échelle de la planète, visible sur une seule carte sombre directement chez vous. Ce serait fou non ? Hé bien c'est ce que nous propose BigBodyCobain qui a sorti ShadowBroker , un tableau de bord OSINT gratuit et open source qui agrège plus de 60 flux de renseignement public, rafraîchis en continu.

Pour l'installer, un git clone, et on entre dans le dossier. Suffit ensuite de lancer un docker compose up (faut juste Docker, et ça tourne sous Linux, Mac ou Windows), vous ouvrez localhost:3000 et la carte se remplit toute seule ! Ça marche même sur un Raspberry Pi 5. C'est donc largement plus simple que la moitié des trucs que je vous présente ici en général.

Y'a qu'une seule clé API qui est vraiment obligatoire, c'est celle d'aisstream.io pour le trafic des bateaux, et c'est une inscription gratuite. Le reste tourne sans rien, sauf qu'une clé OpenSky (gratuite aussi) est chaudement recommandée pour une couverture aérienne correcte, + quelques couches secondaires qui acceptent leur propre clé pour avoir de la meilleure info.

L'interface principale de ShadowBroker : une carte du globe qui empile en temps réel avions, navires et satellites, chat MESH à gauche et fil Global Threat Intercept à droite

Pour ceux qui débarquent, l'OSINT c'est le renseignement à partir de sources ouvertes, c'est à dire toutes ces données déjà publiques que personne ne prend le temps d'aller croiser. Donc cet agrégateur ne pirate rien... il ramasse juste ce qui traîne déjà en accès libre.

Et là, vous vous demandez ce qu'il y a dedans en détails ?

Hé bien accrochez-vous parce qu'on y retrouve les avions civils via OpenSky, les militaires via adsb.lol, l'ADS-B étant le signal que tout avion crache en vol, avec Air Force One bien visible dès le décollage. Et les bateaux sont suivis en AIS, l'équivalent radio côté maritime.

Y'a aussi les satellites dont la trajectoire est calculée depuis leurs paramètres orbitaux, les séismes de l'USGS, les feux repérés par la NASA, les conflits agrégés depuis GDELT, la ligne de front ukrainienne via DeepState et même un tracker pour suivre les porte-avions américains (c'est une position estimée à partir de l'actu publique, et pas du temps réel).

Du coup ça va loin ! Les zones de brouillage GPS probable sont même déduites quand le signal de navigation des avions se dégrade et on y retrouve aussi plus de 11 000 caméras de circulation aussi, de Londres à Singapour en passant par les États-Unis et l'Espagne.

Le panneau Data Layers (séismes, satellites, brouillage GPS, lignes de front) ouvert sur une zone de conflit, avec le détail des reports terrain

Il y a même un tuner d'ondes courtes intégré, branché sur des centaines de récepteurs radio partagés par des amateurs (les SDR, des radios pilotées par logiciel). Et les scanners de la police américaine sont aussi en écoute directe.

Et en faisant un clic droit n'importe où sur le globe, ce radar mondial vous sortira un dossier du pays, avec le type de gouvernement, le chef d'État tiré de Wikidata, un résumé Wikipédia et la dernière image satellite Sentinel-2 disponible.

Côté bidouille, vous pouvez aussi brancher votre propre dongle RTL-SDR, une clé radio à pas cher, en plus du flux distant pour choper les bateaux à portée de votre antenne. Et avec une clé Shodan, un overlay optionnel ajoute les objets connectés visibles depuis Internet, tels que les caméras, les systèmes industriels, les bases de données et j'en passe.

Ça rejoint ce bon vieux moteur de recherche d'objets connectés dont je vous parlais il y a quelques années. Et si l'OSINT vous gratte vraiment, y'a aussi de quoi vous entraîner sérieusement avec ce site aussi.

La légende de cet outil veut que l'idée soit partie d'une envie de pister les déplacements d'Elon Musk avec une interface cyberpunk. Le nom, lui, vient du Shadow Broker de Mass Effect (rien à voir avec le groupe de hacker Shadow Brokers ). D'après le créateur, GitHub aurait même fait retirer le dépôt d'origine à cause de ce nom, d'où un petit détour par GitLab avant de revenir à Github.

Bref, ce truc agrège une quantité hallucinante de données publiques mondiales...

Après, au niveau du code, tout n'est pas non plus très clair car même si l'OSINT c'est légal, le code du scrapeur d'une carte de guerre contourne volontairement la protection Cloudflare Turnstile, ce qui pose une vraie question légale côté CFAA, la loi américaine contre l'intrusion informatique. C'est une zone grise...

Et y'a aussi des failles puisque plusieurs endpoints ne sont pas authentifiés, dont un qui laisse n'importe qui envoyer des messages APRS (le réseau de positionnement des radioamateurs) sous n'importe quel indicatif, ce qui est une infraction pure et simple aux règles radio.

Quant à la messagerie soi-disant chiffrée ne l'est pas de bout en bout, mais juste obfusquée donc ne faites rien transiter de sensible dessus.

Voilà si je vous dis tout ça, c'est pour que vous gardiez cet outil bien au chaud en local et que vous ne l'exposiez pas sur le net.

Zoom sur la côte de Floride : chaque marqueur est un avion suivi en direct via l'ADS-B, façon radar ( Source : GIGAZINE )

Mais bon, ça fait une belle salle de crise gratuite, open source sous licence AGPL, installable par exemple sur un Raspberry Pi. Grâce à ça, le monde n'a jamais été aussi "lisible" depuis votre canapé !

Un grand merci François pour le lien !

Vous ne le savez peut-être pas mais votre serveur Linux embarque plusieurs milliers de modules kernel et pourtant, il n'en utilise que quelques centaines à peine. Tout le reste ça prend la poussière et ça peut vous exposer à des problèmes de sécurité. Hé bien c'est exactement à ces modules inutiles que Jasper Nuyens, le fondateur de Linux Belgium, vient s'attaquer avec son outil ModuleJail .

Ce script lit /proc/modules pour savoir ce qui tourne vraiment sur votre machine, et considère ensuite cet ensemble comme étant intouchable. Par contre, pour tout le reste il ajoute une ligne install <module> /bin/true dans /etc/modprobe.d/modulejail-blacklist.conf.

Comme ça si un jour quelque chose essaie de charger un de ces modules endormis, c'est modprobe qui exécutera /bin/true à la place... et il ne se passe rien !!

C'est malin, hein ? Vous pouvez installer ModuleJail via le script dispo sur la page Github ou grâce aux paquets .deb et .rpm si vous préférez. Et ensuite, pour vérifier que c'est bien en place, un petit modprobe -n -v module_banni devrait vous répondre install /bin/true.

En tout cas, je trouve que ModuleJail tombe très bien parce que la chasse aux failles kernel est clairement en train de changer d'échelle. Je pense notamment à tous ces outils de scan assistés par IA qui débusquent à la chaine des bugs d'élévation de privilèges planqués dans le code depuis des années.

Le script propose 3 profils via le flag -p, minimal pour le strict nécessaire, conservative par défaut (serveur classique plus drivers VM courants) et desktop qui garde WiFi, Bluetooth, audio et vidéo. Vous pouvez aussi ajouter votre propre whitelist.

Et la règle d'or non négociable, c'est de le lancer quand la machine est dans un état stable, avec tous les services démarrés, et tous les disques montés. Car oui, ModuleJail ne devine rien, mais se contente de photographier ce qui tourne à l'instant T. Donc sur un système à moitié démarré, ce serait un peu couillon qu'il bannisse un module dont vous aurez besoin plus tard.

Après pour tout ce qui est compilé en dur dans le kernel (le fameux =y de la config) ça reste là, donc une faille dans le cœur du noyau façon Dirty Cow , ça n'y changera rien du tout. Et si vous branchez une webcam six mois après, son module sera déjà banni donc faudra pas oublier de retirer sa ligne du fichier ou relancer le script avec une whitelist, car un simple modprobe ne suffira pas !

Donc c'est pas forcement le pied pour un Linux Desktop mais pour un parc de serveurs en prod qui ne bougent pas, c'est une petite couche de sécurité en plus.

Source

Si vous avez committé du code depuis VS Code depuis mi-avril, allez tout de suite vérifier vos messages de commit car vous avez peut-être un nouveau co-auteur que vous n'avez jamais embauché.

En effet, Microsoft a discrètement basculé le réglage par défaut de l'éditeur pour ajouter Co-authored-by: Copilot <copilot@github.com> à des commits que VS Code considérait à tort comme contenant des contributions IA, même quand vous n'avez pas utilisé Copilot, et même quand vous avez explicitement désactivé toutes les fonctions IA.

Quelle lose, hein ? La Product Manager Courtney Webster a poussé cette fameuse pull request #310226 des enfers le 15 avril dernier sans aucune description, et le dev dmitrivMS l'a mergée tranquillou le lendemain.

Et le résultat de tout ce bordel, vous pouvez le lire dans la PR #310226 qui a explosé sur GitHub : 372 pouces baissés contre 2 levés, 30 réactions "confused", et des dizaines de commentaires furieux.

L' issue de suivi #314311 , ouverte ensuite par dmitrivMS pour faire son point public, a elle aussi reçu un torrent de réactions virulentes. Tu m'étonnes, ils font vraiment n'importe quoi...

Maintenant si vous êtes dans ce cas, vous pouvez neutraliser ça immédiatement, ajoutez dans votre settings.json :

"git.addAICoAuthor": "off"

Plus de 230 modèles de points d'accès Wi-Fi Cisco ont un problème. Les versions 17.12.4 à 17.12.6a de IOS XE embarquent une bibliothèque qui génère un fichier log, cnssdaemon.log, à raison de 5 Mo par jour. Le fichier ne sert à rien. Et impossible de le supprimer depuis la ligne de commande.

5 Mo par jour. Ça paraît rien. Sauf qu'un point d'accès Wi-Fi n'a pas un disque de 500 Go. La mémoire flash de ces appareils est limitée, et au bout de quelques semaines ou mois, elle sature.

Quand c'est plein, plus moyen de télécharger ou d'installer une mise à jour logicielle. La borne fonctionne encore, mais elle est figée sur sa version actuelle, sans possibilité de patch de sécurité ou de correction de bug.

Et c'est là que le piège se referme. Pour corriger le problème, il faut mettre à jour IOS XE. Mais si la mémoire flash est déjà pleine, la borne n'a pas la place pour stocker la nouvelle image système.

Cisco prévient que tenter la mise à jour dans cet état peut provoquer un bootloop, la borne redémarre en boucle sans jamais finir le boot. Du coup, l'admin se retrouve avec un appareil qu'il ne peut ni patcher ni laisser en l'état.

Cisco a publié un bulletin avec les procédures de test et de remédiation. Il faut d'abord vérifier la version IOS XE, puis libérer de l'espace manuellement avant de tenter la mise à jour.

Ça se fait, mais c'est du travail manuel sur chaque borne, et dans un réseau d'entreprise avec des centaines de points d'accès, la facture en heures de boulot est salée.

Ce genre de bug est particulièrement agaçant parce qu'il est silencieux. Personne ne surveille l'espace disque d'une borne Wi-Fi au quotidien, le problème se découvre en général le jour où une mise à jour échoue, c'est-à-dire trop tard.

Et le fait que la suppression du fichier soit impossible en CLI est quand même un oubli difficile à excuser sur du matériel vendu aux entreprises.

Bref, si vous avez du Cisco en IOS XE 17.12.x, vérifiez vos bornes avant qu'elles ne se bloquent toutes seules.

Source : The Register

Sandbox-exec, c'est un utilitaire en ligne de commande dont pas grand monde ne parle mais qui est intégré à macOS et qui permet de lancer n'importe quel programme dans un bac à sable sécurisé, avec des restrictions sur mesure. Apple l'a déprécié, mais ça marche toujours... et c'est franchement pratique.

Avec ce truc, il suffit de créer un petit fichier de profil (extension .sb) et vous lancez votre commande avec sandbox-exec -f profil.sb votre_commande. En faisant ça, le programme de votre choix tournera dans un environnement verrouillé où il ne pourra accéder qu'à ce que vous autorisez explicitement.

Ensuite, vous avez deux philosophies. Soit vous bloquez tout par défaut et vous n'autorisez que le strict nécessaire, c'est-à-dire l'approche parano parfaite pour tester du code louche. Soit vous autorisez tout et vous ne bloquez que ce qui craint. La première est plus sûre, la seconde plus rapide à mettre en place.

Voici un exemple concret pour avoir un terminal coupé du réseau. Suffit de 3 lignes de profil (c'est du LISP) :

(version 1)
(allow default)
(deny network*)

Le sujet central du lancement de GPT-5.4-Cyber, c'est moins le modèle que le mécanisme d'accès.

OpenAI a annoncé une version fine-tunée de GPT-5.4 dédiée aux cas d'usage cybersécurité, avec une particularité assumée : moins de restrictions sur les capacités du modèle, mais accès réservé aux participants vérifiés du programme Trusted Access for Cyber.

Concrètement, ce GPT-5.4-Cyber sait faire des choses que les modèles grand public refusent ou limitent. On parle ici de Reverse engineering de binaires sans code source, analyse de malware, étude de vulnérabilités, génération de workflows défensifs avancés, et j'en passe.

Des tâches utiles pour un chercheur en sécurité, mais potentiellement dangereuses si elles tombent entre les mauvaises mains. D'où le verrou d'accès au niveau du compte plutôt qu'au niveau du prompt.

Le programme Trusted Access for Cyber avait été lancé plus tôt dans l'année pour donner à des pros de la sécu vérifiés un accès à des capacités normalement bridées.

OpenAI y ajoute désormais des niveaux supplémentaires, avec un principe simple. Plus le niveau de vérification d'identité est élevé, plus les capacités du modèle sont débloquées. Accès étendu à des milliers d'individus et des centaines d'équipes sécurité, à condition de passer les contrôles.

Ce qui frappe en fait, c'est le changement de posture. OpenAI avait longtemps mis l'accent sur le bridage direct du modèle, via du RLHF agressif et des garde-fous au niveau du prompt. L'approche qui s'impose en 2026, c'est celle de la vérification d'identité plus du monitoring d'usage, avec un modèle plus compétent en face.

Moins de refus, plus de traçabilité. C'est cohérent avec le fait que les red teams avaient largement documenté comment contourner les garde-fous classiques.

Le timing est intéressant. L'annonce tombe une semaine après un lancement similaire chez un concurrent sur le même créneau. Mythos avait ouvert le bal avec un modèle spécialisé cyber et un mécanisme d'accès vérifié comparable.

Du coup, OpenAI ne veut pas laisser le marché et pousse son infra d'identité plutôt que de tenter une bataille de benchmarks.

Côté risques, la question qui reste ouverte c'est la solidité du processus de vérification. Un acteur malveillant avec une couverture légitime (société écran, identité empruntée, insider dans une boîte de pentest) peut techniquement passer les contrôles, et OpenAI indique surveiller l'usage a posteriori plutôt que bloquer en amont. Une fuite d'output reste exploitable même si le compte d'origine est révoqué derrière.

Bref, modèle plus fort, bridage déplacé du prompt vers l'identité. On est là devant un marché cyber-IA qui bouge très vite.

Source : Bloomberg

60 Mo de source maps (ces fichiers qui permettent de remonter du code minifié à l'original) ont été oubliés dans un paquet npm. Et voilà comment Anthropic a involontairement balancé en public le code source complet de Claude Code, son outil à 2.5 milliards de dollars de revenus annuels.

Alors qu'est-ce qui s'est passé exactement ?

Hé bien hier, la version 2.1.88 du package @anthropic-ai/claude-code sur le registre npm embarquait un fichier .map de 59.8 Mo. Un truc normalement réservé au debug interne, sauf que ce fichier .map contenait les pointeurs vers les 1 900 fichiers TypeScript originaux, en clair. Chaofan Shou, un développeur chez Solayer Labs, a alors repéré la boulette et l'a partagée sur X. Le temps qu'Anthropic réagisse, le code était déjà mirroré partout sur GitHub, avec 41 500+ forks en quelques heures. Autant dire que le dentifrice ne rentrera pas dans le tube !

Pour ma part, j'avais un petit dépôt à moi assez ancien avec quelques trucs relatifs à Claude Code, qui n'avait rien à voir avec tout ça, qui s'est même retrouvé striké... Ils ratissent large avec leur DMCA donc.

Et là, c'est la fête pour les curieux comme moi parce que les entrailles de l'outil révèlent pas mal de surprises. Côté architecture, on découvre environ 40 outils internes avec gestion de permissions, un moteur de requêtes de 46 000 lignes de TypeScript, un système multi-agents capable de spawner des essaims de sous-tâches en parallèle, et un pont de communication entre le terminal et votre éditeur VS Code ou JetBrains. Le tout tourne sur Bun (pas Node.js ^^) avec Ink pour l'interface terminal. Par contre, pas de tests unitaires visibles dans le dump.

Côté mémoire, c'est plutôt bien pensé puisqu'au lieu de tout stocker bêtement dans la fenêtre de contexte du modèle, l'outil utilise un fichier texte MEMORY.md ultra-léger (genre 150 caractères par entrée) qui sert d'index de pointeurs. Les vraies données, elles, sont distribuées dans des fichiers thématiques chargés à la demande, et les transcripts bruts ne sont jamais relus entièrement, mais juste fouillés à la recherche d'identifiants précis. L'agent traite en fait sa propre mémoire comme un "hint" ce qui le force à vérifier toujours le vrai code avant d'agir. En gros, il a une mémoire sceptique, et pour moi c'est clairement le truc le plus intéressant du dump.

Y'a aussi un truc qui s'appelle KAIROS (mentionné 150 fois dans le code) qui est un genre de mode daemon autonome. En fait, pendant que vous allez chercher votre café, l'agent tourne en arrière-plan et fait ce qu'ils appellent autoDream : il consolide sa mémoire dans des fichiers JSON, vire les contradictions et transforme les observations vagues en données structurées. Comme ça, quand vous revenez devant votre écran, le contexte est nettoyé.

Et puis le code balance aussi la roadmap interne d'Anthropic (bon courage au service comm ^^). On y trouve les noms de code des modèles... Capybara pour un variant de Claude 4.6, Fennec pour Opus 4.6, et un mystérieux Numbat qui n'est pas encore sorti. D'ailleurs, les commentaires internes révèlent que Capybara v8 a un taux de fausses affirmations qui tourne autour de 30%, ce qui est une grosse régression par rapport aux 17% de la v4. Y'a même un "Undercover Mode" qui permet à l'agent de contribuer à des repos publics sans révéler d'infos internes (c'est sympa pour les projets open source).

Anthropic a confirmé la fuite : "C'était un problème de packaging lié à une erreur humaine, pas une faille de sécurité. Aucune donnée client n'a été exposée." Mouais, attention quand même, parce que le code est déjà partout et n'en repartira pas. Et même si aucun secret client n'a fuité, exposer l'architecture complète d'un agent IA à 2.5 milliards de revenus, c'est pas rien non plus.

Bon, et maintenant qu'est-ce qu'on peut en faire ? Bah pas mal de choses en fait.

Par exemple, le système de mémoire auto-correcteur est un pattern directement réutilisable pour vos propres agents IA. L'architecture "index léger + fichiers à la demande" résout élégamment le problème de la pollution de contexte qui fait halluciner les LLM sur les longues sessions. Les +40 outils internes permettent aussi de comprendre comment structurer un système de permissions granulaires dans un agent autonome . Et le concept KAIROS/autoDream, la consolidation mémoire pendant l'idle, c'est une idée qu'aucun outil open source n'implémente encore. Autant dire que les alternatives open source à Claude Code ou Codex vont monter en gamme dans les jours qui viennent. Et le code est déjà nettoyé, réécris en Rust et mis sur GitHub si vous voulez fouiller. Bon, pas sûr que le pattern autoDream soit simple à reimplémenter, mais le système de mémoire oui.

Je trouve ça assez marrant que le code proprio d'une boite qui a aspiré tout l'open source du monde voire plus, sans autorisation, pour le revendre sous la forme de temps machine / tokens, devienne lui aussi en quelque sorte "open source" sans qu'on leur demande leur avis ^^. La vie est bien faite.

Maintenant, pour les développeurs qui publient sur npm, la leçon est limpide : Vérifiez votre .npmignore et votre champ files dans package.json. Ou plutôt, lancez la commande npm pack --dry-run dans votre terminal avant chaque publish. Ça prend 2 secondes et ça vous montre exactement ce qui sera inclus dans le paquet. Ça aurait évité 60 Mo de secrets industriels qui partent en public.

Bref, un .npmignore bien configuré, ça coûte 0 euro. Alors qu'une fuite de propriété intellectuelle évaluée à 2.5 milliards... un peu plus !

Source

Denuvo, la célèbre protection anti-piratage qui emmerde les joueurs PC depuis une décennie, traverse une sale période. Depuis début 2026, des pirates contournent la protection via des hyperviseurs, et les jeux protégés tombent désormais en quelques heures au lieu de plusieurs semaines : Resident Evil Requiem, Crimson Desert, Life is Strange: Reunion... tous craqués le jour de leur sortie ! Même Assassin's Creed Shadows, qui avait tenu 11 mois, a fini par tomber.

En fait, ces crackers ne s'embêtent plus à faire du reverse engineering sur les protections de Denuvo, ce qui leur prenait des mois. Ils ont monté un truc qui attaque sur 5 couches, du UEFI (Ring -2) jusqu'au processus du jeu (Ring 3). Un bootkit open source appelé EfiGuard désactive les protections au démarrage, puis un hyperviseur (SimpleSvm sur AMD, hyperkd sur Intel) prend le contrôle en Ring -1, sous le système d'exploitation. De là, il intercepte les CPUID, falsifie les structures mémoire Windows et triche sur les timings CPU pour que Denuvo croie que tout est normal. Un audit de sécurité indépendant publié sur GitHub n'a certes trouvé aucun malware dans le package, mais prévient que le système est laissé sans protection le temps que l'hyperviseur tourne.

Pour que ça fonctionne, il faut bien sûr désactiver des protections Windows assez critiques comme le VBS (Virtualization-Based Security), le HVCI (Hypervisor-Enforced Code Integrity) et la vérification de signature des driver, ce qui ouvre un peu trop grand le système, qui pourrait alors se voir installer un rootkit ou autre malware...

Et côté matériel, c'est la loterie car ça tourne plutôt bien sur AMD, mais les processeurs Intel posent des soucis de stabilité qui nécessitent des bidouilles franchement dangereuses. FitGirl, la repackeuse la plus connue de la scène, avait même d'abord refusé de toucher à ces cracks en déclarant qu'"aucun jeu ne vaut les dommages potentiels irrécupérables qu'il peut causer à l'ordinateur". Mais depuis, elle a changé d'avis après les améliorations apportées par KiriGiri et l'équipe MKDEV, et publie maintenant des repacks avec un tag "HYPERVISOR" bien visible. M'enfin bon, elle reste quand même prudente.

Irdeto, la boîte qui possède Denuvo, promet bien sûr une contre-mesure qui ne devrait pas ralentir les jeux. Les options sur la table sont : détecter la présence d'hyperviseurs tiers via les CPUID ou la latence CPU, ou imposer des vérifications de licence quotidiennes (ce qui emmerderait aussi les joueurs légitimes).

Et le pire dans tout ça, c'est que Denuvo a un impact mesurable sur les performances des jeux légitimes. Le blogueur Nathan Baggs et le développeur @valigo ont montré que la protection embarque une machine virtuelle qui compresse le code du jeu, bousille le cache processeur, perturbe le prédicteur de branchement et rajoute des instructions parasites. Cela veut dire concrètement que Ghostwire Tokyo mettait 200 secondes à démarrer avec Denuvo contre 54 sans, et Mass Effect Andromeda a gagné 12% de FPS quand la protection a été retirée.

Bref, c'est l'éternel jeu du chat et de la souris et Denuvo sait très qu'ils ne peuvent pas vaincre le piratage. Par contre, ils pouvaient jusqu'à présent maintenir une fenêtre de protection suffisante pour que les éditeurs récupèrent leur investissement sur les premières semaines de vente.

Mais avec ces bypasses hyperviseur, cette fenêtre vient de tomber à zéro. Gloups... Donc la vraie question maintenant, elle est surtout pour les joueurs légitimes : Est-ce que la prochaine "mise à jour de sécurité" de Denuvo va encore bouffer des performances sur leur machine pendant que les pirates jouent sans protection, sans ralentissement, et sans payer ?

On verra bien mais pour l'instant, la tendance des éditeurs c'est plutôt de lâcher les DRM car ils ont compris un truc que Denuvo refuse d'admettre : Avec ces conneries de DRM, ce sont toujours les clients honnêtes qui trinquent !

Source

Le fichier national qui recense toutes les armes détenues en France vient de se faire trouer en version XXL !

En effet, un affreux pirate a réussi à exfiltrer les données liées à la possession de plus de 62 000 armes, et parmi elles, les noms, prénoms, dates de naissance, adresses email et surtout les adresses postales de leurs propriétaires. Mais ce n'est pas tout puisque le fichier contiendrait également le détail complet de chaque arme (modèle, calibre, numéro de série, classement) ainsi que l'historique des transactions (ventes, cessions, réparations, destructions).

Donc on a maintenant dans la nature un joli tableur Excel avec en colonne A le numéro de série de votre Beretta, et en colonne B votre adresse.

J'vois vraiment pas ce qui pourrait mal tourner... 🤡

Alors pour ceux qui débarquent, le SIA (Système d'Information sur les Armes) c'est LA base de données du ministère de l'Intérieur dans laquelle tous les détenteurs d'armes doivent obligatoirement s'enregistrer. Que vous soyez chasseur avec votre Browning, tireur sportif avec votre Glock ou que vous ayez hérité du vieux Manufrance de papy, vous êtes dedans !!

Le ministère a d'ailleurs confirmé l'intrusion dans un courrier envoyé aux personnes concernées (environ 41 000 détenteurs selon les dernières estimations).

En fait, le cybercriminel a compromis les identifiants d'un armurier situé dans le département 84 (c'est le Vaucluse pour les nuls en géo) et a accédé à son Livre de Police Numérique (LPN), le registre dématérialisé qui liste toutes les transactions d'armes du professionnel et qui est directement interconnecté avec le SIA.

Les identifiants de l'armurier auraient pu être récupérés via du phishing, un logiciel espion ou même le vol d'un ordinateur... bref, les classiques, et cerise sur le gâteau, le pirate affirme même avoir été interrompu en pleine exfiltration, ce qui veut dire qu'il aurait pu aspirer encore plus de données s'il n'avait pas été coupé dans son élan.

Le ministère se veut rassurant (lol) en précisant que "le système d'information sur les armes n'a pas été atteint" directement. Mouais... techniquement c'est vrai, c'est le compte pro de l'armurier qui a sauté et pas le SIA en lui-même. Mais en vrai le résultat est le même pour les gens dont l'adresse postale se balade maintenant sur un forum du dark web.

Côté butin, le pirate revendique pas moins d'un listing de 62 511 armes se composant de 46% de carabines, 29% de fusils de chasse, 11% de fusils à pompe et 8% d'armes de poing, le tout allant de la catégorie B (soumise à autorisation) à la catégorie C (sur déclaration).

L'Union Française des amateurs d'Armes (UFA) tempère en rappelant que la base contient plusieurs millions d'armes, et que ces chiffres "tendent à faire penser que la fuite ne concerne pas l'ensemble du système". Heureusement les gars ! Après 41 000 détenteurs avec leurs adresses et le numéro de série de leurs joujoux dans la nature, c'est quand même pas rien non plus.

Et surtout c'est pas la première fois. C'est même la troisième fuite liée au milieu des armes en 6 mois. En octobre 2025, la Fédération Française de Tir (FFTir) s'était déjà fait trouer, puis en janvier 2026 c'était au tour de la Fédération Nationale des Chasseurs (FNC), et maintenant le SIA. Le trio gagnant !!

Les conséquences avaient d'ailleurs été très concrètes après la fuite FFTir puisque la préfecture de police avait alerté sur des repérages et prises de renseignement suspects signalés aux forces de l'ordre, avec des cambrioleurs qui débarquaient chez des tireurs sportifs pour récupérer leurs armes.

Le ministère a déposé plainte et notifié la CNIL et recommande de changer régulièrement de mot de passe et ne jamais communiquer ses identifiants. Merciiiii on n'y avait pas pensé ! Mais le plus beau c'est la mesure d'urgence annoncée en réaction car à partir du 1er avril 2026 (oui, demain), tous les professionnels devront activer la double authentification pour accéder à leur compte SIA. Oui, y'en n'avait pas... un simple identifiant + mot de passe suffisait pour accéder à une base qui gère les données de millions de détenteurs d'armes en France. Ça laisse rêveur.

Après, si vous êtes inscrit au SIA et que vous n'avez pas reçu le courrier du ministère, ça ne veut pas forcément dire que vous n'êtes pas touché alors dans le doute, méfiez-vous de tout appel ou visite prétendument officielle vous demandant de remettre ou montrer vos armes car la police, la gendarmerie et les douanes ne viendront jamais chez vous récupérer vos armes suite à une fuite de données. Donc si quelqu'un sonne à votre porte avec ce prétexte, c'est forcément une arnaque (ou pire...) comme ça s'est passé après la fuite FFTir.

Bref, entre le pistage permanent de nos données en ligne et toutes ces bases gouvernementales qui fuient comme des passoires , j'imagine que la prochaine étape, ça sera le vol et la diffusion du fichier des codes nucléaires mis à dispo sur un forum de script kiddies...

Source

Le groupe de hackers Handala, lié au gouvernement iranien, affirme avoir piraté le compte Gmail personnel de Kash Patel, le directeur du FBI. Des photos privées et plus de 300 emails ont été publiés en ligne.

Le FBI confirme l'incident mais assure qu'aucune donnée gouvernementale n'a été compromise. Une prime de 10 millions de dollars est offerte pour identifier les responsables.

Ce qui a été volé

Le groupe Handala a mis en ligne des photos de Kash Patel posant avec des cigares, au volant d'un cabriolet ancien ou encore à côté de voitures immatriculées à Cuba. Le groupe a aussi publié un échantillon de plus de 300 emails datés de 2010 à 2019, un mélange de correspondances personnelles et professionnelles.

Tous ces messages sont antérieurs à l'arrivée de Patel au sein de l'administration Trump. Le FBI a réagi rapidement en précisant que les données étaient anciennes et qu'aucune information gouvernementale n'était concernée. Le bureau fédéral propose d'ailleurs jusqu'à 10 millions de dollars de récompense pour toute information sur les hackers de Handala.

Handala ?

Le groupe se présente comme des hackers pro-palestiniens, mais les chercheurs occidentaux et le département de la Justice américain le considèrent comme une façade du renseignement iranien, rattachée au ministère du Renseignement et de la Sécurité.

Ces dernières semaines, Handala a aussi revendiqué le piratage de Stryker, un fabricant américain de matériel médical, et la publication des données personnelles de dizaines d'employés de Lockheed Martin basés au Moyen-Orient.

Le piratage du compte de Patel serait une riposte directe à la saisie par le FBI de plusieurs domaines web du groupe après l'attaque contre Stryker.

Un contexte géopolitique tendu

Cette cyberattaque arrive dans un climat de tensions extrêmes entre les États-Unis, Israël et l'Iran. L'objectif, selon les analystes, est d'embarrasser les responsables américains et de leur donner le sentiment d'être vulnérables.

Côté technique, le piratage ne concerne que le Gmail personnel de Patel, pas ses communications officielles. Google n'a pas répondu aux demandes de commentaires. Les métadonnées des fichiers volés indiquent que le piratage aurait eu lieu avant le début des frappes américano-israéliennes contre l'Iran.

Quoi qu'il en soit, le directeur du FBI qui se fait pirater sa boîte mail perso, ça fait un peu désordre. Après, il faut reconnaître que ce sont des emails vieux de plus de six ans et des photos de vacances, pas des secrets d'État de zinzins.

Handala cherche visiblement à faire du bruit plus qu'à obtenir des renseignements. Mais bon, quand on dirige le FBI, on s'attend quand même à ce que le compte Gmail soit un peu mieux verrouillé, non ?

Source : CNBC

Canonical vient de publier la bêta d'Ubuntu 26.04 LTS, nom de code Resolute Raccoon. Au menu de cette future version longue durée : le noyau Linux 7.0, GNOME 50, l'abandon pur et simple de X11 au profit de Wayland, et un bon lot de nouveautés côté sécurité avec chiffrement TPM, cryptographie post-quantique et même sudo réécrit en Rust. La version finale est attendue le 23 avril.

Ce qui change

Ubuntu 26.04 LTS embarque le noyau Linux 7.0, qui apporte la prise en charge des processeurs Intel Nova Lake, AMD Zen 6, et les premières bases pour les puces Qualcomm Snapdragon X2. Le pilote graphique Mesa passe en version 26.0.2, et les pilotes NVIDIA grimpent à la version 590.

Côté langages, on retrouve Python 3.14, GCC 15.2 et OpenJDK 25 par défaut. Et gros changement pour les développeurs : les dépôts AMD ROCm et NVIDIA CUDA sont désormais intégrés directement dans les sources officielles d'Ubuntu. Plus besoin d'aller les chercher à la main, ce qui devrait simplifier pas mal de configurations pour ceux qui bossent avec du GPU.

Wayland seul aux commandes

C'est la grosse rupture de cette version. Ubuntu 26.04 abandonne complètement la session X11 native. GNOME 50 ne la prend plus en charge, et Canonical a suivi le mouvement. Si vous avez des applications qui tournent encore sous X11, elles passeront par la couche de compatibilité XWayland, qui reste présente.

Mais le message est clair : X11, c'est terminé. GNOME 50 en profite pour ajouter le taux de rafraîchissement variable, la sauvegarde et restauration de session après un redémarrage, et un meilleur scaling des applications X11 héritées. Côté visuel, le thème Yaru a été retravaillé avec des icônes de dossiers colorées, un dock complètement opaque, une nouvelle animation de démarrage et un papier peint inédit.

Le lecteur vidéo Totem cède sa place à Showtime, le moniteur système est remplacé par Resources, et le visionneur PDF Evince laisse la main à Papers.

La sécurité passe un cap

Le chiffrement complet du disque via TPM sort enfin du statut expérimental. C'est désormais une fonctionnalité pleinement supportée, ce qui devrait rassurer ceux qui hésitaient à l'activer. La cryptographie post-quantique est activée par défaut sur SSH, avec l'algorithme hybride mlkem768x25519-sha256.

Et détail qui va plaire aux puristes : la commande sudo classique est remplacée par sudo-rs, une réécriture en Rust qui renforce la sécurité mémoire. Les paquets firmware, jusqu'à présent livrés en un seul gros bloc, sont maintenant découpés en 17 paquets spécifiques par constructeur, ce qui réduit la bande passante nécessaire pour les mises à jour.

Visiblement, Canonical a décidé de tout faire bouger d'un coup sur cette LTS. La fin de X11, le passage à GNOME 50, sudo en Rust, la crypto post-quantique par défaut, ça fait un gros paquet de changements pour une version censée rester stable pendant cinq ans.

On apprécie l'intégration directe de CUDA et ROCm dans les dépôts, parce que jusqu'à présent c'était une galère à configurer pour qui voulait faire tourner du machine learning sur Ubuntu. Le passage forcé à Wayland va probablement faire grincer des dents certains utilisateurs qui dépendent encore d'outils graphiques un peu anciens, mais bon, il fallait bien que ça arrive. La version finale est prévue le 23 avril, et le support court jusqu'en 2031, ou 2036 avec Ubuntu Pro. À voir si la bêta tient ses promesses d'ici là.

Source : Phoronix

Les fraudeurs n'ont plus besoin de vrais téléphones pour vider des comptes bancaires. Des smartphones virtuels hébergés dans le cloud, louables quelques centimes de l'heure, imitent sans problème de vrais appareils et passent sous le radar des systèmes anti-fraude.

Un smartphone qui n'existe pas

Group-IB vient de publier un rapport qui fait froid dans le dos. Des plateformes comme GeeLark, Redfinger ou LDCloud proposent de louer des smartphones Android virtuels hébergés dans des datacenters, pour 0,10 à 0,50 dollar de l'heure. À la base, ils sont prévus pour tester des apps ou gérer plusieurs comptes.

Sauf que les fraudeurs ont très vite compris l'intérêt du truc. Ces téléphones fantômes reproduisent tout ce qui fait un vrai smartphone : identifiant unique, adresse IP locale, géolocalisation crédible, et même des données de capteurs comme l'accéléromètre ou le gyroscope.

Votre banque croit parler à un iPhone à Paris. En réalité, c'est un serveur quelque part en Asie. Et le pire, c'est que ça marche. Les systèmes anti-fraude qui se basent sur l'empreinte de l'appareil n'y voient que du feu.

Revolut et Wise en vitrine sur le darknet

Là où ça devient concret, c'est quand on regarde ce qui se vend sur les forums criminels. Des comptes bancaires pré-vérifiés sur Revolut ou Wise, créés via ces cloud phones, s'échangent entre 50 et 200 dollars.

On parle de comptes mules utilisés pour recevoir et faire transiter de l'argent volé. Le tout à échelle industrielle. Côté chiffres, c'est vertigineux : 485 millions de livres de pertes liées à la fraude au Royaume-Uni en 2022.

Aux États-Unis, Deloitte projette 14,9 milliards de dollars d'ici 2028, contre 8,3 milliards en 2024. Et la France n'est pas épargnée, avec 618 millions d'euros de fraude bancaire au premier semestre 2025, en hausse de 7 % par rapport à 2024.

Comment les détecter ?

Group-IB a quand même identifié quelques indices. Un cloud phone n'a en général aucune application par défaut installée. Sa batterie reste bloquée à 100 %. Et surtout, les capteurs de mouvement ne bougent jamais, ce qui est impossible avec un vrai téléphone que quelqu'un tient dans la main.

Le problème, c'est que ces indices sont marginaux face à l'ampleur du phénomène. Les solutions proposées passent par de l'analyse comportementale, de la modélisation par graphes et une meilleure corrélation entre l'appareil et son environnement réseau.

Les banques vont devoir arrêter de se fier uniquement à l'empreinte du téléphone pour vérifier que vous êtes bien vous.

Le modèle de sécurité des banques basé sur l'identification de l'appareil est en train de prendre l'eau. Ces cloud phones sont en location libre, parfaitement légaux, et n'importe qui peut en louer un.

Et puis il faut le dire, les néobanques qui ont misé à fond sur la fluidité d'ouverture de compte se retrouvent avec le revers de la médaille. Quand ouvrir un compte prend deux minutes depuis un téléphone virtuel à 50 dollars, on imagine bien que les fraudeurs ne se privent pas.

Source : Info Security

Europol, Microsoft et plusieurs agences de six pays européens viennent de mettre hors service Tycoon 2FA, une plateforme de phishing vendue sur abonnement qui contournait la double authentification. 330 domaines ont été saisis, et le développeur principal a été identifié au Pakistan.

Une machine à phishing sur abonnement

Pour mieux vous poser le tableau, le Tycoon 2FA fonctionnait comme un service clé en main pour cybercriminels. Pour 120 dollars les dix jours ou 350 dollars par mois, n'importe qui pouvait accéder à un panneau de contrôle avec des pages de phishing prêtes à l'emploi, qui imitent les interfaces de connexion de Microsoft 365, Outlook, Gmail ou même SharePoint.

Le kit interceptait les sessions d'authentification en temps réel, ce qui permettait de contourner la double authentification sans que la victime ne se doute de quoi que ce soit. Depuis août 2023, la plateforme a généré des dizaines de millions de mails de phishing par mois. Microsoft estime en fait que Tycoon 2FA représentait à elle seule 62 % des tentatives de phishing bloquées mi-2025, c'est faramineux.

100 000 organisations touchées dans le monde

64 000 incidents de phishing ont été reliés à la plateforme, et près de 100 000 organisations ont été compromises à travers le monde, dont des hôpitaux, des écoles et des administrations publiques.

Les États-Unis arrivent en tête avec 179 000 victimes, suivis du Royaume-Uni, du Canada, de l'Inde et de la France avec 6 823 victimes identifiées. Si vous utilisez Microsoft 365 ou Outlook au quotidien, c'est le genre de kit qui ciblait directement vos identifiants. Le développeur principal, un certain Saad Fridi basé au Pakistan, a été identifié par Trend Micro dès novembre 2025 sous les pseudos "SaaadFridi" et "Mr_Xaad".

L'opération a mobilisé les polices de six pays (Lettonie, Lituanie, Portugal, Pologne, Espagne et Royaume-Uni) sous la coordination du Centre européen de lutte contre la cybercriminalité d'Europol.

330 domaines saisis d'un coup

Microsoft a mené la partie technique en neutralisant 330 domaines qui servaient de pages de phishing et de panneaux de contrôle. Cloudflare, Coinbase, Intel 471, Proofpoint, SpyCloud et Trend Micro ont aussi participé à l'opération. La plateforme n'a toujours pas donné lieu à des arrestations à ce stade. Le développeur a été identifié, mais aucune interpellation n'a été annoncée.

Le fait que des boîtes privées comme Microsoft et Trend Micro travaillent main dans la main avec Europol est interessant, et ça produit des résultats. Mais 330 domaines saisis sur une infra qui en générait de nouveaux toutes les 24 à 72 heures, on peut se demander combien de temps ça va tenir.

La France est le cinquième pays le plus touché avec presque 7 000 victimes, et quand on sait que le phishing représente 43 % des cyberattaques déclarées par les entreprises françaises, ça donne une idée de l'ampleur du problème.

On espère que cette opération servira d'exemple, mais d'autres plateformes du même genre sont probablement déjà en train de prendre le relais.

Sources : The Hacker News , Europol

J'avoue que faire tourner un agent IA en mode YOLO sur votre machine, y'a de quoi flipper un peu. Un mauvais prompt et hop, votre répertoire home part en fumée.

Mais heureusement, pour ça y'a Yolobox , un outil en Go qui fait tourner vos agents IA dans un conteneur Docker isolé. En gros, l'agent a les pleins pouvoirs dans son bac à sable par défaut comme ça, votre répertoire home reste intouchable. Claude Code, Codex, Gemini CLI, GitHub Copilot, tout est compatible, préconfiguré et prêt à l'emploi.

En fait avec Yolobox, seul votre dossier projet est monté en lecture-écriture avec le même chemin que sur votre machine et comme ça, l'agent bosse comme si de rien n'était. Sauf que tout le reste (vos clés SSH, vos credentials, vos photos de vacances à la plage naturiste et j'en passe...) est inaccessible depuis le conteneur. L'agent peut faire sudo, installer ce qu'il veut, déglinguer sa config... en fait RIEN ne s'échappe.

L'installation tient en une ligne :

brew install finbarr/tap/yolobox

Par contre, faut Docker Desktop qui tourne derrière, car sans ça, rien ne démarre. Ensuite c'est yolobox claude pour lancer Claude Code, yolobox codex pour Codex, yolobox gemini pour le CLI Google. Ou yolobox run suivi de n'importe quelle commande si vous avez un agent custom...

Côté sécu, y'a 4 niveaux qui vont du basique au parano. Le mode par défaut avec isolation conteneur standard. Un cran au-dessus avec --no-network et --readonly-project pour couper le réseau et passer le projet en lecture seule. Ensuite du Podman rootless. Et le niveau max avec isolation VM complète, parce que des fois faut pas déconner. Ça supporte aussi le runtime Apple Container pour ceux qui veulent rester full macOS.

Et les outils de dev sont déjà embarqués dans l'image : Node.js 22, Python 3, Go, Bun, ripgrep, fzf, jq... Les volumes persistants gardent également vos installations entre les sessions, donc pas besoin de tout réinstaller à chaque lancement.

Attention quand même, ça ne marche pas contre un escape de conteneur délibéré car hé, Docker reste Docker. Mais si vous utilisez Claude Code en mode autonome et que vous faites du vibe coding, c'est le minimum vital pour éviter qu'un agent aille fouiller là où il faut pas .

Bref, allez voir ça et merci à Lorenper pour le partage !