Une nouvelle faille dans OVSwrap sous Linux permet aux utilisateurs locaux d'obtenir les privilèges root sur les systèmes configurés par défaut

En bref

Aller directement à la version longue ↓

Description : CVE-2026-64531, également connu sous le nom d’OVSwrap, est une vulnérabilité de l’élevation de privilèges locaux du noyau Linux dans le chemin de validation des actions d’Open vSwitch. Un champ de longueur de 16 bits subit un débordement lorsque le noyau construit une action imbriquée trop volumineuse, et l’analyseur reprend la lecture à l’intérieur d’octets contrôlés par l’attaquant, qui sont ensuite traités comme des actions Open vSwitch légitimes. Aller à cette section →

Impact : un utilisateur local ordinaire peut divulguer des pointeurs du noyau, lire la mémoire du noyau et effectuer une écriture ciblée. La preuve de concept publique enchaîne ces actions pour former un chemin complet de corruption des identifiants qui permet d'écrire une entrée dans le fichier `sudoers` et d'ouvrir un shell root. Elle est fournie avec des décalages précalculés pour environ 800 versions du noyau x86-64. Aller à cette section →

Gravité : avec un score de gravité de 7,8, considérez cette vulnérabilité comme hautement prioritaire. L'exploitation ne nécessite qu'un compte local standard, rien de plus : aucune configuration Open vSwitch, aucun processus ovs-vswitchd en cours d'exécution, aucun pont OVS, aucun droit CAP_NET_ADMIN dans l'espace de noms initial, aucun conteneur privilégié. La commande `unshare -Urn` attribue ce droit au sein d'un espace de noms créé par l'attaquant. Accéder à cette section →

Qui est concerné : tout noyau concerné sur lequel les espaces de noms utilisateur sans privilèges sont autorisés et où le module openvswitch peut être chargé. Il s'agit de la configuration par défaut sur la plupart des distributions. Portée confirmée par notre propre analyse des rétroportages : Enterprise Linux 9.7 et versions ultérieures, Enterprise Linux 10.1 et versions ultérieures, Debian 12 et 13, Ubuntu 22.04 et 24.04, ainsi qu’Amazon Linux 2023. Aller à cette section →

Statut : Il ne s'agit pas d'une faille « zero-day ». Signalée en privé le 19 juin 2026, elle a été corrigée dans les branches stables le 24 juillet. L'enregistrement CVE et l'annonce CVE pour Linux ont été rendus publics le 27 juillet, suivis par la description complète et un exploit fonctionnel le 28 juillet. Aucune exploitation publique n'a été signalée à ce jour. Aller à cette section →

Procédez dès maintenant comme suit : appliquez un noyau fourni par le fournisseur et redémarrez, ou déployez le correctif « live » sans redémarrage de KernelCare (qui a déjà été déployé automatiquement chez les utilisateurs de plusieurs distributions). Si l'hôte n'utilise pas Open vSwitch, bloquez le module en attendant. À noter : la configuration « apparmor_restrict_unprivileged_userns » et les paramètres de renforcement de sécurité « userns » associés sous Debian et Ubuntu n'empêchent pas cette chaîne d'attaques. Notre équipe chargée du noyau les a testés. Aller à cette section →

Vérifier si le module est chargé n'est pas le bon test. Vérifiez s'il est présent sur le disque pour le noyau en cours d'exécution :

ls /lib/modules/$(uname -r)/kernel/net/openvswitch/openvswitch.ko* 2>/dev/null

Si cela affiche un chemin d'accès, l'hôte reste exposé jusqu'à ce que le noyau soit corrigé ou que le module soit bloqué, qu'il ait déjà été chargé ou non.

La plupart des hôtes exposés à OVSwrap n'ont jamais utilisé Open vSwitch en toute connaissance de cause. C'est justement cela qui prend les équipes au dépourvu.

OVS est largement associé aux réseaux définis par logiciel : OpenStack, OVN, les CNI de Kubernetes, les plateformes de virtualisation. Si aucun de ces éléments ne figure dans votre pile, on peut raisonnablement supposer que cette vulnérabilité (CVE) ne vous concerne pas. Cependant, le code vulnérable est fourni sous forme de module chargeable dans le paquetage standard du noyau de presque toutes les distributions courantes, et le noyau le charge à la demande lorsqu’une application le sollicite.

