rsync vient de sortir sa version 3.4.3, un correctif censé boucher plusieurs trous de sécurité. Sauf que pour une partie des utilisateurs, leurs sauvegardes incrémentales se sont mises à mal fonctionner juste après la mise à jour.

En fouillant le code, certains ont remarqué un détail qui ne leur a pas plu. Depuis la version 3.4.1, des dizaines de modifications (des "commits", les unités de changement de code) sont signées "tridge and claude". Comprendre Andrew Tridgell, le créateur historique de rsync, et Claude, l'assistant IA d'Anthropic, le concurrent direct d'OpenAI.

Pour situer, rsync est un outil de synchronisation et de sauvegarde de fichiers qui tourne sur les serveurs Unix et Linux depuis les années 90. Une brique discrète mais utilisée par d'innombrables entreprises, hébergeurs et services informatiques. Quand il déraille, ce sont des sauvegardes entières qui sautent.

D'où la réaction épidermique. Sur GitHub, la plateforme où vit le code source, quelqu'un a ouvert un message au titre sans équivoque, "Please Do Not Vibe Fuck Up This Software". En clair, prière de ne pas bousiller ce logiciel à coups de "vibe coding", cette mode qui consiste à confier des bouts de code à une IA et à faire confiance au résultat sans trop vérifier.

Tridgell a reconnu les régressions. Elles touchent surtout des configurations bien précises, le mode serveur avec l'option chroot désactivée, qu'il décrit comme des "cas d'usage valides mais inhabituels" que la suite de tests du projet ne couvrait tout simplement pas.

Sauf que voilà, il refuse l'étiquette du développeur qui aurait bâclé. "Je n'ai pas juste vibe-codé la conversion de la suite de tests en Python. Je suis un ingénieur logiciel avec 40 ans d'expérience", a-t-il écrit dans un billet intitulé "rsync and outrage".

Concrètement, l'IA a surtout servi à réécrire la vieille batterie de tests, jusque-là en scripts shell, vers le langage Python, pour pouvoir mieux vérifier la sécurité du code. Un travail de fond fastidieux.

Tridgell affirme avoir conçu lui-même l'architecture du nouveau système, utilisé Claude mais aussi Codex d'OpenAI et Gemini de Google pour abattre le gros du débroussaillage répétitif, puis relu et validé chaque ligne produite à la main.

Et il n'a aucune intention d'arrêter. Une version 3.4.4 pourrait corriger les régressions, à moins qu'il ne passe directement à la 3.5, plus ambitieuse côté sécurité. Avec les mêmes outils IA.

Au passage, il rappelle un truc que les mainteneurs de logiciels libres vivent au quotidien, ils croulent sous les signalements de failles de sécurité, dont une bonne partie sont eux-mêmes pondus par des IA. L'IA crée la charge et propose dans la foulée de la résorber.

Source : The Register

Il existe une catégorie d'objets qu'on achète sur un coup de tête, qu'on déballe avec enthousiasme, et qu'on range au fond d'un tiroir une demi-heure plus tard parce qu'ils sont tout bonnement inutilisables. La GB Boy de Sharopolis appartenait pile à cette catégorie. Commandée sur AliExpress il y a des années, puis oubliée.

Le principe de cette console portable est pourtant séduisant sur le papier, puisqu'elle reprend le design d'une Game Boy Pocket tout en acceptant les vraies cartouches d'origine, celles-là mêmes que vous avez peut-être encore dans une boîte à chaussures, au lieu de se contenter d'une puce bourrée de jeux pré-installés comme le font la plupart des clones chinois. Le fabricant, lui, répond au nom de Gangfeng.

Branchez un petit boîtier dans la prise de diagnostic de votre voiture, et celle-ci se met à remonter son niveau de carburant, sa température moteur ou la pression de ses pneus directement dans votre système domotique, au même titre qu'une ampoule connectée ou un thermostat.

C'est la démonstration faite par un vidéaste connu sous le nom de The Stock Pot, repérée par Maya Posch sur Hackaday. L'idée, c'est de faire dialoguer une auto avec Home Assistant, le logiciel open source qui centralise tous les objets connectés d'une maison.

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

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

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

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

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

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

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

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

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

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

Source : Phoronix

Sur Linux, faire passer une vidéo trafiquée pour un vrai flux de webcam dans Zoom ou Discord, ça se fait depuis longtemps. Le souci, c'est que la méthode classique demande de taper des commandes assez obscures dans un terminal. Webcamoid propose de tout faire plus simplement.

Une webcam virtuelle, c'est une fausse caméra logicielle. Votre système et vos applis la voient comme une vraie webcam branchée en USB, sauf qu'à l'autre bout il n'y a aucun capteur : juste une vidéo que vous avez choisie, modifiée ou carrément bricolée avant de l'envoyer.

Webcamoid, c'est justement une application gratuite et open source écrite par l'Argentin Gonzalo Pedone, qui tourne aussi bien sur Linux que sur Mac, Windows, Android ou FreeBSD. Elle se place entre le petit visualiseur de webcam basique et les usines à gaz comme OBS Studio, le logiciel star du streaming.

Le principe est simple. Vous choisissez votre vraie caméra comme source, vous appliquez les effets que vous voulez parmi la soixantaine proposée, puis vous envoyez le résultat vers une caméra virtuelle. Les autres logiciels n'y voient que du feu.

