CVE-2026-31431 'Copy Fail' (CVSS 7.8) : élévation de privilèges root dans le kernel Linux, exploitée dans des environnements cloud multi-locataires. Module algif_aead du sous-système AF_ALG, deadline CISA fixée au 15 mai 2026.
En bref
- CVE-2026-31431 'Copy Fail' (CVSS 7.8) : élévation de privilèges root dans le kernel Linux, ajoutée au CISA KEV le 1er mai 2026.
- Module algif_aead du sous-système cryptographique AF_ALG — exploitation observée dans des environnements cloud multi-locataires.
- Deadline CISA pour les agences fédérales : 15 mai 2026 ; patch upstream disponible.
Les faits
Le 1er mai 2026, la CISA a ajouté la CVE-2026-31431 — surnommée 'Copy Fail' — à son catalogue Known Exploited Vulnerabilities. La faille, divulguée publiquement par Microsoft Security Research, réside dans le module algif_aead du sous-système AF_ALG du kernel Linux. Score CVSS : 7,8 (High), classée CWE-699 (Incorrect Resource Transfer Between Spheres). Les agences fédérales américaines ont jusqu'au 15 mai 2026 pour appliquer le correctif.
Techniquement, 'Copy Fail' exploite une mauvaise gestion du transfert de buffers entre l'espace utilisateur et l'espace noyau lors d'opérations cryptographiques AEAD (Authenticated Encryption with Associated Data) via l'API socket cryptographique du kernel. Lorsqu'une copie partielle échoue, le kernel ne nettoie pas correctement le contexte, ce qui permet à un processus utilisateur non privilégié de manipuler des structures noyau et d'obtenir une exécution de code en anneau 0 — donc le contrôle total de la machine.
Les chercheurs Microsoft ont documenté l'exploitation in-the-wild dans des environnements cloud multi-locataires, notamment Azure Linux et plusieurs distributions Ubuntu utilisées comme images de référence dans les VM clients. Le vecteur d'abus typique : un attaquant disposant déjà d'un accès non privilégié à un container ou une VM (via une autre faille applicative ou un identifiant compromis) utilise Copy Fail pour casser l'isolation de container et accéder à l'hyperviseur ou aux ressources voisines.
Plus inquiétant : l'exploitation ne nécessite aucun module noyau particulier ni configuration exotique. AF_ALG est compilé en dur dans la majorité des kernels distribués (Ubuntu 20.04, 22.04, 24.04, RHEL 8, RHEL 9, Debian 11, Debian 12) et n'est pas désactivable sans recompilation. Toute machine Linux moderne avec un user-space accessible à un attaquant est exploitable.
Le patch upstream a été mergé dans la branche stable du noyau Linux le 28 avril 2026. Les distributions ont publié leurs correctifs progressivement : Red Hat (RHSA-2026:2418), Ubuntu (USN-7124-1), Debian (DSA-5856-1), SUSE (SUSE-SU-2026:1187-1). Le patch consiste à invalider correctement le contexte AEAD lorsqu'une copie échoue, ce qui ferme la fenêtre d'exploitation. La performance du sous-système n'est pas affectée.
L'aspect 'cloud-native' du bug en fait une menace prioritaire pour les opérateurs Kubernetes. Une compromission de pod via une faille applicative classique (RCE PHP, SQL injection menant à RCE) pouvait jusqu'à présent rester confinée au container grâce à l'isolation cgroups/namespace. Avec Copy Fail, cette isolation ne tient plus dès lors que la machine hôte n'est pas patchée. Les distributions Linux dédiées container (Bottlerocket, Talos Linux, Flatcar) sont également concernées : leurs équipes ont publié des images mises à jour entre le 30 avril et le 4 mai.
Pour la France, l'impact est significatif sur les opérateurs cloud nationaux (OVHcloud, Scaleway, 3DS Outscale, Numspot) et sur les infrastructures SecNumCloud. L'ANSSI n'a pas publié d'alerte dédiée à ce stade mais le bulletin CERT-FR du 5 mai référence le correctif via ses avis Linux génériques.
Source : Microsoft Security Blog (1er mai 2026), CISA KEV catalog, Cybersecurity News, advisories Red Hat / Ubuntu / Debian / SUSE, Linux kernel commit log.
Impact et exposition
Toute machine Linux avec un kernel non patché entre les versions 5.4 et 6.12 est exploitable. Cela couvre la quasi-totalité des serveurs Linux en production aujourd'hui. Le bug se distingue par sa surface d'attaque : un container ou une VM accessible à un attaquant suffit, sans privilège initial. Les architectures cloud avec des workloads multi-locataires (FaaS, container as a service, hébergement mutualisé) doivent considérer cette CVE comme prioritaire absolue.
Les opérateurs de SOC doivent surveiller les motifs d'exploitation : appels système setsockopt() vers AF_ALG suivis de manipulations mémoire inhabituelles, escalade de droits sans utilisation de sudo, processus shell générés depuis un user nobody ou www-data avec un UID 0 effectif.
Recommandations
- Patcher tous les kernels Linux exposés vers la version corrigée de votre distribution — RHSA-2026:2418, USN-7124-1, DSA-5856-1 ou équivalent.
- Pour les workloads cloud multi-locataires : prioriser les hôtes hyperviseurs avant les VM clients.
- Auditer les systèmes Kubernetes : vérifier que les nodes ont reçu le patch ; redémarrer les nodes après upgrade kernel.
- Activer eBPF-based monitoring (Falco, Tetragon) pour détecter les escalades de privilège anormales en attendant le déploiement complet.
- Pour les configurations à haut risque, désactiver temporairement AF_ALG via sysctl ou recompilation si compatible avec la pile applicative.
Mon application n'utilise pas la cryptographie kernel — suis-je quand même vulnérable ?
Oui. Le module algif_aead est chargé en permanence sur la majorité des distributions Linux modernes, indépendamment de l'usage applicatif. Tout processus utilisateur peut ouvrir un socket AF_ALG et déclencher la séquence vulnérable. La présence ou non de cryptographie dans votre code ne change rien à l'exposition.
Le patch nécessite-t-il un redémarrage de la machine ?
Oui pour la majorité des configurations. Les distributions qui supportent kpatch (Red Hat) ou Ksplice (Oracle Linux) peuvent appliquer un correctif live, mais les autres environnements nécessitent un reboot complet. Planifiez les fenêtres de maintenance en conséquence et privilégiez les redémarrages roulants pour les clusters à haute disponibilité.
Vos infrastructures cloud sont-elles isolées ?
Ayi NEDJIMI accompagne les équipes Cloud et DevSecOps dans la revue d'isolation container, le hardening kernel et la couverture des CVE critiques.
Demander un auditÀ propos de l'auteur
Ayi NEDJIMI
Auditeur Senior Cybersécurité & Consultant IA
Expert Judiciaire — Cour d'Appel de Paris
Habilitation Confidentiel Défense
ayi@ayinedjimi-consultants.fr
Ayi NEDJIMI est un vétéran de la cybersécurité avec plus de 25 ans d'expérience sur des missions critiques. Ancien développeur Microsoft à Redmond sur le module GINA (Windows NT4) et co-auteur de la version française du guide de sécurité Windows NT4 pour la NSA.
À la tête d'Ayi NEDJIMI Consultants, il réalise des audits Lead Auditor ISO 42001 et ISO 27001, des pentests d'infrastructures critiques, du forensics et des missions de conformité NIS2 / AI Act.
Conférencier international (Europe & US), il a formé plus de 10 000 professionnels.
Domaines d'expertise
Ressources & Outils de l'auteur
Articles connexes
Meta licencie 8 000 personnes le 20 mai pour financer l'IA
Meta démarre le 20 mai 2026 le licenciement de 8 000 personnes (10 % des effectifs) pour financer un capex IA 2026 de 115 à 135 milliards de dollars.
Gemini 3.1 Flash-Lite GA : Google casse les prix de l'IA
Google bascule Gemini 3.1 Flash-Lite en disponibilité générale le 7 mai 2026 à 0,25 $ par million de tokens, ciblant les workloads agentiques à fort volume.
vm2 : 12 CVE critiques, le bac à sable Node.js explose
Douze vulnérabilités critiques publiées le 7 mai 2026 permettent l'évasion totale du sandbox vm2, librairie Node.js déployée dans des milliers de plateformes SaaS et serverless.
Commentaires
Aucun commentaire pour le moment. Soyez le premier à commenter !
Laisser un commentaire