Et si vous pouviez renommer n'importe quel lieu sur la carte du monde ?

Genre, transformer "Paris" en "Pain au Chocolat City" ou "Bordeaux" en "Chocolatine Land" ? Hé bien c'est exactement ce que propose Rename World , et y'a déjà plus de 40 000 renommages au compteur.

Le principe est hyper simple : vous cliquez sur un nom de lieu, vous proposez un nouveau nom, et la communauté vote. Les meilleures propositions restent, les autres disparaissent dans l'oubli. Y'a pas besoin de créer un compte pour explorer la carte, c'est ouvert à tout le monde et c'est dispo en français !

J'ai d'abord cru que ça allait être un festival de noms vulgaires et de spam... mais en fait non. Le créateur (qui se fait appeler kafk) a mis en place un filtre de mots plus un dashboard d'administration qui lui permet de dégager les trolls en quelques clics. Sur les 40 000+ propositions, le spam reste donc marginal et la majorité des renommages sont soit créatifs, soit du jeu de mots inoffensif. Après évidemment, si quelqu'un challenge votre proposition, faudra convaincre la communauté de voter pour vous.

Je vous présente Clermont-Ferrand ^^ :

Mais le site ne s'arrête pas au simple renommage. Y'a aussi un mode Name Duel où deux propositions s'affrontent en face à face, un Quiz pour tester vos connaissances géo, et un Leaderboard pour les plus prolifiques. Du coup c'est devenu un vrai petit jeu communautaire.

Il y a également un bouton "Hide NZ" qui permet de supprimer carrément la Nouvelle-Zélande de la cartographie mondiale. Si vous traînez un peu sur r/MapsWithoutNZ, vous comprendrez la référence. Et un bouton "Show NZ" pour les gens bien, évidemment.

Côté technique, kafk a préféré utiliser des PMTiles (40 Go stockées chez Cloudflare) plutôt que des tuiles raster classiques, ce qui rend la navigation bien plus fluide. Le rendu vectoriel s'appuie comme d'hab sur OpenStreetMap et tourne sur le serveur d'un de ses potes équipé de 256 Go de RAM (oui, on a les amis qu'on mérite ^^). Attention par contre, si vous cherchez à renommer un endroit précis (genre votre village de consanguins) et que le libellé ne s'affiche pas, faudra jouer avec le niveau de zoom car c'est du vectoriel, les étiquettes géographiques apparaissent à des échelles différentes.

Si vous avez déjà perdu des heures sur des cartes interactives de Westeros , attendez de voir ce qui se passe quand Internet a le droit de renommer le monde réel. Perso, j'ai cherché ce que les gens avaient fait de ma ville... et j'ai pas été déçu. Y'a aussi un Discord pour la communauté si vous voulez proposer des idées ou signaler des soucis.

Bref, allez-y, renommez votre bled, la préfecture de votre département, et bon courage à kafk pour la modération !

Ah et merci à AV pour l'info !

Vous vous souvenez d'eMule ? Le petit âne qui monopolisait votre connexion ADSL pendant 3 jours pour télécharger un fichier de 700 Mo... et les fameux "Linux_ISO.avi" qui n'étaient absolument pas des ISOs Linux ?

Eh bien le bougre est de retour sur macOS. macMule c'est eMule packagé en .app native, compatible Apple Silicon via Rosetta 2, zéro configuration. Vous glissez dans Applications, vous lancez, et hop ça se connecte tout seul aux serveurs ed2k et au réseau Kad. Hé oui, ça tourne encore en 2026.

Côté technique, l'app fait environ 1 Go parce qu'elle embarque Wine Crossover (la couche de compatibilité Windows par Gcenx). Le développeur Martin Derouet a pris le build Community x64 d'eMule par irwir, l'a wrappé dans un bundle .app self-contained, et comme ça, ça se lance comme n'importe quelle app Mac.

Y'a pas de dépendances externes à installer, et surtout pas de terminal à ouvrir. Les fichiers téléchargés atterrissent alors dans ~/Library/Application Support/macMule/drive_c/eMule/Incoming/... c'est pas super intuitif comme chemin, mais au moins c'est rangé.

D'ailleurs, si vous avez suivi l'actualité de Wine 10.0 et le support ARM , vous savez que la couche de compatibilité Windows n'a jamais été aussi solide. macMule en profite directement. Et si vous voulez compiler votre propre build, le script est dispo : ./build.sh pour la dernière version stable ou ./build.sh 0.70b pour une version spécifique. Faut juste avoir Homebrew avec wine-crossover et Rosetta 2 installés.

J'ai été surpris que les réseaux ed2k et Kad soient encore debout. Mais c'est cool car ces réseaux hébergent des fichiers qu'on ne trouve nulle part ailleurs. Des archives oubliées, des vieux logiciels, des trucs que personne n'a jamais re-uploadé nulle part. C'est un peu le grenier d'Internet, poussiéreux mais plein de trésors pour qui sait chercher et plein de malwares aussi, alors gaffe à vous !

Attention quand même, ça reste un client P2P pour le réseau ed2k donc les précautions habituelles s'appliquent. Vérifiez ce que vous téléchargez, et n'oubliez pas que l'Arcom (ex-Hadopi) veille toujours au grain.

Bref, si vous avez la nostalgie du petit âne et que vous êtes sur Mac, c'est par là !

Merci à Martin pour la découverte !

Le noyau Linux 7.1 devrait supprimer la possibilité de compiler un noyau pour les processeurs Intel 486. C'est la première fois depuis 2012 qu'une architecture processeur est retirée du noyau, et le minimum requis passera du 486 au Pentium. L'Intel 486 a 37 ans.

Un processeur de 1989

L'Intel 486 est sorti en 1989. C'est le processeur qui a fait passer les PC de la ligne de commande au monde graphique, et il a été vendu pendant une bonne partie des années 90.

Le 486SX, sa version sans coprocesseur mathématique, et l'AMD Elan, une variante embarquée, sont aussi concernés par cette suppression. Le patch a été proposé par Ingo Molnar, un des développeurs historiques du noyau Linux.

