CVE-2026-43456 : la faille noyau Linux cachée depuis 19 ans, payée 80 000 $

Le 7 juillet 2026, les chercheurs Yuki Koike et Kota Toda, de GMO Cybersecurity (Ierae), ont publié les détails complets de CVE-2026-43456, une faille de type confusion nichée dans le module bonding du noyau Linux. Son origine remonte à un commit fusionné en 2007 : pendant près de 19 ans, personne n'avait identifié qu'il s'agissait d'une porte d'entrée exploitable, avant sa correction en mars 2026.

Signalée via le programme de bug bounty kernelCTF de Google, cette découverte a rapporté plus de 80 000 dollars aux deux chercheurs. Le détail qui doit retenir votre attention : un exploit basé sur cette faille aboutit en moins d'une seconde, avec un taux de succès supérieur à 99 %. Voici ce qu'il faut comprendre, et surtout, comment vous protéger si vous gérez des serveurs Linux.

Un bug vieux de 19 ans, comment est-ce possible ?

Pour comprendre la faille, il faut d'abord savoir ce qu'est le bonding sous Linux : une fonctionnalité réseau qui permet de regrouper plusieurs interfaces physiques (les slaves) en une seule interface logique (le bond), utilisée couramment pour la redondance ou l'agrégation de bande passante sur des serveurs de production.

Le code incriminé se trouve dans la fonction bond_setup_by_slave(), appelée quand une interface est attachée à un bond. Cette fonction copie plusieurs propriétés de l'interface esclave vers l'interface bond, dont son header_ops, une table de fonctions qui gère le traitement des en-têtes de paquets réseau. Le raisonnement de départ paraît logique : si le bond doit se comporter comme l'interface qu'il encapsule, autant réutiliser ses fonctions de traitement d'en-tête.

Le problème, c'est que certaines de ces fonctions lisent et modifient une zone de mémoire privée propre à chaque type de périphérique réseau (dev->priv). Pour un bond, cette zone correspond à une structure struct bonding. Pour un tunnel GRE ou IP6GRE utilisé comme esclave, elle correspond à une structure struct ip_tunnel ou struct ip6_tnl, totalement incompatible en mémoire avec struct bonding. En réutilisant les fonctions de traitement d'en-tête du tunnel sur un bond, le noyau finit par lire et écrire dans une zone mémoire en l'interprétant avec le mauvais type de structure : c'est la définition même d'un type confusion, une classe de vulnérabilité qui ouvre la voie à la corruption mémoire.

Une portée quasiment maximale

Les versions concernées vont de Linux 2.6.24 à 6.12.77, ce qui couvre pratiquement l'intégralité des noyaux en production depuis près de deux décennies. Déclencher la faille nécessite toutefois la capability CAP_NET_ADMIN, réservée en théorie à des utilisateurs privilégiés ou à des processus réseau de confiance.

C'est justement ce point qui mérite votre vigilance si vous exploitez des conteneurs. Les espaces de noms utilisateur non privilégiés (user namespaces), largement utilisés par Docker en mode rootless ou par certains runtimes de conteneurs, permettent à un utilisateur standard d'obtenir des capabilities comme CAP_NET_ADMIN à l'intérieur de son propre namespace. Un simple conteneur non privilégié peut donc suffire à réunir les conditions d'exploitation.

Comment vous protéger dès maintenant

La faille a été corrigée en mars 2026 et le correctif est progressivement intégré aux noyaux des principales distributions. La priorité absolue reste donc la mise à jour de votre noyau vers une version patchée.

Si une mise à jour immédiate n'est pas possible sur certains de vos serveurs, deux mitigations existent, à choisir selon votre contexte :

• Désactiver les espaces de noms utilisateur non privilégiés, ce qui empêche un utilisateur standard d'obtenir CAP_NET_ADMIN :

sysctl -w kernel.unprivileged_userns_clone=0

Attention, cette option casse des fonctionnalités qui reposent sur ce mécanisme, comme Docker en mode rootless.

• Désactiver le module bonding, si vous ne l'utilisez pas (c'est le cas de la grande majorité des environnements) :

echo "install bonding /bin/false" > /etc/modprobe.d/disable-bonding.conf

rmmod bonding 2>/dev/null

Notre lecture chez CZSyn

Cette affaire illustre un problème que l'on rencontre régulièrement en audit de sécurité chez nos clients : la dette technique invisible dans le code d'infrastructure partagé. Une seule ligne, écrite en 2007 pour simplifier la gestion des en-têtes réseau, a suffi à ouvrir une voie d'élévation de privilèges pendant près de deux décennies, sans qu'aucun audit ni fuzzing n'ait permis de la repérer avant les travaux de GMO Cybersecurity.

Pour une PME ou une équipe technique qui gère ses propres serveurs, VPS ou clusters Kubernetes, la leçon concrète est double. D'abord, le versioning du noyau ne doit jamais être un angle mort de votre politique de mise à jour : un serveur qui tourne depuis des années sans redémarrage ni mise à jour du noyau porte potentiellement des failles de ce type. Ensuite, l'usage de capabilities comme CAP_NET_ADMIN à l'intérieur de conteneurs mérite d'être audité au cas par cas : ce n'est pas parce qu'un conteneur est non privilégié qu'il ne peut obtenir aucun privilège réseau sensible.

Le programme kernelCTF de Google, qui a financé cette découverte à hauteur de plus de 80 000 dollars, montre aussi la valeur des bug bounties bien dotés sur des composants critiques et rarement audités comme le module bonding. C'est ce genre d'incitation qui permet de faire remonter des bugs dormants avant qu'un acteur malveillant ne les trouve en premier.

Sources primaires

• GMO Cybersecurity (Ierae), « 19+ Years Hidden, $80,000+ Rewarded: Reporting a Linux Kernel Zero-Day for Google kernelCTF », 7 juillet 2026.
• Google Security Research, dépôt officiel du programme kernelCTF.
• Kernel.org, site officiel du noyau Linux.