Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierKorben

Google neutralise la première cyber-attaque massive générée par une IA

12 mai 2026 à 13:49

Google a balancé l'info via son équipe cyberdéfense, le GTIG (Google Threat Intelligence Group). Des cybercriminels ont utilisé une IA générative pour dénicher et écrire un code d'attaque exploitant une faille inconnue (ce qu'on appelle un zero-day, une vulnérabilité que l'éditeur du logiciel n'a pas encore corrigée).

Et ils s'apprêtaient à lancer une vague d'attaques massives. C'est, d'après Google, la première fois qu'on observe ça dans la vraie vie, pas en labo.

La faille concernait un outil d'administration de serveur open-source très utilisé, dont Google ne donne pas le nom (le temps que tout le monde installe le correctif).

Le bug permettait de contourner la double authentification, le fameux code à 6 chiffres ou la notification sur le téléphone qui sécurise vos comptes. En pratique, il fallait quand même un identifiant et un mot de passe valides au départ, donc ce n'est pas une attaque magique en un clic. Mais une fois ce sas franchi, la 2FA tombait toute seule.

Ce qui a mis la puce à l'oreille des chercheurs, c'est l'allure du script Python utilisé pour exploiter la faille. Trop bien écrit, trop documenté, trop scolaire en fait.

Il était bourré de commentaires pédagogiques (le genre qu'on retrouve dans un tuto pour débutant), il affichait un menu d'aide impeccable, et surtout un score de dangerosité CVSS complètement inventé. Cette dernière trouvaille, c'est l'indice qui ne trompe pas, seul un modèle de langage peut halluciner un chiffre officiel avec autant d'aplomb.

John Hultquist, le chef analyste du GTIG, explique que les IA génératives sont vraiment douées pour repérer ce genre de faille logique de haut niveau, là où les outils d'audit classique (les "fuzzers" qui bombardent un logiciel de données aléatoires pour le faire planter) passent à côté.

Google précise au passage que ce n'est pas Gemini, son propre modèle d'IA, qui a été utilisé. Lequel alors ? Mystère, l'équipe de Mountain View ne le dit pas. On imagine que les criminels n'ont pas demandé poliment l'autorisation à un éditeur d'IA. Affaire à suivre.

Le rapport donne d'autres pépites. Le groupe nord-coréen APT45 utiliserait l'IA pour tester des milliers d'exploits en masse. Des opérateurs chinois liés à l'État expérimenteraient l'IA pour chasser les vulnérabilités.

Des backdoors (des portes dérobées cachées) sur Android interrogent directement Gemini pour piloter les téléphones infectés. Et côté désinformation, des opérations russes intègrent du faux audio généré par IA dans de vraies images d'actualités. Bref, ça bouge de partout.

Bonne nouvelle quand même, la campagne d'attaque massive a été désamorcée. Google a coordonné un correctif discret avec l'éditeur avant que les criminels puissent appuyer sur le bouton. Cette fois.

Bref, l'IA fabrique maintenant des armes prêtes à l'emploi pour les criminels, et personne ne sait quel modèle a fait le boulot. Rien de rassurant donc.

Source : The Hacker News

Taggez vos photos avec de l'IA en local

Par : Korben ✨
12 mai 2026 à 08:08

Tagger des milliers de photos à la main, c'est le genre de corvée qu'on remet tous à plus tard depuis des années. Mais c'était sans compter sur photo-folder-tagger de Laurent Voillot qui règle ça grâce à 6 modes IA spécialisés, le tout en local, sans envoyer une seule image dans le cloud.

Vous faites pointer l'outil sur un dossier, vous choisissez le mode IA correspondant à vos photos, et hop, des fichiers XMP annexes sont générés à côté de chaque cliché. Ces fichiers contiennent les tags et sont directement lisibles par Lightroom Classic, Capture One, Bridge, Darktable et DigiKam, ce qui évite d'avoir à ré-importer ou à modifier les originaux !

Les 6 modes couvrent des usages bien distincts. Le mode Balade utilise CLIP SigLIP2 pour la classification générale (~50 ms par photo). Le mode Animaux combine BioCLIP v1 + CLIP (~40 ms). Pour les oiseaux et les insectes, c'est BioCLIP 2, entraîné sur 214 millions d'images de biodiversité (TreeOfLife-200M), à ~55 ms par image. Le mode Vacances sort la grosse artillerie avec Ollama et qwen2.5vl pour générer des descriptions en langage naturel (~1.8 s par photo).

Et le mode qui mérite une mention spéciale c'est Astro capable d'identifier automatiquement les objets célestes : Galaxies, nébuleuses, amas d'étoiles... les tags XMP pointent alors vers les références Messier, NGC ou IC correspondantes. C'est assez dingue comme feature.

En tout cas, c'est plus précis d'avoir tous ces petits modèles spécialisés plutôt que d'avoir un seul modèle qui fait tout. BioCLIP 2 sur la faune donne par exemple des résultats qu'un modèle généraliste n'atteindra pas.

L'installation se fait après récupération des sources via pip install -r requirements.txt. Tout est configurable dans config.yaml, les modèles IA utilisés, la langue des tags, les seuils de confiance...etc puis ça se lance avec python photo_folder_tagger.py. Au passage, n'oubliez pas que si vos photos sont un peu floues avant de lancer le tagger, SuperImage peut les upscaler en amont.

Bref, si vous avez des disques entiers de photos nature, astro ou de rando qui traînent sans tags depuis des années, c'est l'outil qu'il vous faut.

Merci à Laurent Voillot.

Spotify génère maintenant vos podcasts tout seul

Par : Korben ✨
11 mai 2026 à 08:48

Spotify vient d'annoncer un truc intéressant je trouve, qui s'appelle les Personal Podcasts. Le principe c'est de demander absolument tout ce que vous voulez, par exemple un podcast sur un cours que vous venez de suivre, sur un bouquin, sur un article de Korben.info voire sur votre planning de la semaine, vos objectifs...etc etc... Peu importe... Spotify prend tout ça, et génère un épisode audio personnalisé raconté par une voix IA plus ou moins moche.

Et l'épisode apparaît alors directement dans votre bibliothèque, comme si quelqu'un avait fait un résumé audio de votre semaine.

Et pour faire ça, ils ont mis en ligne un repo GitHub save-to-spotify qui est un outil en ligne de commande permettant à des agents IA de créer ce podcast personnalisé tout ça accessible en ligne de commande ou via des agents comme Claude Code, OpenClaw ou Codex.

Que ce soit sous macOS ou Linux, ça s'installe en une ligne (allez lire le install.sh par sécurité quand même avant de l'exécuter) :

curl -fsSL https://saveto.spotify.com/install.sh | bash

Et si vous êtes sous Claude Code, c'est encore plus immédiat :

/plugin marketplace add spotify/save-to-spotify

Le skill se retrouve dans ~/.claude/skills/save-to-spotify/ et votre agent peut demander à Spotify de générer un podcast à la demande pour ensuite le pousser sur Spotify.

Rien de compliqué en fait !

Par contre, le podcast créé est 100% privé, donc vous ne pourrez pas le partager avec vos amis. Mais c'est pas bloquant non plus puisqu'il est toujours possible d'aller récupérer dans les dossiers temporaires de génération de l'émission les MP3 que ça vous crache pour ensuite les mettre ailleurs, soit sur votre site, soit les diffuser sur votre vrai podcast Spotify accessible à tous.

Maintenant, est-ce que je vais faire mon podcast pour raconter les actus que je mets sur ce site ?

Alors j'ai pas le temps mais je le ferai peut-être un jour si la qualité audio de l'IA est suffisante pour que ça ait l'air vraiment produit par un humain et pas par une machine. Pour vous donner une idée, voici ce que ça donne :

Donc c'est pas encore qualitatif... À voir en passant par des moteurs TTS comme ceux d'ElevenLabs... mais pour l'instant, c'est pas d'actualité pour moi. On verra bien... Je me suis quand même amusé à mettre les fichiers texte et JSON produits dans Notebook LM pour faire un autre type de podcast qui cette fois est un peu plus long et plus quali... Je vous mets ici.

Après, peu importe que vous le génériez via l'outil de Spotify ou autrement en passant par un autre outil, le CLI Save To Spotify, vous permettra ensuite de le mettre sur votre compte Spotify pour l'écouter par exemple dans la voiture ou dans les transports.

Bref, c'est disponible et si vous avez Claude Code sous la main, ça prend une ligne à installer. L'annonce complète est par ici .

Google Workspace CLI - Pour piloter tous les services Google avec votre IA

Par : Korben ✨
8 mai 2026 à 16:52

Justin Poehnelt, Senior Developer Relations Engineer chez Google, vient de balancer sur Github un outil en ligne de commande (CLI), codé en Rust qui permet de faire un truc trop pratique, à savoir piloter entièrement Workspace depuis le terminal. Ce logiciel nommé GWS est donc capable de gérer Gmail, Drive, Calendar, Sheets et sept autres services Google d'un coup. Et en plus, comme il a été conçu pour les agents IA, donc c'est pas juste pour vous et votre terminal !

Une fois installé via npm, cargo, brew ou un binaire pré-compilé, vous tapez gws auth login pour vous authentifier via OAuth et vous pouvez ensuite attaquer onze services depuis votre shell : Drive, Gmail, Calendar, Sheets, Docs, Chat, Admin, Apps Script, Tasks, Workspace Events et Model Armor.

Niveau archi, au lieu de hard-coder chaque commande dans le binaire, gws interroge tout simplement le Discovery Service de Google au démarrage et reconstruit son arbre de commandes à la volée. Du coup quand Google ajoute un endpoint à l'API Sheets, le CLI le voit apparaître tout seul. C'est trop bien parce que ça évite de devoir attendre une release pour utiliser un éventuel nouveau service de Google. Et pour un agent IA qui re-fetch le schéma à chaque run, c'est plutôt une bonne idée.

Donc en plus de démarrer en moins d'une seconde, GWS crache des sorties en JSON structurées, y'a un mode --dry-run qui montre la requête sans l'envoyer, et de l'auto-pagination via --page-all. Et côté commandes utilitaires, vous avez aussi les + qui sont des helpers cousus main tels que gws gmail +send, gws drive +upload, gws calendar +agenda, gws sheets +append, gws gmail +triage et un gws gmail +standup-report qui résume vos mails de la semaine en quelques lignes.

Le repo embarque aussi 40+ skills d'agent prêts à l'emploi du type "résume mes mails non lus" ou "génère mon rapport", une extension Gemini CLI qui s'installe avec gemini extensions install https://github.com/googleworkspace/cli, et le helper +sanitize-response qui fait passer la sortie par Model Armor (le filtre anti-prompt-injection de Google Cloud) pour éviter les réponses bizarres.

En gros, c'est un outil pensé pour faire piloter votre Workspace par Claude, Gemini ou n'importe quel agent. Comme ça vous allez pouvoir écrire un workflow qui lit vos mails non lus, en fait un résumé, le poste dans un Chat et classe tout ça proprement dans Drive... sans avoir à toucher à la souris ni avoir à utiliser votre cerveau léthargique. Elle est pas belle la vie ?

Sauf que. Le projet porte le disclaimer "This is not an officially supported Google product", et un employé Google a confirmé sur le thread Hacker News (presque 1000 points, quand même) que c'est un projet DevRel. Comprendre : pas de SLA, pas de roadmap garantie, pas d'équipe SRE qui veille au grain. Vous savez comment ça finit chez Google avec ce genre de statut !

Bref si vous êtes chaud pour tester, le binaire est dispo ici . Maintenant reste à voir si Google lui donnera un statut officiel ou si GWS s'éteindra discrètement comme tant d'autres projets internes oubliés...

Chrome installe en douce un modèle IA de 4 Go sur votre disque sans rien demander

6 mai 2026 à 10:09

Alexander Hanff, consultant, a remonté un truc pas net sur Chrome. La dernière version du navigateur télécharge en arrière-plan un modèle de langage local appelé Gemini Nano, qui pèse environ 4 Go, sans jamais demander la moindre permission à l'utilisateur.

Le fichier s'appelle weights.bin, il atterrit dans un dossier OptGuideOnDeviceModel quelque part dans votre profil Chrome, et il sert ensuite à des fonctions du genre "Help me write" ou détection de fraude.

Hanff a documenté l'opération via les logs système de son macOS. Le 24 avril 2026 vers 16h38, Chrome crée le dossier. Quelques minutes plus tard, il télécharge et décompresse les 4 Go (l'opération prend une quinzaine de minutes), puis il les déplace à l'emplacement final. Tout ça pendant que vous ne touchez rien à votre machine. Si vous supprimez le fichier à la main, il sera réinstallé silencieusement au prochain lancement du navigateur.

