CVE-2026-31431 Copy Fail expliquee

CVE-2026-31431 Copy Fail est une faille d'elevation locale de privileges du noyau Linux qui est passee tres vite d'une divulgation technique a une priorite operationnelle. Au 19 aout 2026, le dossier officiel montre une faille de severite elevee dans le composant algif_aead, des paquets noyau corriges publies par tous les grands distributeurs Linux, et son inclusion dans le catalogue CISA Known Exploited Vulnerabilities depuis le 1 mai 2026. La situation a evolue depuis la divulgation : les mitigations temporaires de desactivation de module publiees fin avril etaient une solution provisoire, et les editeurs ont depuis publie des noyaux corriges et commence a les retirer.

Cet article reste volontairement etroit. Il ne reproduit pas l'exploit, n'estime pas la prevalence et ne reprend pas de claims tiers sur sa fiabilite. Il se limite a ce que les sources officielles confirment reellement : ce que la faille affecte, ou l'exposition compte le plus, quelles mitigations temporaires existent et comment valider l'etat de patch sans creer d'angles morts ni de regressions operationnelles.

Pour le processus plus large d'audit des environnements isoles, voir Audit de securite d'un reseau air-gapped : comment auditer un environnement isole sans faux sentiment de securite. Pour un guide compagnon sur les workflows et outils offline-capable, voir Quels outils de securite fonctionnent dans les reseaux isoles sans acces internet ? Guide pratique des workflows de securite offline-capable.

Qu'est-ce que CVE-2026-31431 (Copy Fail) ?

CVE-2026-31431 est une vulnerabilite du noyau Linux dans algif_aead, un composant lie a l'interface cryptographique du noyau. L'enregistrement NVD reprend la description upstream du correctif : le comportement vulnerable est corrige en ramenant algif_aead a un fonctionnement out-of-place plutot qu'en conservant la logique plus complexe in-place introduite auparavant.

La severite officielle qui compte le plus pour les defenseurs a ce stade est le score kernel CNA de CVSS 3.1 7.8 HIGH, avec le vecteur AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Red Hat et cve.org publient le meme score et le meme vecteur. NVD indique deux classifications de faiblesse provenant de contributeurs differents — CWE-669 (Incorrect Resource Transfer Between Spheres, celle reprise par CISA dans KEV) et CWE-1288 (Improper Validation of Consistency within Input, de Red Hat) — et liste huit references de correctifs kernel.org rattachees a des branches stables.

Sur l'axe des versions, le dossier upstream est explicite. La regression a ete introduite par le commit 72548b093ee3, donc la CVE affecte Linux 4.14 et plus recent, avec des correctifs livres dans les versions stables 5.10.254, 5.15.204, 6.1.170, 6.6.137, 6.12.85, 6.18.22 et 6.19.12. Les distributions rattachent cela a leurs propres versions de paquets : Ubuntu indique que le probleme affecte toutes les releases avant Resolute (26.04), et SUSE indique que cela affecte les noyaux 4.14 et plus recents, de SLES 12 SP5 a SLES 16.0, SLES 11 etant trop ancienne pour etre affectee.

D'un point de vue operationnel, les editeurs traitent le sujet comme une faille de local privilege escalation dans le noyau Linux. C'est important parce qu'une elevation locale de privileges n'est pas une frontiere purement academique. Si un attaquant dispose deja d'une execution de code comme utilisateur normal, ou peut lancer une charge non fiable au mauvais endroit, un chemin fiable vers root peut modifier tres vite la frontiere de confiance d'un bastion, d'un hote partage ou d'un noeud de conteneurs.

Ce que les advisories officiels confirment a ce stade

Le tableau officiel est deja assez clair pour soutenir un triage immediat.

Source	Ce qu'elle confirme	Pourquoi c'est important
NVD / kernel CNA	`algif_aead` est le composant affecte ; le score CNA CVSS est 7.8 HIGH ; NVD montre la CVE dans CISA KEV.	Etablit l'identifiant technique, la severite et le signal de priorisation actuel.
Ubuntu	Date de divulgation publique 29 avril 2026 ; article de mitigation publie le 30 avril 2026 ; impact cadre comme local privilege escalation, avec un volet conteneurs traite a part.	Donne des indications defensives concretes et des caveats operationnels.
SUSE	L'etat produit et paquet est expose publiquement sur la page CVE SUSE, avec references de workaround et d'advisory.	Utile pour la validation au niveau paquet et le triage de flotte.
Red Hat	Le bulletin de securite `RHSB-2026-002` est note Important et son statut est desormais Resolved : "All fixes are now available." Des articles de suivi separes pour RHEL, OpenShift et ROSA existent mais sont reserves aux abonnes.	Confirme que l'editeur a cloture le probleme et montre ou se trouvent les etapes specifiques par produit.

