Dirty Frag (CVE-2026-43284 et CVE-2026-43500) : ce que ces nouvelles vulnérabilités du noyau Linux signifient et comment réagir

Le 7 mai 2026, le chercheur en sécurité Hyunwoo Kim a publiquement divulgué une famille de vulnérabilités du noyau Linux nommée collectivement Dirty Frag. La divulgation est arrivée sur la liste de diffusion oss-security après que l'embargo de divulgation responsable a été rompu par un tiers non lié publiant un exploit fonctionnel. Le résultat est que toutes les distributions Linux majeures expédiées aujourd'hui, incluant Ubuntu, Red Hat Enterprise Linux, CentOS Stream, AlmaLinux, Rocky Linux, Fedora, Debian, openSUSE et CloudLinux, contiennent du code qui permet à tout utilisateur local d'obtenir root en une seule commande. Un exploit fonctionnel public existe. CISA n'a pas encore listé Dirty Frag dans le catalogue des vulnérabilités exploitées connues au moment d'écrire ces lignes, mais étant donné l'exploit public et la couverture universelle, ce listage est probablement imminent.

Si vous êtes client d'un serveur géré chez Gotekky, votre serveur a été atténué. Le reste de ce guide explique ce qu'est Dirty Frag, pourquoi c'est structurellement un problème différent de Copy Fail (CVE-2026-31431) même si elle produit le même résultat, ce que nous avons fait sur les serveurs gérés et ce que vous devriez faire si vous exploitez des serveurs Linux auto-gérés, particulièrement les nœuds cPanel et Webuzo sur AlmaLinux ou CloudLinux.

Ce qu'est réellement Dirty Frag

Dirty Frag n'est pas un seul bogue. C'est une chaîne de deux bogues du noyau Linux liés dans la pile réseau qui partagent le même schéma d'exploitation : un utilisateur non privilégié peut écrire des octets contrôlés par l'attaquant dans le cache de pages du noyau, puis utiliser cette primitive pour écraser une petite région d'une copie en mémoire d'un binaire privilégié comme su ou sudo, puis déclencher ce binaire pour obtenir root. C'est la même stratégie d'exploitation que Copy Fail, mais les points d'entrée sont des chemins de code complètement différents.

Les deux bogues sont suivis sous des identifiants CVE distincts :

• CVE-2026-43284 est la moitié IPsec ESP. Elle réside dans le code de déchiffrement en place des modules esp4 et esp6 (Encapsulating Security Payload pour IPv4 et IPv6) et a été introduite par un commit du noyau en janvier 2017. Par coïncidence, le même commit de janvier 2017 a aussi été la cause racine de CVE-2022-27666, une vulnérabilité de débordement de tampon distincte divulguée il y a des années.
• CVE-2026-43500 est la moitié rxrpc. Elle réside dans le module rxrpc du noyau (appels de procédure à distance Andrew File System) et a été introduite par un commit du noyau en juin 2023.

Les deux bogues sont distincts mais le chercheur les a publiés ensemble car ils couvrent leurs lacunes mutuelles. La variante IPsec ESP nécessite que l'attaquant puisse créer des espaces de noms utilisateur non privilégiés. Ubuntu bloque la création d'espaces de noms utilisateur non privilégiés par défaut via une politique AppArmor, donc la variante ESP échoue sur Ubuntu standard. La variante rxrpc n'a pas besoin d'espaces de noms, donc elle fonctionne sur Ubuntu, mais le module noyau rxrpc n'est pas chargé par défaut sur la plupart des distributions, donc elle échoue sur RHEL et AlmaLinux standard. La combinaison garantit une couverture universelle : quelle que soit la variante qui échoue sur votre distribution, l'autre réussit.

Pourquoi ceci est structurellement différent de Copy Fail

Copy Fail (CVE-2026-31431) réside dans le module algif_aead de l'API cryptographique de l'espace utilisateur du noyau. L'atténuation que tout le monde a déployée la semaine dernière est une liste noire modprobe de ce seul module, qui n'a essentiellement aucun impact opérationnel car aucune charge de travail d'hébergement de production n'utilise algif_aead.

