Passer au contenu principal
Publié le 1 mai 2026
CVE-2026-31431 — surnommée “Copy Fail”. Bug d’élévation locale de privilèges présent dans la quasi-totalité des noyaux Linux récents. Si votre serveur fait tourner du code tiers ou expose un accès shell, traitez la mitigation comme prioritaire.

​
Le problème en deux phrases

La faille loge dans le sous-système cryptographique du noyau Linux, exposé via l’interface AF_ALG (module algif_aead). Elle permet à du code s’exécutant localement avec des droits limités d’écrire en zone noyau et d’en sortir avec les privilèges root. Concrètement, deux scénarios d’exploitation ressortent :
  • Sortie d’un compte utilisateur vers root sur un serveur classique.
  • Évasion de conteneur vers le nœud hôte sur Docker ou Kubernetes — le périmètre d’isolation des pods s’effondre.
L’attaquant a besoin d’un point d’appui local préalable (compte utilisateur, pod, code embarqué dans une dépendance, etc.). Sans cela, la faille n’est pas exploitable à distance.

​
Évaluer son exposition

Plutôt qu’une criticité absolue, la bonne grille de lecture est : qui peut exécuter du code chez vous ?
ProfilExpositionRéaction
VPS dédié à votre application, sans tiers, code maîtriséFaibleAttendre le correctif noyau, planifier la mise à jour
VPS hébergeant plusieurs clients, plusieurs comptes shell, ou exécutant du code non audité (CI partagée, plugins, runtimes utilisateurs)CritiqueMitiger immédiatement, puis patcher
Cluster Kubernetes où vous orchestrez des pods de tiers ou des workloads dynamiquesCritiqueDaemonSet de mitigation sur tous les nœuds

​
Mitigation immédiate

Le correctif définitif passera par une mise à jour du noyau. En attendant qu’il atterrisse dans votre distribution, on désactive le module incriminé. L’opération est réversible et n’impacte pas la grande majorité des charges applicatives.

​
Sur Debian, Ubuntu et dérivés

# Bloque le rechargement automatique au prochain démarrage
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf

# Décharge le module déjà résident en mémoire
sudo rmmod algif_aead 2>/dev/null || true

​
Sur RHEL, AlmaLinux, Rocky Linux, CentOS et Fedora

L’approche est légèrement différente : on passe par GRUB pour neutraliser le module dès l’initialisation du noyau. 
sudo grubby --update-kernel=ALL --args=initcall_blacklist=algif_aead_init
sudo reboot

​
Sur un cluster Kubernetes

Si vous orchestrez vos VPS via Kubernetes, propagez la mitigation sur tous les nœuds avec un DaemonSet privilégié. Le pod pause à la fin évite que le DaemonSet termine et soit relancé en boucle après le initContainer. 
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: disable-algif-aead
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: disable-algif-aead
  template:
    metadata:
      labels:
        app: disable-algif-aead
    spec:
      hostPID: true
      tolerations:
        - operator: Exists
          effect: NoSchedule
        - operator: Exists
          effect: NoExecute
      initContainers:
        - name: disable-algif-aead
          image: alpine:3.23
          securityContext:
            privileged: true
          command:
            - /bin/sh
            - -c
            - |
              echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
              rmmod algif_aead 2>/dev/null || true
          volumeMounts:
            - name: modprobe-d
              mountPath: /etc/modprobe.d
      containers:
        - name: pause
          image: registry.k8s.io/pause:3.10
          resources:
            limits:
              cpu: 1m
              memory: 8Mi
      volumes:
        - name: modprobe-d
          hostPath:
            path: /etc/modprobe.d

​
Vérifier que la mitigation est active

Une vérification rapide après application : 
# Le module ne doit plus apparaître
lsmod | grep algif_aead

# Et toute tentative de chargement doit échouer
sudo modprobe algif_aead 2>&1
# attendu : "install /bin/false algif_aead" suivi de l'échec
Si lsmod ne renvoie rien et que modprobe échoue, la mitigation est en place.

​
Annuler la mitigation

Si un service spécifique exploite l’API AF_ALG du noyau (ce qui reste rare hors usages cryptographiques de bas niveau), vous pouvez réactiver le module : 
sudo rm /etc/modprobe.d/disable-algif.conf
sudo modprobe algif_aead
Sur RHEL et dérivés, retirer aussi le paramètre noyau : 
sudo grubby --update-kernel=ALL --remove-args=initcall_blacklist=algif_aead_init
sudo reboot

​
Et après ?

Surveillez les bulletins de votre distribution — le correctif noyau est la cible finale, la désactivation du module n’est qu’un palliatif. Pour toute question technique, ouvrez un ticket depuis votre espace client OnetSolutions.