Hanff estime entre 100 millions et 1 milliard de machines concernées dans le monde. Multipliez 4 Go par 1 milliard et vous obtenez de quoi remplir une bonne partie d'un datacenter.

L'auteur calcule également l'impact carbone du déploiement, entre 6 000 et 60 000 tonnes de CO2e rien que pour le réseau, sans compter l'empreinte SSD. Pour un fichier que personne ne vous a demandé d'installer.

Sur le plan légal, Hanff parle d'une "violation directe" de l'article 5(3) de la directive ePrivacy européenne, qui interdit de stocker quoi que ce soit sur l'appareil d'un utilisateur sans consentement explicite. Il évoque aussi un manquement RGPD. Si la qualification tient, ça serait une amende salée pour Google, sachant que les Cnil européennes ont déjà sanctionné Meta et Microsoft pour des choses bien moins foireuses.

Pour s'en débarrasser, trois options : aller dans chrome://flags pour désactiver les fonctions IA, passer par les politiques d'entreprise si vous gérez un parc de machines, ou virer Chrome, tout simplement.

Bref, Google qui pousse 4 Go d'IA en silence sur des centaines de millions de machines, c'est un sale moche.

Source : That Privacy Guy

Un C-3PO grandeur nature transformé en assistant vocal qui répond pour de vrai

