6 min de lecture

Le CISA a ajouté CVE-2026-31431 au catalogue des vulnérabilités exploitées connues le 04.05.2026. CrowdStrike confirme une exploitation active en milieu naturel. Concernés : toutes les instances Linux avec un noyau à partir de 2017 et le module AF_ALG chargé. Pour les opérateurs cloud DACH, cela signifie concrètement que quasiment toutes les flottes de machines virtuelles EC2, Compute Engine et Azure VM doivent être corrigées ou dotées d’une solution de contournement fiable dans les 72 heures.

Les points clés en bref

• Un accès SSH constitue la porte d’entrée réelle : CVE-2026-31431 n’est pas exploitable à distance, mais nécessite une session locale. Dans les environnements cloud avec clés divulguées, configurations faibles des bastions ou runners CI compromis, cela suffit amplement. La faille transforme un accès shell classique en accès root.
• Portée étendue, mais pas profonde : Sont concernés AWS EC2, Azure VM, GCP Compute Engine, serveurs Hetzner, hôtes de conteneurs, nœuds worker Kubernetes, runners CI et bastions SSH. Les services gérés de conteneurs (Fargate, Cloud Run) ne sont concernés qu’indirectement, uniquement si l’hôte sous-jacent n’est pas corrigé.
• Une solution de contournement avant le correctif est acceptable : Qui ne peut pas corriger sous 72 heures peut désactiver AF_ALG via une liste noire modprobe. Cela empêche l’exploitation, mais pénalise les performances des opérations cryptographiques utilisant cette interface noyau. À tester avant déploiement en production.

En lien :Régime allégé des images conteneurs 2026 : Distroless, Wolfi, Chainguard  /  État de l’art FinOps 2026

Ce qui s’est produit le 04.05.2026

Qu’est-ce que CVE-2026-31431 ? CVE-2026-31431, baptisée en interne « copyfail », est une vulnérabilité d’élévation de privilèges 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’écriture dans le cache de pages. Un attaquant disposant d’un accès shell classique sur le système peut ainsi obtenir les droits root. Toutes les distributions Linux dont le noyau inclut l’implémentation AF_ALG à partir de 2017 sont concernées.

Le proof-of-concept publié par Theori est un exploit Python de 732 lignes. Ce qui frappe n’est pas sa taille, mais la manière dont il a été découvert : l’agent d’intelligence artificielle autonome de Theori a repéré la faille, construit le primitif d’exploitation et finalisé le PoC en environ une heure. CISA a inscrit la vulnérabilité le même jour au catalogue KEV, et CrowdStrike Threat Intelligence confirme une exploitation active.

Pour les agences fédérales américaines, l’inscription au catalogue KEV implique un délai 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épendamment de toute réglementation.

Où les charges de travail cloud sont concrètement concernées

La portée dépasse largement les hyperscalers. AWS Linux 2 et Amazon Linux 2023 chargent AF_ALG par défaut. Azure Ubuntu, Azure RHEL et Azure SUSE de même. Google Compute Engine avec Debian, Ubuntu ou Container-Optimized OS également. Qui exploite des groupes d’auto-échelle EC2, des nœuds worker AKS, des nœuds GKE ou des clusters Kubernetes auto-hébergés doit vérifier le niveau de correctifs pour chaque image et chaque pool de nœuds.

L’infrastructure d’intégration continue (CI) et de construction est la deuxième zone de risque silencieuse. Les runners auto-hébergés GitHub Actions, les GitLab Runners sur serveurs dédiés, les agents Jenkins et les workers Buildkite tournent généralement sous Linux standard. Un job de pull request compromis avec une étape shell peut donc potentiellement obtenir les droits root sur l’hôte de construction. La recommandation classique « remplacer régulièrement les runners » devient alors une obligation.

Les services de conteneurs gérés allègent partiellement la charge. AWS Fargate, Google Cloud Run et Azure Container Apps abstraient l’hôte de la charge de travail. Les opérateurs de plateforme corrigent les hôtes ; les clients n’ont à mettre à jour leurs images de conteneurs que si ces derniers effectuent des opérations privilégiées. Mais ceux qui exécutent des conteneurs avec hostPID, hostNetwork ou en mode privilégié, ou qui gèrent eux-mêmes les workers Kubernetes, retombent dans l’obligation de mise à jour.

« L’exploitation active en environnement réel est confirmée. Tous les systèmes Linux non corrigés disposant de AF_ALG activé sont exposés. »
Intelligence sur les menaces de CrowdStrike, 04.05.2026