Un second signal operationnel est le statut KEV. NVD note explicitement que cette CVE figure dans le catalogue CISA Known Exploited Vulnerabilities, avec Date Added: May 1, 2026 et Due Date: May 15, 2026. Meme si votre organisation ne suit pas les echeances federales americaines, c'est quand meme un signal de priorisation utile : la faille n'est plus seulement "nouvelle" ou "interessante". Elle est deja dans la classe d'incidents que les defenseurs doivent traiter comme urgents.

Ce classement n'est pas speculatif. Le bulletin Red Hat publie une chronologie de remediation indiquant que le chercheur a publie un article de blog, un write-up technique et un proof-of-concept le 29 avril 2026, qu'un module Metasploit a ete publie le meme jour, et que CISA a ajoute la CVE a KEV deux jours plus tard. Ubuntu confirme que l'exploit publie cible les deploiements sans charges conteneurisees. Cet article ne reproduit rien de tout cela — mais un exploit public fonctionnel est une donnee de triage, et cela explique pourquoi les delais editeur se sont resserres de cette maniere.

Ou Copy Fail compte le plus

Il ne s'agit pas d'une faille edge exposee a Internet et exploitable sans authentification. L'exposition depend de l'existence d'un point d'appui local ou d'un chemin d'execution sur un systeme Linux. Cela laisse quand meme plusieurs scenarios a forte valeur.

Hotes avec utilisateurs locaux ou execution de code locale

Ubuntu indique que, sur les deploiements sans charges conteneurisees, la faille permet a un utilisateur local d'elever ses privileges a root. Cela signifie que la premiere question n'est pas "Mon service expose a Internet est-il directement exploitable depuis l'exterieur ?" La premiere question est de savoir si l'hote peut deja executer du code non fiable ou semi-fiable sous un compte peu privilegie.

Exemples typiques :

hotes Linux d'administration partages
bastions ou jump hosts utilises par plusieurs equipes
runners CI et systemes de build
serveurs multi-utilisateurs avec acces shell
serveurs d'administration adjacents a l'infrastructure d'identite

Environnements conteneurises

Ubuntu documente aussi une preoccupation distincte pour les deploiements conteneurises qui peuvent executer des charges potentiellement malveillantes : la faille peut faciliter des container escape scenarios. Le bulletin RHSB-2026-002 de Red Hat comporte des sections de mitigation specifiques par produit pour OpenShift 4 et pour OpenShift manage (ROSA Classic, ROSA HCP, ARO et OpenShift Dedicated), ce qui confirme que l'editeur traite les plateformes de conteneurs comme un chantier operationnel a part entiere. SUSE fait la meme distinction depuis l'autre bout : Rancher Prime, RKE2 et K3s ne sont pas directement affectes, mais les conteneurs privilegies executant des charges non fiables restent un chemin vers la faille noyau, d'ou le fait que SUSE renvoie vers Pod Security Admission et des controles equivalents plutot que vers un correctif produit.

Cette distinction compte. Une equipe flotte ne doit pas ecrire "container escape" comme un claim global sur tous les deploiements Kubernetes ou conteneurises. La formulation correcte est plus etroite : la documentation editeur dit que les environnements conteneurises meritent une attention separee, et que le triage des noeuds conteneurs ne doit pas etre melange a une simple file de patching postes et serveurs.

Systemes d'administration et systemes adjacents a l'identite

Meme s'il s'agit d'une faille du noyau Linux et non d'une faille Active Directory ou Entra, un root local sur le mauvais hote Linux reste important pour les equipes identite et infrastructure. Bastions, noeuds de provisioning, runners d'automatisation, appliances VPN, PAM jump hosts, et systemes Linux utilises pour administrer Windows ou l'infrastructure cloud font partie du plan effectif d'identite. Une elevation locale de privileges a cet endroit peut changer le modele de confiance autour des credentials, tokens, cles de gestion et chemins d'automatisation.