À quoi ça sert concrètement ? À flouter ou remplacer votre arrière-plan pendant une visio, plaquer un filtre sur votre tête, ou carrément diffuser une vidéo enregistrée à l'avance pendant que vous êtes parti faire un café. Webcamoid sait d'ailleurs prendre comme source autre chose qu'une caméra : un fichier vidéo posé sur votre disque, un flux réseau, ou même une capture de votre écran.

Pour créer cette fausse caméra, deux pilotes sont possibles, un pilote étant le bout de logiciel qui fait le pont entre le matériel et le système. D'un côté v4l2loopback, qui marche en ligne de commande avec un modprobe et trois options. De l'autre AkVCam, plus carré, qui se configure via des fichiers et que Webcamoid préfère utiliser.

Bref, un outil qui pourrait bien vous servir de temps en temps, même si l'installation et la mise en route n'est pas toujours très fluide, comme ça a été raconté chez nos confrères de Hackaday.

Source :  Hackaday , Webcamoid

Emily Velasco , bricoleuse et artiste américaine, a fabriqué une carte électronique fonctionnelle à partir d'un simple disque d'argile tourné à la main, sans la moindre plaque de fibre de verre ni le moindre bain d'acide qu'on associe d'habitude à ce genre d'objet.

L'idée vient d'ailleurs. Elle raconte avoir été inspirée par un collectif de hackeuses européennes qui fabriquait ses propres circuits à partir d'argile creusée dans le sol et cuite dans un feu de camp, et comme elle développait déjà depuis un moment ses propres émaux au cuivre pour la poterie, elle a décidé de pousser l'expérience un cran plus loin.

Un bidouilleur connu sous le pseudo ThatCrazyDcGuy a réussi à rendre sa radio CB entièrement pilotable depuis une simple page web, et la prouesse tient surtout à ce qu'il y soit parvenu sans pratiquement ouvrir l'appareil ni modifier le moindre composant d'origine de la machine.

L'engin en question est une Albrecht AE-5900 Mini SSB, une petite radio européenne de la fameuse Citizens Band, cette bande publique située autour de 27 MHz que les routiers et les passionnés utilisent depuis des décennies pour discuter librement, sans licence ni abonnement, et que ce modèle exploite jusqu'à 12 watts en mode SSB tout en affichant la fréquence et le niveau de signal sur un écran couleur.

Le point de départ du projet repose sur une particularité assez sympa du boîtier, puisque l'AE-5900 a la bonne idée de pouvoir être entièrement commandé depuis son micro d'origine, le AMM-500, lequel dialogue avec la radio en lui transmettant des codes en hexadécimal sur une banale liaison série, exactement comme deux puces qui s'échangeraient des instructions.

Plutôt que de toucher au circuit, ThatCrazyDcGuy s'est donc inséré pile au milieu de cette conversation entre le micro et la radio, en concevant un montage qui se fait passer pour le AMM-500 et rejoue les bonnes commandes au bon moment, si bien que l'électronique d'origine ne se rend compte de rien et continue d'obéir comme si tout était normal.

Côté matériel, l'ensemble reste étonnamment sobre, puisqu'un adaptateur FTDI, cette petite puce chargée de traduire l'USB en liaison série, gère toute la partie contrôle pendant qu'une carte son USB équipée de transformateurs d'isolation s'occupe de l'audio, le tout étant regroupé derrière un connecteur RJ45 et soudé sur une plaque à pastilles glissée dans un boîtier minuscule.

Le rôle de cerveau revient quant à lui à un Raspberry Pi, ce mini-ordinateur grand comme une carte bancaire, sur lequel tourne un script écrit en Python et reposant sur le framework Flask, qui se charge à lui seul de générer l'intégralité de l'interface web consultée par l'utilisateur.

Cette interface n'a d'ailleurs rien d'un gadget puisqu'elle expose le bouton PTT (le push-to-talk, c'est-à-dire la pédale qu'on presse pour parler), le déclenchement à la voix, le balayage des canaux à vitesse réglable, ainsi que le squelch, le clarifier et le réglage du volume du micro, alors que la voix elle-même transite par Mumble, un logiciel de voix sur IP capable de transporter le son en temps réel, ce qu'une page web seule serait bien incapable de faire.

Le système prévoit même un garde-fou plutôt rassurant, car en cas de coupure de la connexion un coupe-circuit interrompt automatiquement l'émission au bout de trente secondes, histoire d'éviter qu'une radio reste bloquée à émettre toute seule dans le vide pendant des heures sans que personne ne s'en aperçoive.

Pour piloter le poste depuis l'autre bout du pays et plus seulement sur le réseau local de la maison, le projet s'appuie enfin sur Tailscale, un outil qui tisse un réseau privé chiffré entre les différentes machines sans qu'on ait à reconfigurer sa box (que j'utilise d'ailleurs au quotidien), l'ensemble du code est disponible publiquement sur GitHub sous le nom AE5900_Remote_V2.

Ce qui est sympa dans cette réalisation, c'est justement qu'elle ne charcute rien du tout, sans conversion de bande hasardeuse ni fer à souder plongé dans les entrailles de l'émetteur, l'auteur se contentant de parler le même langage que le micro pour, dit-il, redonner un peu d'attrait à une CB que le smartphone a depuis longtemps reléguée au placard.

Franchement, piloter une radio de l'âge des routiers depuis un onglet de navigateur, c'est quand même bien rigolo.

Source : Hackaday , GitHub

