Deux failles, deux propriétaires
PwnEscape porte l'identifiant CVE-2026-99999. Le défaut se trouve dans la pile réseau IPv4 du noyau, dans la fonction skb_checksum_help, et il est atteint par le trafic qu'une machine virtuelle envoie par virtio-net. Le score CVSS 3.1 est de 9.3, avec un vecteur local (AV:L). Paulos Yibelo (Pwn.ai) l'a découvert pendant le concours Vercel Sandbox et a démontré une évasion en laboratoire sur KVM et Firecracker. Le noyau exposé est celui de l'hôte de virtualisation, pas celui de votre VPS.
Vghost porte l'identifiant CVE-2026-74580. Il touche le sous-système vhost : un cache de métadonnées des files virtio (les vrings) n'est pas vidé quand leur configuration change, ce qui contourne une validation de plages. Un utilisateur local qui peut ouvrir /dev/vhost-net ou /dev/vhost-vsock peut obtenir les droits root. Une preuve de concept est publique. Pour l'une comme pour l'autre, aucune exploitation dans la nature n'était rapportée à la rédaction de ce guide.
Qui corrige quoi
Faites défiler le tableau
| Cas de figure | Où se trouve le défaut | Qui agit |
|---|---|---|
| PwnEscape (CVE-2026-99999) | Noyau de l'hôte de virtualisation, pile réseau IPv4 | L'hébergeur, sur ses hôtes. Rien ne se corrige depuis votre VPS |
| Vghost (CVE-2026-74580), côté VPS | Noyau de votre VPS, si les nœuds `/dev/vhost-*` sont atteignables | Vous : noyau corrigé, puis redémarrage |
| Vghost, chemin déclenché depuis un invité | Noyau et QEMU de l'hôte, sous conditions précises | L'hébergeur |
| Mise à jour du noyau invité face à PwnEscape | Le défaut est sur l'hôte | Aucune protection de ce côté ; elle reste utile pour Vghost et les autres correctifs |
| Serveur dédié ou VPS dont vous êtes l'hyperviseur (KVM, Proxmox) | Vous êtes l'hôte | Vous : les deux failles vous concernent |
| Conteneurs Docker sur le VPS | Ils partagent le noyau du VPS | Corriger le noyau du VPS ; reconstruire une image n'y change rien |
| Hébergement mutualisé cPanel | Noyau géré par l'hébergeur | L'hébergeur |
PwnEscape : ce qui incombe à l'hébergeur
Pour une évasion, c'est le noyau qui reçoit le trafic de la machine virtuelle qui doit être corrigé, donc celui de l'hôte. Les branches stables corrigées sont 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 et 7.2.11 ; les noyaux de distribution rétroportent souvent un correctif sans changer de numéro de base, il faut donc lire le bulletin de la distribution plutôt que comparer des numéros. L'enregistrement CVE affiche d'ailleurs des bornes de versions peu cohérentes : fiez-vous aux trackers des distributions.
Sur un VPS, vous ne pouvez pas appliquer ce correctif, et mettre à jour votre noyau invité ne vous en protège pas. Demandez à votre hébergeur, quel qu'il soit, si ses hôtes sont corrigés, à quelle date, et si un redémarrage d'hôte est prévu. Nous ne prétendons pas ici qu'une offre précise est ou non vulnérable : seule la confirmation de l'exploitant fait foi. Dans son article, le chercheur prévoit des exploits publics pour les configurations les plus faibles d'ici quelques semaines : c'est sa prévision, pas un constat, et l'évaluation CISA ne signale aucune exploitation à ce jour.
Vghost : ce qui incombe à vous
Vghost est une escalade locale : l'attaquant doit déjà exécuter du code sur la machine, par exemple à travers un site client compromis qui tourne sous un compte sans privilège. Le correctif du noyau principal porte l'empreinte de845981da67. Les premières versions stables corrigées sont 5.10.265, 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9 et 7.2. Là encore, un noyau de distribution peut porter le correctif sous un autre numéro : comparez au bulletin de la distribution, pas au numéro amont.
Tout dépend des droits sur les nœuds vhost. D'après l'annonce publiée sur oss-security, dans les tests de son auteur, Ubuntu limitait /dev/vhost-vsock au groupe kvm, alors que RHEL, Amazon Linux, Azure Linux et Oracle Linux l'ouvraient à tout utilisateur. Sur un VPS qui n'héberge aucune machine virtuelle, ces nœuds sont normalement absents ; c'est à vérifier, pas à supposer. Le correctif ne s'active qu'au redémarrage sur le nouveau noyau.
Vérifier le noyau et l'exposition en dix minutes
Relever le noyau en cours d'exécution
uname -r
Cette commande affiche le noyau chargé en mémoire, pas celui qui est installé sur le disque. C'est ce numéro qui compte pour Vghost, et il ne change qu'après un redémarrage.Lister les noyaux installés
dpkg -l 'linux-image*' | grep '^ii'rpm -q kernel
La première commande vaut pour Debian et Ubuntu, la seconde pour AlmaLinux, Rocky et RHEL. Si le noyau le plus récent de la liste diffère de celui deuname -r, un correctif est peut-être installé sans être actif.Savoir si un redémarrage est en attente
cat /var/run/reboot-requiredsudo needrestart -ksudo dnf needs-restarting -r
Les deux premières commandes servent sur Debian et Ubuntu, la troisième sur AlmaLinux et Rocky (paquetdnf-utilssi la commande manque). Elles comparent noyau en cours et noyau installé.Chercher les nœuds vhost et leurs droits
ls -l /dev/vhost-net /dev/vhost-vsocklsmod | grep '^vhost'getent group kvm
Sans nœud ni module chargé, la voie décrite pour Vghost n'est pas ouverte à cet instant, mais un logiciel ou un administrateur peut charger le module plus tard. Si un nœud existe, lisez son mode :0666signifie que tout compte local peut l'ouvrir,0660qu'il faut appartenir au groupe propriétaire. Si vous exploitez vous-même des machines virtuelles, ajoutezls -l /dev/kvm.Chercher l'identifiant dans le journal du paquet
apt changelog linux-image-$(uname -r) | grep CVE-2026-74580rpm -q --changelog kernel | grep CVE-2026-74580
La première ligne vaut pour Debian et Ubuntu, la seconde pour la famille RHEL. Trouver l'identifiant est un bon signe ; ne pas le trouver ne prouve rien, car le journal peut citer le correctif autrement. Le tracker de la distribution tranche.Traiter les conteneurs et les droits d'accès aux périphériques
docker exec <conteneur> uname -rdocker ps -q | xargs -r docker inspect | grep -E 'Privileged|vhost'
La première commande affiche le noyau du VPS, preuve que le conteneur n'en a pas un à lui. La seconde repère les conteneurs lancés en mode privilégié ou avec un périphérique vhost monté : eux voient les nœuds de l'hôte.
Où en sont les distributions
L'état des correctifs change d'un jour à l'autre et diffère d'une version de distribution à l'autre, certaines étant corrigées avant d'autres. Relisez le tracker de votre distribution pour les deux identifiants, CVE-2026-74580 et CVE-2026-99999, avant de conclure : les liens figurent en fin d'article. Pour AlmaLinux et Rocky, suivez les errata publiés par chaque projet à la suite de ceux de RHEL. Tant que votre version n'affiche pas de correctif publié, appliquez une parade provisoire et revenez vérifier.
Mettre à jour selon l'environnement
Debian et Ubuntu
sudo apt updatesudo apt full-upgradeapt list --installed 'linux-image*'
Utilisezfull-upgrade: un nouveau noyau arrive sous un nouveau nom de paquet, etapt upgradele laisse souvent de côté (« kept back »). Si le tracker indique que le correctif n'est pas encore publié pour votre version, la mise à jour n'apporte rien sur ce point : appliquez une parade provisoire et repassez régulièrement.AlmaLinux, Rocky et RHEL
sudo dnf upgrade --refresh kernelsudo grubby --default-kernelsudo dnf needs-restarting -r
La deuxième commande confirme que le noyau installé est bien celui qui démarrera par défaut. La troisième dit si le système attend un redémarrage.Docker et conteneurs
Il n'y a rien à reconstruire : les conteneurs utilisent le noyau du VPS. Mettez à jour le noyau de la machine comme ci-dessus, puis redémarrez-la. Après le redémarrage, vérifiez que chaque conteneur est reparti :
docker psetdocker ps -a --filter status=exited. Une politiquerestart: unless-stoppeddans vos fichiers Compose évite de relancer à la main.Hyperviseur maison (KVM, Proxmox)
Vous êtes l'hôte, donc les deux failles vous concernent. Appliquez les mêmes mises à jour sur l'hôte, puis redémarrez-le après avoir migré ou arrêté proprement les machines virtuelles. Gardez l'hôte à jour avant les invités, pas après.
Un noyau installé n'est pas un noyau en cours
Un apt full-upgrade réussi ne corrige rien tant que la machine n'a pas redémarré : le noyau vulnérable reste chargé en mémoire. Le seul contrôle valable est uname -r après redémarrage, à comparer au numéro attendu dans le bulletin de votre distribution. Notez-le dans votre registre, avec la date, pour chaque serveur.
Redémarrer sans couper les sites clients
Planifiez plutôt que de subir. Choisissez une fenêtre creuse, prévenez les clients, vérifiez que vos sauvegardes sont récentes, puis programmez le redémarrage : sudo shutdown -r 03:30 "Redémarrage noyau". Avant, relevez l'état des services avec systemctl --failed et la liste des conteneurs avec docker ps ; après, rejouez les mêmes commandes et comparez. Traitez le parc par paliers de quelques machines.
Le livepatch peut éviter un redémarrage, mais sa disponibilité dépend de la distribution et de l'abonnement : Canonical Livepatch sur Ubuntu avec Ubuntu Pro, kpatch sur la famille RHEL, KernelCare chez un éditeur tiers. Ne supposez pas qu'un correctif à chaud existe pour ces deux failles : lisez le bulletin du fournisseur et, sur Ubuntu, canonical-livepatch status --verbose. L'avis de Vghost demande un redémarrage sur le noyau corrigé ; sans livepatch confirmé, c'est la seule voie.
Parades provisoires et leurs limites
Si le correctif de votre distribution n'est pas encore publié, deux gestes réduisent la surface de Vghost, sans la fermer. Le premier consiste à retirer l'accès général aux nœuds, par exemple sudo chmod 0660 /dev/vhost-net /dev/vhost-vsock, puis à garder les conteneurs non fiables loin de ces périphériques. Cela ne révoque pas les descripteurs déjà ouverts. Le second, que la fiche Red Hat de Vghost propose comme parade, empêche le chargement des modules : printf 'install vhost_net /bin/false\ninstall vhost_vsock /bin/false\n' | sudo tee /etc/modprobe.d/vhost-off.conf, puis sudo modprobe -r vhost_net vhost_vsock. Red Hat prévient que couper vhost peut dégrader les performances d'entrée-sortie des machines virtuelles, et que le déchargement échoue si le pilote est utilisé.
Ces mesures ne servent à rien contre PwnEscape, dont le défaut est sur l'hôte, et aucune ne remplace le noyau corrigé. Rétablissez la configuration d'origine une fois le correctif appliqué.
Contrôler les traces après coup
Aucun indicateur de compromission propre à ces failles n'a été publié à notre connaissance, ce qui rend le contrôle imparfait. Parcourez quand même ce qui peut trahir une élévation de privilèges récente : sudo journalctl -k --since "30 days ago" | grep -i -E 'vhost|oops|general protection' pour les anomalies noyau, last -x | head -30 pour les connexions et redémarrages, sudo awk -F: '$3==0' /etc/passwd pour les comptes de niveau root, puis les clés de /root/.ssh/authorized_keys et les tâches crontab -l de root. Cherchez aussi les binaires setuid récents avec sudo find / -xdev -perm -4000 -mtime -30.
Un attaquant devenu root peut effacer ses traces : un contrôle propre n'est pas une preuve de santé. En cas de doute sur un serveur qui a hébergé du code non fiable, reconstruisez-le depuis une image saine et restaurez les données plutôt que de le nettoyer.
Pour une agence : un créneau commun, pas un serveur après l'autre
Avec des dizaines de VPS chez des clients différents, la commande de mise à jour prend une minute ; le temps part à savoir quel serveur tourne sur quel noyau, qui valide le redémarrage et quand. Tenez un registre vivant alimenté par uname -r et par la présence de /var/run/reboot-required, puis fixez un créneau commun annoncé d'avance plutôt que de découvrir la faille serveur par serveur. Triez d'abord les machines où du code client non fiable s'exécute, puis celles où /dev/vhost-* existe.
L'espace agence ServOrbit centralise services et échéances, ce qui évite de les suivre compte par compte. Pour qui ne souhaite pas tenir le noyau lui-même, ServOrbit propose l'option administration VPS ; ce guide, lui, est fourni sans prise en charge.
La documentation officielle
Divulgation de Vghost sur oss-security : https://openwall.com/lists/oss-security/2026/10/14/2
Analyse technique de Vghost : https://matrix.tencent.com/en/2026/10/12/vghost-cve-2026-74580
Enregistrement CVE de PwnEscape : https://cveawg.mitre.org/api/cve/CVE-2026-99999
Article du découvreur de PwnEscape : https://pwn.ai/blog/pwnescape
Tracker Debian pour Vghost : https://security-tracker.debian.org/tracker/CVE-2026-74580
Tracker Debian pour PwnEscape : https://security-tracker.debian.org/tracker/CVE-2026-99999
Tracker Ubuntu pour Vghost : https://ubuntu.com/security/CVE-2026-74580
Tracker Ubuntu pour PwnEscape : https://ubuntu.com/security/CVE-2026-99999
Fiche Red Hat pour Vghost : https://access.redhat.com/security/cve/CVE-2026-74580
Errata AlmaLinux : https://errata.almalinux.org/
Canonical Livepatch : https://ubuntu.com/security/livepatch
Outil needrestart : https://github.com/liske/needrestart