Un utilisateur sans privilèges en fait la demande. Il crée un espace de noms utilisateur et réseau privé, qui lui accorde le droit CAP_NET_ADMIN au sein de cet espace de noms, ce qui suffit pour installer les flux Open vSwitch via l'interface Netlink. La requête charge automatiquement le module dans le noyau de l'hôte. Aucune intervention de l'administrateur, aucun fichier de configuration, aucun démon.

Ainsi, « nous n'utilisons pas Open vSwitch » n'est pas une remarque concernant l'exposition. Il s'agit plutôt de savoir si le blocage du module entraînera des dysfonctionnements, ce qui est une question différente et plus pertinente.

Le timing est l'autre élément à prendre en compte. Le commit en amont 3f1f75536668 a été intégré à la branche stable quatre jours avant que l'exploit ne soit rendu public ; les flottes utilisant des cycles de mise à jour rapides pour le noyau stable pourraient donc déjà être protégées. Ces quatre jours correspondent également à l'intervalle total entre la « mise à disposition du correctif » et l'« exploit fonctionnel avec des décalages pour 800 versions ».

Les actions Open vSwitch sont transmises sous forme d'attributs Netlink. Chacune d'entre elles commence par un en-tête de type struct nlattr contenant un champ nla_len de 16 bits, pouvant représenter au maximum 65 535 octets.

Lorsque OVS valide un flux, il développe les actions imbriquées en un flux d'actions interne généré par le noyau lui-même. C'est l'attribut OVS_ACTION_ATTR_CLONE qui est en cause ici, car il encapsule une autre liste d'actions et peut donc s'imbriquer. Le code vulnérable ne vérifiait jamais si un attribut imbriqué généré tenait toujours dans le champ de longueur de 16 bits.

[Attacker enters a private user and network namespace]
|
v
[Attacker gains CAP_NET_ADMIN inside that namespace]
|
v
[Attacker installs a flow packing hundreds of conntrack
actions inside a CLONE wrapper]
|
v
[Generated nested action stream exceeds 65,535 bytes]
|
v
[Length is stored in the 16-bit nla_len field and wraps
to a small value]
|
v
[Parser resumes mid-stream, inside attacker-controlled data]
|
v
[Forged action headers are parsed as real OVS actions]
|
v
[Kernel read and constrained write primitives]
|
v
[Host-process credentials corrupted, root shell]

L'exploit regroupe des centaines d'actions conntrack au sein d'un wrapper CLONE. Lorsque OVS les développe, le flux généré dépasse la capacité de nla_len ; la valeur est alors tronquée et ramenée à une valeur très faible, ce qui fait que l'analyseur s'arrête à un décalage erroné. Il reprend ensuite à mi-chemin du flux, à partir d'octets choisis par l'attaquant et agencés de manière à ressembler à des en-têtes d'actions valides. Le noyau les traite alors comme des actions authentiques.

Les seules contraintes réelles concernent les conditions d'accessibilité : x86-64, un chemin de données du noyau OVS prenant en charge conntrack et FTP-helper, et la création d'espaces de noms sans privilèges autorisée. Un noyau de distribution x86-64 standard avec les conteneurs « rootless » activés répond à ces trois critères.

C'est à partir des actions forgées que proviennent les primitives.

Les actions SET sur un faux tunnel entraînent une fuite de pointeur du noyau et une lecture de la mémoire du noyau. Un chemin de nettoyage distinct de la destination du tunnel entraîne une écriture restreinte, sous la forme d'une décrémentation ciblée du compteur de références sur 32 bits.

Une simple réduction de 32 bits semble trop insignifiante pour avoir une quelconque importance, et c'est effectivement le cas en soi. C'est le contexte dans lequel elle s'inscrit qui lui confère toute sa portée. Avant d'accéder à l'espace de noms, l'exploit crée un processus fils qui reste côté hôte. Il cible ensuite la réduction sur les identifiants de ce processus, et une fois que celui-ci dispose des privilèges nécessaires, il ajoute une entrée dans la configuration de sudoers et lance un shell root.

Il en résulte une élévation de privilèges fiable, plutôt qu'un plantage. Grâce aux décalages précalculés pour environ 800 versions du noyau, le travail nécessaire pour reproduire ce phénomène sur une cible prise en charge est quasi nul.