3 mai 2026 à 08:20

Un maker a transformé une réplique grandeur nature de C-3PO en assistant vocal interactif, et le résultat est franchement convaincant. Sa version du droïde papote, répond à vos questions, et tient même une conversation, le tout sans dépendre du moindre cloud une fois en local.

Le truc tient sur un Raspberry Pi 5 planqué dans la coque dorée du droïde. Un micro capte ce que vous racontez, un moteur de speech-to-text le transcrit, et un LLM local s'occupe de comprendre votre question pour formuler une réponse. Jusque là, rien de fou c'est même devenu même assez classique.

Le truc rigolo, c'est la couche par dessus. L'auteur a ajouté un prompt système qui force le LLM à répondre comme C-3PO le ferait : un peu anxieux, très formel, avec ce ton un brin pompeux qu'on connaît tous. Du coup, quand vous lui demandez bêtement la météo, vous pouvez vous prendre une réponse genre "Oh dear, je crains que les conditions atmosphériques ne soient guère favorables à un déplacement humain". Très C-3PO.

Pour la voix, le projet utilise un modèle synthétique entraîné sur les dialogues d'Anthony Daniels, l'acteur original. Le son passe ensuite par une chaîne d'effets audio qui ajoute la résonance métallique et le léger souffle qu'on entend dans les films. Le résultat n'est pas parfait, mais ça reste franchement bluffant pour un projet bricolé à la maison.

Tout le code est dispo en open source, ce qui veut dire que vous pouvez théoriquement le reproduire chez vous, à condition d'avoir une réplique C-3PO sous la main. Ce qui n'est pas le plus simple. Pour les budgets plus modestes, l'auteur précise que le pipeline tourne aussi très bien dans une simple enceinte connectée custom, le côté droïde doré n'étant pas indispensable au fonctionnement.

Le seul vrai bémol, c'est la latence. Entre le moment où vous parlez et la réponse vocale, comptez quelques secondes, ce qui casse un peu l'illusion d'avoir affaire à un assistant réactif. Mais bon, le vrai C-3PO du film mettait aussi trois plombes à comprendre les ordres, donc on peut presque considérer ça comme un détail de fidélité au personnage.

Source : Hackaday

Japan Airlines teste des robots humanoïdes pour charger les bagages

1 mai 2026 à 11:33

Japan Airlines va confier la manutention des bagages à des robots humanoïdes sur les pistes de l'aéroport Haneda. Le test démarre en mai 2026, dure deux ans, et implique pour commencer deux machines posées au milieu des bagagistes humains.

L'opération est pilotée par JAL Ground Service avec GMO AI & Robotics. Les robots viennent de Chine : un Unitree G1 d'environ 1m30 et un Walker E d'UBTECH.

Le programme est découpé en plusieurs étapes (cartographie du site, simulations en environnement reconstitué, puis tarmac réel), avec à terme l'idée de leur faire transporter les containers de fret, manipuler les leviers de verrouillage et même nettoyer les cabines une fois les avions vides. L'autonomie annoncée est de 2 à 3 heures, avant qu'il ne faille recharger la machine.

Sauf que la première démo publique a calmé tout le monde. Le G1 a tapoté un colis sur le tapis roulant et fait coucou à un humain, mais personne ne l'a vu soulever quoi que ce soit.

La presse anglo-saxonne a gentiment moqué la chose : démarche hésitante, gestes cosmétiques, et surtout aucune preuve de capacité à porter une valise standard.

Le Japon n'a pas le choix. Population vieillissante, faible immigration, et tourisme record qui sature les infrastructures : les aéroports japonais galèrent à recruter des bagagistes, et la situation ne va pas s'arranger dans les prochaines années.

Du coup, plutôt que d'investir dans des bras articulés industriels qui demandent de repenser tout le poste de travail, JAL parie sur des humanoïdes capables de s'intégrer dans un poste conçu pour des humains. 

En pratique, on est encore loin du compte. Une valise standard pèse entre 20 et 30 kg. Un humanoïde d'environ 35 kg sur deux jambes qui tient à peine debout, ce n'est pas vraiment l'outil idéal pour balancer du Samsonite à la chaîne pendant huit heures. JAL le sait.

D'où les deux ans de test prévus avant tout déploiement réel, et l'envie d'observer ce qui marche, ce qui casse, et ce qui finira aux oubliettes. Les deux fournisseurs choisis ne sont d'ailleurs pas des inconnus : Unitree et UBTECH se positionnent comme les gros chinois de l'humanoïde, face à un Tesla Optimus encore largement scénarisé.

Vous l'avez compris  on est plus dans la com' que sur de l'efficacité pure. Faire coucou à un bagage, ça ne le met toujours pas en soute.

Source : ARS Technica

Copy Fail - Une IA trouve la faille Linux que personne n'a vue

Par : Korben ✨
30 avril 2026 à 09:27

732 octets, c'est tout ce qu'il faut pour passer de simple utilisateur à root sur n'importe quel Linux non patché compilé depuis 2017, soit la quasi-totalité des kernels. Cette faille béante s'appelle Copy Fail (CVE-2026-31431), elle a été dénichée par Taeyang Lee de chez Theori avec leur outil d'audit IA Xint Code. Et comme elle vient d'être divulguée hier sur la liste oss-security et qu'en plus, ils ont fait un joli petit site qui explique tout comme ça fonctionne, je vais essayer de tout vous expliquer !

La faille elle-même est moche mais surtout, c'est un agent IA qui l'a sorti en une heure environ. C'est un bug que la communauté kernel a laissé passer durant près de 9 ans et qui se trouve dans le sous-système crypto.

En gros, le noyau Linux expose une interface réseau spéciale pour accéder aux opérations de chiffrement depuis un programme normal, sans droits particuliers.

Et depuis 2017, une optimisation dans ce mécanisme a créé une situation bizarre : un fichier en lecture seule sur le disque, disons un binaire système, peut se retrouver dans la zone de sortie d'une opération de chiffrement .C'est la zone que votre programme a le droit de modifier.

Il suffit alors d'enchaîner un appel système particulier (splice) pour écrire 4 octets au bon endroit, on répète ça en boucle, et on modifie progressivement un binaire système de votre choix comme par exemple /usr/bin/su.

Et voilà, vous êtes root !

Maintenant, si vous administrez un serveur, le plus propre reste de patcher le kernel via votre distro. En attendant le patch, la mitigation dépend de comment votre distro a compilé le module algif_aead, et là il y a deux situations bien distinctes.

