---
title: "CVE-2026-31431 \"Copy Fail\" - Impact sur mes serveurs Debian 13"
canonical: "https://blog.kaptus.net/space/BKAP/blog/802783233/CVE-2026-31431%20%22Copy%20Fail%22%20-%20Impact%20sur%20mes%20serveurs%20Debian%2013"
format: markdown
---
> Macro (toc)

# 1. Introduction.

Un faille sévère a été détecté sur le kernel Linux .

# 2. Bulletin de sécurité - CVE-2026-31431 : Analyse, périmètre et plan de remédiation

Ceci est une note d'information concernant la [CVE-2026-31431](https://www.sysdig.com/blog/cve-2026-31431-copy-fail-linux-kernel-flaw-lets-local-users-gain-root-in-seconds), connue sous le nom "Copy Fail". Elle représente l'une des vulnérabilités du noyau Linux les plus larges de ces dernières années, avec un impact potentiel sur l'ensemble du parc Linux mondial. Cette faille a été remontée le **29 Avril 2026**.

Notre équipe sécurité a pris connaissance de cette divulgation le jour même de sa publication et a engagé sans délai les investigations nécessaires.

Cette faille, située dans le sous-système cryptographique du noyau (via l'interface `AF_ALG`), permet une élévation de privilèges locaux (`LPE`). Sur un serveur classique, elle permet à un utilisateur standard de devenir root (**administrateur**). Dans le cadre d'un environnement conteneurisé (comme **Docker** ou **Kubernetes**), elle permet une évasion de conteneur pour prendre le contrôle du nœud hôte.

La sécurité de vos infrastructures étant notre priorité, voici les détails concernant l'impact de cette vulnérabilité sur vos services `Scaleway` et les recommandations à suivre. 

## 2.1. Ce qui a été fait côté `Scaleway`.

Dès la divulgation de cette faille, nos équipes ont pris les mesures nécessaires pour sécuriser les environnements et fournir des images saines :

Sur `Kubernetes Kapsule` : De nouvelles images d'OS désactivant le module `algif_aead` ont été déployées : Tout nouveau nœud créé après le **30/04/2026 à 14h20 CEST **utilisera automatiquement une version mitigée. (Vous pouvez vérifier la date de la version utilisée dans le champ OS-IMAGE remontée par kubectl get node -o wide)

## 2.2. Évaluation du risque : Contexte Multi-tenant vs Environnement isolé.

L'urgence d'appliquer les correctifs dépend fortement de la typologie de vos usages et de l'architecture de vos services :

<u>**Environnement Multi-tenant / Partagé (Criticité Élevée) **</u><u>: </u>

Si vos machines ou vos clusters Kapsule hébergent des applications de différents clients, fournissent des accès shell à de multiples utilisateurs, ou exécutent du code tiers non vérifié, cette vulnérabilité est critique. Un attaquant disposant d'un accès limité (utilisateur standard ou accès dans un pod) peut exploiter cette faille pour prendre le contrôle total du serveur (accès root) et compromettre les données des autres locataires du système.

<u>**Environnement Single-tenant / Isolé (Criticité Modérée) : **</u>

Si vos serveurs ou clusters sont strictement dédiés à votre usage et n'exécutent que des applications de confiance dont vous maîtrisez le code (sans accès local ou exécution arbitraire possible par des tiers), le risque est nettement plus faible. La vulnérabilité nécessite en effet une exécution de code local préalable pour être exploitée.

## 2.3. Actions requises et Mitigation temporaire.

La solution pérenne consiste à mettre à jour le noyau de vos systèmes une fois qu'une version incluant le patch sera disponible, nous vous invitons à consulter régulièrement la disponibilité du patch concernant votre OS. 

<u>**Mesure d'atténuation (Workaround) :**</u>

Si un redémarrage ou une mise à jour immédiate n'est pas possible, vous pouvez appliquer une mitigation temporaire directement sur vos nœuds et serveurs affectés pour bloquer l'interface vulnérable. Exécutez les commandes suivantes avec des privilèges administrateur (root ou sudo) :

Créer une règle pour empêcher leur rechargement automatique :

```shell
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
```

Décharger le module vulnérable de la mémoire 

```shell
rmmod algif_aead 2>/dev/null || true
```

## 2.4. Pour les serveurs basés sur du RedHat / CentOS / Fedora / AlmaLinux / RockyLinux 

Créer une règle pour empêcher le chargement automatique du module au démarrage 

```shell
grubby --update-kernel=ALL --args=initcall_blacklist=algif_aead_init
```

## 2.5. Redémarrer le système pour appliquer la modification

Pour `Kubernetes Kapsule,` cette manipulation doit être effectuée sur les nœuds `workers`, par exemple via un accès `SSH` ou en déployant un `DaemonSet privilégié`:

```yaml
apiVersion: apps/v1

kind: DaemonSet

metadata:
  name: disable-algif-aead
  namespace: kube-system
  labels:
app: disable-algif-aead
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
```

## 2.6. Rollback : Commandes de réactivation.

La désactivation de `af_alg` n'a aucun impact pour la grande majorité des applications standards. Toutefois, si certains de vos services nécessitent spécifiquement l'accélération cryptographique fournie par ce sous-système (et que vous observez des dysfonctionnements), vous pouvez annuler cette mitigation à tout moment avec ces commandes :

<u>**Supprimer le fichier de blocage :**</u>

```shell
sudo rm /etc/modprobe.d/disable-algif.conf
```

<u>**Recharger manuellement le module dans le noyau :**</u>

```shell
sudo modprobe algif_aead
```

Nous restons à votre entière disposition pour tout complément d'information ou assistance technique via la console.  
L'équipe `Scaleway`.

# 3. Concernant les serveurs KAPTUS.

Ne sachant quel était l’impact pour les serveurs DEBIAN, j’ai posé la question à `Claude IA`.

## 3.1. Peux-tu me dire si ce problème de la CVE-2026-31431 "Copy Fail" affecte mes serveur DEBIAN 13 ?

### 3.1.1. CVE-2026-31431 "Copy Fail" — Impact sur tes serveurs Debian 13

**Oui, tes serveurs Debian 13 sont vulnérables.**

La faille affecte tous les noyaux Linux 4.14 jusqu'à 6.18.x antérieur à 6.18.22, introduite via un commit de 2017 dans `algif_aead.c`. Ton kernel Debian 13 (6.12.x) est donc dans la plage vulnérable. [Sysdig](https://www.sysdig.com/blog/cve-2026-31431-copy-fail-linux-kernel-flaw-lets-local-users-gain-root-in-seconds)

`Debian 13 Trixie` avec kernel `6.12.75` a été confirmé vulnérable. [GitHub](https://github.com/theori-io/copy-fail-CVE-2026-31431/issues/39)

#### 3.1.1.1. Évaluation du risque pour ton infra

La CVE nécessite une exécution de code locale en tant qu'utilisateur standard — elle ne peut pas être exploitée à distance seule. Mais chaînée avec un `RCE web`, un accès `SSH` ou un r`unner CI/CD`, elle donne root. [Help Net Security](https://www.helpnetsecurity.com/2026/04/30/copyfail-linux-lpe-vulnerability-cve-2026-31431/)

Ton infra est en **criticité modérée** — serveurs `single-tenant,` pas d'utilisateurs tiers, pas de code non maîtrisé. Mais tu as `Docker` sur certains serveurs — la faille peut aussi permettre une évasion de container car le page cache est partagé entre containers. [CCB Safeonweb](https://ccb.belgium.be/advisories/warning-copy-fail-getting-root-major-linux-distributions-patch-immediately)

#### 3.1.1.2. Patch Debian — pas encore disponible

Au 30 avril 2026, aucune distribution n'a encore publié de kernel patché. Le fix mainline a été committé le 1er avril 2026, mais les mises à jour vendor sont encore en attente. [CERT-EU](https://cert.europa.eu/publications/security-advisories/2026-005/)

#### 3.1.1.3. Mitigation immédiate

Applique le `workaround` sur tous tes serveurs :

```shell
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true
```

**⚠️ Point critique sur la mitigation** — sur certains systèmes, le module `algif_aead` est compilé directement dans le kernel (`CONFIG_CRYPTO_USER_API_AEAD=y`), donc `modprobe.d` ne peut pas bloquer son chargement et `rmmod` ne peut pas le retirer — les commandes s'exécutent sans erreur mais ne font rien, donnant un faux sentiment de protection. [CloudLinux](https://blog.cloudlinux.com/cve-2026-31431-copy-fail-mitigation-and-patches)

Vérifie si le module est chargeable ou compilé en dur :

```shell
# Si retourne un fichier -> module chargeable -> mitigation efficace
modinfo algif_aead 2>/dev/null | grep filename

# Si vide -> compilé dans le kernel -> mitigation insuffisante
# Vérifier
grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)
```

La mitigation n'affecte pas `dm-crypt/LUKS`, `kTLS`, `IPsec`, `OpenSSL`, `GnuTLS`, `NSS` ou `SSH`. [CERT-EU](https://cert.europa.eu/publications/security-advisories/2026-005/)

#### 3.1.1.4. Via Ansible sur tous tes serveurs.

```
- name: CVE-2026-31431 - Disable algif_aead module
  ansible.builtin.copy:
    dest: /etc/modprobe.d/disable-algif.conf
    content: "install algif_aead /bin/false\n"
    mode: '0644'

- name: CVE-2026-31431 - Unload algif_aead if loaded
  ansible.builtin.command: rmmod algif_aead
  ignore_errors: true
  changed_when: false
```

Surveille le tracker Debian pour le patch kernel : [https://security-tracker.debian.org/tracker/CVE-2026-31431](https://security-tracker.debian.org/tracker/CVE-2026-31431)

## 3.2. Peux ajouter dans le playbook Ansible un test pour voir si le module est chargeable et appliquer le workaround si c'est le cas et lever une alerte sinon ?

```yaml
- name: CVE-2026-31431 - Vérifier si algif_aead est un module chargeable
  ansible.builtin.command: modinfo algif_aead
  register: modinfo_result
  ignore_errors: true
  changed_when: false

- name: CVE-2026-31431 - Bloquer le module algif_aead (module chargeable)
  ansible.builtin.copy:
    dest: /etc/modprobe.d/disable-algif.conf
    content: "install algif_aead /bin/false\n"
    owner: root
    group: root
    mode: '0644'
  when: modinfo_result.rc == 0

- name: CVE-2026-31431 - Décharger algif_aead si chargé
  ansible.builtin.command: rmmod algif_aead
  ignore_errors: true
  changed_when: false
  when: modinfo_result.rc == 0

- name: CVE-2026-31431 - ALERTE module compilé en dur - mitigation insuffisante
  ansible.builtin.fail:
    msg: >
      ALERTE SECURITE CVE-2026-31431 sur {{ inventory_hostname }} :
      Le module algif_aead est compilé directement dans le kernel (CONFIG_CRYPTO_USER_API_AEAD=y).
      La mitigation via modprobe.d est INEFFICACE.
      Un patch kernel est obligatoire. Kernel actuel : {{ ansible_kernel }}.
  when: modinfo_result.rc != 0
```

Le `fail` stoppe le playbook et remonte l'erreur clairement dans la sortie Ansible avec le nom du serveur et la version du kernel. Si tu préfères une alerte sans stopper le playbook, remplace `ansible.builtin.fail` par `ansible.builtin.debug` avec `msg:` et `verbosity: 0`.

## 3.3. Oui je veux bien que le playbook continue sur l'ensemble des serveurs.

```yaml
- name: CVE-2026-31431 - Vérifier si algif_aead est un module chargeable
  ansible.builtin.command: modinfo algif_aead
  register: modinfo_result
  ignore_errors: true
  changed_when: false

- name: CVE-2026-31431 - Bloquer le module algif_aead (module chargeable)
  ansible.builtin.copy:
    dest: /etc/modprobe.d/disable-algif.conf
    content: "install algif_aead /bin/false\n"
    owner: root
    group: root
    mode: '0644'
  when: modinfo_result.rc == 0

- name: CVE-2026-31431 - Décharger algif_aead si chargé
  ansible.builtin.command: rmmod algif_aead
  ignore_errors: true
  changed_when: false
  when: modinfo_result.rc == 0

- name: CVE-2026-31431 - ALERTE module compilé en dur - mitigation insuffisante
  ansible.builtin.debug:
    msg: >
      *** ALERTE SECURITE CVE-2026-31431 sur {{ inventory_hostname }} ***
      Le module algif_aead est compilé directement dans le kernel.
      La mitigation via modprobe.d est INEFFICACE.
      Un patch kernel est obligatoire. Kernel actuel : {{ ansible_kernel }}.
  when: modinfo_result.rc != 0
```

Le playbook continue sur tous les serveurs — les serveurs vulnérables sans mitigation possible apparaîtront clairement dans la sortie avec `*** ALERTE SECURITE ***`. Tu pourras les identifier facilement à la fin du run :

```shell
ansible-playbook playbooks/cve_2026_31431.yml 2>&1 | grep -A4 "ALERTE SECURITE"
```

## 3.4. Que faire pour les serveurs qui sont en alerte ?

Pour les serveurs où le module est compilé en dur, la seule vraie solution est le **patch kernel**. Mais en attendant il y a des mitigations alternatives.

## 3.5. Actions par ordre de priorité.

### 3.5.1. Vérifier si le module est réellement actif.

```shell
# Sur les serveurs en alerte
grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)
# CONFIG_CRYPTO_USER_API_AEAD=y -> compilé en dur -> vulnérable
# CONFIG_CRYPTO_USER_API_AEAD=m -> module -> mitigation efficace
# not set -> pas compilé -> pas vulnérable
```

### 3.5.2. Mitigation alternative — blacklist via GRUB

Pour les serveurs `Debian` :

```shell
# Ajouter le paramètre kernel au démarrage
nano /etc/default/grub
```

```shell
GRUB_CMDLINE_LINUX="initcall_blacklist=algif_aead_init"
```

```shell
update-grub
reboot
```

Après reboot vérifier :

```shell
cat /proc/cmdline | grep algif_aead_init
```

### 3.5.3. Dans ton playbook Ansible.

```yaml
- name: CVE-2026-31431 - Mitigation GRUB pour module compilé en dur
  ansible.builtin.lineinfile:
    path: /etc/default/grub
    regexp: '^GRUB_CMDLINE_LINUX='
    line: 'GRUB_CMDLINE_LINUX="initcall_blacklist=algif_aead_init"'
    backrefs: yes
  when: modinfo_result.rc != 0
  notify: update grub

- name: CVE-2026-31431 - Mettre à jour GRUB
  ansible.builtin.command: update-grub
  when: modinfo_result.rc != 0
```

⚠️ **Cette mitigation nécessite un reboot** pour être effective.

### 3.5.4. Solution définitive — patch kernel

Surveiller et appliquer dès disponibilité :

```shell
apt update && apt list --upgradable | grep linux-image
apt upgrade linux-image-amd64
reboot
```

Quels serveurs sont remontés en alerte ?

## 3.6. Bon je vais lancer d'abord le premier playbook pour voir les serveurs qui sont en alerte. Et en fonction du résultat je reviens vers toi.

Parfait. Lance :

```shell
ansible-playbook playbooks/cve_2026_31431.yml 2>&1 | tee /tmp/cve_2026_31431.log
```

Le `tee` garde une trace dans un fichier. Pour voir rapidement les serveurs en alerte à la fin :

```shell
grep -A2 "ALERTE SECURITE" /tmp/cve_2026_31431.log
```

Je suis là quand tu as les résultats.

# 4. Application du playbook Ansible.

A l’arrivée mon plyabook final : 

```yaml
---
## Playbook to mitigate CVE-2026-31431
##
######################################
## Check if hosts is reachable
- name: Include a play after another play
  import_playbook: hosts_reachable.yml

- name: CVE-2026-31431 mitigation
  hosts: reachable
  become: true
  tasks:
    - name: CVE-2026-31431 - Vérifier si algif_aead est un module chargeable
      ansible.builtin.command: modinfo algif_aead
      register: modinfo_result
      ignore_errors: true
      changed_when: false

    - name: CVE-2026-31431 - Bloquer le module algif_aead (module chargeable)
      ansible.builtin.copy:
        dest: /etc/modprobe.d/disable-algif.conf
        content: "install algif_aead /bin/false\n"
        owner: root
        group: root
        mode: '0644'
      when: modinfo_result.rc == 0

    - name: CVE-2026-31431 - Décharger algif_aead si chargé
      ansible.builtin.command: rmmod algif_aead
      ignore_errors: true
      changed_when: false
      when: modinfo_result.rc == 0

    - name: CVE-2026-31431 - ALERTE module compilé en dur - mitigation insuffisante
      ansible.builtin.debug:
        msg: >
          *** ALERTE SECURITE CVE-2026-31431 sur {{ inventory_hostname }} ***
          Le module algif_aead est compilé directement dans le kernel.
          La mitigation via modprobe.d est INEFFICACE.
          Un patch kernel est obligatoire. Kernel actuel : {{ ansible_kernel }}.
      when: modinfo_result.rc != 0
```

Lancement du playbook : 

```shell
export ANSIBLE_CONFIG=/etc/ansible/ansible.cfg ; time /usr/bin/ansible-playbook -i /etc/ansible/hosts /etc/ansible/playbooks/cve_2026_31431.yml -e 'ansible_python_interpreter=/usr/bin/python3' -l 'kaptus_servers' 2>&1 | tee /tmp/cve_2026_31431.log
```

L’analyse de Claude IA sur le fichier de résultat `/tmp/cve_2026_31431.log `:

Excellent résultat — **tous tes serveurs sont protégés**. La tâche d'alerte est `skippée` sur l'ensemble du parc ce qui signifie que le module `algif_aead` est chargeable (pas compilé en dur) sur tous les serveurs et que la mitigation via `modprobe.d` est efficace partout.

<u>**Résumé**</u>

- **25 serveurs mitigés** ✅
- **0 serveur en alerte** ✅
- **Prochaine étape** — appliquer le patch kernel dès qu'il sera disponible dans les dépôts Debian 13

bash

```shell
# Surveiller la disponibilité du patch
apt update && apt list --upgradable 2>/dev/null | grep linux-image
```

Et penser à retirer le fichier `disable-algif.conf` après avoir appliqué le patch kernel patché. 

# 5. Conclusion.

L'utilisation de `Claude IA `m'a permis de corriger (**temporairement**) cette faille critique en **moins de 2h**. Ce gain de productivité et de réactivité en utilisant l'IA illustre concrètement un changement de paradigme dans la gestion des incidents sécurité.

Traditionnellement, la réponse à une **CVE** critique suit un processus séquentiel long : 

- veille sécurité,
- lecture des advisories,
- analyse d'impact sur son parc,
- recherche de mitigations,
- écriture et test des procédures,
- déploiement.

Ce cycle, même bien rodé, **se compte en heures voire en jours pour une équipe réduite gérant une infrastructure hétérogène.**

L’apport de l'IA compresse radicalement ce cycle. En quelques échanges contextualisés, j'ai pu qualifier précisément l'impact de cette faille critique sur l'ensemble de l'**infrastructure KAPTUS **(une infrastructure multi-serveurs sous Debian 13), hébergeant à la fois les services internes de la société et les applications clientes. J'ai pu identifier les limites de la mitigation officielle selon la configuration kernel de chaque serveur, et générer un playbook Ansible de remédiation incluant une détection automatique des cas non couverts, **dans un délai extrémement court**.

L'enjeu ici dépasse le simple confort opérationnel. Une infrastructure qui héberge des données et des applications clientes engage la responsabilité de son exploitant. La rapidité de réponse face à une CVE critique n'est pas qu'une question technique, c'est une obligation vis-à-vis des clients hébergés et une composante directe de la posture de sécurité globale de KAPTUS.

Ce qui change fondamentalement, ce n'est pas la technique, c'est la **vitesse de décision**. Dans un contexte où **un code d'exploitation fonctionnel **est disponible publiquement quelques heures après la divulgation d'une faille, réduire le temps de réponse de plusieurs jours à quelques heures n'est plus un avantage, **ça devient une nécessité.** Pour les équipes réduites, qui ne disposent pas d'un **SOC** dédié, l'IA comble l'écart entre la vitesse des menaces et leur capacité de réponse.