CVE-2026-31431 « Copy Fail » : faille du noyau Linux

Shared FAQ page chrome (breadcrumb, dates, read time, «Continuer la lecture», enquiry block, category labels): see INDEX-AND-CHROME.md. Translate once.

Résumé

Une vulnérabilité d'élévation de privilèges locale à fort impact dans le noyau Linux, CVE-2026-31431, aussi connue sous le nom « Copy Fail », a été divulguée publiquement.

Cette vulnérabilité touche l'interface cryptographique du noyau Linux, plus précisément le chemin algif_aead / AF_ALG. Sur les versions de noyau concernées, un utilisateur local non privilégié peut être en mesure d'élever ses privilèges jusqu'à root. Les chercheurs à l'origine de la découverte décrivent le problème comme touchant les principales distributions Linux dont les noyaux ont été compilés depuis 2017, avec un risque particulier pour les serveurs multi-utilisateurs, les plateformes de conteneurs, les runners CI/CD et les environnements multi-tenant.

Le problème est suivi sous la référence CVE-2026-31431. Ubuntu le classe High avec un CVSS de 7.8, tandis que Red Hat évalue l'impact comme Important.

EuroVPS recommande vivement que tous les serveurs Linux concernés soient passés en revue et corrigés dès que des noyaux corrigés ou des mesures de contournement sont disponibles chez l'éditeur.

---

Qu'est-ce que la CVE-2026-31431 ?

La CVE-2026-31431 est une vulnérabilité du noyau Linux dans le sous-système crypto. Le défaut est lié à une opération en place incorrecte dans algif_aead, lorsque les mappages source et destination diffèrent. Le correctif upstream du noyau est associé au commit mainline a664bf3d603d, qui annule l'optimisation problématique de 2017.

La vulnérabilité n'est pas en elle-même une vulnérabilité réseau distante. Toutefois, si un attaquant dispose déjà d'un accès shell local, d'un accès via une application web compromise, d'une exécution dans un conteneur ou d'un autre point d'appui, cette vulnérabilité peut lui permettre d'obtenir les privilèges root complets.

---

Systèmes d'exploitation concernés et correctifs des éditeurs

La vulnérabilité peut toucher de nombreuses distributions Linux dont les noyaux ont été compilés depuis 2017. L'état varie selon la distribution et la branche de noyau, la bonne démarche est donc de suivre l'avis officiel de l'éditeur de votre système d'exploitation.

1. AlmaLinux

AlmaLinux a publié des noyaux corrigés pour les versions prises en charge. Les versions corrigées confirmées sont :

OS	Version de noyau corrigée
AlmaLinux 8	kernel-4.18.0-553.121.1.el8_10 ou plus récent
AlmaLinux 9	kernel-5.14.0-611.49.2.el9_7 ou plus récent
AlmaLinux 10	kernel-6.12.0-124.52.2.el10_1 ou plus récent
AlmaLinux Kitten 10	kernel-6.12.0-225.el10 ou plus récent

Mise à jour recommandée :

sudo dnf clean all
sudo dnf upgrade 'kernel*'
sudo reboot

Vérifier après le redémarrage :

uname -r
rpm -q kernel

2. Oracle Linux

Oracle Linux est également concerné lorsqu'il exécute des builds de noyau vulnérables. Oracle a publié des mises à jour de sécurité de l'Unbreakable Enterprise Kernel (UEK) pour la CVE-2026-31431 via les errata officiels Oracle Linux.

Version Oracle Linux / branche de noyau	Noyau corrigé / niveau de correctif
Oracle Linux 7 / 8, UEK R6	kernel-uek-5.4.17-2136.354.4.2.el7uek / el8uek ou plus récent
Oracle Linux 8 / 9, UEK R7	kernel-uek-5.15.0-319.201.4.4.el8uek / el9uek ou plus récent
Oracle Linux 9 / 10, UEK R8	kernel-uek-6.12.0-201.74.2.2.el9uek / el10uek ou plus récent

Oracle classe les mises à jour UEK comme SECURITY, IMPORTANT, publiées le 1er mai 2026, et inclut la CVE-2026-31431 dans les correctifs crypto du noyau.

Mise à jour recommandée :

sudo dnf clean all
sudo dnf update 'kernel*'
sudo reboot

Pour les systèmes Oracle Linux plus anciens utilisant yum :

yum clean all
yum update 'kernel*'
reboot

Vérification Oracle Linux