Cas 1 - Distros où le module est chargeable dynamiquement (Ubuntu, Debian, Arch, etc.). Vous le bloquez avec :

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead

Cas 2 - Distros entreprise où le module est compilé en dur dans le kernel (RHEL, Rocky Linux, AlmaLinux, Oracle Linux, SUSE Enterprise...). Là, attention au piège : lsmod | grep algif_aead ne renvoie rien, mais ça ne signifie PAS que c'est désactivé. Le code est embarqué directement dans le vmlinuz, donc rmmod et la blacklist via /etc/modprobe.d/ sont sans effet (vous aurez "Module algif_aead is builtin"). La vraie mitigation passe par la kernel command line au boot :

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo reboot

Ça empêche l'init_call du module de tourner au démarrage. Vous vérifiez ensuite avec cat /proc/cmdline que le paramètre est bien pris en compte. Si vous voulez aller encore plus loin, il est aussi possible de bloquer toute la surface d'attaque AF_ALG via seccomp au niveau de chaque service exposé.

Le PoC est également trouvable. C'est un script Python (Python 3.10+ obligatoire pour os.splice) capable de faire tomber Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1 et SUSE 16 avec exactement le même code.

Dans une première version j'avais écrit que SELinux en mode enforcing par défaut bloquait l'exploit sur Fedora et RHEL. C'est inexact, et je remercie le lecteur qui m'a fait corriger. La policy SELinux par défaut de Fedora et RHEL autorise les contextes utilisateurs à créer des sockets AF_ALG, et l'exploit écrit directement dans le page cache kernel sans déclencher les hooks LSM file-based.

Donc SELinux enforcing ne bloque pas Copy Fail tel que livré par défaut. Le seul OS immune via SELinux est GrapheneOS , qui durcit la policy AOSP en réservant AF_ALG au seul process dumpstate. Ceux qui veulent tester sans Python peuvent aussi regarder du côté du port C indépendant , un exécutable statique de 1,7 Ko sans dépendance externe.

Les comparaisons avec Dirty COW et Dirty Pipe pleuvent, sauf que là où Dirty COW exigeait du timing précis et où Dirty Pipe demandait une manipulation spécifique du pipe-buffer, Copy Fail tape tout pareil sur 4 distribs majeures sans rien avoir à ajuster.

Et côté sévérité officielle, c'est du 7.8/10 donc c'est assez élevé !

Pour trouver cette faille, Xint Code, l'agent IA de Theori, n'a pas tâtonné à l'aveugle. Taeyang Lee lui a surtout glissé un prompt très précis qui lui demandait d'examiner tous les chemins accessibles depuis un programme utilisateur dans le sous-système crypto, en insistant sur le fait que splice() peut faire atterrir des fichiers en lecture seule dans des zones modifiables.

Une heure plus tard, Copy Fail sortait comme trouvaille critique ! Theori précise que le même scan a aussi remonté d'autres vulnérabilités encore sous embargo. Brrrrrr.... Tremblez simples mortel !

Ouais donc ouais, l'IA n'a pas remplacé l'expertise humaine, mais elle l'a démultipliée. Car Lee savait où regarder, et Xint Code a juste fait ce qu'il aurait fait mais en plus rapide ! C'est pas magique donc... Mais ça fait gagner du temps !

L'exploit est dispo ici sur le GitHub de Theori et côté impact, c'est costaud sur les hôtes multi-users et tout ce qui est environnements partagés. Je pense aux conteneurs Docker, aux clusters Kubernetes, aux pipelines CI/CD...etc.

Après si y'a que vous qui avez accès à votre serveur, c'est un peu moins critique car il faut forcément un accès local pour l'exploiter. C'est la même logique de chaînage que BlueHammer côté Windows , sauf qu'ici la marche jusqu'à root est encore plus petite.

Comment tester le PoC sur une machine de test ?

Si vous avez une VM sous Ubuntu 22.04 non patchée (kernel 5.15.x), voilà exactement ce qui se passe, testé en conditions réelles. Ne faites ça que sur une machine dont vous êtes propriétaire et où vous avez l'autorisation explicite.

Étape 1 - Cloner le PoC et vérifier le hash

manu@ubuntu:~$ git clone https://github.com/theori-io/copy-fail-CVE-2026-31431
Cloning into 'copy-fail-CVE-2026-31431'...
remote: Enumerating objects: 9, done.
Resolving deltas: 100% (1/1), done.

manu@ubuntu:~$ cd copy-fail-CVE-2026-31431 && sha256sum copy_fail_exp.py
a567d09b15f6e4440e70c9f2aa8edec8ed59f53301952df05c719aa3911687f9 copy_fail_exp.py

manu@ubuntu:~/copy-fail-CVE-2026-31431$ id
uid=1000(manu) gid=1000(manu) groups=1000(manu) ← utilisateur normal, pas root

Theori ne publie pas de hash officiel dans leur README, mais le SHA256 ci-dessus est celui du PoC tel qu'il est actuellement sur le repo. Si votre hash diffère, ne lancez pas le script.

Étape 2 - Lancer l'exploit

manu@ubuntu:~/copy-fail-CVE-2026-31431$ python3 copy_fail_exp.py

# L'exploit écrit 4 octets à la fois dans le page cache de /usr/bin/su
# via l'interface AF_ALG du kernel (authencesn + splice)
# Aucune race condition, aucun timing précis requis.

Mot de passe :