Il y a des failles qui réclament un arsenal de hacker chevronné, et puis il y a HTTP/2 Bomb, qui se contente de quelques kilo-octets pour faire vaciller des serveurs parmi les plus utilisés de la planète. Dévoilée le 2 juin sous la référence CVE-2026-49975, elle s'attaque à HTTP/2, le protocole qui transporte une bonne partie des pages que vous consultez chaque jour.

Le résultat ressemble à une mauvaise blague. Une poignée d'octets envoyés au bon endroit, et la mémoire vive du serveur se met à enfler jusqu'à engloutir des dizaines de gigaoctets en quelques secondes, jusqu'à ce que la machine ne réponde plus à personne.

On parle ici d'une attaque par déni de service, un DoS dans le jargon, dont le but n'est pas de dérober quoi que ce soit mais d'asphyxier le serveur. Rien de bien neuf, donc, sauf que l'ampleur du désastre, elle, l'est totalement.

Toute l'astuce tient dans le mariage de deux mécanismes connus depuis des lustres. HTTP/2 sait compresser les en-têtes des requêtes pour éviter de répéter cent fois la même chose, et c'est précisément cette générosité que l'attaquant retourne contre le serveur, en faisant référence des milliers de fois à un en-tête glissé une seule fois, si bien que la machine réserve de la mémoire à tour de bras pour quelque chose qui, au départ, ne pèse presque rien. C'est le principe de la bombe de décompression, ce fichier piégé minuscule qui se déplie en montagne de données dès qu'on l'ouvre.

Et comme si ça ne suffisait pas, l'attaquant fait mine de ne pas pouvoir recevoir la réponse, ce qui interdit au serveur de boucler sa tâche et de relâcher ce qu'il a accumulé. Quelques octets envoyés de loin en loin, et la connexion reste ouverte indéfiniment. C'est diabolique de simplicité.

Les chiffres, eux, font carrément peur. Sur Envoy, les chercheurs ont mesuré un rapport de plus de 5 000 pour 1, avec 32 Go engloutis en une dizaine de secondes, là où Apache craque en moins de vingt secondes et nginx comme IIS en moins d'une minute. Une simple connexion domestique à 100 Mb/s peut donc mettre à genoux une infrastructure entière.

Le plus déroutant dans cette histoire, c'est que les deux ingrédients de la recette traînaient en accès libre depuis des années. Il aura fallu attendre l'équipe de Codex, et le chercheur Quang Luong, pour avoir l'idée de les mélanger et constater les dégâts.

Du côté des correctifs, tout le monde n'est pas logé à la même enseigne. nginx a réagi avec sa version 1.29.8 et une nouvelle option pour brider les en-têtes, Apache a corrigé dans mod_http2 2.0.41, mais Microsoft IIS, Envoy et Cloudflare Pingora attendaient encore leur rustine au moment de la divulgation.

Bref, vieille recette, ingrédients connus, mais cocktail dévastateur. Si vous gérez un serveur en HTTP/2, allez vérifier vos versions avant qu'on ne teste la recette à votre place.

Source : The Hacker News

À sa conférence Build 2026, le 2 juin, l'éditeur a lancé Coreutils for Windows, un paquet qui amène directement dans Windows les commandes de base bien connues des utilisateurs de Linux.

On parle des classiques du terminal, ls pour lister des fichiers, cp pour copier, mv pour déplacer, grep pour chercher du texte, ou encore cat, find et rm. Au total, près de 75 petites commandes que tout bidouilleur tape machinalement sans même y penser.

Au passage, une petite précision historique s'impose (et merci à MG pour le rappel) : si on les appelle par habitude des « commandes Linux », ces classiques sont en réalité bien plus vieux que ça. ls, cp, cat et compagnie viennent d'Unix, le système né au tout début des années 70 dans les labos de Bell, soit une bonne vingtaine d'années avant que Linux ne débarque en 1991. On les retrouve d'ailleurs dans à peu près toutes les versions d'Unix, de Solaris aux BSD jusqu'à macOS, et Linux n'a fait qu'hériter de ce patrimoine. Donc « commandes Unix » serait techniquement plus juste, mais bon, on se comprend.

Le but affiché est simple. Les développeurs jonglent en permanence entre Windows, macOS et Linux, et s'agacent quand une commande qui marche d'un côté refuse obstinément de fonctionner de l'autre. L'idée, ici, c'est de pouvoir réutiliser les mêmes commandes et les mêmes scripts partout, sans rien réécrire.

Le plus intéressant, c'est ce qu'il y a sous le capot. Et là, surprise. Coreutils for Windows ne réinvente rien, puisqu'il s'appuie sur uutils, un projet communautaire qui réécrit les fameux coreutils de GNU en Rust, un langage réputé pour éviter toute une famille de bugs mémoire.

Autrement dit, Microsoft reprend un travail open source mené par la communauté, l'empaquette proprement et le maintient sous son nom. Le tout s'installe en une seule ligne via WinGet, le gestionnaire de paquets maison de Windows, avec un simple winget install Microsoft.Coreutils.

Côté technique, l'astuce est plutôt élégante. Plutôt que de livrer un exécutable par commande, Microsoft fournit un unique programme, coreutils.exe, et crée à l'installation une série de raccourcis (ls.exe, cp.exe, grep.exe et les autres) qui pointent tous vers lui. Selon le nom que vous tapez, ce programme sait quelle casquette enfiler. Malin.