C'est aussi pour cela que les equipes qui executent deja Audit de securite Active Directory : quoi verifier d'abord et comment prouver la remediation ou Durcissement d’Active Directory : quoi verrouiller d’abord et comment le valider ne devraient pas traiter les hotes Linux d'administration comme etant hors du perimetre d'assurance identite. Si vos chemins d'administration derivent deja avec le temps, le meme schema operationnel decrit dans Derive des acces privilegies dans Active Directory : comment les droits admin reviennent apres les audits s'applique souvent aussi aux bastions et aux outils Linux adjacents.

Mitigations temporaires et leurs compromis

L'histoire de la mitigation temporaire est importante parce que la documentation editeur officielle ne la presente pas comme un simple interrupteur neutre.

Des la divulgation, l'equipe securite d'Ubuntu a publie une mitigation qui desactive le module affecte algif_aead via le paquet kmod. Ubuntu a depuis mis a jour cet advisory : les paquets noyau corriges sont desormais disponibles et la mitigation kmod va etre retiree, donc le blocage du module est un filet de secours pour les hotes qui ne peuvent pas encore appliquer la mise a jour noyau, pas la destination finale. SUSE documente un workaround modprobe equivalent (blacklist algif_aead plus install algif_aead /bin/false) et a publie des mises a jour pour toutes les distributions SUSE Linux Enterprise et openSUSE Leap maintenues.

Red Hat est l'exception a connaitre. Sur RHEL, le code affecte est compile dans le noyau et ne peut pas etre mis en liste noire comme un module, donc le palliatif documente est un argument de boot — initcall_blacklist=algif_aead_init, ou initcall_blacklist=af_alg_init pour bloquer entierement l'interface AF_ALG — avec un avertissement explicite sur l'impact de performance pour tout ce qui utilise les fonctions cryptographiques du noyau. Une regle modprobe recopiee d'un runbook Debian ou SUSE n'aura aucun effet la.

Chacune de ces options achete du temps, et chacune vient avec des compromis.

La mitigation n'est pas neutre sur le comportement

Ubuntu avertit explicitement que la mitigation desactive un module utilise pour l'acceleration cryptographique materielle. Le comportement attendu est un fallback vers des fonctions cryptographiques userspace, mais Ubuntu ajoute que certaines applications peuvent ne pas gerer cette transition correctement. De plus, les applications deja en cours d'execution peuvent etre affectees si le module est desactive ou decharge, et un reboot peut etre necessaire pour forcer un comportement de fallback coherent.

Cela signifie que la decision de mitigation doit etre traitee comme un vrai changement operationnel, pas comme un simple drapeau d'urgence sans effet de bord.

Etape de mitigation	Benefice	Compromis a valider
Desactiver `algif_aead` via la mitigation fournie par l'editeur	Reduit l'exposition avant que tous les correctifs noyau ne soient deployes	Peut affecter le comportement crypto accelere et les processus de longue duree ; non disponible en blocage de module sur RHEL, ou un argument de boot est requis
Decharger immediatement le module	Peut reduire la fenetre d'exposition sur les systemes en cours d'execution	Peut necessiter une validation de service ou un reboot pour garantir les chemins de fallback
Appliquer les paquets noyau corriges	Supprime le besoin d'une posture basee uniquement sur le workaround	Exige une discipline standard de rollout kernel, une planification des reboots et une validation de version

La regle pratique est simple : si vous appliquez le workaround, documentez qu'il est temporaire, validez les applications dependantes de la crypto, et confirmez que le systeme rejoint ensuite un etat noyau corrige au lieu de rester indefiniment sur une posture de mitigation temporaire. Puisque les noyaux corriges sont disponibles, tout hote encore sur un workaround en aout 2026 porte une remediation inachevee, pas une mitigation.

Comment verifier l'exposition et l'etat du patch

La sequence de verification la plus sure est vendor-first. Ne supposez pas qu'un simple headline de version noyau vu sur les reseaux sociaux suffit a dire si une flotte est exposee.

Verifications Ubuntu

Ubuntu fournit des commandes concretes dans son advisory :

uname -r

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

dpkg -l kmod

Ubuntu documente aussi comment verifier si le module affecte est encore charge :

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

Ces verifications sont utiles meme au-dela d'Ubuntu parce qu'elles refletent la bonne logique : verifier le noyau en cours d'execution, verifier les paquets installes, puis verifier separement l'etat du module.

Verifications SUSE

SUSE expose une page CVE publique avec l'etat produit/paquet et les versions corrigees publiees. Pour les environnements geres par SUSE, le chemin autoritaire consiste a comparer les paquets noyau installes avec les versions listees sur la page CVE et les advisories lies, plutot qu'a s'appuyer sur une formule generique par famille de distribution.