La dernière fois que Linux a retiré le support d'une architecture processeur, c'était en 2012, quand le 80386 avait été abandonné. Ca fait donc 14 ans que personne n'avait touché à ce genre de nettoyage.

Du ménage dans le code

Le patch supprime trois options de configuration du noyau : M486, M486SX et MELAN. Sans ces options, il ne sera plus possible de compiler un noyau Linux spécifiquement pour un 486. Le processeur minimum deviendra le Pentium, qui supporte les instructions TSC et CMPXCHG8B, deux fonctions que le 486 ne gère pas.

Molnar explique que le code de compatibilité pour ces vieux processeurs pose régulièrement des problèmes et demande du temps de maintenance que les développeurs préfèrent consacrer à autre chose. Linus Torvalds avait d'ailleurs déclaré dès 2022 que les processeurs 486 n'étaient plus utilisés que comme pièces de musée.

Et le 32 bits, alors ?

Le retrait du 486 ne veut pas dire que Linux abandonne le 32 bits. Le noyau continue de supporter les architectures 32 bits, et il y a encore suffisamment de processeurs Atom et de systèmes embarqués 32 bits en circulation pour que ça reste le cas un moment.

Mais la tendance est claire : l'avenir de Linux sur x86 est en 64 bits, et le code 32 bits finira par suivre le même chemin que le 486.

Aucune distribution Linux récente ne proposait de toute façon un noyau compilé pour 486. Les utilisateurs qui font tourner Linux sur ce type de matériel pourront continuer avec des noyaux plus anciens.

Ca concerne très peu de monde en pratique, mais c'est quand même un petit moment d'histoire informatique. Le 486 a été le premier vrai processeur grand public chez Intel, et le voir disparaître du noyau Linux après 37 ans de bons et loyaux services, ça fait quelque chose.

En tout cas les développeurs du noyau semblent soulagés de pouvoir enfin faire le ménage. Pour la petite histoire, mon premier PC était un 386 SX25, et je suis ensuite passé directement au Pentium 60 (celui qui avait le bug de la virgule flottante), je trouve ça dingue qu'avec tous les ordinateurs que j'ai eu chez moi, je n'ai jamais eu de 486 !

Source : Phoronix

Si vous avez déjà installé Nextcloud sur un serveur, vous savez que c'est pas une partie de plaisir ! La stack PHP + MySQL, les mises à jour qui cassent tout, les performances qui s'effondrent dès que vous dépassez 50 utilisateurs... Relouuu.

Mais c'est là qu' OpenCloud débarque avec une approche radicalement différente puisque tout est écrit en Go, y'a zéro base de données, et l'installation se fait en deux commandes sur n'importe quel serveur à 5 balles par mois.

OpenCloud, en fait, c'est un fork d'ownCloud Infinite Scale (OCIS). Les développeurs du projet original chez Heinlein Group ont quitté ownCloud, forké le code, et relancé le tout sous licence Apache 2.0. Du coup, c'est pas un projet qui part de zéro mais une réécriture déjà très mature qui tourne en prod.

Là où Nextcloud utilise une base MySQL ou PostgreSQL pour stocker les métadonnées, OpenCloud balance donc tout dans le système de fichiers. Pas de SGBD ce qui veut dire pas de migration de base à gérer ni de tables corrompues après un crash. Tout atterrit dans le dossier $HOME/.opencloud/ et c'est réglé. Donc si vous savez faire un rsync, vous savez aussi faire une sauvegarde complète de votre instance. Oui la vie est belle !

Côté fonctionnalités, on retrouve donc le partage de fichiers, la collaboration en temps réel avec une suite bureautique intégrée, le chiffrement, le versioning (pratique contre les ransomwares), l'authentification via OpenID Connect... bref tout le classique d'un cloud privé correct.

Maintenant, le problème je trouve, c'est que l'écosystème d'apps est pas forcément au niveau de Nextcloud. Le CalDAV/CardDAV passe par Radicale en conteneur séparé (pas intégré au core), y'a pas d'app Notes ni de client mail intégré. Donc si vous avez besoin de tout ça, Nextcloud reste le bon choix. Mais bon, pour du stockage et de la collaboration pure, c'est clairement plus léger (genre 200 Mo de RAM au lieu de 2 Go pour Nextcloud) et surtout plus rapide.

D'ailleurs, l'architecture microservices en Go fait que ça scale nettement mieux.

Maintenant, pour installer ça, le plus simple c'est Docker Compose. Le repo opencloud-compose vous propose même des configs prêtes à l'emploi. À vrai dire, si vous êtes du genre à auto-héberger vos services , c'est un candidat sérieux pour remplacer votre Nextcloud donc si vous avez surtout besoin de fichiers et de collaboration, ça vaut le test. D'ailleurs, comme OpenCloud utilise OIDC pour l'auth, Pocket ID s'intègre pile poil avec pour du SSO sans mot de passe. Je dis ça, je dis rien ^^.

Bref, si Nextcloud vous gonfle avec sa lourdeur PHP et ses 47 tables MySQL, OpenCloud mérite un bon petit coup d'oeil !

Merci à fredix pour le lien !

Le système de distribution d'applications Linux vient de publier la version 1.16.4, qui corrige quatre failles de sécurité découvertes dans son mécanisme de bac à sable.

La plus critique permettait à une app de sortir de son environnement isolé pour accéder à tous les fichiers de la machine et y exécuter du code. Le Steam Deck et la plupart des grandes distributions sont concernés.

Quatre failles, dont une critique

Flatpak, c'est le format de distribution d'applications qui s'est imposé sur Linux ces dernières années. Son principe : chaque application tourne dans un bac à sable isolé du reste du système, un peu comme sur iOS. C'est aussi le format utilisé par le Steam Deck de Valve pour installer des applications en mode bureau.

La version 1.16.4, publiée le 7 avril, corrige quatre failles de sécurité. La plus grave, référencée CVE-2026-34078, est une vraie mauvaise surprise : une application pouvait exploiter des liens symboliques dans les options d'exposition du portail Flatpak pour accéder à l'intégralité des fichiers de la machine hôte, et même y exécuter du code.

Des fichiers supprimés et des téléchargements détournés