Le script utilise AF_ALG (l'interface crypto du kernel) combiné à splice() pour écrire un shellcode de 160 octets directement dans le page cache de /usr/bin/su, sans jamais toucher le disque. Il remplace ensuite le binaire patché pour exécuter un shell root.

Étape 3 - Shell root obtenu

root@ubuntu:~# id
uid=0(root) gid=1000(manu) groups=1000(manu)

root@ubuntu:~# whoami
root

root@ubuntu:~# uname -r
5.15.0-143-generic

# Kernel 5.15 vulnérable confirmé - Ubuntu 22.04 non patché

Notez le uid=0(root) alors qu'on est parti d'un uid=1000 sans aucun mot de passe, aucune race condition, aucun timing à ajuster. Brutal.

Étape 4 - Accès aux fichiers root-only

root@ubuntu:~# cat /etc/shadow | head -3
root:*:20271:0:99999:7:::
daemon:*:20271:0:99999:7:::
bin:*:20271:0:99999:7:::

root@ubuntu:~# cat /etc/passwd | grep root
root:x:0:0:root:/root:/bin/bash

/etc/shadow est normalement illisible pour un utilisateur standard. Là, avec notre PoC en Python et zéro interaction supplémentaire, on y accède comme si de rien n'était. Sur un serveur multi-utilisateurs, c'est game over pour tous les comptes présents.

Sur un système patché, le script échoue proprement à l'étape 2 avec un message d'erreur. C'est aussi simple que ça pour vérifier votre exposition.

Bref, mettez à jour vos kernels ou désactivez le module fautif rapidement !

Source

Starcraft2.ai - Le coach IA SC2

Par : Korben ✨
30 avril 2026 à 09:00

Starcraft2.ai débarque en force pour les joueurs de StarCraft 2 et de Brood War qui voudraient disséquer leurs replays sans bouger de leur navigateur. Le créateur de ce site, qui se présente sous le pseudo de Tomkit, a sorti un analyseur gratuit qui combine un moteur de rendu isométrique et un coach IA.

Vous balancez un fichier .SC2Replay (ou .rep pour Brood War), et chose incroyableuuuh, le site reconstruit votre partie complète en vue isométrique avec mouvement des unités, brouillard de guerre activable / désactivable et heatmaps. Comme ça plus besoin de relancer le client pour mater une partie.

Et le truc qui tue, c'est que vous pouvez aussi partager n'importe quel replay via une simple URL.

L'outil derrière ce projet, c'est sc2reader (la bibliothèque Python de référence pour Starcraft) qui parse intégralement les binaires des replays : Position détaillée des unités, séquence des ordres de construction, économie, kills, tout est extrait du fichier directement.

Le truc cool, c'est évidemment le coach IA. L'outil envoie le contexte de la partie (courbe d'éco, build order, échanges d'unités, résultat des batailles) à Claude, qui sort alors un debrief avec des conseils actionnables. Par exemple, le LLM identifie le type de stratégie déployée (timing attack, macro, all-in, cheese) et balance des recommandations basées sur les standards pro. C'est quand même bien plus utile que tous ces guides génériques qu'on retrouve en ligne.

Puis ce qui est cool avec ce logiciel, c'est aussi le support de Brood War et à où j'écris ces lignes, c'est l'un des seuls analyseurs encore maintenus pour le vieux premier StarCraft . Donc pour ceux qui parmi vous ont encore des replays archivés depuis l'ère du modem 56k, c'est carrément une bonne nouvelle !

Bref, si vous jouez encore à SC2 ou si vous voulez juste mater de beaux replays sans lancer le jeu, c'est par ici .

Un agent IA chinois a trouvé près de 1 000 failles inédites, dont certaines dans Microsoft Office

23 avril 2026 à 11:27

360 Digital Security, la filiale cybersécurité du géant chinois Qihoo 360, revendique environ mille vulnérabilités inédites déterrées par un agent IA maison baptisé Vulnerability Discovery Agent. 

L'annonce, faite le 22 avril, cite nommément Microsoft Office et le framework open source OpenClaw parmi les logiciels touchés. Le chiffre est donné sur un seul cycle de campagne.

Mille failles non documentées en un seul cycle de recherche, ça fait un peu tourner la tête. Ce type d'agent fonctionne en boucle pour scanner massivement les bases de code, trier ce qui est potentiellement exploitable, et valider les candidats avant publication interne.

Plus tôt dans l'année, 360 avait déjà présenté un autre outil dédié à la construction automatisée de chaînes d'exploitation. L'un déterre les failles, l'autre fabrique le code qui les utilise.

Mis bout à bout, ça donne une ligne de production offensive entièrement pilotée par IA, que l'équipe 360 décrit comme une réponse directe au projet Mythos d'Anthropic, qui fait le même pari côté occidental mais en mode défense.

Le vrai souci, c'est le devenir de ces 1 000 failles. Si toutes ont été remontées aux éditeurs concernés, tant mieux. 360 affirme d'ailleurs avoir utilisé les canaux de divulgation responsables, mais sans publier de calendrier de patch.

Sauf que l'entreprise est connue pour ses liens étroits avec le ministère chinois de la Sécurité d'État, et plusieurs de ses chercheurs ont déjà été soupçonnés par le passé de garder pour l'État ce qu'ils trouvaient. Du coup, l'annonce met les équipes de sécurité occidentales quelque peu en alerte.

Microsoft, qui patche Office tous les mois pour des failles trouvées à la main, va probablement devoir accélérer le rythme si ce genre de scan industriel se généralise. En pratique, la chasse aux vulnérabilités est en train de changer d'échelle.

On passe de quelques failles trouvées par un chercheur humain sur plusieurs semaines à un agent qui en déniche des centaines en quelques jours. Et la logique économique derrière est folle : un seul opérateur bien outillé peut désormais couvrir ce qu'il fallait avant à une équipe complète.

Bref, le mur est tombé côté IA offensive. Et les éditeurs qui patchent à la main ont un vrai problème de cadence face à un scan automatisé à cette échelle.

Source : Bloomberg

Flipbook - Le web où chaque page est une image IA

Par : Korben ✨
23 avril 2026 à 07:03

Flipbook est un navigateur web génératif où aucune page n'existe avant que vous ne la demandiez. Pas de HTML, pas de boutons, pas de liens... A la place, vous tapez simplement un mot ou un sujet dans la barre de recherche (ou vous uploadez une image), et hop, ça vous pond une image en direct façon "infographie" qui explique ce sujet.

Ensuite, vous cliquez n'importe où sur cette image, et une nouvelle image apparaît qui creuse ce que vous venez de cliquer. En gros, faut imaginer Wikipedia mais avec aucun article pré-écrit puisque chaque page est dessinée par une IA pendant que vous patientez. C'est un genre d'Infinite Wiki en version 100% visuelle !

La page que Flipbook m'a sortie quand j'ai tapé mon nom. Tout ce que vous voyez est une seule image générée par le modèle, y compris le texte.

Perso, j'ai juste tapé mon pseudonyme ce matin pour tester et comme résultat, j'ai obtenu une page intitulée "Korben: The French Tech Influence", avec mon vrai nom Manuel Dorne, le lancement de korben.info noté en 2004, RemixJobs cité et même cette citation : "A cornerstone of the French-speaking web for over two decades" écrit en bas.

Ne vous inquiétez pas pour mes chevilles, c'est pas moi qui le dit mais l'IA qui a chopé ces infos très précises et pour la majorité exacte. Le système de Flipbook fait une vraie recherche web agentique, et pas juste de l'hallucination pure à partir de son modèle. Les créateurs l'expliquent d'ailleurs dans leur FAQ.

Ensuite, il suffit de cliquer sur des éléments de l'image pour qu'une nouvelle image soit générée avec d'autres informations plus précises selon ce sur quoi vous avez cliqué.

Mais le détail qui tue, c'est que TOUT le texte affiché à l'écran est rendu par le modèle d'image lui-même ! Aucune superposition HTML, aucun overlay texte. Les titres, les labels, les légendes, les flèches... tout est dessiné pixel par pixel au moment de la génération, comme si Photoshop crachait une infographie complète à chaque requête.

Le hic c'est que parfois ça bug (le modèle écrit un mot au mauvais endroit, ou fait une petite faute de frappe), mais c'est le choix assumé de l'équipe, qui ne souhaite aucune couche de rendu HTML classique. Sous le capot en fait, y'a LTX Studio (le modèle vidéo de Lightricks) qui anime les transitions en stream vidéo live, et Modal Labs pour l'infra GPU serverless qui encaisse la charge.

Après comme d'hab avec ce genre d'outils c'est que les hallucinations factuelles sont invisibles pour l'utilisateur, puisqu'il n'y a pas de source citée, ni de lien à cliquer pour vérifier.

Et Zain Shah, l'un des créateurs, l'admet lui-même dans son thread de lancement sur X, Flipbook est aujourd'hui limité aux explications visuelles. Donc pas forcément adapté pour du vrai mode interactif (coder, réserver un truc, stocker de la data). Il faudra donc attendre que les modèles d'image et de vidéo deviennent plus rapides, plus précis, et surtout capables de conserver leur état pour assurer une cohérence dans le contenu (texte et images).

Bref, ça vaut le coup de tester , tapez votre nom ou votre animal préféré et voyez ce qui en sort !

Source

bbDump - L'alternative moderne à pgAdmin, sauce MCP

Par : Korben ✨
23 avril 2026 à 07:00

pgAdmin, l'outil "officiel" pour administrer vos bases PostgreSQL, c'est le type d'interface qu'on n'a pas vraiment envie d'ouvrir un lundi matin ! C'est lent, c'est cheum de ouf en mode figé dans les années 2000 et ça rame sérieusement dès qu'on tente un export un peu costaud. Alors oui je sais, DBeaver, c'est plus joli, mais faut se coltiner Java et un workspace qui traîne au démarrage.

Du coup quand bbDump est passé sur mon radar, j'ai eu envie de creuser un peu. C'est un gestionnaire PostgreSQL moderne, en Electron + Vue + TypeScript, signé par Poups, un dev indé français. L'outil reprend tout ce que vous faites habituellement en CLI (pg_dump, pg_restore, coups d'œil aux tables, schéma de la DB) et met ça dans une interface vraiment propre.