Parcours de correction en 72 heures

Le chemin rapide est généralement identique dans les flottes cloud productives. Premièrement : l’inventaire. Quelles versions de Linux tournent, avec quel noyau, dans quelles groupes d’auto-échelle ou pools de nœuds ? Les clients AWS peuvent l’obtenir via Systems Manager Inventory, Azure via Update Management, GCP via OS Config. Ceux qui n’ont pas cela construisent en une heure un inventaire ad hoc avec SSM Run Command ou Ansible Ad-hoc.

Deuxièmement : déploiement progressif des correctifs. D’abord en préproduction, puis 10 % de la production, ensuite le reste. Pour les groupes d’auto-échelle, cela signifie une nouvelle AMI avec un noyau corrigé et un remplacement progressif. Pour Kubernetes, une mise à niveau du pool de nœuds, idéalement protégée par des PDB pour les charges critiques. Troisièmement : vérification. Un seul commande par machine corrigée suffit : uname -r à comparer avec le noyau correctif propre à la distribution.

Celui qui ne peut pas suivre le parcours en 72 heures dispose du correctif temporaire. Créer le fichier /etc/modprobe.d/blacklist-af_alg.conf contenant la ligne install af_alg /bin/false empêche le chargement du module au démarrage. Les sessions existantes nécessitent un redémarrage pour que la modification prenne effet. Attention : le déchargement TLS, les piles de chiffrement de disque et les connexions HSM utilisant AF_ALG reviendront à des solutions de repli en espace utilisateur. Mesurer l’impact sur les performances avant la mise en production.

Foire aux questions

Les conteneurs dans des services gérés comme Fargate ou Cloud Run sont-ils directement concernés ?

Pas directement. L’hyperscaler corrige l’hôte, et les conteneurs en dessous n’ont tout simplement pas accès à l’interface du noyau. Indirectement, oui : si un conteneur fonctionne en mode privilégié ou avec hostPID, ou si l’application elle-même déclenche des opérations AF_ALG, l’exploit peut devenir pertinent même dans ces environnements. Les charges de travail web standard sans opérations de chiffrement au niveau du noyau ne sont pas la cible principale.

Quelles distributions Linux disposaient déjà de correctifs le 05.05.2026 ?

Red Hat Enterprise Linux 8 et 9 disposent de mises à jour via le canal régulier des erratas. Ubuntu LTS 20.04, 22.04 et 24.04 ont des correctifs dans le pocket Security. Debian Stable a la mise à jour dans le dépôt 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énéralement dans un délai de 48 heures.

Quel est l’impact sur les performances du contournement AF_ALG ?

Fortement dépendant 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és d’AES-NI, entraîne une différence minime. Les connexions HSM et PKCS11 utilisant AF_ALG pour l’abstraction matérielle peuvent devenir nettement plus lentes. Avant d’appliquer le contournement en production, mesurez une courte pointe de charge sur un nœud de préproduction.

Un redémarrage après l’application du correctif suffit-il, ou faut-il faire plus ?

Un correctif appliqué au fichier image du noyau n’est effectif qu’après redémarrage. Dans le cas de groupes de mise à l’échelle automatique, cela se fait généralement via un nouvel AMI intégrant le noyau corrigé. Sous Kubernetes, via une mise à niveau du pool de nœuds. Le correctif à chaud via kpatch ou kgraft est possible sur certaines distributions, mais pas toutes. Si vous n’utilisez pas de correctif à chaud, prévoyez un redémarrage progressif dans les 72 heures imparties.

Et les instances cloud basées sur ARM comme AWS Graviton ?

Également concernées. AF_ALG est une interface noyau, indépendante de l’architecture processeur. AWS Graviton, Azure Cobalt et Google Tau-T2A fonctionnent tous avec les mêmes distributions Linux que les instances x86. Le processus de correction est identique : mise à jour spécifique à la distribution, redémarrage, vérification.

Plus d’actualités du réseau MBF Media

• SecurityToday : Bilan de la RSA Conference 2026 – Les devoirs des CISO DACH sur la PQC, la détection et la consolidation des fournisseurs
• Digital Chiefs : Les CIO sous pression – 62 % en matière de gouvernance de l’IA
• MyBusinessFuture : EUDI Wallet dès le déploiement pilote 2026 – Une infrastructure d’identité pour les PME

Source image titre : Pexels / Brett Sayles