Alerte Zero-Day : la faille critique Dirty Frag permet d'obtenir les droits root sur Linux. Les patchs sont en attente : voici comment se protéger.

Le post Dirty Frag : cette faille zero-day donne les droits root sur Linux a été publié sur IT-Connect.

Nouvelle alerte du côté de Node.js : une faille de sécurité critique a été découverte dans la bibliothèque vm2 : protégez vos applications de la CVE-2026-26956.

Le post vm2 : la célèbre sandbox Node.js affectée par une faille critique (CVE-2026-26956) a été publié sur IT-Connect.

Palo Alto Networks (PAN-OS) : une faille de sécurité zero-day (CVE-2026-0300) exploitable sans authentification et déjà exploitée par des cybercriminels.

Le post Palo Alto Networks alerte sur une nouvelle zero-day déjà exploitée (CVE-2026-0300) a été publié sur IT-Connect.

Une vulnérabilité a été corrigée dans Slider Revolution, un plugin WordPress. Elle permet un attaquant de compromettre totalement un site web.

Le post WordPress : le plugin Slider Revolution doit être mis à jour (CVE-2026-6692) a été publié sur IT-Connect.

Protégez vos serveurs Apache contre la faille CVE-2026-23918 dans le module HTTP/2. Cette vulnérabilité peut entraîner un DoS, et même une RCE.

Le post Faille Apache : deux simples trames suffisent à faire un déni de service (CVE-2026-23918) a été publié sur IT-Connect.

La faille de sécurité critique affectant cPanel et WHM, associée à la référence CVE-2026-41940, est exploitée massivement, y compris avec le ransomware Sorry.

Le post Linux : les données des serveurs cPanel chiffrées par le ransomware Sorry a été publié sur IT-Connect.

Copy Fail (CVE-2026-31431), c'est le nom de la faille critique découverte dans le noyau Linux. Elle offre un accès root sur les distributions Linux depuis 2017.

Le post Copy Fail : cette redoutable faille Linux permet d’obtenir un accès root a été publié sur IT-Connect.

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

Toutes les versions actuellement supportées de cPanel sont affectées par une faille pouvant permettre d'obtenir un accès non autorisé à l'interface de gestion.

Le post Patchez votre serveur : une faille critique a été découverte dans cPanel a été publié sur IT-Connect.

Microsoft a révisé son bulletin de sécurité associé à la CVE-2026-32202 pour informer de son exploitation. Quels sont les risques ? Voici l'essentiel à savoir.

Le post Vols d’identifiants sur Windows : Microsoft révèle l’exploitation de la CVE-2026-32202 a été publié sur IT-Connect.

Une simple commande git push pour compromettre un serveur ? C'est possible grâce à la faille CVE-2026-3854 qui affecte GitHub.com et GitHub Enterprise Server.

Le post Cette faille GitHub est exploitable par un simple Git Push (CVE-2026-3854) a été publié sur IT-Connect.

Pack2TheRoot (CVE-2026-41651), c'est le nom d'une faille de sécurité importante découverte dans un composant omniprésent sur Linux : PackageKit.

Le post Pack2TheRoot : cette vulnérabilité vieille de 12 ans menace Linux a été publié sur IT-Connect.

Microsoft a publié la version 10.0.7 d'ASP .NET sous la forme d'une mise à jour hors bande afin de patcher une faille de sécurité critique : CVE-2026-40372.

Le post Microsoft a publié un patch pour une faille critique dans ASP.NET : CVE-2026-40372 a été publié sur IT-Connect.

La faille CVE-2026-28950 impacte les iPhone et les iPad : le FBI en a fait usage dernièrement pour récupérer des messages Signal via les notifications.

Le post Le FBI exploitait un bug de l’iPhone pour lire les messages Signal supprimés a été publié sur IT-Connect.

Bon, les amis, si vous utilisez Tor Browser pour faire du sérieux, faut que vous sachiez un truc. Le bouton "New Identity", censé vous donner une nouvelle identité vierge à chaque clic... bah il laissait filer, jusqu'à il y a peu de temps, un identifiant stable tant que Firefox tournait.

Deux chercheurs de Fingerprint ont en effet trouvé comment une fonction toute bête du navigateur se transformait en empreinte unique de votre browser, partagée entre tous les sites que vous visitiez.

Il faut donc dès à présent faire la mise à jour vers Firefox 150 ou l'ESR 140.10.0 (la version long-terme utilisée par Tor Browser), ainsi que la dernière version de Tor Browser qui récupère le patch. Si vous voulez en savoir plus, la CVE c'est CVE-2026-6770 , classé comme sévérité modérée par Mozilla.