Le dashboard bbDump, tout de suite plus respirable que pgAdmin

Côté fonctionnalités classiques, vous avez ce qu'on attend d'un client PostgreSQL correct. Gestion multi-bases organisée par projet, backups avec liste, restauration, filtre par base, tailles et dates. De leur côté, les tâches planifiées via expressions cron sont configurables par base, et il y a même une visionneuse de logs en temps réel qui trace chaque opération pg_dump.

Ajoutez à ça un navigateur de tables avec édition inline (avec support complet des types), un constructeur de requêtes SQL visuel en plus de l'éditeur brut, l'export CSV, et un diagramme entité-relation interactif via Vue Flow pour visualiser les tables et les clés étrangères. Grâce à bbDump, plus besoin d'aller chercher un outil externe pour comprendre une base héritée d'un projet qui traîne !!

Le schema visualizer en mode ERD interactif, pratique pour décortiquer une base héritée

Mais le vrai twist, c'est l'intégration du MCP (Model Context Protocol) puisque bbDump expose 31 outils MCP aux agents IA, ce qui veut dire que votre Claude d'amour ou votre LLM peut interroger la DB, regarder un schéma, tester une requête. Et comme les mutations passent par un système de confirmation, pas de DROP TABLE à l'insu de votre plein gré !

Je vous avais déjà parlé de cette approche avec Ghidra MCP côté reverse engineering et BrowserWing côté automatisation navigateur. bbDump rejoint donc la famille côté backend de données.

Autre détail sympa, le dev a pensé à la sécurité puisque les backups sont chiffrés en AES-256-GCM, donc si vous synchronisez vos dumps sur un cloud random, pas de panique sur les données sensibles. Sur macOS, y'a même une mini-app menu bar pour accéder aux bases et aux connexions proxy sans ouvrir l'app complète.

Côté installation, c'est facile :

curl -fsSL https://poups.dev/bbdump.sh | bash

sur macOS et Linux (qui reste en beta). Bien sûr, si balancer un script dans bash direct vous fait tiquer (normal), vous pouvez aussi chopper le DMG ou l'AppImage en release sur GitHub et inspecter avant. Le code est sous licence MIT, avec une doc dédiée et une page Ko-fi si vous voulez soutenir le projet. Par contre, rien pour Windows pour l'instant.

Le projet est encore tout jeune puisque sorti fin mars de cette année donc si vous cherchez un outil ultra-stable pour une prod critique, attendez un peu. Mais pour vos projets perso, votre dev local, ou juste pour arrêter de râler sur pgAdmin, ça vaut clairement le coup d'œil.

Bref, un dev français de talent qui se lance en indé sur un créneau pourri d'outils vieillots, avec une vision cohérente et une intégration MCP propre, moi j'aime bien. Je pense que Poups mérite d'être soutenu sur ce coup-là, d'où mon article !

Chez Meta, les salariés ne veulent pas installer de logger sur leur PC pour entraîner l'IA

22 avril 2026 à 09:16

Les salariés de Meta devront bientôt installer un logiciel qui enregistre leurs frappes clavier, les mouvements de souris et des captures d'écran régulières sur leur poste de travail.

Le programme s'appelle Model Capability Initiative, et il doit alimenter les futurs modèles d'IA maison capables de faire du travail de bureau en autonomie. L'info a été révélée par The Register cette semaine.

Concrètement, l'outil surveille l'activité sur une liste d'applications professionnelles, dont Gmail, GChat, VCode et l'outil interne Metamate. Meta a justifié le dispositif en expliquant que ses modèles d'IA ne comprennent pas bien comment les humains utilisent un ordinateur.

Les données serviront à entraîner des agents capables de reproduire les micro-gestes que les modèles actuels galèrent à faire, comme sélectionner une option dans un menu déroulant ou enchaîner deux raccourcis clavier. Le directeur technique Andrew Bosworth a expliqué que la vision, c'est d'avoir des agents qui font le boulot pendant que les humains dirigent, relisent et corrigent les sorties.

Côté salariés, l'accueil est glacial. Un ingénieur cité par The Register résume la chose : il y a une différence entre savoir que votre travail est évalué et savoir que chaque frappe clavier peut nourrir un modèle commercial vendu à des clients externes.

L'analyste Ed Zitron, très critique sur l'IA, décrit l'ambiance interne chez Meta comme horrible et parle d'une culture de la paranoïa qui ne va pas s'arranger avec cette nouvelle couche de surveillance.

Le programme cible d'abord les employés basés aux États-Unis. En Europe, les règles sur le pistage des salariés sont beaucoup plus strictes, donc Meta évite de tester ce genre de dispositif sous les yeux de la CNIL irlandaise ou de son équivalent allemand.

Il y a aussi l'ironie évidente de la situation : Meta surveille les utilisateurs depuis quinze ans pour son ciblage publicitaire, et a collectionné les amendes RGPD au passage. Maintenant ce sont ses propres salariés qui passent sous le scanner.