Deux conditions déterminent si un hôte peut être exploité, et toutes deux sont activées par défaut presque partout : les espaces de noms d'utilisateurs sans privilèges sont autorisés, et openvswitch fait partie du paquet standard du noyau sans aucune restriction de chargement automatique. Les distributions laissent les espaces de noms activés car Podman sans droits root, Docker sans droits root, Bubblewrap, Flatpak, la fonction unshare(1) sans privilèges et le bac à sable de Chromium en dépendent tous.

L'attaque décrite ne nécessite pas :

• Un processus ovs-vswitchd en cours d'exécution
• Un pont Open vSwitch existant
• Toute configuration antérieure d'Open vSwitch
• CAP_NET_ADMIN dans l'espace de noms de l'hôte
• Un conteneur privilégié
• Le module à charger avant le début de l'attaque

Cela signifie que la surface d'attaque est plus étendue que celle des hôtes qui exécutent activement OVS : elle inclut les systèmes vulnérables sur lesquels le module est simplement accessible à un utilisateur sans privilèges qui pourrait le déclencher, et les tests menés par le chercheur ont montré que cela concernait la plupart des distributions testées dans leur configuration d'origine.

Imaginez un peu le scénario. Un outil de build partagé exécutant tout ce qui a été poussé lors de la dernière demande de fusion. Un nœud multi-locataires où le code client s'exécute sous un compte ordinaire. Un poste de travail de développeur équipé de conteneurs sans droits root et comportant quelques centaines de dépendances que personne n'a lues. Dans chaque cas, l'attaquant dispose déjà du compte local, et le module dont il a besoin n'est qu'à une requête Netlink de se charger.

La décision concernant chaque hôte est brève :

• Si l'hôte n'utilise pas OVS et qu'aucun élément de celui-ci ne dépend de ponts basés sur OVS, bloquez le module. Cela permet de supprimer le chemin d'exécution vulnérable plutôt que de simplement bloquer une voie d'accès à celui-ci.
• Si l'hôte utilise bien OVS, qu'il s'agisse d'un nœud OVN ou OpenStack Neutron, d'un cluster Kubernetes exécutant ovn-kubernetes ou Antrea, ou encore d'un hôte libvirt ou oVirt doté de ponts basés sur OVS, ne modifiez pas le module. Refusez plutôt les espaces de noms des utilisateurs non privilégiés ou appliquez le correctif.

La faille est ancienne, mais la fenêtre d'exploitation ne l'est pas

Deux dates sont importantes, et les confondre conduit à une erreur dans le triage.

Cette affectation non sécurisée au champ de longueur de 16 bits existe depuis environ 13 ans. Pendant la majeure partie de cette période, une limite conditionnelle distincte plafonnait le flux d'actions généré à 32 KiB, ce qui empêchait une action d'atteindre une taille suffisante pour dépasser la valeur de nla_len. Cette limite a été supprimée en mars 2025, ce qui a rendu ce bogue latent exploitable.

En termes de branche principale, la fenêtre de vulnérabilité s'ouvre aux alentours de la version 6.14 de Linux. Les anciennes branches à long terme sont devenues vulnérables lorsque la suppression de la limite a été rétroportée dans celles-ci, et non pas au moment où le bogue initial a été créé.

Plages de valeurs stables publiées :

• 5.15.180 à 5.15.211
• du 6.1.132 au 6.1.177
• du 6.6.84 au 6.6.144
• de la version 6.18.0 à la version 6.18.39
• 7.1.0 à 7.1.4

Versions dont les premiers correctifs ont été signalés : 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40 et 7.1.5.

Les noyaux des éditeurs divergent de la version en amont dans les deux sens ; les plages indiquées ci-dessus constituent donc un point de départ plutôt qu'une réponse définitive. Certains noyaux 5.14 dérivés de RHEL intègrent la modification d'activation et sont concernés bien qu'ils se situent en dessous de toutes les plages du tableau. Certains noyaux SUSE 6.12 ont conservé l'ancienne limite et ne sont pas concernés bien qu'ils se situent à l'intérieur de l'une d'entre elles.

Les distributions d'entreprise effectuent également le portage en amont de modifications individuelles sans adopter la version en amont ; ainsi, un noyau dont la version se situe en dehors de la plage publiée peut tout de même comporter la combinaison vulnérable. Cette plage a été introduite directement dans la branche de développement 6.14, puis étendue aux branches à long terme plus anciennes à mesure que cette modification y était portée. Vérifiez l'avis de sécurité ou l'état du correctif pour le noyau de la distribution concernée.