Tout n'a pas fait le voyage, cela dit. Des commandes comme chmod, chown ou kill restent sur le carreau, faute d'équivalent propre sous Windows, qui ne gère pas les permissions de fichiers à la manière d'Unix.

Ce n'est d'ailleurs pas un geste isolé. Depuis des années, Microsoft a glissé un vrai noyau Linux dans Windows avec WSL, ouvert le code de pans entiers de ses outils et multiplié les passerelles avec l'écosystème open source. Coreutils for Windows s'inscrit dans cette continuité, et confirme que l'éditeur a définitivement enterré la hache de guerre.

Reste que pour quiconque vit dans un terminal et passe ses journées entre WSL, la couche Linux intégrée à Windows, et l'invite de commandes classique, c'est un vrai confort au quotidien. Et voir Microsoft s'appuyer ouvertement sur du logiciel libre écrit en Rust, on n'aurait pas forcément parié là-dessus il y a dix ans.

Bref, le Microsoft qui détestait Linux est bel et bien mort, et c'est tant mieux pour ceux qui codent les deux pieds dans le terminal.

Source : Bleeping Computer

Si vous avez un Zenbook récent avec cet écran miniature encastré dans le couvercle, vous étiez jusqu'ici coincé sous Windows pour l'allumer. Un développeur vient de débloquer la situation.

Olivier Magnier a fait fonctionner le ZenVision d'ASUS sous Linux, en rétro-concevant de A à Z le protocole de communication que le constructeur n'avait jamais documenté publiquement.

Le ZenVision, pour situer, c'est un petit écran OLED monochrome de 3,5 pouces logé dans la coque supérieure de certains Zenbook, dont l'édition Space. Il affiche l'heure, la date, le niveau de batterie, des animations maison ou un message que vous y collez vous-même.

La définition est minuscule. 256 pixels sur 64, de quoi montrer un logo, une horloge ou un QR code, mais certainement pas une vidéo.

Le souci, c'est que tout passait par MyASUS, l'application du constructeur qui n'existe que sous Windows. Sur Linux, l'écran restait éteint alors que le matériel, lui, était bel et bien présent dans la machine.

Pour contourner ça, Magnier a ouvert le logiciel officiel d'ASUS dans Ghidra, un outil de rétro-ingénierie qui décompile un programme pour comprendre son fonctionnement interne, puis il a observé précisément quelles commandes l'application envoyait à l'écran via le port USB.

En clair, il a écouté la conversation entre l'ordinateur et la dalle pour en reconstituer le langage. Une fois ce protocole compris et documenté, le plus dur était fait.

Du coup, il a écrit un pilote (le bout de logiciel qui fait le lien entre le système et le matériel) en Python, publié sous licence MIT , donc librement réutilisable et modifiable par qui veut. À côté, il propose ZenVision-Studio , une application pour charger ses propres animations et même des applets en direct, ces mini-programmes qui affichent des informations animées.

Et comme tout tourne en espace utilisateur, l'adoption devient bien plus simple : pas besoin de toucher au noyau Linux ni de recompiler quoi que ce soit, ça fonctionne par-dessus le système comme un programme classique.

C'est typiquement le genre de bidouille qui rend Linux vivable sur du matériel pensé pour Windows, et qui fait souvent pencher la balance entre garder un double démarrage et basculer pour de bon.

Bref, un gadget purement cosmétique, mais récupéré proprement et offert à tout le monde en open source. C'est chouette.

Source : Phoronix

Un développeur a réussi à contrôler un ordinateur sous Linux sans clavier, sans souris et sans écran, uniquement en tapant du morse sur un bouton et en lisant les réponses clignotées par une petite diode lumineuse.

La machine, c'est la LuckFox Lyra, un ordinateur monocarte vendu autour de 15 dollars, avec 128 Mo de mémoire et un gabarit grand comme une clé USB un peu épaisse, qui fait pourtant tourner un vrai système Linux complet.

L'idée de départ tenait en une contrainte que s'est imposée Gabriel Broussard Korr, son créateur, à savoir piloter cette carte sans jamais y brancher le moindre périphérique, ni clavier, ni dalle, ni rien.

Ce qui a tout déclenché, c'est sa simplicité matérielle. La carte n'a qu'un bouton, celui de démarrage, et une diode pilotable par logiciel. De quoi faire entrer et sortir de l'information, sans rien ajouter.

Côté saisie, vous tapotez vos commandes en morse sur l'unique bouton. Une pression brève pour un point, une pression longue pour un trait, et un script traduit tout ça en commandes pour le shell, l'invite en ligne de commande de Linux.

Pour les réponses, la diode reprend la main. Elle vous renvoie le résultat en clignotant, toujours en morse. Un dialogue complet avec la machine qui passe par une seule LED, dans les deux sens.

Le tout tient dans un script baptisé Morstdio , écrit pour rester compatible avec à peu près n'importe quel système de la famille Unix. Rien de plus.

Sauf que le morse classique ne suffisait pas. L'alphabet d'origine gère les lettres et les chiffres, pas tous les symboles dont un terminal a besoin, comme les barres obliques ou les parenthèses. Korr a donc inventé son "morse pour programmeurs", avec des traits très longs pour marquer les espaces et trois durées différentes à distinguer afin d'éviter toute ambiguïté.

Il a même soigné le confort d'usage, ce qui est franchement inattendu vu le concept. On retrouve des commandes inspirées de l'éditeur de texte vim, une pour exécuter une ligne, une autre pour effacer la saisie, et un re-clignotement qui vous laisse relire ce que vous venez d'entrer avant de valider.