cat /etc/oracle-release
uname -r
rpm -q kernel-uek
rpm -q kernel kernel-core

Assurez-vous que le noyau en cours d'exécution affiché par uname -r est bien le noyau corrigé, et pas seulement installé.

3. CloudLinux

CloudLinux confirme que CL7 n'est pas concerné, tandis que CL7h, CL8, CL9 et CL10 sont concernés. CL7h et CL8 sont corrigés via les noyaux CloudLinux, tandis que CL9 et CL10 utilisent les mises à jour de noyau AlmaLinux.

Les versions cibles CloudLinux confirmées sont :

OS	Version de noyau corrigée
CloudLinux 7	Non concerné
CloudLinux 7 Hybrid / CL7h	kernel-4.18.0-553.121.1.lve.el7h.x86_64 ou plus récent
CloudLinux 8	kernel-4.18.0-553.121.1.lve.el8.x86_64 ou plus récent
CloudLinux 9	kernel-5.14.0-611.49.2.el9_7 ou plus récent
CloudLinux 10	kernel-6.12.0-124.52.2.el10_1 ou plus récent

Mise à jour recommandée pour CloudLinux 8 / 9 / 10 :

sudo dnf clean metadata
sudo dnf upgrade 'kernel*'
sudo reboot

Pour les systèmes CloudLinux plus anciens utilisant yum :

yum update 'kernel*'
reboot

Vérifier :

uname -r
rpm -q kernel

Pour les systèmes KernelCare :

kcarectl --update
kcarectl --info | grep CVE-2026-31431

CloudLinux indique que les correctifs à chaud KernelCare pour de nombreuses distributions concernées, dont les branches AlmaLinux, CloudLinux, Red Hat, Rocky, Oracle Linux, Ubuntu et Debian, ont été publiés dans le flux principal au 2 mai 2026.

---

4. Ubuntu

Ubuntu a publié un suivi CVE et un article de blog dédié à ce problème. Ubuntu indique que la mesure de contournement est distribuée via le paquet kmod et que le correctif de la vulnérabilité sera distribué via les paquets d'image du noyau Linux.

Mise à jour recommandée :

sudo apt update
sudo apt upgrade
sudo reboot

Pour appliquer uniquement le paquet de contournement là où c'est applicable :

sudo apt update
sudo apt install --only-upgrade kmod
sudo reboot

Vérification :

uname -r
dpkg -l 'linux-image*' | grep ^ii
dpkg -l kmod

Pour vérifier si le module concerné est actuellement chargé :

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

Ubuntu documente aussi une mesure de contournement manuelle via une règle modprobe.d et le déchargement d'algif_aead, mais cette approche ne convient pas à toutes les distributions, en particulier les systèmes de la famille RHEL où la fonctionnalité peut être compilée dans le noyau.

---

5. Debian

Le suivi de sécurité de Debian liste les versions corrigées pour plusieurs versions de Debian :

Version Debian	Version corrigée
Bullseye security	5.10.251-3
Bookworm security	6.1.170-1
Trixie security	6.12.85-1
Forky	6.19.14-1
Sid	7.0.3-1

Mise à jour recommandée :

sudo apt update
sudo apt upgrade
sudo reboot

Vérifier :

uname -r
dpkg -l 'linux-image*' | grep ^ii

---

6. Red Hat Enterprise Linux

Red Hat a publié un bulletin de sécurité et une page CVE pour la CVE-2026-31431. Red Hat la décrit comme un problème de l'interface cryptographique du noyau Linux permettant à un utilisateur local d'obtenir les privilèges root. Red Hat classe le problème comme Important et indique que les correctifs sont publiés via les canaux Red Hat concernés.

Action recommandée :

sudo dnf update 'kernel*'
sudo reboot

Vérifier :

uname -r
rpm -q kernel
rpm -q kernel-core

Pour les systèmes sous souscription Red Hat, consultez aussi la page CVE officielle de Red Hat et ses avis pour connaître le paquet corrigé exact de votre version de RHEL et de votre branche de noyau.

---

7. SUSE

SUSE classe la CVE-2026-31431 comme important et suit l'état par produit et par paquet. Certains paquets SUSE 15 SP7 sont marqués comme publiés, tandis que plusieurs branches SUSE 16 et SUSE Linux Micro étaient encore listées comme concernées ou en cours sur la page CVE de SUSE au moment de la consultation.

Action recommandée :

