CVE-2026-31431 « Copy Fail » : ce que cette vulnérabilité du noyau Linux signifie et comment réagir

Le 29 avril 2026, une vulnérabilité du noyau Linux appelée Copy Fail (CVE-2026-31431) a été publiquement divulguée. C'est une faille logique dans l'API cryptographique du noyau qui permet à tout utilisateur local, y compris tout compte à faibles privilèges sur un serveur d'hébergement partagé, d'escalader vers root en quelques secondes. Le bogue existe silencieusement dans toutes les distributions Linux majeures depuis 2017. Un exploit fonctionnel est disponible publiquement, tient en 732 octets de Python et fonctionne sans modification sur Ubuntu, AlmaLinux, Rocky, Debian et la plupart des images Linux des fournisseurs cloud.

Si vous êtes client d'un serveur géré chez Gotekky, cette vulnérabilité a été atténuée centralement sur votre serveur. Vous n'avez aucune action à prendre. Le reste de ce guide explique ce qu'est le bogue, pourquoi il est important, ce que nous avons fait à ce sujet et ce que vous devriez faire si vous exploitez aussi des serveurs Linux auto-gérés ailleurs.

Ce qu'est réellement Copy Fail, en termes simples

Le noyau Linux a une fonctionnalité appelée API cryptographique de l'espace utilisateur qui permet aux programmes ordinaires de demander au noyau d'effectuer des opérations cryptographiques en leur nom. Elle est utilisée par certains logiciels VPN, certains outils IPsec et quelques autres applications de niche. Une optimisation de 2017 d'un coin spécifique de cette API, la partie qui gère un wrapper appelé authencesn, a accidentellement introduit une faille : quand une opération cryptographique contrôlée par l'utilisateur échoue d'une manière particulière, le noyau écrit 4 octets contrôlés par l'attaquant dans la copie en mémoire de tout fichier que l'attaquant peut lire.

Cela semble limité. Ce ne l'est pas. Le noyau Linux garde les fichiers récemment utilisés en mémoire pour la performance, y compris le code exécutable de programmes comme sudo et su. En écrivant 4 octets soigneusement choisis dans la copie en mémoire d'un binaire privilégié comme /usr/bin/su, un attaquant remplace temporairement un petit morceau de son code. La prochaine fois que quelqu'un exécute su, la version modifiée s'exécute et accorde root à l'attaquant. Le fichier sur disque n'est jamais modifié, donc les moniteurs d'intégrité de fichiers comme AIDE et Tripwire ne voient rien d'anormal. Un redémarrage annule le changement car la mémoire est effacée.

Le bogue a été découvert par la firme de sécurité offensive Theori en utilisant un scanneur de code assisté par IA. L'analyse aurait pris environ une heure. Ce détail importe : ce type de découverte de vulnérabilité devient plus rapide et moins coûteux, ce qui signifie que davantage de bogues de cette classe surfaceront dans les mois et années à venir.

Qui est réellement exposé

Copy Fail est une vulnérabilité locale uniquement. Elle ne peut pas être exploitée par le réseau seule. Pour l'utiliser, un attaquant doit déjà pouvoir exécuter du code sur votre serveur en tant qu'utilisateur quelconque. Cela semble être un seuil élevé mais ce ne l'est pas, car il existe de nombreuses façons d'arriver à cette position :

• Vous exploitez un hébergement partagé et un client payant veut escalader vers root
• L'un des sites de vos clients a été compromis via un plugin vulnérable et l'attaquant a une exécution de code PHP sous l'utilisateur de ce client
• Vous exploitez un VPS où plusieurs développeurs ont accès au shell et l'ordinateur portable d'un développeur est compromis
• Vous exploitez un système CI/CD qui exécute du code de pull request de contributeurs
• Vous exploitez des nœuds Kubernetes qui partagent un noyau entre les conteneurs

Pour les clients d'hébergement canadiens exploitant un seul site web de petite entreprise sur un VPS géré ou un plan d'hébergement partagé, où vous êtes le seul utilisateur du serveur, le profil de risque est beaucoup plus faible. Il n'y a pas de chemin réaliste pour qu'un attaquant atteigne l'étape d'exécution locale sur un serveur géré, durci et surveillé à locataire unique. Le risque est concentré dans les environnements partagés et tout système où du code non fiable s'exécute déjà.

Ce que Gotekky a fait à ce sujet sur les serveurs gérés

