Exploitation active : fourn. cloud DACH trop lents à corriger
Une vulnérabilité dans un outil d’assistance expose des machines virtuelles étrangères, les exploits fonctionnent depuis des jours.
El patching de proveedores cloud requiere responsabilidades claras, ventanas realistas y seguimiento continuo.
Les points clés en bref
- Le SSH est la porte d’entrée réelle : Le CVE-2026-31431 n’est pas exploitable à distance, mais nécessite une session locale. Dans les environnements cloud avec des clés compromises, des configurations de bastion faibles ou des CI-Runner compromis, cela suffit. Le défaut transforme un accès shell normal en root.
- La portée des charges de travail est large, mais pas profonde : Affectées sont les EC2 d’AWS, les VMs d’Azure, les machines virtuelles Compute Engine de GCP, les serveurs Hetzner, les hôtes de conteneurs, les nœuds de travail Kubernetes, les CI-Runner et les bastions SSH. Les services de conteneurs gérés (Fargate, Cloud Run) sont indirectement touchés si le hôte sous-jacent n’est pas correctifié.
- Un workaround avant le correctif est légitime : Si vous ne pouvez pas correctifier dans les 72 heures, désactivez le module AF_ALG via une liste noire modprobe. Cela empêche l’exploitation, mais coûte la performance des opérations cryptographiques qui utilisent l’interface du noyau. Testez en production avant.
Liens :Le régime des images de conteneurs 2026 : Distroless, Wolfi, Chainguard / L’état des FinOps 2026
Qu’est-ce qui s’est passé le 04.05.2026
Qu’est-ce que CVE-2026-31431 ? CVE-2026-31431, nommé interne « copyfail », est une faille de privilège d’escalation locale dans le noyau Linux. Elle se trouve dans l’interface AF_ALG du Kernel Crypto API et combine une erreur dans la composante ONC-ESN avec un primitif de write dans le cache de page. Un attaquant avec une ligne de commande normale sur le système peut y escalader pour obtenir des droits root. Toutes les distributions Linux sont concernées, y compris celles qui incluent l’implémentation AF_ALG de 2017 ou plus récente dans leur noyau.
Le Proof-of-Concept de Theori est un exploit Python de 732 lignes. Ce qui est remarquable n’est pas sa taille, mais la façon dont la faille a été découverte : l’agent autonome de l’IA de Theori a découvert la faille, construit le primitif d’exploit et a réalisé le PoC en environ une heure. CISA a ajouté la faille au catalogue KEV le même jour, et CrowdStrike Threat Intelligence a confirmé l’exploitation active.
Pour les agences gouvernementales américaines, l’ajout au KEV signifie une période de correction très serrée. Pour les organisations DACH, cela n’est pas obligatoire, mais le signal est clair : un exploit public plus l’exploitation active plus la portée large des distributions crée un pression de correction indépendamment de l’autorité de surveillance.
Où les charges de travail cloud sont concrètement concernées
La portée au-delà des hypercaleurs est élevée. AWS Linux 2 et Amazon Linux 2023 activent AF_ALG par défaut. Azure Ubuntu, Azure RHEL et Azure SUSE aussi. Google Compute Engine avec Debian, Ubuntu ou OS optimisé pour conteneurs également. Celui qui exploite des groupes d’auto-scaling EC2, des nœuds de travail AKS, des nœuds GKE ou des clusters Kubernetes hébergés doit vérifier la version des correctifs par image et par pool de nœuds.
L’infrastructure CI et de build est la deuxième zone de risque discrète. Les runners GitHub Actions hébergés sur site, les runners GitLab sur des hôtes, les agents Jenkins et les workers Buildkite s’exécutent généralement sur des systèmes Linux standard. Un job de pull request comprometté avec une étape shell peut potentiellement obtenir root sur le host de build. La recommandation standard « changer régulièrement les runners » devient obligatoire dans ce contexte.
Les services conteneurs gérés soulagent partiellement la charge. AWS Fargate, Google Cloud Run et Azure Container Apps isolent le host des charges de travail. Les fournisseurs de plateforme appliquent les correctifs aux hosts, les clients n’ayant à adapter leurs images de conteneurs que si le conteneur exécute des opérations privilégiées. Cependant, si des conteneurs s’exécutent avec hostPID, hostNetwork ou mode privilégié, ou si des nœuds Kubernetes sont hébergés, on retrouve le mode de correctif obligatoire.
Chemin de correctif en 72 heures
Le chemin rapide ressemble généralement dans les flottes cloud productives. Premierement : l’inventaire. Quelles versions de Linux sont en cours d’exécution, avec quel noyau, dans quelles groupes d’auto-scaling ou pools de nœuds ? Les clients AWS reçoivent cela via Systems Manager Inventory, Azure via Update Management, GCP via OS Config. Celui qui ne l’a pas, construit un inventaire ad hoc pour une heure avec SSM-Run-Command ou Ansible-Ad-hoc.
Deuxièmement : déploiement de correctifs par vagues. Premierement le stage, puis 10 pour cent de la production, puis le reste. Dans les groupes d’auto-scaling, cela signifie une nouvelle AMI avec le noyau correctif et un remplacement en cours de route. Dans Kubernetes, un upgrade de pool de nœuds, idéalement avec protection PDB sur les charges de travail de noyau. Troisièmement : vérification. Un seul commande par machine correctée suffit : uname -r contre le noyau de fixation spécifique au distributeur.
Si on ne peut pas respecter le chemin de 72 heures, il y a un workaround. La création de la file /etc/modprobe.d/blacklist-af_alg.conf avec la ligne install af_alg /bin/false empêche le module de se charger au démarrage. Les sessions existantes nécessitent un redémarrage pour que les modifications prennent effet. Attention : le déchargement TLS, les piles de chiffrement de disque et les connexions HSM utilisant AF_ALG basculent vers des retours de l’espace utilisateur. Mesurer l’impact sur la performance avant la production.
Foire aux questions
Sont les conteneurs dans les services gérés tels que Fargate ou Cloud Run directement concernés ?
Directement, non. Le hyper-scalaire applique les correctifs au noyau, mais le conteneur ne voit pas l’interface du noyau. Indirectement, oui : si un conteneur s’exécute en mode privilégié ou avec hostPID, ou si l’application elle-même lance des opérations AF_ALG, l’exploit peut devenir pertinant dans ces environnements. Les charges de travail web standard sans opérations de chiffrement du noyau ne sont pas les cibles principales.
Quelles distributions Linux ont déjà des correctifs le 05.05.2026 ?
Red Hat Enterprise Linux 8 et 9 ont des mises à jour via le canal d’errata régulier. Ubuntu LTS 20.04, 22.04 et 24.04 ont des correctifs dans le Security Pocket. Debian Stable a l’update dans le Stable Security Repo. Amazon Linux 2 et Amazon Linux 2023 sont disponibles via yum/dnf. SUSE Linux Enterprise 15 est dans le Maintenance Channel. Arch et openSUSE Tumbleweed utilisent le noyau principal. Alpine Linux suit généralement dans les 48 heures.
Quel est l’impact de la performance de la solution de contournement AF_ALG ?
Fortement dépendant de la charge de travail. Un serveur web standard avec OpenSSL ne fait pas usage d’AF_ALG et n’a aucun impact. L’encryption de disque avec dm-crypt revient à AES en espace utilisateur, ce qui a une faible différence sur les CPUs modernes avec AES-NI. Les connexions HSM et PKCS11 qui utilisent AF_ALG pour l’abstraction matérielle peuvent devenir significativement plus lentes. Il est recommandé d’effectuer une mesure de charge sur un noeud de staging avant de mettre en œuvre le contournement.
Est-ce qu’un redémarrage est suffisant après le correctif ou est-ce qu’il faut plus ?
Un correctif dans l’image du noyau ne prend effet qu’après un redémarrage. Dans les groupes d’auto-scaling, il est pratique de passer à une nouvelle AMI avec un noyau correctifié. Dans Kubernetes, il est recommandé d’effectuer une mise à niveau du pool de noeuds. Le patching en ligne via kpatch ou kgraft est possible sur certaines distributions, mais pas sur toutes. Si vous n’avez pas de patching en ligne dans votre stack, planifiez un redémarrage progressif dans les 72 heures suivant.
Qu’est-ce qui se passe avec les instances cloud basées sur ARM comme AWS Graviton ?
Egalement concernés. AF_ALG est une interface du noyau, indépendamment de l’architecture de la CPU. AWS Graviton, Azure Cobalt et Google Tau-T2A s’exécutent tous avec les mêmes distributions Linux que les instances x86. Le chemin du correctif est identique : mise à jour spécifique à la distribution, redémarrage, vérification.
Plus du réseau MBF Media
SecurityTodaySecurityToday: Bilan de la RSA Conference 2026 – priorités des CISO DACH sur PQC, détection et consolidation fournisseursDigital ChiefsDigital Chiefs: CIOs sous pression – 62 pour cent concernés par la gouvernance de l’IAMyBusinessFutureMyBusinessFuture: EUDI Wallet depuis le déploiement pilote 2026 – Infrastructure d’identité pour les entreprises de taille intermédiaireSource image de couverture : Pexels / Brett Sayles
