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 2 mai 2026, le dossier officiel montre une faille de severite elevee dans le composant algif_aead, des mitigations editeur publiees par de grandes distributions Linux, et son inclusion dans le catalogue CISA Known Exploited Vulnerabilities au 1 mai 2026.

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. NVD indique aussi la classification CWE-669 et liste plusieurs references de correctifs kernel.org rattachees a des branches stables.

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 public `RHSB-2026-02` est marque Important et Ongoing ; des pages publiques separees existent pour RHEL et OpenShift.	Confirme une prise en charge editeur active et des chemins de suivi 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.

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. Les guides publics OpenShift et ROSA de Red Hat confirment que l'editeur traite l'exposition managed et OpenShift comme un sujet operationnel separe, ce qui est le bon cadrage defensif.

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.

Ubuntu indique que son equipe securite a publie une mitigation qui desactive le module affecte algif_aead via le paquet kmod pendant le deploiement des paquets noyau corriges. SUSE documente de son cote un workaround similaire qui bloque le module via une configuration modprobe.

C'est utile, mais cela 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
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.

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

La page publique de bulletins de Red Hat montre RHSB-2026-02 comme etant en cours, et Red Hat publie aussi des consignes publiques pour determiner si un produit est affecte par une CVE donnee via la base CVE Red Hat et les liens d'advisory associes. Red Hat a egalement publie des pages publiques distinctes pour RHEL et OpenShift sur CVE-2026-31431, ce qui constitue le bon chemin pour une validation par produit.

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.

CVE-2026-31431 (Copy Fail) : ce que la vulnerabilite du noyau Linux affecte et comment la mitiguer