sudo zypper refresh
sudo zypper update
sudo reboot

Vérifier :

uname -r
rpm -q kernel-default

Consultez la page CVE de SUSE pour l'état exact des paquets de votre produit, service pack et variante de noyau.

---

Mesure de contournement temporaire si vous ne pouvez pas mettre à jour immédiatement

Pour les systèmes OracleLinux / AlmaLinux / CloudLinux / famille RHEL

Pour les systèmes de la famille RHEL, la mesure de contournement temporaire la plus sûre consiste à mettre l'initcall algif_aead_init sur liste noire via la ligne de commande du noyau, puis à redémarrer :

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo reboot

Vérifier après le redémarrage :

cat /proc/cmdline | grep initcall_blacklist=algif_aead_init

ou :

sudo grubby --info=ALL | grep initcall_blacklist

CloudLinux avertit expressément que la mesure de contournement courante via modprobe.d peut ne pas fonctionner sur CloudLinux, AlmaLinux ou d'autres systèmes de la famille RHEL, car algif_aead peut être compilé dans le noyau. Dans ce cas, rmmod et les règles modprobe.d peuvent donner un faux sentiment de protection.

Après l'installation d'un noyau corrigé, vous pouvez retirer la mesure temporaire :

sudo grubby --update-kernel=ALL --remove-args="initcall_blacklist=algif_aead_init"
sudo reboot

---

Pour les systèmes Ubuntu / Debian

Ubuntu documente la mesure suivante là où elle est applicable :

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/manual-disable-algif_aead.conf
sudo rmmod algif_aead 2>/dev/null

Vérifier :

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

Un redémarrage peut être nécessaire si le module ne peut pas être déchargé en toute sécurité.

---

Durcissement des conteneurs et de Kubernetes

Pour les environnements conteneurisés, la correction du noyau de l'hôte reste la mesure principale. Un confinement supplémentaire est toutefois fortement recommandé.

Le CERT-EU recommande de bloquer la création de sockets AF_ALG via des politiques seccomp pour les charges conteneurisées et les pipelines CI/CD. Docker documente seccomp comme une fonctionnalité du noyau Linux servant à restreindre les actions des conteneurs, et le profil seccomp par défaut de Docker repose sur un modèle de liste d'autorisation.

Vérification seccomp Docker :

grep CONFIG_SECCOMP= /boot/config-$(uname -r)

Résultat attendu :

CONFIG_SECCOMP=y

Exécutez les conteneurs avec le profil seccomp par défaut, sauf raison précise de ne pas le faire :

docker run --security-opt seccomp=default.json ...

Pour Kubernetes, utilisez RuntimeDefault ou un profil seccomp personnalisé lorsque c'est approprié. Kubernetes permet d'appliquer des profils seccomp aux Pods et aux conteneurs, et sa documentation explique comment charger et appliquer ces profils.

Exemple de contexte de sécurité Kubernetes :

securityContext:
  seccompProfile:
    type: RuntimeDefault

---

Étape supplémentaire pour les serveurs LiteSpeed Enterprise

Pour les serveurs exécutant LiteSpeed Enterprise, en particulier les environnements d'hébergement utilisant CloudLinux / CageFS, EuroVPS recommande d'appliquer l'étape de durcissement LiteSpeed supplémentaire ci-dessous.

Il s'agit d'un durcissement supplémentaire pour les serveurs disposant du binaire lscgid de LiteSpeed ; la mise à jour du noyau ou la mesure de contournement ci-dessus reste nécessaire.

LiteSpeed 6.3.5 est présentée par LiteSpeed comme une version de sécurité, d'optimisation et de correction de bogues, incluant des changements liés à CloudLinux CageFS. La documentation de LiteSpeed montre aussi que lscgid utilise historiquement la permission setuid dans le fonctionnement normal de LiteSpeed/PHP.

Étape 2 : durcir le binaire lscgid

Vérifiez d'abord si LiteSpeed est installé :

/usr/local/lsws/bin/lshttpd -v

Puis choisissez une des options suivantes.

Option A : mettre à niveau vers LiteSpeed Enterprise 6.3.5 Build 5 ou plus récent (recommandé)

C'est l'option à privilégier. La mise à niveau de LiteSpeed applique automatiquement le durcissement de permissions requis sur lscgid :

/usr/local/lsws/admin/misc/lsup.sh -f -v 6.3.5

Après la mise à niveau, redémarrez LiteSpeed si nécessaire :