Dans les heures suivant la divulgation, nous avons déployé l'atténuation de module noyau recommandée sur chaque serveur géré dans notre infrastructure de Toronto. Le correctif consiste à désactiver le module noyau algif_aead, qui est le point d'entrée dont l'exploit a besoin et qu'aucune charge de travail d'hébergement de production ne nécessite. L'atténuation est persistante au redémarrage, n'a aucun impact mesurable sur les performances et ne casse aucune application que nous ayons jamais vue sur un serveur d'hébergement. Une fois que les correctifs de noyau fournis par les distributions arrivent (Ubuntu en a déjà publié certains, AlmaLinux et Debian sont en cours de déploiement, d'autres sont imminents), nous les appliquerons pendant les fenêtres de maintenance habituelles et l'atténuation par module devient redondante mais sans danger.

Les clients sur des plans gérés par Gotekky n'ont rien à faire. Nous avons déjà vérifié l'atténuation sur chaque serveur que nous gérons. Si vous voulez confirmer sur votre propre serveur, notre équipe de support peut vous guider à travers les étapes de vérification.

Si vous exploitez aussi des serveurs Linux auto-gérés, faites ceci aujourd'hui

Le correctif intermédiaire est simple et fonctionne sur toutes les distributions Linux modernes. En tant que root, exécutez :

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

Cela met le module vulnérable sur liste noire de façon persistante. Pour vérifier qu'il ne peut pas être chargé :

modprobe algif_aead && echo "ENCORE CHARGEABLE" || echo "BLOQUE"

La sortie devrait être BLOQUE. Presque aucune charge de travail réelle n'utilise algif_aead. Le chiffrement de disque (LUKS, dm-crypt), TLS (kTLS, OpenSSL, GnuTLS), SSH, IPsec et la mise en réseau Kubernetes ne sont pas affectés. Les seules applications qui pourraient être affectées sont certains logiciels explicitement liés au moteur afalg d'OpenSSL, ce qui est rare. Vous pouvez auditer l'utilisation existante des sockets AF_ALG avec lsof | grep AF_ALG avant d'appliquer le changement si vous voulez être prudent.

Après avoir appliqué le contournement, surveillez le flux d'avis de sécurité de votre distribution et appliquez la mise à jour du noyau quand elle sera publiée. Les outils de suivi pertinents sont les Ubuntu Security Notices, la page de suivi de sécurité Debian pour CVE-2026-31431, la base de données CVE du portail client Red Hat et le canal de mise à jour standard de votre distribution. Une fois que vous avez un noyau corrigé installé et le système redémarré, la liste noire modprobe devient optionnelle, bien que la laisser en place soit sans danger.

Ce que cela signifie spécifiquement pour l'hébergement partagé et les serveurs multi-locataires

Si vous exploitez un serveur cPanel, Webuzo, Plesk ou DirectAdmin avec plusieurs comptes clients, Copy Fail est véritablement de haute priorité. Le modèle de menace est exact : n'importe lequel de vos clients, ou n'importe quelle exploitation PHP réussie contre n'importe lequel de leurs sites, devient un candidat pour prendre le contrôle de tout le serveur. Appliquez la liste noire modprobe maintenant. N'attendez pas le correctif du noyau. Le déploiement de la liste noire prend 30 secondes et un redémarrage n'est pas requis pour qu'elle prenne effet.

Appliquez la même logique à tout exécuteur CI/CD, tout nœud Kubernetes, tout serveur shell de développeur et tout hôte de conteneurs où du code non fiable ou semi-fiable s'exécute. AWS Lambda, Fargate et Cloudflare Workers ne sont pas affectés car ils s'exécutent sur des microVMs par locataire ou des isolats plutôt que sur un noyau partagé. Les VMs EC2, GCE et Azure standard exécutant Linux sont affectées.

Mise à jour : Dirty Frag est le problème de deuxième étape

Une semaine après Copy Fail, le chercheur en sécurité Hyunwoo Kim a divulgué une famille de vulnérabilités liée nommée collectivement Dirty Frag (CVE-2026-43284 dans le sous-système IPsec ESP et CVE-2026-43500 dans le module rxrpc). Dirty Frag affecte toutes les distributions Linux majeures, incluant Ubuntu, Red Hat Enterprise Linux, AlmaLinux, Rocky, Fedora, Debian et openSUSE. Elle produit le même résultat que Copy Fail (escalade de privilèges immédiate vers root) mais via un chemin de code différent et, élément critique, l'atténuation du module algif_aead qui protège contre Copy Fail ne protège pas contre Dirty Frag. Ce sont deux problèmes distincts qui nécessitent des correctifs distincts.

Gotekky a publié un guide dédié à Dirty Frag couvrant la couverture complète des distributions, les étapes d'atténuation pour les deux CVE, les interactions avec les charges de travail IPsec VPN et AFS (que l'atténuation de Dirty Frag peut affecter) et les versions corrigées du noyau au fur et à mesure de leur publication. Si vous avez appliqué l'atténuation Copy Fail de ce guide, cette protection reste valide, mais elle ne couvre pas Dirty Frag. Lisez le guide Dirty Frag comme étape suivante immédiate.

Le tableau d'ensemble

Copy Fail n'est pas isolée. Elle a coïncidé cette semaine avec CVE-2026-41940, un contournement d'authentification critique dans cPanel et WHM activement exploité dans la nature depuis fin février. Ensemble, les deux vulnérabilités forment une chaîne complète : un attaquant peut prendre le contrôle d'un serveur cPanel à distance sans identifiants, accéder à un shell non privilégié et escalader immédiatement vers root sur l'hôte en utilisant Copy Fail. Si vous n'avez pas encore corrigé cPanel également, c'est le plus urgent des deux problèmes. Nous avons publié un guide séparé sur CVE-2026-41940 couvrant le côté cPanel.

La leçon à retenir de cette semaine est que le schéma standard de multi-location à noyau partagé plus un seul démon de contrôle exposé à internet est activement sondé par les chercheurs et les attaquants, et que la cadence de correctifs pour les serveurs auto-gérés ne suffit plus à elle seule. La défense en profondeur (durcissement du noyau, application rapide des correctifs, surveillance, isolation entre comptes clients, accès shell restreint) compte maintenant d'une manière qui n'était pas le cas il y a cinq ans. Si vous exploitez une infrastructure que vous n'avez pas sérieusement examinée du point de vue sécurité depuis un certain temps, cette semaine est un bon moment pour commencer.