Le plus dingue arrive à la fin. Il a fait tourner llama.cpp, le logiciel qui exécute un modèle d'IA en local, avec un petit modèle Qwen directement sur la carte. Il obtient ce qu'il présente comme le plus petit chatbot autonome du monde, capable de vous répondre en morse à la diode, au rythme d'environ un mot par minute.

Autant dire qu'à cette vitesse, échanger trois phrases avec l'engin relève déjà de l'exploit de patience.

Bref, c'est totalement inutile, et c'est génial.

Source : Hackaday

Un bricoleur connu sous le nom de Startup Chuck a eu une idée que personne ne lui avait demandée : fabriquer des cookies de A à Z avec son imprimante 3D. Pas seulement les façonner. Les cuire aussi, dans la machine. Le tout documenté dans une vidéo YouTube, évidemment.

Tout commence par l'attirail. Chuck a imprimé en plastique l'ensemble du matériel du pâtissier, comme s'il montait une vraie petite chaîne de production de biscuits.

Et il ne fait pas semblant. Il parle carrément d'une production sérieuse de cookies, avec de quoi tout faire de la première à la dernière étape sans sortir un seul ustensile de cuisine du commerce.

J'ai reçu et testé pendant quelques jours la nouvelle série FineTrack 2.0 d'UGREEN, trois petits traceurs d'objets pensés pour ne plus jamais perdre ses clés, son sac ou son vélo.

Premier truc qui saute aux yeux, aucun des trois ne ressemble à un AirTag. Et c'est tant mieux. Le galet blanc d'Apple, un voleur ou un curieux le repère en une seconde, alors qu'ici on passe beaucoup plus inaperçu. Discrétion, donc.

La gamme compte trois modèles. Le FineTrack Mini 2, un carré ultra-compact de 36 millimètres de côté pour 10,7 d'épaisseur, livré avec une coque en silicone et un porte-clés. Le FineTrack 2, une boule de 34 millimètres avec sa petite dragonne déjà fixée. Et le FineTrack Duo, au format carré.

Les deux premiers embarquent une batterie ni rechargeable ni remplaçable, donnée pour 5 à 7 ans. Impossible évidemment de vérifier une durée pareille en quelques jours, mais sur le principe, ça change tout.

Parce qu'avec une batterie qui tient cinq à sept ans, vous pouvez carrément planquer le traceur et l'oublier. Dans une voiture, sous la selle d'un vélo, dans une valise, sur n'importe quel objet dont vous ne voulez plus vous soucier, sans jamais penser à le recharger. Le jour où la batterie rendra l'âme, dans plusieurs années, vous changerez simplement de traceur. Alors certes c'est du jetable, mais 5 à 7 ans, c'est large…

On se dit forcément qu'avec une batterie rechargeable ils auraient été un peu plus gros, ou moins endurants. Mais bref, à ce niveau d'autonomie, la question ne se pose même plus.