/usr/local/lsws/bin/lswsctrl restart

Option B : correctif rapide si vous n'êtes pas prêt à mettre à niveau

Si vous ne pouvez pas mettre LiteSpeed à niveau immédiatement, retirez dès maintenant manuellement la permission setuid du binaire lscgid :

chmod u-s /usr/local/lsws/bin/lscgid.*

Puis redémarrez LiteSpeed :

/usr/local/lsws/bin/lswsctrl restart

Liste de vérification

Exécutez les vérifications suivantes après avoir appliqué les mises à jour ou les mesures de contournement.

1. Identifier l'OS et le noyau

cat /etc/os-release
uname -r

2. Vérifier les paquets de noyau installés

Systèmes RPM :

rpm -q kernel
rpm -q kernel-core

Systèmes Debian/Ubuntu :

dpkg -l 'linux-image*' | grep ^ii

3. Confirmer que le noyau en cours d'exécution est le noyau corrigé

Après le redémarrage :

uname -r

Comparez la version du noyau en cours d'exécution avec la version officielle corrigée par l'éditeur pour votre OS.

4. Confirmer que la mesure de contournement est active, si elle est utilisée

Pour les systèmes de la famille RHEL utilisant la mesure grubby :

cat /proc/cmdline | grep initcall_blacklist=algif_aead_init

Pour la mesure par module sur Ubuntu/Debian :

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

5. Vérification KernelCare

kcarectl --update
kcarectl --info | grep CVE-2026-31431

La CVE doit apparaître comme corrigée dans la sortie de KernelCare lorsqu'un correctif à chaud est disponible.

---

Remarques opérationnelles importantes

N'exécutez pas de code public de preuve de concept d'exploit sur des serveurs de production.

---

Plan d'action recommandé par EuroVPS

EuroVPS recommande le plan d'action suivant :

1. Au-delà du correctif et du redémarrage : appliquez des politiques seccomp aux charges conteneurisées, retirez les systèmes d'exploitation en fin de vie et, sur LiteSpeed Enterprise, mettez à niveau vers 6.3.5 Build 5 ou retirez le bit setuid de lscgid.

Besoin d'aide ?

Si vous souhaitez que nos ingénieurs vérifient, corrigent, protègent et valident votre serveur, ouvrez un ticket de support depuis l'espace client en indiquant le nom d'hôte ou l'IP ; communiquez l'accès root uniquement via le champ d'identifiants sécurisé du ticket, jamais dans le texte du ticket.

Liens officiels des éditeurs et références :

[1] Divulgation officielle Copy Fail : https://copy.fail/ [2] Suivi CVE Ubuntu, CVE-2026-31431 : https://ubuntu.com/security/CVE-2026-31431 [3] Blog Ubuntu, correctifs Copy Fail disponibles : https://ubuntu.com/blog/copy-fail-vulnerability-fixes-available [4] Avis AlmaLinux, CVE-2026-31431 Copy Fail : https://almalinux.org/blog/2026-05-01-cve-2026-31431-copy-fail/ [5] Blog CloudLinux, mise à jour du noyau CVE-2026-31431 Copy Fail : https://blog.cloudlinux.com/cve-2026-31431-copy-fail-kernel-update [6] Page d'incident / de statut CloudLinux : https://cloudlinux.statuspage.io/incidents/642sgcmntkkk [7] Page CVE Red Hat, CVE-2026-31431 : https://access.redhat.com/security/cve/CVE-2026-31431 [8] Bulletin de sécurité Red Hat : https://access.redhat.com/security/vulnerabilities/RHSB-2026-02 [9] Page CVE SUSE, CVE-2026-31431 : https://www.suse.com/security/cve/CVE-2026-31431 [10] Suivi de sécurité Debian, CVE-2026-31431 : https://security-tracker.debian.org/tracker/CVE-2026-31431 [11] Documentation seccomp Docker : https://docs.docker.com/engine/security/seccomp/ [12] Documentation seccomp Kubernetes : https://kubernetes.io/docs/tutorials/security/seccomp/ [13] Oracle Linux 7 / 8, UEK R6 : https://linux.oracle.com/errata/ELSA-2026-50255.html [14] Oracle Linux 8 / 9, UEK R7 : https://linux.oracle.com/errata/ELSA-2026-50253.html [15] Oracle Linux 9 / 10, UEK R8 : https://linux.oracle.com/errata/ELSA-2026-50254.html