La validation a1e64addf3ff, intitulée « net : openvswitch : suppression de la vérification de la longueur des actions présentant un comportement anormal », a supprimé cette limite en mars 2025, car elle provoquait des défaillances imprévisibles, les actions OVS pouvant s'allonger ou se raccourcir lors de leur conversion en format interne. La suppression de la vérification de la longueur totale était justifiée. Cela a eu pour effet secondaire de ne plus empêcher un attribut imbriqué individuel de dépasser 65 535 octets.

Notre analyse du noyau a confirmé l'existence d'une faille de sécurité dans les familles de plateformes prises en charge suivantes :

• Enterprise Linux 9.7 et versions ultérieures
• Enterprise Linux 10.1 et versions ultérieures
• Debian 12 (uniquement les versions 6.1.132-1 et ultérieures) et Debian 13
• Ubuntu 22.04 LTS et Ubuntu 24.04 LTS
• Amazon Linux 2023

La portée d'Enterprise Linux couvre les noyaux RHEL, AlmaLinux, Rocky Linux et CloudLinux correspondants, dans la mesure où ils partagent le code concerné. CloudLinux 9 utilise le noyau AlmaLinux 9 et CloudLinux 10 utilise le noyau AlmaLinux 10 ; ces deux versions sont donc directement exposées à cette vulnérabilité.

La couverture dépend de la version et de la variante. Il ne faut pas en déduire qu'une branche adjacente est vulnérable ou corrigée simplement parce qu'une autre version de la même distribution figure dans la liste.

Deux points restent encore en suspens. Enterprise Linux 8 et CloudLinux 8, qui utilisent leur propre branche de noyau distincte de celle d’AlmaLinux 8, n’ont pas encore fait l’objet d’une confirmation, pas plus qu’Ubuntu 20.04 et les anciennes branches Debian et Ubuntu à support à long terme. La question qui se pose pour toutes ces distributions est de savoir si elles ont intégré le portage de la suppression de la limite.

Une hypothèse concernant la sécurisation qu’il convient d’écarter d’emblée : le chercheur indique que ni SELinux ni AppArmor n’ont bloqué aucune étape de l’exploitation lors des tests, à l’exception de la politique d’AppArmor relative à l’espace de noms utilisateur qui empêche la création d’espaces de noms sur certaines versions d’Ubuntu, ce qui est abordé ci-dessous. Le mode « Enforcing » ne change rien au résultat dans ce cas précis.

Pourquoi les restrictions courantes relatives à l'espace de noms utilisateur peuvent ne pas être utiles

C'est la partie qui risque le plus de faire perdre un week-end à quelqu'un.

Les versions récentes d'Ubuntu intègrent une politique AppArmor qui restreint la création d'espaces de noms par des utilisateurs non privilégiés, contrôlée par le paramètre `kernel.apparmor_restrict_unprivileged_userns`. C'est le premier levier sur lequel la plupart des équipes se tournent, et il bloque effectivement la commande `unshare -Urn` : sous Ubuntu 24.04 et 26.04, toute tentative directe échoue lorsque la politique par défaut est activée.

Ce n'est pas une mesure de protection sur laquelle vous devriez compter. Une faille permettant de contourner AppArmor, documentée publiquement, rend la politique inefficace sur la version 24.04, et sur la version 26.04, l'exploit fonctionne dès que la restriction est désactivée. Notre propre équipe chargée du noyau a réussi à atteindre le chemin vulnérable alors que les paramètres de renforcement de sécurité de ces versions de Debian et d'Ubuntu étaient activés. Considérez cette politique comme un simple ralentisseur en attendant la publication d'un correctif.

Le fait d'interdire purement et simplement la création d'espaces de noms rompt effectivement la chaîne publiée, car l'attaquant ne peut plus accéder à CAP_NET_ADMIN via la commande « unshare -Urn ». Le contrôle qui provoque cela est celui en amont :

# /etc/sysctl.d/99-ovswrap.conf
user.max_user_namespaces = 0

sudo sysctl --system