Le truc marche en vase clos mais traverse les murs.

Mais avant, IndexedDB c'est quoi ?

En gros c'est une mini-base de données que les sites web peuvent créer dans votre navigateur, pour stocker des trucs en local (du cache, des données offline, l'état d'une app web). Chaque site peut y ranger plusieurs bases nommées, et une petite fonction JavaScript indexedDB.databases() permet au site de demander la liste de ses bases.

Rien de foufou sur le papier. Sauf que dans Firefox en navigation privée, le navigateur renomme en coulisse chaque base avec un identifiant aléatoire (UUID), et range tout ça dans une seule grosse table interne. Et le gros problème, c'est que cette table est partagée entre tous les sites ouverts, et pas cloisonnée site par site.

Et là, ça devient croustillant puisque quand un site redemande la liste de ses bases, Firefox la renvoie sans la trier, dans un ordre qui dépend de la structure interne de cette table partagée. Du coup, deux sites totalement différents qui créent chacun seize bases dans le même ordre récupèrent exactement la même suite en retour. Pas l'ordre de création donc mais une permutation bizarre, genre g,c,p,a,l,f,n,d,j,b,o,h,e,m,i,k.

Je vous passe les détails mais ça fait dans les 17 000 milliards de combinaisons possibles. Donc largement de quoi distinguer votre navigateur parmi des millions, comme une empreinte digitale qui colle au doigt !

Et ce qui pique vraiment c'est que cet identifiant survit à la fermeture de toutes vos fenêtres privées. Tant que le process Firefox tourne en arrière-plan, l'ID reste. Un site peut donc vous reconnaître après que vous ayez fermé vos onglets privés, rouvert une session pensée comme neuve, et revisité le site. Pour le user, c'est une session fraîche alors que pour le serveur c'est clairement le même navigateur qu'il y a dix minutes.

Côté Tor Browser c'est pire puisque le bouton "New Identity" a pour mission explicite de couper tout lien avec ce que vous faisiez avant. Il ferme les onglets, efface l'historique, vide les cookies, tire de nouveaux circuits Tor. La promesse officielle, c'est "empêcher votre activité future d'être liée à ce qui précède".

Sauf que cette fameuse table interne, elle, ne bouge pas. Le New Identity reset donc tout sauf ce qu'il ignore. C'est comme changer de fringues dans le même ascenseur... en gardant le même parfum. Techniquement vous êtes différent, mais reconnaissable en deux secondes. Bref, c'est assez grave car un site capable d'exploiter la faille peut lier votre session avant-New-Identity à votre session après-New-Identity.

Tant qu'on n'a pas redémarré Firefox complètement, l'ID persiste.

Les chercheurs disent avoir fait une divulgation responsable, directement à Mozilla et au Tor Project avant publication donc c'est nickel, et les deux équipes ont poussé les patches avant de communiquer sur quoi que ce soit. Donc les utilisateurs à jour sont tout simplement protégés contre cette faille précise.

Après si vous êtes du genre parano, pensez à redémarrer complètement votre Tor Browser entre deux sessions vraiment sensibles. Ça coupe le process Firefox, ça vide cette fameuse table, et ça évite ce genre de surprise pour d'autres leaks similaires qu'on n'aurait pas encore trouvés.

A bon entendeur, salut !!

Source

RedSun, c'est le nom de la nouvelle faille zero-day impactant Microsoft Defender. Elle permet d'obtenir les privilèges SYSTEM sur une machine Windows à jour.

Le post Windows : un chercheur publie la faille RedSun pour se venger de Microsoft a été publié sur IT-Connect.

Une faille critique a été découverte et patchée dans la bibliothèque wolfSSL, particulièrement utilisée sur les systèmes embarqués et l'IoT : CVE-2026-5194.

Le post CVE-2026-5194 : quand un bug dans wolfSSL valide des certificats falsifiés a été publié sur IT-Connect.

Adobe a publié des mises à jour de sécurité pour patcher une faille zero-day dans Acrobat et Acrobat Reader (CVE-2026-34621). Voici comment protéger votre PC.

Le post CVE-2026-34621 – Adobe a publié un patch pour la zero-day exploitée ! a été publié sur IT-Connect.

Depuis décembre 2025, cette faille zero-day dans Adobe Reader est exploitée pour voler des données. L'ouverture d'un PDF piégé suffit à déclencher l'attaque.

Le post Un PDF suffit : cette faille zero-day Adobe Reader menace vos données a été publié sur IT-Connect.