Dirty Frag réside dans IPsec ESP et rxrpc. L'atténuation est plus perturbatrice de deux manières spécifiques. Premièrement, mettre esp4 et esp6 sur liste noire casse les VPN IPsec. Si l'un de vos clients exécute des connexions VPN IPsec depuis ou vers le serveur, ces connexions cesseront de fonctionner. Deuxièmement, mettre rxrpc sur liste noire casse les montages Andrew File System, ce que pratiquement personne n'utilise, mais vérifiez avant d'appliquer. Les recommandations AWS pour Amazon Linux étendent la liste noire recommandée pour inclure aussi ipcomp4 et ipcomp6 (compression de charge utile IP pour IPv4 et IPv6), qui partagent la même classe de code vulnérable.

La différence pratique la plus importante : l'atténuation algif_aead qui protégeait contre Copy Fail ne protège pas contre Dirty Frag. Ce sont des chemins de code distincts. Un serveur qui n'a que l'atténuation Copy Fail appliquée est encore vulnérable à Dirty Frag et tombera face à l'exploit public. Les deux atténuations sont nécessaires simultanément jusqu'à ce que les correctifs du noyau soient installés sur la flotte.

État des correctifs par distribution au 8 mai 2026

Le paysage des correctifs évolue rapidement car plusieurs distributions ont commencé à reconstruire les noyaux dès l'arrivée de la divulgation. L'état actuel :

• AlmaLinux : les noyaux corrigés sont dans les dépôts de production depuis le 8 mai 15h22 UTC. AlmaLinux 8 est affectée seulement par CVE-2026-43284 car rxrpc n'est pas livré. AlmaLinux 9 et 10 sont affectées par CVE-2026-43500 seulement si kernel-modules-partner du dépôt Devel est installé. AlmaLinux 7 est en fin de vie et ne recevra pas de correctif.
• CloudLinux : les livepatches KernelCare et les noyaux corrigés sont en construction et test active depuis le 7 mai. KernelCare livre les correctifs sans redémarrage, ce qui est le chemin le plus propre pour les nœuds CL7, CL8 et CL9.
• Red Hat Enterprise Linux : a classifié Dirty Frag comme sévérité Important et accélère les correctifs sur les versions RHEL prises en charge. Le statut se déploie sur l'arborescence prise en charge.
• Ubuntu, Debian, Fedora, openSUSE : les équipes de sécurité des distributions ont reconnu le problème et les correctifs sont en cours. Le flux d'avis de sécurité de chaque distribution les publiera au fur et à mesure de leur sortie.
• Amazon Linux : travaille à confirmer la gamme complète des versions affectées. Le bulletin d'Amazon recommande la liste noire des modules (étendue pour inclure ipcomp4/ipcomp6) plus la désactivation des espaces de noms utilisateur non privilégiés comme mesures intermédiaires.

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

Pour notre flotte cPanel et Webuzo fonctionnant sur AlmaLinux et CloudLinux, nous déployons les atténuations dans les heures qui suivent la publication de ce guide. Le déploiement est structuré par distribution car le bon chemin diffère :

• Nœuds CloudLinux avec KernelCare : reçoivent le livepatch automatiquement via kcarectl. Aucun redémarrage requis, aucune liste noire de modules nécessaire une fois le correctif appliqué. KernelCare vérifie les CVE comme corrigés dans la sortie de kcarectl --patch-info.
• Nœuds AlmaLinux 8, 9, 10 : mise à jour du noyau via dnf upgrade, puis redémarrage pendant la prochaine fenêtre de maintenance. AlmaLinux a publié le noyau corrigé kernel-6.12.0-124.55.3.el10_1 le 8 mai avec l'équivalent pour 8.x et 9.x.
• Tout nœud où un redémarrage le jour même n'est pas réalisable : liste noire modprobe intermédiaire de esp4, esp6, ipcomp4, ipcomp6 et rxrpc, plus la liste noire algif_aead existante pour Copy Fail. L'atténuation intermédiaire ne nécessite pas de redémarrage et est retirée une fois le noyau corrigé installé.
• Nœuds AlmaLinux 7 : AlmaLinux 7 est en fin de vie et ne recevra pas de correctif. Nous appliquons la liste noire des modules plus le sysctl user.max_user_namespaces=0 comme mesure de défense en profondeur sur ces nœuds, et nous accélérons la migration d'AlmaLinux 7 vers AlmaLinux 9 comme projet distinct.