En pratique, ce qui est demandé ressemble à ce que font déjà plusieurs boîtes qui entraînent des agents : il faut des jeux de données de démonstrations humaines sur des tâches réelles pour que l'IA apprenne. Sauf que voilà, Meta franchit un cap en allant chercher ces données dans l'outil quotidien de ses salariés.

Bref, chez Meta le clavier devient un jeu de données d'entraînement. Difficile d'imaginer que des ingénieurs un peu pointus acceptent ça longtemps sans râler, et on les comprend.

Source : The Register

Hazmat - Vos agents IA en cage sous macOS

Par : Korben
8 avril 2026 à 13:30

J'sais pas si vous vous en rendez compte mais les agents IA qui codent sur votre machine ont accès à vos clés SSH, vos credentials AWS, votre Keychain et compagnie. Ils ont accès à TOUT ! C'est comme filer les clés de votre appart à un gars que vous avez croisé sur le parking de Leclerc y'a pas 5 min.

Hazmat prend le problème à l'envers : au lieu de demander poliment à l'agent de se tenir tranquille, il l'enferme dans un compte macOS séparé. Du coup, vos ~/.ssh, ~/.aws, votre Keychain deviennent structurellement inaccessibles. Pour en profiter, faut faire un

brew install dredozubov/tap/hazmat

puis

cd /tmp
hazmat init --bootstrap-agent claude

Et hop, 10 minutes plus tard votre agent tourne dans sa cage. (le premier snapshot est ultra loooong mais après c'est de l'incrémental donc ça ira plus vite)

L'isolation repose sur 3 couches indépendantes, un peu comme les sas d'un sous-marin. Il y a d'abord un utilisateur agent dédié (vos fichiers perso deviennent alors hors de portée, point). Ensuite, une politique seatbelt générée dynamiquement à chaque session qui consiste à ce que le kernel de macOS vérifie chaque accès fichier et refuse tout ce qui n'est pas explicitement autorisé pour cette session précise.

Et par-dessus, des règles pf firewall qui empêchent l'agent d'envoyer du trafic SMTP, IRC, FTP, Tor ou VPN. Comme ça, un agent qui tentera d'exfiltrer vos données par mail se retrouvera bloqué net au niveau du noyau.

Côté supply chain, Hazmat force npm ignore-scripts=true par défaut. Comme ça, par exemple le fameux hack axios qui livrait un RAT via un hook postinstall en 2 secondes chrono n'est plus possible ici ! Y'a aussi une blocklist DNS qui redirige les services de tunnel connus (ngrok, pastebin, webhook.site) vers localhost. Contre un domaine perso fraîchement enregistré, ça passera mais les vecteurs d'exfiltration classiques, ça devrait résister.

Hazmat utilise TLA+, le même formalisme que les ingés d'Amazon utilisent pour vérifier les protocoles de DynamoDB. Genre, l'installation des règles sudoers AVANT le firewall (évidemment, ça crée une fenêtre de vulnérabilité), les restrictions qui bloquaient les lectures mais pas les écritures, ou encore une restauration cloud sans vérifier qu'un snapshot existait...etc, c'est le genre de truc qu'aucun test unitaire n'aurait chopé.

Ça supporte Claude Code (y compris le fameux --dangerously-skip-permissions), OpenCode et Codex. Attention par contre, si votre projet utilise Docker, y'a deux cas de figure : soit le daemon Docker est privé au projet et Hazmat le route automatiquement vers un mode Docker Sandbox, soit c'est un daemon partagé et là faudra passer --docker=none explicitement.

La commande hazmat explain montre aussi exactement ce que le sandbox autorise avant de lancer quoi que ce soit... et ça, c'est pas du luxe quand on sait pas trop ce qu'on va lâcher dans la nature. Le hazmat diff qui affiche les changements faits par l'agent depuis le dernier snapshot Kopia, c'est plutôt bien pensé. Et si l'agent casse un truc ? hazmat restore et c'est reparti, comme un Ctrl+Z géant pour tout votre projet.

Si vous avez déjà configuré votre Mac avec teaBASE pour sécuriser votre env de dev, c'est un complément logique.

Côté limites, faut être honnête, Seatbelt n'est pas documenté par Apple depuis macOS 10.5 et c'est du defense-in-depth, et pas une vraie frontière de VM. Quand à l'exfiltration HTTPS elle n'est pas bloquée car l'agent peut toujours curl n'importe quoi sur le port 443. C'est logique mais bon, c'est pas étanche à 100% quoi...

Et surtout c'est macOS only pour l'instant (le port Linux est en chantier), et bien sûr le /tmp partagé entre les comptes locaux reste un vecteur potentiel. J'aurais aimé aussi que le réseau soit coupé par défaut sauf whitelist, mais bon, faudra attendre. Après entre ça et laisser Claude Code en roue libre avec les pleins pouvoirs sur votre machine... y'a pas photo.

Bref, pour du vibe coding sur Mac, c'est le minimum vital.

Le VLIW, cette architecture de processeur "impossible" qui revient par la porte de l'IA

Par : Korben
8 avril 2026 à 13:10

La chaîne YouTube Asianometry vient de publier une vidéo qui retrace l'histoire du VLIW, une architecture de processeur née dans les années 80 et longtemps considérée comme un échec. Sauf que cette technologie, enterrée avec l'Itanium d'Intel, refait surface dans les puces dédiées à l'intelligence artificielle. Et elle est peut-être déjà dans votre smartphone.

Le principe, et c'est un peu technique

Si vous ne connaissez pas Asianometry, c'est une chaîne qui décortique l'histoire des semi-conducteurs avec un vrai talent de vulgarisation, et cette vidéo sur le VLIW (pour Very Long Instruction Word) ne fait pas exception.

L'idée est assez simple sur le papier. Un processeur classique exécute ses instructions une par une, ou les réordonne à la volée avec du matériel dédié (c'est ce que font les puces modernes avec l'exécution "out-of-order").

Le VLIW fait l'inverse : c'est le compilateur, le logiciel qui transforme le code en instructions machine, qui regroupe à l'avance plusieurs opérations dans un seul "mot" très long. Du coup, le processeur n'a plus qu'à exécuter le paquet en une seule fois, sans se pose la moindre question. Le matos est de fait plus simple, moins gourmand en énergie, et plus rapide.

Le problème, c'est que tout repose sur le compilateur. S'il ne trouve pas assez d'opérations à paralléliser, le processeur tourne à vide. Et écrire un compilateur capable de faire ça correctement, c'est un casse-tête qui a occupé des chercheurs pendant des décennies.

L'Itanium, le plus gros pari raté d'Intel

Les premières tentatives commerciales datent des années 80 avec Multiflow et Cydrome, deux entreprises qui ont fait faillite. Intel a sorti le i860 en 1989, un processeur VLIW quasi impossible à programmer. Et puis il y a eu l'Itanium. Développé avec HP à partir de 1994 sous le nom IA-64, ce processeur devait remplacer le x86 et dominer les serveurs. Les analystes prédisaient la fin des architectures classiques.