Utilisez `user.max_user_namespaces` plutôt que `kernel.unprivileged_userns_clone`. Ce dernier est un correctif en aval de la famille Debian, désormais obsolète, qui n'existe pas du tout sur Enterprise Linux ; quant à Ubuntu, où les deux peuvent être présents, le fait de ne définir que le paramètre `unprivileged_userns_clone` peut laisser une voie résiduelle à la création d'espaces de noms, selon la version du noyau.

Vérifiez la valeur effectivement prise en compte, car un fichier de distribution situé dans /usr/lib/sysctl.d/ et appliqué ultérieurement prévaudra sans avertissement :

sysctl user.max_user_namespaces

Le coût lié à la compatibilité est bien réel. Les outils de conteneurs sans accès root cessent de fonctionner, la commande `unprivileged unshare(1)` ne fonctionne plus et le bac à sable de Chromium tombe en panne. Sur un parc d'hébergement ou de bases de données classique, personne ne s'en rend compte. Sur les postes de travail des développeurs et les hôtes de compilation de conteneurs, cela se remarque en quelques minutes.

Existe-t-il une solution de contournement ?

La solution temporaire appropriée dépend du fait que l'hôte utilise ou non Open vSwitch. Aucune de ces deux options ne remplace la correction définitive.

1. Bloquez le module Open vSwitch. Cette opération est recommandée sur tout hôte qui n'utilise pas OVS, ce qui est le cas de la plupart des parcs de serveurs d'hébergement. Vérifiez d'abord avec la commande `lsmod | grep openvswitch` qu'aucun processus `ovs-vswitchd` n'est en cours d'exécution. Ensuite :

# /etc/modprobe.d/99-ovswrap.conf
blacklist openvswitch
install openvswitch /bin/false

C'est la ligne « install » qui effectue l'opération. Une entrée dans la liste noire ne suffit pas à elle seule à empêcher la demande de module à la demande effectuée par le noyau lui-même, ce qui est précisément la voie empruntée par cette faille ; l'ajout à la liste noire ne constitue donc pas une mesure de protection suffisante dans ce cas. Notez que l'utilisateur root peut toujours passer outre une directive « install » à l'aide de la commande « modprobe –ignore-install », et que les modules chargés de force via l'initramfs ne sont soumis à aucune de ces deux directives.

Cette règle bloque uniquement les chargements futurs. Si le module se trouve déjà en mémoire, arrêtez tout ce qui en dépend et déchargez-le ; cela ne nécessite pas non plus de redémarrage :

sudo modprobe -r openvswitch

Le fichier du module reste sur le disque et la commande `modinfo openvswitch` continue de renvoyer des informations par la suite. C'est normal. La règle cesse d'être chargée ; elle ne supprime rien.

N'appliquez pas cette configuration sur les nœuds de calcul et de réseau OVN ou OpenStack Neutron, sur les clusters Kubernetes utilisant ovn-kubernetes ou Antrea, ni sur les hôtes libvirt et oVirt dotés de ponts basés sur OVS. Le blocage du module dans ces environnements entraînera une interruption de la connectivité réseau.

2. Refusez les espaces de noms aux utilisateurs non privilégiés. Utilisez le paramètre sysctl « user.max_user_namespaces » mentionné ci-dessus. Il fonctionne quel que soit l'état du module, ce qui en fait la solution de secours pour les hôtes qui exécutent véritablement OVS, au prix de la rupture de fonctionnement des outils « rootless » déjà décrite. Testez-le d'abord sur vos charges de travail.
3. Manipulez avec précaution le dispositif de protection BPF tiers. Le référentiel public d'exploits fournit un dispositif de protection d'urgence basé sur BPF. Nous ne l'avons pas testé. Vérifiez-le et validez-le sur des systèmes représentatifs avant toute utilisation en production, et ne le considérez pas comme équivalent à un correctif fourni par le fournisseur.

Une fois le correctif appliqué, supprimez la restriction d'espace de noms si elle n'est plus nécessaire :

sudo rm -f /etc/sysctl.d/99-ovswrap.conf

Le bloc de modules peut rester en place. Il n'est pas lié à une version spécifique du noyau, il résiste aux mises à jour et aux redémarrages, et sur un hôte qui n'utilise pas Open vSwitch, il permet de réduire considérablement la surface d'attaque. Documentez-le afin que la personne suivante comprenne pourquoi la mise en réseau échoue si cet hôte venait à avoir besoin d'OVS, puis supprimez-le à l'aide de la commande `rm /etc/modprobe.d/99-ovswrap.conf`.

