6 min de lecture<\/p>\n
Le CISA a ajout\u00e9 CVE-2026-31431 au catalogue des vuln\u00e9rabilit\u00e9s exploit\u00e9es connues le 04.05.2026. CrowdStrike confirme une exploitation active en milieu naturel. Concern\u00e9s : toutes les instances Linux avec un noyau \u00e0 partir de 2017 et le module AF_ALG charg\u00e9. Pour les op\u00e9rateurs cloud DACH, cela signifie concr\u00e8tement que quasiment toutes les flottes de machines virtuelles EC2, Compute Engine et Azure VM doivent \u00eatre corrig\u00e9es ou dot\u00e9es d’une solution de contournement fiable dans les 72 heures.<\/strong><\/p>\n En lien :<\/span>R\u00e9gime all\u00e9g\u00e9 des images conteneurs 2026 : Distroless, Wolfi, Chainguard<\/a> \/<\/span> \u00c9tat de l’art FinOps 2026<\/a><\/p>\n Qu’est-ce que CVE-2026-31431 ?<\/strong> CVE-2026-31431, baptis\u00e9e en interne \u00ab copyfail \u00bb, est une vuln\u00e9rabilit\u00e9 d’\u00e9l\u00e9vation de privil\u00e8ges locale dans le noyau Linux. Elle se situe au niveau de l’interface AF_ALG de l’API cryptographique du noyau et combine une faille dans le composant ONC-ESN avec un primitif d’\u00e9criture dans le cache de pages. Un attaquant disposant d’un acc\u00e8s shell classique sur le syst\u00e8me peut ainsi obtenir les droits root. Toutes les distributions Linux dont le noyau inclut l’impl\u00e9mentation AF_ALG \u00e0 partir de 2017 sont concern\u00e9es.<\/p>\n Le proof-of-concept publi\u00e9 par Theori<\/a> est un exploit Python de 732 lignes. Ce qui frappe n’est pas sa taille, mais la mani\u00e8re dont il a \u00e9t\u00e9 d\u00e9couvert : l’agent d’intelligence artificielle autonome de Theori a rep\u00e9r\u00e9 la faille, construit le primitif d’exploitation et finalis\u00e9 le PoC en environ une heure. CISA a inscrit la vuln\u00e9rabilit\u00e9 le m\u00eame jour au catalogue KEV<\/a>, et CrowdStrike Threat Intelligence confirme une exploitation active.<\/p>\n Pour les agences f\u00e9d\u00e9rales am\u00e9ricaines, l’inscription au catalogue KEV implique un d\u00e9lai de correctif strict. Pour les organisations DACH, cela n’est pas contraignant, mais le message est clair : la combinaison d’un exploit public, d’une exploitation active et d’une large couverture des distributions exerce une pression au correctif, ind\u00e9pendamment de toute r\u00e9glementation.<\/p>\n La port\u00e9e d\u00e9passe largement les hyperscalers. AWS Linux 2 et Amazon Linux 2023 chargent AF_ALG par d\u00e9faut. Azure Ubuntu, Azure RHEL et Azure SUSE de m\u00eame. Google Compute Engine avec Debian, Ubuntu ou Container-Optimized OS \u00e9galement. Qui exploite des groupes d\u2019auto-\u00e9chelle EC2, des n\u0153uds worker AKS, des n\u0153uds GKE ou des clusters Kubernetes auto-h\u00e9berg\u00e9s doit v\u00e9rifier le niveau de correctifs pour chaque image et chaque pool de n\u0153uds.<\/p>\n L\u2019infrastructure d\u2019int\u00e9gration continue (CI) et de construction est la deuxi\u00e8me zone de risque silencieuse. Les runners auto-h\u00e9berg\u00e9s GitHub Actions, les GitLab Runners sur serveurs d\u00e9di\u00e9s, les agents Jenkins et les workers Buildkite tournent g\u00e9n\u00e9ralement sous Linux standard. Un job de pull request compromis avec une \u00e9tape shell peut donc potentiellement obtenir les droits root sur l\u2019h\u00f4te de construction. La recommandation classique \u00ab remplacer r\u00e9guli\u00e8rement les runners \u00bb devient alors une obligation.<\/p>\n Les services de conteneurs g\u00e9r\u00e9s all\u00e8gent partiellement la charge. AWS Fargate, Google Cloud Run et Azure Container Apps abstraient l\u2019h\u00f4te de la charge de travail. Les op\u00e9rateurs de plateforme corrigent les h\u00f4tes ; les clients n\u2019ont \u00e0 mettre \u00e0 jour leurs images de conteneurs que si ces derniers effectuent des op\u00e9rations privil\u00e9gi\u00e9es. Mais ceux qui ex\u00e9cutent des conteneurs avec hostPID, hostNetwork ou en mode privil\u00e9gi\u00e9, ou qui g\u00e8rent eux-m\u00eames les workers Kubernetes, retombent dans l\u2019obligation de mise \u00e0 jour.<\/p>\n \n\u00ab L\u2019exploitation active en environnement r\u00e9el est confirm\u00e9e. Tous les syst\u00e8mes Linux non corrig\u00e9s disposant de AF_ALG activ\u00e9 sont expos\u00e9s. \u00bb Le chemin rapide est g\u00e9n\u00e9ralement identique dans les flottes cloud productives. Premi\u00e8rement : l\u2019inventaire. Quelles versions de Linux tournent, avec quel noyau, dans quelles groupes d\u2019auto-\u00e9chelle ou pools de n\u0153uds ? Les clients AWS peuvent l\u2019obtenir via Systems Manager Inventory, Azure via Update Management, GCP via OS Config. Ceux qui n\u2019ont pas cela construisent en une heure un inventaire ad hoc avec SSM Run Command ou Ansible Ad-hoc<\/a>.<\/p>\n Deuxi\u00e8mement : d\u00e9ploiement progressif des correctifs. D\u2019abord en pr\u00e9production, puis 10 % de la production, ensuite le reste. Pour les groupes d\u2019auto-\u00e9chelle, cela signifie une nouvelle AMI avec un noyau corrig\u00e9 et un remplacement progressif. Pour Kubernetes, une mise \u00e0 niveau du pool de n\u0153uds, id\u00e9alement prot\u00e9g\u00e9e par des PDB pour les charges critiques. Troisi\u00e8mement : v\u00e9rification. Un seul commande par machine corrig\u00e9e suffit : uname -r<\/span> \u00e0 comparer avec le noyau correctif propre \u00e0 la distribution.<\/p>\n Celui qui ne peut pas suivre le parcours en 72 heures dispose du correctif temporaire. Cr\u00e9er le fichier \/etc\/modprobe.d\/blacklist-af_alg.conf<\/span> contenant la ligne install af_alg \/bin\/false<\/span> emp\u00eache le chargement du module au d\u00e9marrage. Les sessions existantes n\u00e9cessitent un red\u00e9marrage pour que la modification prenne effet. Attention : le d\u00e9chargement TLS, les piles de chiffrement de disque et les connexions HSM utilisant AF_ALG reviendront \u00e0 des solutions de repli en espace utilisateur. Mesurer l\u2019impact sur les performances avant la mise en production.<\/p>\n Pas directement. L’hyperscaler corrige l’h\u00f4te, et les conteneurs en dessous n’ont tout simplement pas acc\u00e8s \u00e0 l’interface du noyau. Indirectement, oui : si un conteneur fonctionne en mode privil\u00e9gi\u00e9 ou avec hostPID, ou si l’application elle-m\u00eame d\u00e9clenche des op\u00e9rations AF_ALG, l’exploit peut devenir pertinent m\u00eame dans ces environnements. Les charges de travail web standard sans op\u00e9rations de chiffrement au niveau du noyau ne sont pas la cible principale.<\/p>\n<\/details>\n Red Hat Enterprise Linux 8 et 9 disposent de mises \u00e0 jour via le canal r\u00e9gulier des erratas. Ubuntu LTS 20.04, 22.04 et 24.04 ont des correctifs dans le pocket Security. Debian Stable a la mise \u00e0 jour dans le d\u00e9p\u00f4t Stable-Security. Amazon Linux 2 et Amazon Linux 2023 sont disponibles via yum\/dnf. SUSE Linux Enterprise 15 est accessible dans le canal Maintenance. Arch et openSUSE Tumbleweed adoptent le noyau mainline. Alpine Linux suit g\u00e9n\u00e9ralement dans un d\u00e9lai de 48 heures.<\/p>\n<\/details>\n Fortement d\u00e9pendant de la charge de travail. Un serveur web standard utilisant OpenSSL n’utilise pas AF_ALG et n’a donc aucun impact. Le chiffrement de disque avec dm-crypt revient au chiffrement AES en espace utilisateur, ce qui, sur des processeurs modernes dot\u00e9s d’AES-NI, entra\u00eene une diff\u00e9rence minime. Les connexions HSM et PKCS11 utilisant AF_ALG pour l’abstraction mat\u00e9rielle peuvent devenir nettement plus lentes. Avant d’appliquer le contournement en production, mesurez une courte pointe de charge sur un n\u0153ud de pr\u00e9production.<\/p>\n<\/details>\n Un correctif appliqu\u00e9 au fichier image du noyau n’est effectif qu’apr\u00e8s red\u00e9marrage. Dans le cas de groupes de mise \u00e0 l’\u00e9chelle automatique, cela se fait g\u00e9n\u00e9ralement via un nouvel AMI int\u00e9grant le noyau corrig\u00e9. Sous Kubernetes, via une mise \u00e0 niveau du pool de n\u0153uds. Le correctif \u00e0 chaud via kpatch ou kgraft est possible sur certaines distributions, mais pas toutes. Si vous n’utilisez pas de correctif \u00e0 chaud, pr\u00e9voyez un red\u00e9marrage progressif dans les 72 heures imparties.<\/p>\n<\/details>\n \u00c9galement concern\u00e9es. AF_ALG est une interface noyau, ind\u00e9pendante de l’architecture processeur. AWS Graviton, Azure Cobalt et Google Tau-T2A fonctionnent tous avec les m\u00eames distributions Linux que les instances x86. Le processus de correction est identique : mise \u00e0 jour sp\u00e9cifique \u00e0 la distribution, red\u00e9marrage, v\u00e9rification.<\/p>\n<\/details>\n Source image titre : Pexels \/ Brett Sayles<\/p>\n","protected":false},"excerpt":{"rendered":"~9 Min. Lesezeit<\/span>Les points cl\u00e9s en bref<\/h2>\n
\n
Ce qui s’est produit le 04.05.2026<\/h2>\n
O\u00f9 les charges de travail cloud sont concr\u00e8tement concern\u00e9es<\/h2>\n
\n
\nIntelligence sur les menaces de CrowdStrike, 04.05.2026<\/cite>\n<\/p>\n<\/blockquote>\nParcours de correction en 72 heures<\/h2>\n
Foire aux questions<\/h2>\n
Les conteneurs dans des services g\u00e9r\u00e9s comme Fargate ou Cloud Run sont-ils directement concern\u00e9s ?<\/strong><\/summary>\n
Quelles distributions Linux disposaient d\u00e9j\u00e0 de correctifs le 05.05.2026 ?<\/strong><\/summary>\n
Quel est l’impact sur les performances du contournement AF_ALG ?<\/strong><\/summary>\n
Un red\u00e9marrage apr\u00e8s l’application du correctif suffit-il, ou faut-il faire plus ?<\/strong><\/summary>\n
Et les instances cloud bas\u00e9es sur ARM comme AWS Graviton ?<\/strong><\/summary>\n
Plus d’actualit\u00e9s du r\u00e9seau MBF Media<\/h2>\n
\n