Les deux partagent la même fiche : certification officielle Apple Find My (le réseau Localiser d'Apple, qui se sert des iPhone des autres passants pour retrouver vos affaires), un haut-parleur de 110 décibels pour les faire hurler même enfouis au fond d'un sac, une étanchéité IP68 qui encaisse la poussière comme l'immersion, et des petites notes fluorescentes pour les repérer dans le noir.

Mon préféré, c'est clairement la boule de type ballon de foot, le FineTrack 2. Avec sa dragonne, elle fait un porte-clés vraiment chouette, et je la verrais bien aussi accrochée au sac ou au manteau d'un enfant pour garder un œil dessus.

Si vous tenez à la recharge, le troisième modèle est fait pour ça. Le FineTrack Duo se recharge en USB-C, annonce environ 12 mois d'autonomie pour deux heures de charge, et surtout il fonctionne aussi bien sur iOS que sur Android grâce à sa double compatibilité Apple Find My et Google Find Hub, l'équivalent côté Google. L'idéal pour un foyer où cohabitent iPhone et téléphones Android. Son haut-parleur tape un peu moins fort, 80 décibels, et il embarque une certification de sécurité enfants contre l'ingestion.

Bref, trois traceurs intéressants, discrets et bien finis. Je recommande.

• Lot de 4 FineTrack Mini 2, autonomie de 5 à 7 ans, pour 40 euros les 4 (actuellement en promo à 28,50 euros les 4, autant dire que c'est donné).
• Lot de 4 FineTrack Duo, compatibles iOS et Android, à moins de 35 euros les 4.
• FineTrack 2 "Ballon" à 15 euros au lieu de 20 euros, lui aussi avec une autonomie de 5 à 7 ans.

Un affilié du gang Nova, spécialisé dans les rançongiciels (ces logiciels qui chiffrent vos fichiers pour vous réclamer une rançon), a commis la bourde qui restera probablement dans les annales du milieu. Il a verrouillé les serveurs d'Eriell, une grosse société de forage pétrolier dont le siège se trouve en Ouzbékistan et qui garde un bureau à Moscou.

Le souci, c'est la géographie. L'Ouzbékistan fait partie de la CEI, la Communauté des États indépendants, en gros l'ensemble des anciennes républiques soviétiques. Et dans ce métier, on ne s'attaque pas à la CEI. Jamais.

"La première règle du club des rançongiciels, c'est qu'on n'attaque pas les organisations de la CEI, et elle est manifestement toujours valable en 2026", résume Allan Liska, analyste chez Recorded Future, une société spécialisée dans le renseignement sur les cybermenaces.

Eriell n'est pas une PME de quartier. C'est un acteur du forage qui travaille pour le secteur pétrolier et gazier de la région, et son nom avait bien été ajouté fin mai à la liste des victimes publiée sur le site du gang, avant le rétropédalage.

Cette règle n'a rien d'une question de politesse entre voyous. Les groupes qui opèrent depuis la Russie et les ex-républiques soviétiques sont tranquilles tant qu'ils dirigent leurs attaques vers l'Occident, mais le jour où ils s'en prennent à une cible locale, ils risquent de réveiller des autorités qui, jusque-là, fermaient les yeux. Pas d'extradition vers les États-Unis, pas d'ennuis, à condition de rester dans les clous.

En temps normal, le tri se fait tout seul. Une partie de ces logiciels vérifie la langue du clavier avant de s'installer, et s'ils détectent du cyrillique, ils s'effacent d'eux-mêmes plutôt que de risquer une cible russophone. L'astuce est tellement connue que des chercheurs en sécurité conseillent, à moitié sérieusement, d'installer un clavier russe sur sa machine pour passer sous le radar de ces logiciels. Là, le garde-fou a visiblement sauté.

Plus drôle encore, c'est Eriell qui a contacté Nova pour signaler l'erreur. Le gang, connu jusqu'à récemment sous le nom de RALord, fonctionne comme une franchise: les développeurs louent leur logiciel à des "affiliés" qui mènent les attaques sur le terrain et partagent ensuite le butin. Le reste du temps, Nova frappe sans état d'âme des cibles un peu partout dans le monde.

Et la suite vaut le détour. Nova a publié des excuses officielles, promis d'aider Eriell à tout remettre en état gratuitement, assuré qu'aucun fichier n'avait été chiffré et juré qu'aucune des données volées ne fuiterait. Quant à l'affilié maladroit, il a tout simplement été banni de l'opération.

Des cybercriminels qui dégainent des excuses publiques et un service après-vente, on ne voit pas ça tous les jours.

Source : The Register

Microsoft a présenté le 2 juin, pendant sa conférence développeurs Build 2026, une version expérimentale de son terminal baptisée Intelligent Terminal 0.1, un logiciel open source publié sous licence MIT qui intègre directement des assistants IA dans la fenêtre où l'on tape des commandes.

Pour situer le truc si vous êtes vraiment très noob, le terminal c'est cette interface en texte que les développeurs et les administrateurs système utilisent au quotidien pour lancer des commandes, compiler du code ou piloter un serveur à distance. Microsoft propose déjà Windows Terminal depuis des années, et Intelligent Terminal en est une déclinaison distincte, pas un remplacement.

L'élément central, c'est l'agent pane, un panneau ancré sur le côté de la fenêtre qui joue le rôle de copilote. Il lit en permanence ce qui s'affiche dans votre terminal, et quand une commande échoue, il détecte l'erreur et vous propose une explication ou un correctif.

Vous pouvez choisir de recevoir une simple notification dans la barre d'état, ou laisser l'assistant appliquer directement ses corrections selon la configuration que vous avez définie.

Il y a aussi une astuce intégrée à la palette de commandes : tapez un point d'interrogation suivi de votre demande, et l'outil lance une tâche en arrière-plan dans un onglet dédié, sans bloquer la session en cours. Pratique quand on veut déléguer une opération longue sans interrompre son travail.

Côté assistants, Microsoft a fait un choix ouvert. Par défaut, c'est GitHub Copilot CLI, l'assistant maison qui fonctionne en ligne de commande. Mais Intelligent Terminal accepte n'importe quel agent compatible avec l'Agent Client Protocol (ACP), une norme qui permet à différents assistants IA de venir se brancher sur le même outil.

Vous pouvez donc passer par Claude Code, l'assistant de codage signé Anthropic, le concurrent d'OpenAI, ou par Codex, l'équivalent maison d'OpenAI, à la place de la solution de Microsoft. C'est suffisamment rare chez l'éditeur de Windows pour être signalé.

Le logiciel s'installe depuis le Microsoft Store ou via la commande winget install Microsoft.IntelligentTerminal, et il se pose à côté de Windows Terminal sans le remplacer. Microsoft précise que si vous ne voulez pas d'IA dans votre terminal habituel, rien ne change pour vous.

Il y a quand même un détail qui coince, et c'est Phoronix, le site spécialisé dans l'actualité Linux, qui le relève : malgré son code ouvert publié sous licence MIT, Intelligent Terminal ne tourne pour le moment que sous Windows.

On parle aussi d'une version 0.1 estampillée expérimentale, ce qui annonce des bugs et des changements à venir avant une éventuelle version stable.

Bref, un terminal open source qui laisse l'utilisateur choisir son IA au lieu d'imposer la sienne, c'est un geste plutôt bien pensé de la part de Microsoft.

Source : Phoronix

Tout se joue dans une conversation polie avec l'assistant IA du support de Meta, le robot conversationnel censé dépanner les utilisateurs quand ils ont un souci avec leur compte.

Le principe tient en quelques étapes. Le pirate se connecte d'abord via un VPN, un outil qui maquille sa localisation, pour faire croire qu'il se trouve dans la ville de sa victime et ne pas déclencher les protections automatiques d'Instagram.

Ensuite, il ouvre une discussion avec le Meta AI Support Assistant et lui demande tout bonnement d'ajouter une nouvelle adresse e-mail au compte ciblé.

Le robot envoie alors un code de vérification vers l'adresse fournie par le pirate. Celui-ci renvoie le code au chatbot, qui affiche aussitôt un bouton pour réinitialiser le mot de passe. Nouveau mot de passe, et le compte change de mains.

Le plus dingue, c'est qu'à aucun moment l'attaquant n'a eu besoin de toucher à la vraie boîte mail de la victime. Pas de phishing élaboré, pas de faux site à monter, pas de malware à glisser. Le support officiel faisait tout le travail à sa place.

Côté victimes, ça pique. Le compte de la Maison-Blanche de l'ère Obama, inactif depuis 2017, celui du sergent-chef de l'US Space Force John Bentivegna, ou encore celui de la chercheuse en sécurité Jane Wong, qui a raconté s'être fait voler le sien. S'ajoutent plusieurs comptes aux pseudos très courts, ceux qui se revendent cher au marché noir, dont la valeur cumulée dépasserait le demi-million de dollars.

L'attaque a été mise en scène dans une vidéo de démonstration, publiée fin mai sur Telegram par un groupe de pirates pro-iraniens, avec un mode d'emploi qui a tranquillement circulé sur plusieurs canaux.

Heureusement, il y a un garde-fou. L'exploit ne marche pas contre les comptes protégés par une authentification à deux facteurs, ce deuxième code demandé en plus du mot de passe, souvent reçu par SMS. Même la version la plus basique de cette protection suffisait à bloquer les pirates net.

Chez Meta, le porte-parole Andy Stone affirme que le problème est réglé et que les comptes touchés sont en train d'être sécurisés. Un correctif d'urgence a été déployé , et l'entreprise précise qu'aucune base de données interne n'a été piratée. Le trou était dans le chatbot, pas dans les serveurs.

Reste le fond du problème. Pour Ian Goldin, chercheur en cybersécurité chez Black Lotus Labs, ces assistants IA ouvrent une toute nouvelle surface d'attaque, et on va sûrement en voir beaucoup d'autres du même genre dans les mois qui viennent.

Bref, un chatbot conçu pour rendre service qui finit par surtout servir les pirates, c'est le genre de bug qu'on n'avait pas avec un bon vieux formulaire.

Source : ARS Technica

Neuf failles de sécurité viennent d'être corrigées d'un coup sur le serveur X.Org, le vieux logiciel qui dessine les fenêtres, gère la souris et le clavier sur une grande partie des machines Linux. Et le plus marquant, c'est qui les a trouvées.

Huit des neuf ont été repérées par une intelligence artificielle. Plus précisément par TrendAI, l'outil maison du programme de chasse aux bugs de l'éditeur de sécurité Trend Micro, la Zero Day Initiative, qui rémunère depuis des années la découverte de failles. La neuvième, elle, a été dénichée à l'ancienne par Peter Hutterer, un développeur de Red Hat qui travaille sur la gestion clavier et souris de X.Org depuis bien longtemps.

Dans le lot, on retrouve surtout deux familles de problèmes bien connues. Des dépassements de mémoire tampon d'abord, où le programme écrit plus de données que prévu dans une case mémoire et le surplus déborde sur le code voisin. Et des "use-after-free" ensuite.

Ce dernier type est vicieux : le logiciel continue d'utiliser un bout de mémoire qu'il a pourtant déjà rendu au système, ce qui permet à un attaquant de glisser son propre code à la place. Trois des neuf failles tombent dans cette catégorie, planquées dans le composant qui synchronise l'affichage.

Le reste touche un peu partout : la gestion du clavier, les alias de polices, la couche graphique 3D, l'économiseur d'écran et le sous-système qui parle directement à la carte graphique, autant de morceaux qu'un programme malveillant déjà présent sur la machine pourrait détourner pour s'octroyer plus de droits que prévu ou aller lire de la mémoire qui ne le regarde pas.

Les correctifs sont déjà là. X.Org a sorti du coup les versions 21.1.23 du serveur et 24.1.12 de XWayland, la passerelle qui fait tourner les vieilles applications X.Org sur les bureaux Wayland modernes. Si vous êtes sur Linux, la mise à jour s'impose.

Côté historique, ça fait plus de dix ans que la sécurité de X.Org traîne une sale réputation. Un chercheur avait résumé l'affaire d'une formule restée célèbre : c'est pire que ça en a l'air. Le code est vieux, tentaculaire, et personne n'a vraiment envie de le réécrire.

Ce qui change cette fois, c'est la méthode. Lâcher une IA sur une base de code aussi ancienne, c'est un peu comme passer un détecteur de métaux sur une plage que personne n'a jamais ratissée : elle remonte des objets que plus personne n'avait le courage d'aller chercher à la main. Et X.Org n'est pas un cas isolé, le noyau Linux voit lui aussi défiler les failles à bon rythme.

Bref, si les IA se mettent à éplucher tout le vieux code de l'open-source, on n'a pas fini d'en voir passer cet été. Tant mieux qu'elles soient dans notre camp.

Source : Phoronix

Du code piégé glissé dans des paquets signés Red Hat, et téléchargé environ 80 000 fois par semaine. C'est le bilan d'une attaque repérée le 1er juin.

Pour bien saisir, il faut d'abord savoir ce qu'est npm. C'est l'immense bibliothèque où les développeurs JavaScript piochent des briques de code toutes prêtes plutôt que de tout réécrire. Des millions de projets en dépendent au quotidien.

Et c'est exactement là qu'un malware s'est faufilé. Plusieurs dizaines de paquets publiés sous le nom de Red Hat (l'éditeur du système Linux du même nom, racheté par IBM) ont été infectés par un ver, c'est-à-dire un logiciel malveillant capable de se propager tout seul d'une machine à l'autre.

Le ver s'appelle "Miasma", une variante du tristement célèbre Shai-Hulud, du nom des vers géants du film Dune. Cette fois les pirates ont troqué les clins d'œil à Dune contre de la mythologie grecque, mais le principe ne change pas.

Son fonctionnement est vicieux. Le code malveillant se déclenche via un "preinstall hook", un petit script qui s'exécute automatiquement dès qu'on installe le paquet, avant même que le développeur n'ait touché à la moindre ligne. Pas besoin d'ouvrir quoi que ce soit, l'infection est immédiate.

Une fois en place, il fait les poches de la machine. Clés d'accès aux clouds d'Amazon, Google et Microsoft, jetons Kubernetes et Vault, clés SSH, tokens npm... bref, tout ce qui permet de se connecter ailleurs et de continuer à se répandre.

Et c'est tout l'intérêt d'un ver pour un pirate. Avec un jeton npm volé, le malware peut republier d'autres paquets vérolés au nom de leurs vrais propriétaires, qui contamineront à leur tour de nouvelles machines. La chaîne s'auto-alimente.

D'après les chercheurs de Wiz (la filiale sécurité de Google) et de Socket, qui ont levé le lièvre, le tout remonte au compte GitHub piraté d'un employé de Red Hat. Socket a compté de son côté une trentaine de paquets touchés et près d'une centaine de versions vérolées. Les paquets ont été publiés via la chaîne de production automatisée de l'entreprise, pas via un simple mot de passe volé, ce qui rend l'attaque encore plus difficile à repérer.

Red Hat a réagi vite et retiré les paquets de npm. La boîte précise que ce code n'a jamais été destiné à ses clients et qu'il s'agissait d'outils internes, sans impact connu sur ses systèmes en production.

Le coupable, lui, est encore inconnu. Le groupe TeamPCP avait publié le code source de ce ver en accès libre, du coup impossible de dire si ce sont eux ou un imitateur qui sont derrière l'attaque.

Ce qui est fou, c'est moins cette attaque que sa facilité de copie. Hélas, des vers open source qui se dupliquent, on n'a clairement pas fini d'en voir passer.

Source : The Register

Molly Lynch, de l'université Hollins, et Michael Weselcouch, du Roanoke College, deux profs de maths américains, ont eu une idée que personne n'avait osé tenter : estimer la valeur de Pi en lâchant des monstres dans Minecraft, sans programmer quoi que ce soit, juste en exploitant les règles du jeu.

Tout part d'une vieille technique de probabilités appelée méthode de Monte-Carlo, qu'on surnomme aussi la méthode des fléchettes. Imaginez un carré avec un cercle dessiné dedans, qui touche les bords. Vous lancez des fléchettes au hasard sur le carré. La proportion de fléchettes qui tombent dans le cercle, comparée au total, vaut environ Pi divisé par quatre. Vous multipliez par quatre, et vous obtenez une approximation de Pi.

Sauf qu'ici, pas de fléchettes. Les fléchettes, ce sont les slimes, ces créatures cubiques et gélatineuses de Minecraft qui se baladent au hasard, même quand aucun joueur ne les regarde.

Le duo a construit un cercle avec des blocs rouges, d'un rayon de 11 blocs, le tout enfermé dans un carré de blocs bleus. Au sol, des entonnoirs (des "hoppers" dans le jeu) récupèrent automatiquement tout ce qui tombe.

Ensuite, il a fallu un bourreau. Ce rôle revient aux zoglins, des bestioles programmées pour attaquer les slimes à vue. Chaque fois qu'un zoglin tue un slime à l'intérieur du cercle rouge, l'objet lâché par la victime atterrit dans les entonnoirs.

Il suffit alors de comparer le nombre d'objets récoltés dans le cercle au nombre total d'objets récoltés partout. Ce rapport, multiplié par quatre, donne Pi. Les monstres font tout le boulot, et le hasard de leurs déplacements remplace le générateur aléatoire d'un ordinateur.

Sur un essai, 619 slimes ont été tués, dont 508 à l'intérieur du cercle. Quatre fois 508 sur 619, ça donne environ 3,283. La vraie valeur de Pi tourne autour de 3,14159, donc on est encore loin du compte.

Mais c'est normal. La méthode de Monte-Carlo devient plus précise quand on multiplie les tirages. Pour s'approcher du vrai Pi, il faudrait agrandir le cercle et envoyer beaucoup plus de slimes au massacre. C'est lent, c'est inefficace, et ça n'a jamais été le but.

Le but, c'est de montrer les maths autrement. Lynch et Weselcouch visent les jeunes, ceux qui décrochent devant une formule au tableau mais qui passent leurs soirées sur Minecraft. Là, d'un coup, une notion abstraite vue en cours devient un truc qu'on peut regarder fonctionner sous ses yeux.

Franchement, calculer Pi en regardant des monstres s'entretuer dans un cube, c'est la plus belle excuse que j'aie vue pour rester devant un jeu vidéo.

Source : Techspot