La correction en amont correspond au commit 3f1f75536668, intitulé « net : openvswitch : rejet des attributs d'action imbriqués trop volumineux ».

Elle ajoute une validation qui rejette toute action imbriquée générée dont la taille ne peut pas être représentée en toute sécurité dans `nla_len`. Plutôt que de laisser une valeur trop grande être tronquée à 16 bits, le noyau interrompt l'action non valide lors de la validation, avant que le flux mal formé n'atteigne le chemin de données.

Cette modification s'inscrit dans le chemin de validation plutôt que dans le chemin rapide de traitement des données. Elle ne nécessite aucune migration des structures de données du noyau ni aucun état persistant par tâche, ce qui la rend adaptée à l'application de correctifs sans redémarrage.

Appliquer le correctif et vérifier le noyau en cours d'exécution

L'installation d'un paquet de noyau mis à jour n'applique pas de correctif au noyau en cours d'exécution en mémoire. Pour une mise à jour classique : installez le paquet corrigé correspondant exactement à votre distribution et à votre version, redémarrez, puis vérifiez que le noyau corrigé est bien en cours d'exécution.

uname -r

Comparez cela avec l'avis du fournisseur concerné, et non avec la version la plus récente du paquet présente sur le disque. Et ne partez pas du principe qu'un noyau compilé après le 24 juillet 2026 intègre le correctif. Les numéros de version des distributions ne correspondent pas aux versions en amont ; la vulnérabilité a été introduite dans ces branches via un backport, et le correctif a été rétroporté selon des calendriers distincts.

Patching sans redémarrage

KernelCare applique la même logique de validation « en amont » au noyau actif. Une fois corrigé, OVS rejette les actions imbriquées générées trop volumineuses avant que la longueur ne boucle, sans qu'il soit nécessaire de désactiver Open vSwitch, de modifier la politique du module ou de redémarrer la charge de travail. Il s'agit d'un bug propre au noyau, sans composant de bibliothèque en espace utilisateur à rechercher.

La plupart des déploiements récupèrent automatiquement les nouveaux correctifs en arrière-plan à intervalles réguliers, généralement toutes les quatre heures. Pour les récupérer à la demande à partir du flux de production :

kcarectl --update

Lorsqu'un correctif est encore en cours de test pour votre famille de noyaux :

kcarectl --update --prefix test

Vérifiez ensuite si le CVE figure dans les informations relatives au correctif installé :

kcarectl --patch-info | grep 'CVE-2026-64531'

Vérifiez que le correctif est bien disponible pour la version exacte du noyau en cours d'exécution avant de supprimer toute mesure d'atténuation temporaire. Si le correctif n'a pas encore été intégré pour votre famille de noyaux, maintenez le blocage du module ou la restriction d'espace de noms en place.

Détection et analyse des incidents

Il n'existe pas d'indicateur unique et incontestable ; considérez donc tout ce qui est présenté ici comme une piste plutôt que comme une preuve.

Le signal le plus utile est le module lui-même. Sur un hôte où Open vSwitch n'a aucune utilité légitime, la présence d'« openvswitch » dans la commande `lsmod` constitue en soi une anomalie, et il vaut la peine d'examiner les enregistrements d'audit de chargement de modules ou les entrées de journal qui s'y rapportent. Ce signal disparaît dès que vous déployez le bloc `modprobe` ; veillez donc à vérifier avant de l'appliquer.

Vérifiez ensuite ce que fait le PoC publié avec ses droits d'accès root :

sudo stat /etc/sudoers /etc/passwd /etc/shadow
sudo find /etc/sudoers.d -maxdepth 1 -type f -printf '%TY-%Tm-%Td %TH:%TM:%TS %p\n'

Les entrées inattendues dans le fichier `sudoers` ou les nouveaux fichiers présents dans le répertoire `/etc/sudoers.d/` sont des traces laissées par la démonstration de concept publiée ; toutefois, un attaquant disposant des droits root pourrait ignorer complètement cette étape. Recherchez également les comptes nouveaux ou ayant récemment obtenu des privilèges, les clés SSH inexpliquées, ainsi que les acquisitions de privilèges ne correspondant à aucun événement `sudo`, de connexion ou d'authentification, car les identifiants corrompus par une écriture dans le noyau ne laissent aucune trace d'authentification.