Pour les clients sur des plans gérés par Gotekky, aucune action n'est requise. Nous avons communiqué le calendrier d'atténuation via nos canaux de support habituels et nous mettrons à jour ce guide à mesure que le déploiement du noyau corrigé se termine sur la flotte.

Si vous exploitez des serveurs AlmaLinux ou CloudLinux auto-gérés, faites ceci aujourd'hui

Le chemin d'atténuation dépend de la distribution que vous exécutez et si vous avez KernelCare. Choisissez la ligne qui correspond à votre flotte.

CloudLinux 7, 8, 9 avec KernelCare

C'est le chemin le plus propre. D'après le blog CloudLinux, les livepatches KernelCare pour les deux CVE sont en construction et test active. Exécutez :

kcarectl --update
kcarectl --patch-info | grep -E "CVE-2026-43284|CVE-2026-43500"

Si les deux CVE apparaissent comme corrigés, vous avez terminé. Aucune liste noire de modules nécessaire, aucun redémarrage requis. KernelCare livre le correctif en place une fois que CloudLinux le publie. Si vous n'avez pas KernelCare sur ces nœuds, suivez le chemin AlmaLinux ci-dessous.

AlmaLinux 8, 9, 10

Les noyaux corrigés sont dans les dépôts de production depuis le 8 mai 15h22 UTC. Mettez à jour et redémarrez :

sudo dnf clean metadata
sudo dnf upgrade kernel
sudo reboot

Après redémarrage, vérifiez avec uname -r. La version du noyau corrigé sur AL10 est kernel-6.12.0-124.55.3.el10_1 avec des équivalents sur 8.x et 9.x. Vérifiez le blog AlmaLinux pour la version cible exacte de votre flux. AlmaLinux 9 et 10 sont affectées par CVE-2026-43500 seulement si kernel-modules-partner du dépôt Devel est installé. Vérifiez avec rpm -qa | grep kernel-modules-partner. Si oui, assurez-vous qu'il est mis à jour avec le noyau.

AlmaLinux 7

Fin de vie. Aucun correctif à venir. Appliquez la liste noire des modules ci-dessous comme mesure provisoire et migrez d'AlmaLinux 7 comme projet prioritaire. CloudLinux 7 avec KernelCare est une alternative intermédiaire viable si la migration prend plus de quelques semaines.

Liste noire intermédiaire pour tout nœud que vous ne pouvez pas redémarrer aujourd'hui

Cela fonctionne sur toutes les distributions prises en charge. En tant que root :

cat > /etc/modprobe.d/dirtyfrag.conf <<'EOF'
install esp4 /bin/false
install esp6 /bin/false
install ipcomp4 /bin/false
install ipcomp6 /bin/false
install rxrpc /bin/false

# Vider le cache de pages
sync
echo 3 > /proc/sys/vm/drop_caches
EOF

# Vérifiez si l'un d'entre eux est actuellement chargé
lsmod | grep -E "esp4|esp6|ipcomp4|ipcomp6|rxrpc"

# Déchargez-les si oui
rmmod esp4 esp6 ipcomp4 ipcomp6 rxrpc 2>/dev/null

# Vérifiez qu'ils ne peuvent pas être chargés
modprobe esp4 && echo "ENCORE CHARGEABLE" || echo "BLOQUE"

La sortie de la vérification finale devrait être BLOQUE. Important : cette liste noire casse les connexions VPN IPsec (esp4 et esp6 transportent les charges utiles chiffrées IPsec). Si un client ou un service sur le serveur utilise un VPN IPsec, planifiez en conséquence. La liste noire casse aussi les montages Andrew File System (rxrpc), ce qui est rarement un problème sur les charges de travail d'hébergement. Les entrées ipcomp4 et ipcomp6 sont l'ajout recommandé d'AWS pour traiter la même classe de code de manière proactive.