Quand l'Itanium est sorti en 2001 après dix ans de développement, les performances étaient décevantes, la compatibilité avec les logiciels existants était catastrophique, et AMD avait entre-temps lancé le x86-64 qui faisait tout pareil en restant compatible avec l'ancien. L'Itanium est devenu un produit de niche avant de disparaître. La presse tech l'a rebaptisé "Itanic", en référence au Titanic.

Le retour par l'intelligence artificielle

Le VLIW n'a jamais complètement disparu. Texas Instruments l'utilise dans ses processeurs de traitement du signal depuis 1997 avec la famille TMS320C6000. Le DSP Hexagon de Qualcomm, celui qui gère l'inférence IA dans les puces Snapdragon, est lui aussi basé sur du VLIW.

Et Groq, la startup qui fait beaucoup parler d'elle pour la vitesse de ses puces d'inférence, utilise une architecture VLIW où le matériel ne prend aucune décision à l'exécution.

L'inférence de réseaux de neurones, c'est justement le type de calcul idéal pour le VLIW : des opérations régulières, prévisibles, massivement parallèles.

Pas besoin de réordonnancer quoi que ce soit, le compilateur peut tout planifier en amont. Des chercheurs travaillent d'ailleurs sur des extensions RISC-V qui intègrent des principes VLIW pour combiner le meilleur des deux mondes.

C'est quand même amusant de voir une technologie enterrée il y a vingt ans revenir grâce à l'IA. Le VLIW a échoué dans les années 2000 parce que le code des logiciels classiques est trop imprévisible pour être optimisé par un compilateur.

Mais l'inférence IA, c'est l'exact opposé : tout est prévisible et régulier. Du coup, l'architecture qui devait remplacer le x86 se retrouve à alimenter les accélérateurs IA de votre Snapdragon. Comme quoi, en informatique, rien ne meurt vraiment.

Source : Hackaday

Linux va abandonner le support du processeur Intel 486, sorti en 1989

Par : Korben
8 avril 2026 à 09:25

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

Glasswing - L'IA d'Anthropic qui déniche des milliers de zero-days

Par : Korben
8 avril 2026 à 04:53

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

Et le truc qui tue, c'est que Mythos n'a pas été entraîné spécifiquement pour la cybersécurité. Il a juste été entraîné pour être bon en code... et par effet de bord, il est devenu redoutable en sécu. En fait, les benchmarks sont assez parlants. Sur CyberGym (reproduction de vulnérabilités), Mythos tape du 83% contre 67% pour Opus 4.6. Mais c'est sur l'exploitation de Firefox 147 (en collaboration avec Mozilla je tiens à le préciser), que le fossé est le plus flippant : 84% de taux de réussite en exploitation shell, contre 15% pour Opus 4.6 et 4% pour Sonnet.

Lors de tests internes , une version précoce de Mythos enfermée dans un sandbox sécurisé a réussi à s'en échapper (on lui en avait donné l'instruction pour le test), a développé un exploit multi-étapes pour accéder à Internet, puis a envoyé un email au chercheur pour le prévenir de son évasion. Le chercheur l'a reçu lorsqu'il était en train de faire sa pause sandwich dans un parc ! Dans moins de 0,001% des cas, ces versions précoces ont même carrément tenté de dissimuler des actions interdites en modifiant l'historique git pour ne pas laisser de traces. Bon, Anthropic précise que ces comportements ont été corrigés dans la version finale parce que c'était clairement pas tolérable... mais quand même.

Ce qui est vraiment impressionnant, c'est cette coalition derrière Glasswind. Apple, Microsoft, Google, AWS, NVIDIA, CrowdStrike, Cisco, Palo Alto Networks, JPMorgan, Broadcom, la Linux Foundation... des partenaires qui d'habitude se tirent dans les pattes, réunis autour de la même table, plus 40 autres organisations.

Le problème c'est que Mythos ne sera pas accessible au public. Trop dangereux. Seuls les professionnels de la sécurité vérifiés y auront droit, via un "Cyber Verification Program" dédié. Je suis triste, j'aurais vraiment kiffé le tester...

Anthropic met 100 millions de dollars de crédits sur la table pour la recherche, plus 2,5 millions pour l'OpenSSF et 1,5 million pour la fondation Apache. Le programme "Claude for Open Source" donne un accès dédié aux mainteneurs de projets open source. C'est du bon gros marketing c'est sûr, mais quand on voit le nombre de mainteneurs open source qui bossent seuls le soir sans budget sécu... franchement, c'est pas de refus.

Du coup, on vient vraiment de passer à une autre échelle.

L'année dernière, o3 d'OpenAI avait trouvé UN zero-day Linux et c'était déjà une première mondiale. Là, Mythos en trouve des milliers et crée des preuves de concept d'exploitation quasiment toujours du premier coup. C'est chouette pour la sécurité mais cette capacité est clairement un couteau à double tranchant. Entre les mains d'un défenseur, c'est un bouclier mais entre les mains d'un attaquant... bon, on préfère pas y penser.

Anthropic s'engage à publier un rapport dans les 90 jours sur les vulnérabilités patchées et à terme, ils veulent créer un organisme indépendant, public-privé, pour coordonner tout ça. Comme l'a dit le CTO de CrowdStrike : "ce qui prenait des mois prend maintenant des minutes".

Bref, Glasswing c'est le moment où l'IA en cybersécurité passe du labo au terrain, mais maintenant reste à voir si le bouclier sera déployé plus vite que l'épée.

CATAI - Des chats pixel art boostés à l'IA sur votre dock

Par : Korben
7 avril 2026 à 13:30

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

La compilation prend genre 3 secondes sur un M1, et le binaire pèse dans les 500 Ko, soit moins qu'une photo iPhone. Y'a aussi un build.sh qui crée un .app propre avec son icône si vous préférez.

Les plus anciens d'entre vous se souviendront peut-être de Neko, le petit chat qui courait après votre curseur, porté sur Mac en 1989 par Kenji Gotoh. L'un des premiers desktop pets connus. Sauf que là, comme on est en 2026, le chat vous fait la conversation via un LLM local. Si vous bidouillez déjà avec Ollama ou que vous avez découvert le LLM caché de votre Mac , c'est un usage auquel vous n'aviez probablement pas pensé.

Notez que sans Ollama, ça fonctionne, les chats se baladent mais restent muets (ce qui est déjà sympa en soi). Et si vous collez un modèle trop lourd genre un 70B, ça va ramer vu que le streaming passe par localhost. Un petit Qwen 2.5 ou Llama 3.2 3B fait largement le taf pour des réponses de chat en 2-3 phrases.

Merci à William pour la découverte.

Il menace un agent du renseignement en parlant à ChatGPT, le RAID débarque chez lui

Par : Korben
7 avril 2026 à 11:09

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

❌
❌