Autres indices comportementaux : des processus sans privilèges créant des espaces de noms utilisateur et réseau alors qu'aucune charge de travail ne le fait normalement ; un processus s'exécutant avec des droits root alors qu'il n'a pas été lancé en tant que root et ne possède pas d'ancêtre setuid ; ainsi que des avertissements du noyau ou des « oops » provenant du chemin de validation des flux OVS, que des tentatives infructueuses peuvent générer.

Nous n'avons pas encore reproduit en interne la démonstration de faisabilité (PoC) publique dans des environnements restreints ou conteneurisés ; ne partez donc pas du principe que l'isolation par utilisateur ou par conteneur permet de contenir la faille sans avoir testé ce chemin d'appel système dans votre propre configuration.

Non. Le problème a été signalé en privé le 19 juin 2026 ; le correctif a été intégré aux branches stables le 24 juillet dans le cadre d’un embargo coordonné, et le rapport ainsi que la preuve de concept (PoC) ont été publiés le 28 juillet. Rien dans cette divulgation ne laisse entendre que le problème ait été exploité en conditions réelles avant la mise en place d’un correctif.

Cela ne signifie pas pour autant que cette vulnérabilité soit de faible priorité. Dès que l’exploit a été rendu public, les pirates ont disposé d’une méthode éprouvée permettant de passer d’un compte local standard au niveau root, ainsi que des décalages pour un grand nombre de versions du noyau. Cette avance de quatre jours ne profite qu’aux parcs informatiques qui avaient déjà rapidement appliqué les correctifs aux noyaux stables.

Pourquoi la vulnérabilité CVE-2026-64531 est-elle importante ?

Trois éléments permettent de classer facilement cette affaire parmi les affaires courantes, et ces trois éléments induisent en erreur.

Cela nécessite un accès local, ce qui laisse penser qu’il s’agit d’un problème de deuxième niveau, sauf que cet accès local est déjà dont disposent les locataires, les exécuteurs CI et les dépendances non fiables. Cela nécessite Open vSwitch, ce qui laisse penser qu’il s’agit d’un problème de réseau de niche, sauf que le module se charge automatiquement à la demande. Et cela nécessite un espace de noms utilisateur sans privilèges, ce qui laisse penser que cela est déjà couvert par des mesures de renforcement de sécurité existantes, sauf que les mesures spécifiques auxquelles la plupart des équipes Debian et Ubuntu font confiance dans ce domaine ne fonctionnent pas.

L'historique des versions nous enseigne une autre leçon. Une modification qui a supprimé une limite de taille en mars 2025 a transformé une affectation inactive depuis une décennie en une faille d'élévation de privilèges active, et celle-ci a été intégrée dans des branches à long terme sous la forme d'un simple backport plutôt que d'une version officielle. Une file d'attente de triage basée uniquement sur les numéros de version en amont aurait considéré ces noyaux comme hors de la période concernée.

Pour les systèmes corrigés de manière classique, installez la mise à jour du fournisseur et vérifiez que l’hôte démarre correctement avec celle-ci. Pour les parcs informatiques où les redémarrages d’urgence constituent un risque opérationnel, KernelCare comble la faille de validation dans le noyau en cours d’exécution sans mettre les systèmes hors ligne. Dans tous les cas, la solution la plus économique à l’heure actuelle consiste à bloquer le module sur chaque hôte qui n’utilise pas OVS : cette mesure est réversible, a un faible impact et supprime le chemin d’exécution du code au lieu de tenter de le contourner.

Procurez-vous KernelCare dès aujourd’hui →

Chronologie

Références

• Asim Manizada, OVSwrap disclosure, oss-security, 28 juillet 2026, et le miroir de seclists
• Documentation technique sur OVSwrap : https://heyitsas.im/posts/ovswrap
• Preuve de concept publique d'OVSwrap et garde BPF : https://github.com/manizada/OVSwrap
• Correction en amont sous Linux 3f1f75536668, « net : openvswitch : rejet des attributs d'action imbriqués trop volumineux »
• Annonce Linux relative à la vulnérabilité CVE-2026-64531
• Fiche CVE, CVE-2026-64531
• Avis de sécurité concernant RHEL, AlmaLinux, Rocky Linux, CloudLinux, Debian, Ubuntu et Amazon Linux