Défense en profondeur optionnelle : désactiver les espaces de noms utilisateur non privilégiés

Cela bloque entièrement la variante IPsec ESP (CVE-2026-43284) mais laisse la variante rxrpc exploitable sur les systèmes où rxrpc est chargé. Utile comme couche de durcissement par-dessus la liste noire des modules :

echo "user.max_user_namespaces=0" > /etc/sysctl.d/dirtyfrag.conf
sysctl --system

Cela casse les conteneurs sans root (Podman sans root, navigateurs sandboxés, Flatpak). Sur un hôte cPanel ou Webuzo dédié, aucun de ceux-ci ne devrait être en usage, donc l'impact pratique est nul. Sur les nœuds AlmaLinux 7 qui ne reçoivent pas de correctif du noyau, son application est recommandée.

Vérifier que vous êtes protégé

Après avoir appliqué les atténuations, deux vérifications confirment l'état du système :

cat > /root/check-dirtyfrag-protection.sh <<'EOF'
#!/usr/bin/env bash

RED="\033[31m"
GREEN="\033[32m"
BLUE="\033[34m"
BOLD="\033[1m"
RESET="\033[0m"

PASS_COUNT=0
WARN_COUNT=0

pass() {
  echo -e "${GREEN}OK${RESET} : $1"
  PASS_COUNT=$((PASS_COUNT + 1))
}

warn() {
  echo -e "${RED}ATTENTION${RESET} : $1"
  WARN_COUNT=$((WARN_COUNT + 1))
}

info() {
  echo -e "${BLUE}$1${RESET}"
}

check_module() {
  local mod="$1"

  echo
  info "Vérification du module noyau : $mod"

  if modprobe -n -v "$mod" 2>/dev/null | grep -qE '^install /bin/false|^install /bin/true'; then
    pass "$mod est bloqué par une règle modprobe."
  elif modprobe "$mod" >/dev/null 2>&1; then
    warn "$mod semble pouvoir être chargé. La mitigation doit être vérifiée."
  else
    pass "$mod ne peut pas être chargé."
  fi
}

clear
echo -e "${BOLD}Vérification de la protection Dirty Frag${RESET}"
echo "========================================"

check_module esp4
check_module rxrpc

echo
info "Vérification des namespaces utilisateur non privilégiés"

NS_VALUE="$(sysctl -n user.max_user_namespaces 2>/dev/null || echo inconnu)"

if [ "$NS_VALUE" = "0" ]; then
  pass "user.max_user_namespaces est défini à 0."
else
  warn "user.max_user_namespaces est défini à $NS_VALUE, pas à 0."
fi

echo
echo -e "${BOLD}Résumé${RESET}"
echo "------"

if [ "$WARN_COUNT" -eq 0 ]; then
  echo -e "${GREEN}Protégé : toutes les vérifications sont réussies.${RESET}"
else
  echo -e "${RED}Vérification requise : $WARN_COUNT avertissement(s) trouvé(s).${RESET}"
fi

echo
echo "Vérifications réussies : $PASS_COUNT"
echo "Avertissements : $WARN_COUNT"

echo
echo -e "${BOLD}Détails techniques pour administrateurs${RESET}"
modprobe -c | egrep '^(install|blacklist) (esp4|rxrpc)' || echo "Aucune règle modprobe esp4/rxrpc trouvée."
EOF

chmod +x /root/check-dirtyfrag-protection.sh
/root/check-dirtyfrag-protection.sh

Si le serveur a été redémarré sur un noyau corrigé, la liste noire des modules n'est plus requise (bien que la laisser en place soit sans danger). Vérifiez la version du noyau en cours d'exécution par rapport au numéro de version corrigé publié par votre distribution. Pour AlmaLinux 10 c'est kernel-6.12.0-124.55.3.el10_1 ou ultérieur.