La deuxième faille (CVE-2026-34079) permettait de supprimer des fichiers sur la machine hôte en passant par un bug dans le cache du chargeur dynamique ld.so. Flatpak supprimait les fichiers de cache obsolètes sans vérifier que le chemin fourni par l'application pointait bien vers le bon répertoire.

Deux autres problèmes ont aussi été corrigés : l'un permettait de lire des fichiers via le service système de Flatpak, l'autre de perturber le téléchargement d'une application lancé par un autre utilisateur, sans possibilité de l'arrêter proprement.

Qui doit mettre à jour

Toutes les distributions Linux qui utilisent Flatpak sont concernées, et c'est un paquet de monde : Fedora, Ubuntu, Linux Mint, SteamOS sur le Steam Deck, et bien d'autres.

La mise à jour vers la version 1.16.4 est disponible, ou le sera très vite, via les canaux habituels de chaque distribution. Si vous utilisez un Steam Deck en mode bureau avec des apps Flatpak installées via Discover, la mise à jour devrait arriver automatiquement.

C'est quand même un comble : un système conçu pour isoler les applications qui laisse une porte grande ouverte vers tout le système. Que Flatpak se fasse prendre en défaut sur son coeur de métier, ça fait un peu désordre.

Bon par contre, la réactivité a été bonne : la faille a été identifiée et corrigée, et les détails n'ont été publiés qu'avec le correctif disponible. C'est la base, mais au moins c'est fait.

Source : Phoronix

Si votre coeur bat, sachez que la CIA peut vous retrouver n'importe où !

C'est pas moi qui le dis, c'est John Ratcliffe, le directeur de la CIA en personne, qui l'a annoncé ce lundi 7 avril après que ses équipes aient utilisé un outil baptisé Ghost Murmur pour localiser un membre d'équipage américain abattu en Iran, à 65 kilomètres de distance, en captant juste les battements de son coeur.

On dirait vraiment de la SF mais je vais tout vous expliquer.

L'officier des systèmes d'armes d'un F-15E Strike Eagle (oui c'est son titre officiel), nom de code "Dude 44 Bravo", s'est éjecté de son appareil et a du se planquer dans une crevasse en plein désert montagneux du sud de l'Iran, avec les forces iraniennes qui le cherchaient trèèèès activement. Durant 2 jours, le gars a survécu en terrain hostile et c'est là que la CIA a décidé de dégainer Ghost Murmur pour la toute première fois en conditions réelles.

Et la techno est vraiment dingue ! Le système utilise de la magnétométrie quantique, c'est-à-dire des capteurs construits autour de défauts microscopiques dans des diamants synthétiques et ces capteurs sont capables de détecter la signature électromagnétique des battements cardiaques... C'est un signal normalement tellement faible qu'on ne peut le mesurer qu'à l'hôpital, avec des capteurs collés sur la peau.

Hé bien Ghost Murmur capte ce signal à des dizaines de kilomètres en utilisant l'IA pour isoler un seul battement de cœur du bruit ambiant. Comme l'a dit un officiel du gouvernement américain, "c'est comme entendre une voix dans un stade, sauf que le stade fait 2 500 km²" !

Et devinez qui est derrière tout ça... Lockheed Martin et sa division Skunk Works , ceux là même qui ont pondu le SR-71, le F-117, et à peu près tous les trucs volants classifiés du Pentagone. Le système a été testé à bord d'hélicoptères Black Hawk et pourrait finalement être adapté pour les F-35. Et son nom n'est pas choisi au hasard : "Murmur" c'est le terme clinique pour un souffle au coeur, et "Ghost" parce que la cible est invisible... sauf pour eux.

Bon, après faut relativiser quand même. Le plus gros problème c'est que ce bidule fonctionne surtout en zone déserte, là où y'a quasi zéro interférence électromagnétique. Donc si vous êtes le seul être vivant dans un rayon de 100 bornes, ça marchera du tonnerre de Zeus mais par contre, en plein centre-ville avec des milliers de cœurs qui font boum boum au mètre carré, ça ne marchera pas aussi bien. Et surtout, ça demande un temps de traitement conséquent car on n'est clairement pas du temps réel. Mais le jour où ça miniaturise assez pour tenir dans un drone civil... là, même un randonneur en forêt devient traçable.

Xavier Dupont de Ligonnès, t'es dans la merde ! ^^

D'abord y'a donc eu les IMSI-Catchers pour intercepter nos communications mobiles puis les capteurs quantiques chinois pour traquer les sous-marins . Et maintenant on localise un humain à son battement de cœur... hé bé... Et pour votre culture G sachez que c'est la même famille de capteurs NV-diamond que l'armée US développe pour détecter à distance tout ce qui est explosifs improvisés.

Donc la question maintenant n'est plus "est-ce qu'on peut vous trouver ?" mais "est-ce qu'on le veut vraiment ?".

Voilà c'est foutu pour vous planquer dans le Larzac... Vous pouvez passer votre téléphone en mode avion autant que vous voudrez, votre cœur lui pourra toujours vous trahir... ^^

Source

Anthropic vient de lâcher une bombe !

Le labo derrière Claude a dévoilé le Projet Glasswing , une initiative de cybersécurité qui embarque un nouveau modèle, Claude Mythos, tellement efficace pour trouver des failles qu'ils ont décidé de ne pas le rendre public. En gros, l'IA est devenue meilleure que la plupart des humains pour dénicher des vulnérabilités zero-day... et ça va faire mal ^^.

Concrètement, Mythos a trouvé des milliers de zero-days dans tous les OS et navigateurs majeurs ces dernières semaines. Et pas des failles mineures, hein ! Une vulnérabilité dans OpenBSD qui traînait depuis 27 ans, un bug dans FFmpeg vieux de 16 ans qui avait survécu à 5 millions d'itérations de tests automatisés... et des exploits chaînés dans le noyau Linux (3, 4, parfois 5 vulnérabilités enchaînées de manière autonome) qui permettent une escalade de privilèges complète. Comme le dit un chercheur dans la vidéo de présentation : "J'ai trouvé plus de bugs ces dernières semaines que pendant tout le reste de ma carrière combinée".

