432 CVE du noyau Linux publiées au cours des dernières 24 heures

• D’après le titre sur Hacker News, 432 CVE du noyau Linux ont été publiées au cours des dernières 24 heures, mais la page d’annonce actuelle ne permet pas d’en consulter les détails individuels
• La page d’annonce applique la procédure antibot Anubis afin d’éviter les interruptions de serveur et les restrictions d’accès aux ressources dues à la collecte web à grande échelle
• Avec une preuve de travail (Proof-of-Work) de type Hashcash, la charge pour les accès ordinaires reste faible tandis que le coût cumulé de la collecte massive augmente
• Cette méthode est une solution temporaire utilisée jusqu’à ce que des techniques d’identification des navigateurs headless soient disponibles
• Des fonctionnalités JavaScript récentes sont nécessaires ; les extensions qui les bloquent, comme JShelter, doivent être désactivées pour ce domaine afin d’y accéder

---

État actuel de la page d’annonce des CVE

• Le titre sur Hacker News indique que 432 CVE du noyau Linux ont été publiées au cours des dernières 24 heures, mais la page fournie ne contient ni liste de CVE ni détails
• À la place, seul un écran de calcul de preuve de travail de difficulté 4 s’affiche

Fonctionnement et limites d’Anubis

• La preuve de travail de type Hashcash impose une charge de calcul négligeable à chaque accès individuel, mais génère un coût cumulé pour la collecte à grande échelle
• À l’avenir, l’objectif est d’identifier par empreinte les navigateurs headless, par exemple via le rendu des polices, afin de ne pas afficher la page de preuve de travail aux utilisateurs légitimes
• Les fonctionnalités JavaScript récentes requises par Anubis peuvent être bloquées par JShelter et autres ; il faut donc désactiver ces extensions pour y accéder

[GN⁺]

Réactions sur Lobste.rs

• Un CVE n’est pas la vulnérabilité elle-même mais un identifiant, qui peut être attribué lorsqu’une vulnérabilité réelle est découverte

  • J’ai compris l’intention après coup ; je pense que cela voulait dire que le titre aurait dû être 432 vulnérabilités du noyau Linux

• Le projet du noyau Linux a indiqué à plusieurs reprises qu’il considère la plupart des bugs comme des candidats CVE, à l’exception des correctifs de performance, des correctifs de bugs matériels et de la corruption du système de fichiers

  http://www.kroah.com/log/blog/2026/01/02/linux-kernel-security-work/

  http://www.kroah.com/log/blog/2026/02/16/linux-cve-assignment-process/

  • L’équipe sécurité du noyau ne peut pas savoir partout et de toutes les façons dont le noyau est utilisé, et c’est aussi une conséquence particulière du fait que le noyau Linux soit devenu sa propre autorité de nommage CVE (CNA)
    Le système CVE a été conçu à l’origine pour des produits et s’adapte mal à un noyau de système d’exploitation utilisé comme composant dans de nombreux produits. Idéalement, CachyOS, un fabricant de caméras intégrant le noyau et Red Hat devraient déterminer indépendamment si le même bug est un candidat CVE dans leur propre contexte
    Mais cela pourrait alors produire un CVE distinct pour 300 modèles de caméras, 300 routeurs-serveurs de fichiers au comportement étrange lorsqu’on y branche un périphérique USB, et des dizaines de consoles rétro d’émulation utilisant des cartes SD ; même si c’est structurellement maladroit, il vaut mieux gérer cela au niveau du composant pour l’ensemble de l’écosystème
  • Les bugs de corruption du système de fichiers peuvent aussi être considérés comme des candidats CVE

• Je me demande s’il y a parmi eux des vulnérabilités particulièrement intéressantes

• Un grand nombre d’entrées commencent par la formule « La vulnérabilité suivante a été corrigée dans le noyau Linux »

• Je n’ai pas pu résister et j’ai demandé à un LLM d’inventer un nom accrocheur pour chaque CVE
  https://git.infradead.org/~rw/cvenames-2026-07-19.html

• Si l’on regarde la première entrée liée à XFS, le problème ne se produirait qu’avec un journal manipulé
  En pratique, l’exploitation semble nécessiter de mettre le système de fichiers hors ligne puis d’écrire directement sur le périphérique bloc où le journal est stocké ; dans ce cas, il semblerait qu’il faille des privilèges root ou un accès physique, ainsi que la capacité d’arrêter le système. Je me demande si je comprends mal le journal XFS

  • Ce n’est peut-être pas une menace pour des serveurs qui ne montent pas automatiquement les clés USB ou les cartes SD et qui disposent en plus d’une surveillance physique, mais cela peut affecter d’autres environnements Linux
    Par exemple, quelqu’un pourrait vous donner une carte SD en disant qu’elle contient des « photos », alors qu’elle embarque un système de fichiers XFS malveillant ; une fois branchée chez vous, cela pourrait déclencher une chaîne d’exploitation. Le montage d’un système de fichiers devrait être une opération sûre, comme l’ouverture d’un fichier image
  • Ce n’est pas parce que c’est peu probable que ce n’est pas une vulnérabilité potentielle, et le contexte d’utilisation compte aussi
    Il peut exister des appareils de type kiosque qui montent automatiquement les périphériques de stockage, et des problèmes qui paraissent irréalistes en temps normal deviennent des attaques réalistes quand plusieurs défauts ou un environnement particulier se combinent
  • Dans une installation d’hébergement en colocation, une attaque consistant à brancher un périphérique USB ou un HDD sur un serveur aurait probablement un taux de réussite d’environ 95 %
    Même si c’est filmé par caméra, il serait difficile de vérifier clairement qu’il n’a pas été branché sur un autre serveur du même rack