Copy Fail (CVE-2026-31431) : élévation locale de privilèges dans le noyau Linux

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 ?

Profil	Exposition	Réaction
VPS dédié à votre application, sans tiers, code maîtrisé	Faible	Attendre 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)	Critique	Mitiger immédiatement, puis patcher
Cluster Kubernetes où vous orchestrez des pods de tiers ou des workloads dynamiques	Critique	DaemonSet 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.

Paiement par Paysafecard

React2Shell (CVE-2025-55182) : RCE non authentifiée dans React Server Components

Vue d'ensemble

Annonces produits

Hébergement web

Conseils & comparaisons

Paiement

Avis de sécurité

Copy Fail (CVE-2026-31431) : élévation locale de privilèges dans le noyau Linux

Le problème en deux phrases

Évaluer son exposition

Mitigation immédiate

Sur Debian, Ubuntu et dérivés

Sur RHEL, AlmaLinux, Rocky Linux, CentOS et Fedora

Sur un cluster Kubernetes

Vérifier que la mitigation est active

Annuler la mitigation

Et après ?

​Le problème en deux phrases

​Évaluer son exposition

​Mitigation immédiate

​Sur Debian, Ubuntu et dérivés

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

​Sur un cluster Kubernetes

​Vérifier que la mitigation est active

​Annuler la mitigation

​Et après ?

Le problème en deux phrases

Évaluer son exposition

Mitigation immédiate

Sur Debian, Ubuntu et dérivés

Sur RHEL, AlmaLinux, Rocky Linux, CentOS et Fedora

Sur un cluster Kubernetes

Vérifier que la mitigation est active

Annuler la mitigation

Et après ?