Retrouver un vieil article sur korben.info, c'est pas toujours simple. La home s'arrête à 5 pages (site statique oblige) et après, fallait se débrouiller avec les catégories ou le moteur de recherche. Alors pour vous faciliter un peu la vie, je vous ai mis à dispo des pages d'archives accessibles via le footer.

Ainsi, vous scrollez en bas de n'importe quelle page, vous cliquez sur "Archives" ou sur une année, et vous tombez sur un index chronologique complet. Chaque mois est listé avec tous ses jours, et pour chaque jour, un petit nombre entre parenthèses vous indique combien d'articles ont été publiés ce jour-là. Vous cliquez, vous avez tout.

C'est vrai qu'avec plus de 19 000 articles publiés depuis août 2004, soit 22 ans de blog, autant dire que les catégories seules, c'était un peu l'aiguille dans la botte de foin ! Vous verrez d'ailleurs que le rythme varie pas mal... certains jours y'a 1 seul article, d'autres y'a carrément 25 (genre mars 2026, c'était dense).

Ma meilleure année c'était 2008 avec 1668 articles ! Suivi de 2011 avec 1487 articles, 2012 avec 1410 article et plus récemment 2025 avec 1318 articles. C'est pour ça que quand je poste à peine 5 articles par jours et que les commentateurs habituels chouinent à base de "Sans IA tu pourrais jamais faire ça c'est pas possible humainement", je rigole fort ^^

Par contre attention, y'a pas de recherche par mot-clé sur cette page mais pour ça y'a toujours le champ de recherche du site .

Bref, c'est dans le footer. Allez fouiller !

Un passionné a tenté de récupérer son Pokémon coincé dans un Pokéwalker, ce petit podomètre vendu avec Pokémon HeartGold sur DS en 2009, après avoir perdu la cartouche de jeu.

Entre reverse engineering du protocole infrarouge et manipulation du générateur de nombres aléatoires, la tentative est bien technique. Et le résultat est plutôt cruel, pour une raison que personne n'avait anticipée…

Un Pokémon sans cartouche, un vrai problème

Le Pokéwalker, pour ceux qui ne s'en souviennent pas, c'était ce petit podomètre vendu avec Pokémon HeartGold et SoulSilver sur Nintendo DS en 2009. Le principe était simple : vous transfériez un Pokémon de votre partie vers cet accessoire, vous le glissiez dans votre poche, et chaque pas comptait pour gagner des points et débloquer des objets.

Des chats en pixel art qui se baladent sur votre dock macOS et qui causent grâce à un LLM local... non vous ne rêvez pas car c'est ce qu'on peut obtenir avec CATAI , qui vous fera adopter 6 matous virtuels avec chacun sa personnalité.

En gros, c'est le Tamagotchi de votre dock, sauf qu'au lieu de biper quand il a faim, il vous cite du Nietzsche. Vous lancez l'app, et hop, un chat orange débarque. Il marche, il mange, il dort, il s'énerve... soit 368 sprites dessinés à la main (c'est devenu assez rare pour le souligner !!). Et quand le dock est masqué, le chat se téléporte directement sur le bord supérieur de votre fenêtre active. Parce que vous le savez, un chat, ça squatte toujours les rebords les plus improbables.

Vous pouvez en coller jusqu'à 6 en même temps, chacun avec sa couleur et son caractère. Le noir (Ombre) est philosophe et vous pose des questions existentielles, le blanc (Neige) s'exprime en vers, le gris (Einstein) vous balance des faits scientifiques et le brun (Indiana) raconte des aventures. De temps en temps, ils miaulent tout seuls dans des bulles pixel art. "Mrrp !", "Prrr...", "ronronronron". Perso, je trouve ça craquant.

Et quand vous cliquez sur un chat, ça ouvre une bulle de discussion connectée à Ollama (le moteur d'IA locale que vous connaissez sûrement). Si vous avez déjà un modèle qui tourne, votre matou vous répond alors avec sa propre personnalité. La mémoire de conversation est même persistante entre les sessions (max 20 messages par chat, pour garder un contexte de conversation raisonnable).

Comme c'est du Swift pur, juste les Command Line Tools suffisent pour compiler le fichier source :

swiftc -O -o cat cat.swift -framework AppKit -framework Foundation

Un vidéaste scientifique vient de reproduire des expériences de physique quantique depuis chez lui, avec un simple détecteur gamma portable et une capsule radioactive récupérée dans un vieux détecteur de fumée. Et les résultats sont plutôt convaincants.

De la physique quantique dans un garage

Huygens Optics, une chaîne YouTube spécialisée dans l'optique et la physique, s'est attaqué à une question qui occupe les physiciens depuis plus d'un siècle : la lumière est-elle une onde ou une particule ? Pour tenter d'y répondre, pas besoin d'un accélérateur de particules ou d'un labo à plusieurs millions d'euros.

Le vidéaste a utilisé un Radiacode 110, un petit détecteur de rayons gamma qui tient dans la main (67 grammes, connecté en Bluetooth à un smartphone), une capsule d'américium-241 extraite d'un détecteur de fumée hors service, un boîtier en plomb coulé maison et un Arduino pour mesurer les impulsions. Le tout pour quelques centaines d'euros.

49 jours, les amis, c'est la durée de vie d'un Mac avant que son réseau TCP ne s'effondre dans un silence assourdissant. Il suffit d'un overflow d'entier 32 bits dans le kernel XNU, une horloge interne qui se bloque, et hop, plus moyen d'ouvrir la moindre connexion. Le ping marche toujours, parce qu'ICMP se fout du TCP, mais pour le reste... c'est reboot obligatoire ou rien.

Pour savoir combien de temps il vous reste, tapez uptime dans le Terminal. Si votre Mac sous macOS Sequoia, Sonoma ou même Ventura tourne depuis plus de 7 semaines sans redémarrage, c'est le moment d'y remédier car le bug touche toutes les versions.

C'est l'équipe de Photon qui a révélé le problème. Celui-ci est apparu sur une flotte de Macs dédiée à la télémétrie iMessage. Pile 49,7 jours après le dernier redémarrage, plusieurs machines ont lâché en même temps. Plus de nouvelles connexions réseau, mais le ping répondait toujours.

En fouillant le code du noyau XNU d'Apple (qui est open source, faut le rappeler), ils sont tombé sur une variable tcp_now, qui est un compteur 32 bits qui s'incrémente chaque milliseconde. En gros, imaginez un compteur kilométrique qui arrivé au max (environ 4,3 milliards), repasse à zéro.

Sauf que le code contient un garde fou censé empêcher l'horloge de reculer du genre "si la nouvelle valeur est plus petite que l'ancienne, on ne met pas à jour". Ça a l'air malin mais en fait, au moment du rebouclage, patatras : la nouvelle valeur (proche de zéro) est forcément plus petite que l'ancienne (proche du max), du coup le garde fou bloque tout et l'horloge TCP se fige.

Et ensuite, ça part en cascade. Les connexions fermées restent normalement en TIME_WAIT durant 30 secondes sur macOS, avant d'être nettoyées par tcp_gc() mais avec l'horloge gelée, ce nettoyage ne se fait plus. Un netstat -an | grep TIME_WAIT montre alors la catastrophe en temps réel avec des connexions mortes qui s'empilent, et finissent par bouffer les 16 384 ports éphémères (range 49152-65535 sur macOS) restant... Et au bout de quelques heures, plus rien ne passe !

Photon a laissé tourner deux machines après l'overflow pour voir. Neuf heures plus tard, l'une affichait 8 000 connexions zombies et un load average de 49. La machine ne faisait plus que scanner sa propre file d'attente de connexions mortes.

Si ça vous rappelle quelque chose, c'est normal car j'sais pas si vous vous souvenais mais Windows 95 plantait au bout du même délai pour la même raison (le fameux GetTickCount() en 32 bits). Le Boeing 787 avait également un souci similaire au bout de 51 jours sur ses switches réseau, sans oublier le bug de l'an 2038 sous Unix, qui est la version signée du même phénomène. 30 ans séparent certains de ces bugs qui pourtant appartiennent à la même catégorie !

Après flippez pas car des devs avec des Macs à plus de 600 jours d'uptime disent n'avoir jamais eu le souci. À vrai dire, le bug ne se déclencherait que si votre Mac n'a aucun trafic TCP pile au moment de l'overflow. Si votre machine cause au réseau en permanence (et c'est le cas de 99% des Macs), l'horloge passe le cap sans broncher.

Les machines les plus exposées sont en fait les serveurs CI/CD sous macOS, les Mac mini en ferme de build Jenkins ou GitHub Actions, les Mac Pro dédiés au rendu 3D avec Blender ou Cinema 4D. Le MacBook qui passe en veille tous les soirs n'est pas vraiment concerné (le compteur tcp_now ne tourne pas pendant la veille, donc le délai de 49 jours ne concerne que le temps d'activité réel).

Maintenant pour vérifier votre compte à rebours personnel, ouvrez un Terminal et collez y ceci :

boot_sec=$(sysctl kern.boottime | grep -o 'sec = [0-9]*' | head -1 | awk '{print $3}')
now_sec=$(date +%s)
remain=$(( 4294967 - (now_sec - boot_sec) ))
echo "Temps restant avant overflow : $((remain/3600))h $((remain%3600/60))m"

Un Strasbourgeois de 37 ans a été interpellé par le RAID après avoir formulé des menaces dans une conversation avec ChatGPT. OpenAI a signalé les propos au FBI, qui a transmis l'alerte aux autorités françaises via la plateforme Pharos.

L'affaire a été classée sans suite, mais elle montre que les échanges avec les chatbots ne sont pas vraiment privés.

Des menaces repérées par OpenAI

Les faits remontent au 3 avril. L'homme a indiqué à ChatGPT vouloir acheter un pistolet Glock pour "tuer un agent du renseignement de la CIA, du Mossad ou de la DGSI". Les propos ont été détectés par les systèmes de modération d'OpenAI, qui applique depuis 2024 une politique claire : si une conversation présente un risque de violence physique, l'entreprise peut transmettre les échanges aux forces de l'ordre.

Ici, OpenAI a alerté le FBI, qui a relayé l'information aux autorités françaises via Pharos, la plateforme de signalement en ligne gérée par l'OCLCTIC.

Le RAID intervient, aucune arme trouvée

L'intervention a eu lieu au domicile de l'homme, dans le quartier de Koenigshoffen à Strasbourg. Le RAID est entré sans incident et n'a trouvé aucune arme sur place. L'homme a été placé en garde à vue puis libéré le lendemain.

Il a expliqué être schizophrène, en rupture de traitement depuis deux ans, et avoir voulu "tester la fiabilité et la surveillance de l'intelligence artificielle" plutôt que planifier quoi que ce soit. Le parquet de Strasbourg a classé l'affaire sans suite et l'homme a été hospitalisé d'office en psychiatrie.

Vos conversations avec les chatbots ne sont pas privées

Cette affaire est un bon rappel pour tous les utilisateurs de ChatGPT et d'autres assistants IA. OpenAI le dit dans ses conditions d'utilisation : les conversations peuvent être analysées, et dans certains cas transmises à la police.

Depuis février 2024, l'entreprise a perturbé plus de 40 réseaux qui enfreignaient ses règles. Et le mécanisme est rapide : entre les propos tenus à Strasbourg et l'intervention du RAID, il s'est visiblement passé très peu de temps. La coopération entre OpenAI, le FBI et les autorités françaises a fonctionné en quasi temps réel.

C'est le genre d'histoire qui fait réfléchir. On parle quand même d'un type qui tape des menaces dans un chatbot depuis chez lui et qui voit le RAID débarquer à sa porte quelques heures plus tard. Ici l'affaire s'est bien terminée, l'homme avait visiblement besoin de soins et pas d'un Glock.

Mais ça pose une question très concrète : est-ce que tous les utilisateurs de ChatGPT, Claude ou Gemini ont bien conscience que leurs conversations sont surveillées et peuvent remonter aux autorités de n'importe quel pays ? On imagine bien que non.

Source : Vosges Matin

Un développeur connu sous le pseudo ThroatyMumbo vient de réussir un petit exploit : faire lire des DVD à une Sega Dreamcast, la console qui n'a jamais eu droit à cette fonctionnalité.

Sa méthode passe par un Raspberry Pi 5, un Raspberry Pi Pico 2 et le port manette de la console, le tout sans la moindre modification hardware. Vingt-cinq ans après, la Dreamcast peut enfin lire des DVD.

Une vieille histoire de format

La Dreamcast est sortie en 1998 au Japon et utilisait le format GD-ROM, un disque propriétaire développé avec Yamaha capable de stocker jusqu'à 1 Go de données. Sega avait choisi ce format pour éviter les frais de licence du DVD Forum et garder des coûts de production proches de ceux d'un CD classique.

CUPS, le système d'impression utilisé par macOS et la plupart des distributions Linux, est touché par deux nouvelles vulnérabilités. Elles ont été trouvées par des agents d'intelligence artificielle, et permettent une exécution de code à distance.

Aucun correctif officiel n'est disponible pour le moment, et les preuves de concept sont déjà publiques. Les environnements professionnels sont les premiers concernés.

Quand l'IA fait le boulot des chercheurs en sécurité

C'est un ingénieur sécurité de SpaceX, Asim Manizada, qui a publié les détails de ces deux failles. Le plus surprenant, c'est qu'il ne les a pas trouvées tout seul. Il a utilisé des agents IA pour analyser le code de CUPS et débusquer les problèmes.

Son travail s'inspire des recherches de Simone Margaritelli, qui avait déjà montré en 2024 comment enchaîner plusieurs failles CUPS pour exécuter du code à distance sur des machines Linux.

Les deux vulnérabilités portent les références CVE-2026-34980 et CVE-2026-34990. Elles touchent CUPS 2.4.16 et peuvent être combinées pour un résultat assez redoutable.

Deux failles qui se complètent

La première faille permet à un attaquant d'envoyer une tâche d'impression sur une file PostScript partagée, sans aucune authentification.

CUPS accepte par défaut les requêtes anonymes sur les files partagées, et un mécanisme d'échappement de caractères permet d'injecter du code qui sera exécuté en tant qu'utilisateur "lp". En pratique, un attaquant peut forcer le serveur à lancer un programme de son choix.

La seconde faille concerne l'authentification du démon cupsd. Un utilisateur local sans privilège peut tromper le service pour qu'il s'authentifie auprès d'un faux serveur IPP contrôlé par l'attaquant.

Le jeton récupéré permet alors d'écraser n'importe quel fichier avec les droits root. Combinées, les deux failles donnent à un attaquant distant et non authentifié la possibilité d' écraser des fichiers système en tant que root.

Pas de patch, mais des correctifs dans les tuyaux

Pour le moment, aucune mise à jour officielle de CUPS n'a été publiée. Michael Sweet, le créateur et mainteneur du projet, a mis en ligne des correctifs sur GitHub, mais il n'y a pas encore de version patchée à télécharger.

Manizada prévient que ces failles seront faciles à reproduire, vu que les preuves de concept sont publiques et que les modèles de langage actuels peuvent transformer un rapport technique en exploit fonctionnel en quelques minutes.

Côté impact, CUPS est le système d'impression par défaut de macOS et de la quasi-totalité des distributions Linux. Pour être vulnérable, il faut que le serveur CUPS soit accessible sur le réseau avec une file d'impression partagée configurée, ce qui est courant dans les environnements professionnels.

C'est quand même un drôle de signal. D'un côté, l'IA montre qu'elle sait trouver des failles de sécurité plus vite que les humains. De l'autre, les mainteneurs open source galèrent toujours autant pour sortir les correctifs à temps. Manizada lui-même le dit : les modèles de langage peuvent convertir un simple rapport technique en code d'attaque prêt à l'emploi.

Du coup, entre la divulgation d'une faille et le premier exploit, on parle de quelques heures, pas de quelques semaines. Si vous gérez des imprimantes en réseau, le plus prudent reste de couper le partage des files CUPS en attendant le patch, ou au moins de restreindre l'accès réseau au service. Pas très pratique, mais c'est le prix à payer quand le système d'impression a vingt ans de code derrière lui.

Source : The Register

Les extensions Chrome qui promettent de l'IA, ça pullule de ouf et à vrai dire, la plupart se contentent d'envoyer vos données sur un serveur distant. C'est naze ! Heureusement, l'extension Gemma Gem prend le problème à l'envers puisque son modèle tourne directement dans votre navigateur via WebGPU, sans clé API, sans cloud, et vos données ne sortent jamais de votre machine. C'est comme le kir, royal !

Comme c'est pas sur le Chrome Web Store, faudra la builder vous-même... Vous clonez le repo, vous lancez pnpm install puis pnpm build et vous chargez le dossier dans chrome://extensions en mode développeur et ensuite, elle téléchargera le modèle de Google (environ 500 Mo pour la version légère, genre le poids d'un gros jeu mobile), et pif paf pouf, ensuite vous aurez un agent IA qui vit sa best life dans votre Chrome.

Cliquez alors sur l'icône en bas à droite, une fenêtre de chat s'ouvre et vous pourrez interroger n'importe quelle page. Et si vous préférez un modèle plus costaud, l'E4B pèse 1,5 Go et permet d'obtenir des réponses plus fines.

Sauf que c'est pas juste un chatbot de plus. En effet, l'extension fait du tool calling en boucle à l'aide de 6 outils : read_page_content, click_element, type_text, scroll_page, take_screenshot et run_javascript. Elle peut ainsi lire une page, cliquer sur des boutons, remplir un formulaire et même balancer du JavaScript dans le contexte de la page.

Comme l'inférence WebGPU ne peut pas tourner dans un service worker Chrome (y'a pas d'accès au GPU, c'est une limitation connue depuis des années), le développeur a trouvé une parade : il utilise un offscreen document, c'est-à-dire une page HTML invisible que Chrome maintient en arrière-plan et qui, elle, a accès au GPU. Résultat, le modèle calcule dans cette page fantôme, le service worker joue le facteur entre les morceaux, et le content script affiche le chat. Je trouve ça bien pensé comme découpage !

Toute la boucle d'agent (le code qui décide quand appeler un outil et quand répondre) est isolée dans un dossier agent/ sans aucune dépendance Chrome. Cela veut dire que vous pouvez prendre ces 5 fichiers .ts (agent-loop.ts, prompt-builder.ts, tool-parser.ts, types.ts et index.ts), les coller dans un projet Node.js ou Deno, et hop, vous avez votre propre boucle agentique. Yaniv Kessler, le développeur a pensé le truc pour que ça serve ailleurs.

Les deux variantes (E2B et E4B) sont compressées en q4f16 avec 128K tokens de contexte en théorie, même si en pratique la fenêtre effective dépend de votre VRAM. Cela dit, c'est largement de quoi avaler une page web complète sans broncher ! Et le modèle reste en cache après le premier téléchargement, du coup au deuxième lancement, c'est quasi instantané. Par contre, si vous êtes sur un vieux Chromebook avec un Intel UHD intégré et 4 Go de RAM, ça risque de mouliner à fond. Et sur Firefox (qui est le meilleure navigateur du monde, comme je n'ai de cesse de vous le dire), le WebGPU est encore un peu expérimental, donc pour l'instant ce sera Chrome ou rien... Sniiif.

Si vous avez déjà testé des extensions comme Localsumm qui faisaient tourner Phi-3 en local pour résumer des pages, disons que Gemma Gem pousse le concept beaucoup plus loin avec ses capacités d'agent. Et si le sujet de l'IA locale dans le navigateur vous branche, jetez un oeil à Clippy qui fait tourner des LLM localement sur votre desktop.

Notez quand même que sur Hacker News, le projet a déclenché pas mal de débat. Certains pointent le risque du tool run_javascript qui donne au modèle les pleins pouvoirs sur le DOM (genre, supprimer des trucs ou poster un formulaire à votre place). C'est vrai que c'est important mais bon, c'est le même modèle de permissions que n'importe quel script web classique, sauf que là au moins vos données restent chez vous.

Bref, 500 Mo de modèle, pas de cloud, et votre navigateur qui devient plus autonome que votre fils de 22 ans. Pas mal non ?

Vous vous souvenez de BadUSB ? Mais siiii, c'est ce truc dévoilé en 2014 à la Black Hat qui avait foutu la trouille à tout le monde. Ça montrait qu'un simple périphérique USB pouvait se faire passer pour un clavier et balancer des commandes à votre place. Hé bien depuis, les attaques se sont bien raffinées et c'est pourquoi un dev vient de proposer un module kernel Linux capable de détecter ces saloperies.

Enfin !

Ce module s'appelle hid-omg-detect et c'est signé Zubeyr Almaho. Le patch (déjà en v2) a été soumis le 4 avril dernier sur la LKML. Alors je pense que vous allez vous dire que c'est encore un truc qui va bloquer par défaut vos périphériques USB sauf que non, ça ne bloque rien. En fait, il surveille passivement les périphériques HID (claviers, souris...) et leur attribue un score de suspicion basé sur trois critères.

D'abord, l'entropie des frappes clavier. Un humain tape de manière irrégulière, avec des pauses, des hésitations, des fautes (perso je fais au moins 3 fautes de frappe par phrase ^^). Un câble trafiqué, lui, balance ses commandes avec une régularité de métronome, genre 500 caractères en 2 secondes sans une seule erreur. Ensuite, y'a la latence entre le branchement et la première frappe. Si votre "clavier" commence à taper immédiatement après avoir été branché... y'a comme un souci. Et enfin, le fingerprinting des descripteurs USB pour repérer les vendor/product IDs suspects ou les anomalies dans les descripteurs HID.

Pas con hein ? Et si le score dépasse un certain seuil (configurable), hop, le module balance un warning dans dmesg et vous oriente vers USBGuard pour bloquer le périphérique. Parce que hid-omg-detect ne touche à rien lui-même. Il sonne juste l'alarme, et c'est à vous d'agir !

Mais alors pourquoi lancer ça maintenant ?

Hé bien parce que les outils d'attaque USB sont devenus légion ! Les câbles O.MG (créés par le chercheur MG et distribués via Hak5), par exemple, ça ressemble à un câble USB lambda que vous emprunteriez sans réfléchir pour charger votre téléphone. Sauf que dedans y'a un implant WiFi capable d'injecter des frappes, de les logger, de spoofer les identifiants USB, le tout contrôlable à distance. Quand je pense qu'il y a quelques mois, des chercheurs montraient qu'une simple webcam Lenovo pouvait être transformée en dispositif BadUSB ... Sa fé grav réchéflir 🤓 comme dirait les citoyens souverains ^^.

Maintenant, en attendant que le patch soit accepté, vous n'êtes pas totalement démunis non plus. Des outils comme USBRip (un script Python, pip3 install usbrip) permettent déjà de tracer les connexions et déconnexions USB en parsant /var/log/syslog. Y'a pas ce scoring d'anomalies, mais au moins vous avez un historique pour savoir qui a branché quoi et quand. Et si vous êtes vraiment parano (et franchement, vous avez raison de l'être), USBGuard peut carrément whitelister vos périphériques de confiance et bloquer tout le reste. Mais le problème d'une telle solution c'est que ça demande de maintenir une liste blanche à jour, ce qui n'est pas toujours pratique quand on branche 15 trucs par jour.

On verra si les mainteneurs du kernel l'accepte... Après ça ne protégera pas contre tous les scénarios non plus. Un périphérique qui attend 30 secondes avant de commencer son injection pourrait passer sous le radar. Et si un attaquant injecte du jitter aléatoire dans ses frappes pour simuler un humain, là ce sera plus compliqué. Mais combiné avec USBGuard, ça donnera enfin une vraie ligne de défense native contre les attaques par périphériques USB piégés . Et c'est quand même mieux que de boucher ses ports au plâtre et ciment (Mais pleure pas au dessus du mortier...) !

Bref, va falloir garder un œil là-dessus.

Source

EDIT (7 avril, 22h) : Depuis la publication de cet article, plusieurs analyses techniques indépendantes ont sérieusement remis en question ce projet. Aimar Haddadi a découvert que le code aurait été écrit par un développeur tiers nommé Lu (DTL), pas par Milla Jovovich, et que l'historique git a été squashé pour masquer l'attribution.

Thin Signal a démonté la méthodologie des benchmarks : le score de 96.6% mesure en réalité les performances de ChromaDB (la base vectorielle utilisée), pas celles de l'architecture "palace", et il compare du Recall@5 avec des scores de QA accuracy d'autres systèmes, ce qui revient à comparer des pommes et des oranges.

Enfin, une analyse de code complète a révélé que la compression AAAK est lossy (84.2% de retrieval contre 96.6% en brut, soit 12 points de perte), que la détection de contradictions mentionnée dans le README n'existe tout simplement pas dans le code, et que le "+34% d'amélioration" annoncé est du filtrage métadata standard, pas une innovation.

Bref, le marketing est frauduleux, même si certaines briques techniques (100% local, coût de démarrage léger, métaphore spatiale) restent intéressantes.

Milla Jovovich a un compte GitHub !! Oui, l'actrice des films Resident Evil, celle qui découpe des zombies depuis 2002 et qui a également incarné Leeloo dans un film qui est cher à mon cœur a mis en ligne son premier repo. Ça s'appelle MemPalace , et c'est un système de mémoire pour IA, qui annonce un score de 96.6% sur LongMemEval. Même si, comme expliqué dans l'édit ci-dessus, ce score est à relativiser fortement.

Un petit pip install mempalace et ça tourne en local sur votre machine, sous licence MIT, en Python pur. Le projet est attribué à Milla et Ben Sigman, même si l'attribution réelle du code fait débat (voir édit). Et c'est bien la vraie Milla qui en fait la promo, hein... vidéo sur sa page Facebook à l'appui.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/mempalace-milla-jovovich-ia-memoire/mempalace-milla-jovovich-ia-memoire-1.mp4">lien vers la vidéo</a>.

Ce week-end, pendant qu'on se gavait d'oeufs de Pâques au Cadmium, un chercheur en sécu a balancé un zero-day Windows dans la nature... et tout ça d'après ce que j'ai compris, à cause de Microsoft qui l'a vraiment poussé à bout. L'exploit s'appelle BlueHammer et il permet à quiconque ayant un accès local sur une machine Windows 11 25H2 de passer SYSTEM. Et vous vous en doutez y'a toujours pas de patch.

Il s'agit d'une d'une escalade de privilèges locale (LPE) qui exploite une race condition de type TOCTOU (time-of-check to time-of-use), combinée avec une confusion de chemins dans le processus de mise à jour des signatures de Windows Defender. Je sais, il est trop tôt pour ces conneries mais disons que c'est le bug classique où un programme vérifie un truc, puis l'utilise, mais entre les deux quelqu'un a changé le truc en question.

En gros, l'exploit profite d'une fenêtre de temps entre le moment où Defender vérifie un fichier et celui où il l'utilise pour glisser un lien symbolique qui redirige vers la ruche SAM, le fichier C:\Windows\System32\config\SAM (là où Windows stocke les identifiants locaux). Et là, après ça devient open bar sur les hash de mots de passe de tous les comptes locaux.

Le chercheur derrière tout ça opère sous les pseudos Chaotic Eclipse et Nightmare-Eclipse et le 3 avril 2026, il a publié le code source complet sur GitHub , signé PGP, avec ce message assez salé : " I was not bluffing Microsoft, and I'm doing it again. "

Son reproche ? D'abord le MSRC (Microsoft Security Response Center) qui lui a demandé une vidéo de démonstration pour valider son rapport, et ensuite une réponse sur ce bug Windows Defender qui ne l'a visiblement pas satisfait : "I'm just really wondering what was the math behind their decision"

Will Dormann, analyste principal chez Tharros (ex-Analygence) et référence dans le milieu, a confirmé que l'exploit fonctionne, même s'il précise que l'exploitation n'est pas triviale. Une fois les privilèges obtenus, l'attaquant a les clés du royaume et peut lancer un shell avec les privilèges SYSTEM comme si c'était chez lui... Donc pas trivial, certes mais bien réel. D'ailleurs, c'est pas la première fois que Windows se fait éplucher par des chercheurs qui trouvent sans difficultés des failles d'escalade de privilèges en série.

Source : Will Dormann

Après, sous le capot, c'est quand même bien foutu. Un développeur (0xjustBen) a réimplémenté le PoC de manière modulaire et ça montre bien la mécanique : un module télécharge une vraie mise à jour Defender, un autre surveille les Volume Shadow Copies, un troisième enregistre un callback via l'API Cloud Files.

Source : Will Dormann

Et le cœur du truc joue la race condition avec un swap de lien symbolique pour lire la ruche SAM.

Notez quand même que le PoC original contient des bugs (le chercheur l'admet lui-même dans le README) et ne fonctionne pas sur Windows Server... ce qui ne veut pas dire que c'est inoffensif, attention. Et la réimplémentation de 0xjustBen, elle, n'a fonctionné que sur Windows 11 25H2, les versions 22H2, 23H2 et 24H2 n'étant pas affectées. Pas de CVE attribuée non plus pour l'instant, ce qui veut dire que Microsoft n'a même pas encore catalogué officiellement le problème.

Côté protection, c'est pas simple vu qu'il n'y a pas de correctif officiel mais comme l'attaque nécessite un accès local à la machine, ça limite pas mal les scénarios. Faut déjà être sur le poste Windows, que ce soit via un malware, du social engineering ou un accès physique. Après on sait bien qu'en entreprise, un poste partagé ou un stagiaire un peu curieux, c'est pas rare...

Premier réflexe donc : allez vérifier votre version de Windows (Paramètres > Système > À propos, ou winver dans Exécuter). Si vous n'êtes pas sur 25H2, vous n'êtes pas concerné. Sinon, vérifiez que vos comptes locaux ont des mots de passe costauds (pas "admin123"), désactivez les comptes inutilisés et gardez un œil sur les processus qui tournent avec des privilèges élevés. Côté entreprise, les solutions EDR devraient pouvoir détecter le comportement suspect (création de service temporaire, accès SAM inhabituel).

Bref, je pense que Microsoft finira bien par patcher... un jour.

Source