Conseils spécifiques pour les serveurs cPanel et Webuzo

Les serveurs cPanel et Webuzo sont structurellement exposés à Dirty Frag de la même manière qu'ils étaient exposés à Copy Fail : tout utilisateur cPanel ou Webuzo avec accès shell, ou toute exploitation PHP réussie contre tout site hébergé, devient un candidat pour prendre le contrôle de tout le serveur. La combinaison avec CVE-2026-41940 (le contournement d'authentification cPanel divulgué le 28 avril) est particulièrement dangereuse car le bogue cPanel accorde WHM root à distance sans identifiants, et Dirty Frag transforme cela en root sur l'hôte Linux en quelques secondes. Un serveur qui a été corrigé contre CVE-2026-41940 mais pas contre Dirty Frag n'est pas en sécurité.

L'ordre recommandé pour les opérateurs cPanel et Webuzo :

1. Appliquez le correctif cPanel et WHM pour CVE-2026-41940 si ce n'est pas déjà fait. Exécutez /scripts/upcp --force en tant que root et vérifiez que le numéro de version correspond à la version corrigée publiée dans l'avis cPanel.
2. Appliquez l'atténuation Dirty Frag appropriée à votre distribution : livepatch KernelCare sur CloudLinux avec abonnement, dnf upgrade kernel + redémarrage sur AlmaLinux 8/9/10, liste noire des modules sur AlmaLinux 7 ou tout nœud où le redémarrage n'est pas réalisable aujourd'hui.
3. Vérifiez que l'atténuation Copy Fail existante (liste noire algif_aead) est encore en place. Les deux atténuations sont nécessaires simultanément jusqu'à ce que les correctifs du noyau soient installés.
4. Auditez les comptes utilisateurs cPanel et Webuzo et les comptes avec accès shell pour des entrées inconnues. La fenêtre d'exposition CVE-2026-41940 s'étendait de fin février au 28 avril, donc tout compte inconnu créé dans cette fenêtre devrait être traité comme suspect.

Le tableau d'ensemble que cela représente

Dirty Frag est la deuxième escalade universelle de privilèges du noyau Linux en neuf jours. Copy Fail et Dirty Frag ne sont pas le même bogue, mais ce sont la même classe de bogue : déterministe, aucune condition de course requise, aucun panic du noyau en cas d'échec, taux de réussite très élevé, exploitation en une seule commande. Le chercheur Hyunwoo Kim a maintenant publié deux de ces bogues en succession rapide, trouvés grâce à une combinaison d'analyse de code automatisée et d'analyse humaine ciblée. Il y en aura d'autres.

La leçon structurelle pour l'infrastructure d'hébergement n'a pas changé depuis la semaine dernière, mais elle a été renforcée : la multi-location à noyau partagé est le risque sous-jacent et la cadence des correctifs seule n'est pas une défense suffisante quand la découverte de bogues est maintenant aussi rapide. La défense en profondeur à travers le durcissement du noyau, l'application rapide des correctifs, la surveillance, l'isolation entre comptes clients, l'accès shell restreint et les limites de ressources et d'espaces de noms par compte est maintenant la base opérationnelle. Nous continuons à investir dans le travail de surveillance et d'isolation sur l'infrastructure gérée à la suite de cette série de divulgations et nous publierons davantage sur ce travail à mesure qu'il sera mis en ligne.

Références pour les opérateurs auto-gérés

Les sources principales pour ce guide et pour le suivi continu sont le billet de blog AlmaLinux sur Dirty Frag, le billet de blog CloudLinux couvrant KernelCare et les noyaux corrigés, l'avis du portail client Red Hat RHSB-2026-003, le bulletin de sécurité AWS étendant la liste des modules affectés pour inclure ipcomp4 et ipcomp6, le fil de divulgation de la liste de diffusion oss-security du 7 mai par Hyunwoo Kim et la preuve de concept publique sur GitHub. Chacune de ces sources est mise à jour en place à mesure que les correctifs sont déployés, donc consultez-les plutôt que de vous fier à ce guide pour les derniers numéros de version corrigés du noyau.