Copy.Fail CVE-2026-31431 : protéger les clusters MKS OVHcloud

Fail CVE-2026-31431 : protéger les clusters MKS OVHcloud Analyse de Copy. Fail et des mesures d'atténuation pour les clusters MKS OVHcloud. Fail, identifiée sous le nom CVE-2026-31431, est l'une des vulnérabilités d'élévation de privilèges les plus graves révélées ces dernières années.

La faille Copy.Fail, identifiée sous le nom CVE-2026-31431, est l'une des vulnérabilités d'élévation de privilèges les plus graves révélées ces dernières années. Discrètement divulguée le 29 avril 2026 par Theori, elle exploite le noyau Linux et peut permettre à un utilisateur ordinaire d'obtenir les droits root, sans dépendre d'un bug de race ou d'une configuration particulière.

Ce qu'est Copy.Fail et pourquoi elle est dangereuse

Copy.Fail s'appuie sur une faille logique du module crypto algif_aead du noyau Linux, introduite lors d'une optimisation en 2017. En abusant de l'interface AF_ALG, un attaquant peut écrire des données manipulées dans le cache de pages (la représentation en mémoire des binaires système de confiance). Cela permet de détourner temporairement des binaires comme /usr/bin/su sans toucher les fichiers sur disque.

Concrètement, cela signifie qu'un utilisateur normal peut devenir root, qu'un conteneur compromis peut s'échapper vers l'hôte et qu'un job CI malveillant peut prendre le contrôle du runner. Les infrastructures partagées et multi-locataires deviennent vulnérables, et les traces sur le disque peuvent être absentes puisque les modifications se produisent en mémoire.

Impact et risques pour les environnements multi-locataires

Les environnements concernés incluent notamment les clusters Kubernetes, les systèmes CI/CD, et les plateformes de développement partagées.

• Élévation de privilèges : un utilisateur peut accéder à des droits privilégiés sur le système.
• Évasion de conteneur : un conteneur compromis peut accéder à l'hôte.
• Risques multi-tenant : une faille peut se propager entre tenants partageant l'infrastructure.
• Forensics RAM uniquement : les preuves peuvent être limitées à la mémoire vive.

Réponse d'OVHcloud et correctifs pour les clusters MKS

OVHcloud prépare des versions MKS corrigées, intégrant le correctif du noyau upstream. Les versions patchées sont attendues le 30 avril 2026 à 16:00 UTC+2. En attendant cette release, OVHcloud propose une mitigation sous forme de DaemonSet à déployer dans les clusters MKS.

Mise en œuvre pratique dans les clusters MKS

Pour réduire rapidement l'exposition, vous pouvez appliquer le patch suivant dans vos clusters MKS. Il s'agit d'un DaemonSet qui désactive le module algif_aead et recharge l’initramfs, afin d’atténuer Copy.Fail dans l’immédiat.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: patch-copy-fail-cve
  labels:
    app: patch-copy-fail-cve
  namespace: default
spec:
  selector:
    matchLabels:
      app: patch-copy-fail-cve
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 100%
  template:
    metadata:
      labels:
        app: patch-copy-fail-cve
    spec:
      hostPID: true
      priorityClassName: system-node-critical
      volumes:
        - name: root-mount
          hostPath:
            path: /
            type: Directory
      initContainers:
        - name: patch-copy-fail-cve
          image: busybox:1.36.1
          command: ["/bin/bash", "-c"]
          args:
            - |
              printf "install algif_aead /bin/false\n" > /etc/modprobe.d/disable-algif-aead.conf
              rmmod algif_aead 2>/dev/null || true
              update-initramfs -u
          securityContext:
            privileged: true
            runAsUser: 0
          volumeMounts:
            - name: root-mount
              mountPath: /
      containers:
        - image: "k8s.gcr.io/pause:3.6.1"
          name: pause

Pour appliquer ce patch, exécutez :

kubectl apply -f patch-copy-fail-cve.yaml

Attention : cette mitigation a été testée sur des environnements de test internes OVHcloud. Son déploiement sur vos services reste votre responsabilité. Si la faille a déjà été exploité dans votre cluster, cette mitigation ne résout pas une compromission préexistante. La remediation officielle reste le correctif sécurité publié par les éditeurs et distribuée via les releases MKS.

Pour en savoir plus sur la mitigation et le contexte, consultez : GitHub – mitigation Copy.Fail.

Limites et ce qu'on ne sait pas encore

Bien que les correctifs du noyau et les mécanismes d'atténuation réduisent le risque, Copy.Fail peut encore exister sous certaines configurations ou si des systèmes non corrigés restent en production. Un arc de sécurité interdépendant peut nécessiter des mises à jour complémentaires et une vérification des chaînes d’approvisionnement et des images utilisées dans les clusters.

Pour terminer

La correction officielle est en cours de déploiement dans l’écosystème MKS. Restez vigilant sur les releases et appliquez rapidement les mesures d’atténuation recommandées — en particulier dans les environnements Kubernetes et multi-locataires — afin de limiter l’impact de ce zéro-day.