Verifications Red Hat

Le bulletin RHSB-2026-002 de Red Hat est desormais marque Resolved et indique que tous les correctifs sont disponibles. Deux pages Red Hat sont reellement publiques et portent l'etat produit faisant autorite : le bulletin lui-meme, et la page CVE Red Hat pour CVE-2026-31431, qui liste les produits affectes, les errata publies, la notation Important propre a Red Hat, et son attribution CWE. Les articles how-to RHEL, OpenShift 4 et ROSA/OpenShift Dedicated lies depuis ces pages sont un contenu reserve aux abonnes, donc un ingenieur envoye vers ces liens a besoin d'un compte Red Hat pour qu'ils lui soient utiles.

Ce qu'il faut enregistrer pendant le triage

Pour chaque systeme ou groupe de clusters, enregistrer au minimum :

la version du noyau actuellement chargee
la version du paquet noyau installe
si algif_aead est charge ou non
si une mitigation temporaire a ete appliquee
l'etat de l'advisory editeur pour cette ligne produit
si un reboot reste necessaire apres patch ou mitigation

C'est suffisant pour transformer un headline bruyant sur une vulnerabilite en vraie file de remediation. Si vous faites deja des revues recurrentes d'infrastructure, la meme discipline de preuve decrite dans Audit Active Directory recurrent : pourquoi les audits annuels derivent et comment fonctionne une supervision continue de posture s'applique ici : capturer l'etat, rejouer la verification apres remediation, et garder la preuve que la mitigation temporaire a bien ete retiree.

Ce qu'il faut valider apres application des correctifs

Une reponse a Copy Fail ne doit pas s'arreter a "le paquet est mis a jour". La phase de validation est l'endroit ou se cachent le plus souvent les mitigations temporaires, les reboots en attente et les deploiements partiels.

Zone de validation	Ce qui ressemble a un succes
Etat du noyau en cours d'execution	L'hote execute bien le noyau corrige attendu, et ne se contente pas d'avoir le paquet present sur disque.
Etat du module	`algif_aead` est desactive ou absent la ou la mitigation temporaire reste necessaire, et son etat est compris apres patch complet.
Statut de reboot	Les systemes qui ont besoin d'un reboot pour completer la mitigation ou activer le noyau corrige ne restent pas dans un etat ambigu.
Comportement applicatif	Les services dependants de la crypto continuent de fonctionner correctement apres desactivation du module ou remplacement du noyau.
Posture des noeuds conteneurs	Les noeuds qui hebergent des charges conteneurisees sont verifies via le chemin editeur pour OpenShift, ROSA, OSD ou la guidance specifique a la distribution concernee.
Preuve de flotte	Chaque environnement dispose d'une source editeur enregistree, d'un etat de patch, et d'une action residuelle si le workaround est encore en place.

L'erreur operationnelle cle serait de traiter le workaround comme identique a un correctif pleinement valide. La documentation editeur ne supporte pas cela. Le workaround achete du temps ; le noyau corrige et la validation post-changement ferment la boucle. Pour la visibilite de logs et d'escalade autour des systemes d'identite adjacents, on peut le coupler avec Supervision Active Directory : les Event IDs de securite qui comptent lorsque l'hote Linux affecte se trouve sur un chemin d'administration ou alimente une revue d'incident plus large.

Pourquoi cette CVE reste importante pour les equipes identite et infrastructure

Copy Fail n'appartient pas au catalogue de vulnerabilites AD/Azure d'EtcSec, et cet article ne doit pas pretendre le contraire. Mais il reste important pour les equipes identite et infrastructure parce qu'un root local sur le mauvais systeme Linux change plus qu'un seul hote.

Exemples :

des bastions utilises pour administrer Windows ou l'infrastructure cloud
des noeuds Linux qui detiennent des credentials d'automatisation ou des secrets de configuration
des noeuds OpenShift ou conteneurs adjacents a des frontieres de confiance internes
des jump systems dans des environnements segmentes ou air-gapped

C'est la bonne raison de couvrir cette CVE ici. Non pas parce qu'elle se rattache proprement au catalogue existant, mais parce que la confiance infrastructure, les chemins d'administration et les preuves de remediation comptent encore quand le systeme affecte se situe a proximite du plan d'identite.

References primaires

Toutes les references ci-dessus ont ete re-verifiees et confirmees le 19 aout 2026.