[{"data":1,"prerenderedAt":193},["ShallowReactive",2],{"seo-verification":3,"blog-pwnescape-vghost-noyau-linux-vps-mettre-a-jour-fr":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-pwnescape-vghost-noyau-linux-vps-mettre-a-jour-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":139,"ctaBody":140,"ctaButton":141,"ctaUrl":142,"relatedPosts":143},517,"pwnescape-vghost-noyau-linux-vps-mettre-a-jour",{"fr":10,"en":12,"ar":13,"es":14},"pwnescape-vghost-linux-kernel-vps-update","ثغرتا-pwnescape-و-vghost-تحديث-نواة-لينكس-على-vps","pwnescape-vghost-kernel-linux-vps-actualizar","PwnEscape et Vghost : mettre à jour le noyau Linux d'un VPS","Deux failles noyau Linux d'octobre 2026 : PwnEscape se corrige chez l'hébergeur, Vghost sur votre VPS. Vérifier le noyau, mettre à jour, planifier le redémarrage.",11,0,false,"2026-10-28T00:00:00+00:00","2026-10-29T03:10:22+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Sécurité & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fpwnescape-vghost-noyau-linux-vps-mettre-a-jour-poster.svg","À la mi-octobre 2026, deux failles du noyau Linux ont été rendues publiques : PwnEscape, qui permet à une machine virtuelle de s'échapper vers son hôte, et Vghost, une escalade locale vers root dont la preuve de concept est publique. Sur un VPS, la question n'est pas de savoir s'il faut mettre à jour, mais qui met à jour quoi. L'hôte de virtualisation relève de l'hébergeur ; le noyau de votre VPS relève de vous, et il ne se corrige qu'au redémarrage. Ce guide donne les commandes par distribution, la vérification d'exposition et un plan de redémarrage qui ménage les sites clients.",[35,39,74,77,80,102,105,120,124,127,130,133,136],{"type":36,"title":37,"body":38},"h2","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.\n\nVghost 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 `\u002Fdev\u002Fvhost-net` ou `\u002Fdev\u002Fvhost-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.",{"type":40,"title":41,"headers":42,"rows":46},"comparison","Qui corrige quoi",[43,44,45],"Cas de figure","Où se trouve le défaut","Qui agit",[47,51,55,59,63,67,71],[48,49,50],"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",[52,53,54],"Vghost (CVE-2026-74580), côté VPS","Noyau de votre VPS, si les nœuds `\u002Fdev\u002Fvhost-*` sont atteignables","Vous : noyau corrigé, puis redémarrage",[56,57,58],"Vghost, chemin déclenché depuis un invité","Noyau et QEMU de l'hôte, sous conditions précises","L'hébergeur",[60,61,62],"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",[64,65,66],"Serveur dédié ou VPS dont vous êtes l'hyperviseur (KVM, Proxmox)","Vous êtes l'hôte","Vous : les deux failles vous concernent",[68,69,70],"Conteneurs Docker sur le VPS","Ils partagent le noyau du VPS","Corriger le noyau du VPS ; reconstruire une image n'y change rien",[72,73,58],"Hébergement mutualisé cPanel","Noyau géré par l'hébergeur",{"type":36,"title":75,"body":76},"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.\n\nSur 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.",{"type":36,"title":78,"body":79},"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.\n\nTout 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 `\u002Fdev\u002Fvhost-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.",{"type":81,"title":82,"steps":83},"steps","Vérifier le noyau et l'exposition en dix minutes",[84,87,90,93,96,99],{"title":85,"body":86},"Relever le noyau en cours d'exécution","`uname -r`\nCette 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.",{"title":88,"body":89},"Lister les noyaux installés","`dpkg -l 'linux-image*' | grep '^ii'`\n`rpm -q kernel`\nLa 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 de `uname -r`, un correctif est peut-être installé sans être actif.",{"title":91,"body":92},"Savoir si un redémarrage est en attente","`cat \u002Fvar\u002Frun\u002Freboot-required`\n`sudo needrestart -k`\n`sudo dnf needs-restarting -r`\nLes deux premières commandes servent sur Debian et Ubuntu, la troisième sur AlmaLinux et Rocky (paquet `dnf-utils` si la commande manque). Elles comparent noyau en cours et noyau installé.",{"title":94,"body":95},"Chercher les nœuds vhost et leurs droits","`ls -l \u002Fdev\u002Fvhost-net \u002Fdev\u002Fvhost-vsock`\n`lsmod | grep '^vhost'`\n`getent group kvm`\nSans 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 : `0666` signifie que tout compte local peut l'ouvrir, `0660` qu'il faut appartenir au groupe propriétaire. Si vous exploitez vous-même des machines virtuelles, ajoutez `ls -l \u002Fdev\u002Fkvm`.",{"title":97,"body":98},"Chercher l'identifiant dans le journal du paquet","`apt changelog linux-image-$(uname -r) | grep CVE-2026-74580`\n`rpm -q --changelog kernel | grep CVE-2026-74580`\nLa 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.",{"title":100,"body":101},"Traiter les conteneurs et les droits d'accès aux périphériques","`docker exec \u003Cconteneur> uname -r`\n`docker ps -q | xargs -r docker inspect | grep -E 'Privileged|vhost'`\nLa 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.",{"type":36,"title":103,"body":104},"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.",{"type":81,"title":106,"steps":107},"Mettre à jour selon l'environnement",[108,111,114,117],{"title":109,"body":110},"Debian et Ubuntu","`sudo apt update`\n`sudo apt full-upgrade`\n`apt list --installed 'linux-image*'`\nUtilisez `full-upgrade` : un nouveau noyau arrive sous un nouveau nom de paquet, et `apt upgrade` le 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.",{"title":112,"body":113},"AlmaLinux, Rocky et RHEL","`sudo dnf upgrade --refresh kernel`\n`sudo grubby --default-kernel`\n`sudo dnf needs-restarting -r`\nLa 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.",{"title":115,"body":116},"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 ps` et `docker ps -a --filter status=exited`. Une politique `restart: unless-stopped` dans vos fichiers Compose évite de relancer à la main.",{"title":118,"body":119},"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.",{"type":121,"title":122,"body":123},"tip","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.",{"type":36,"title":125,"body":126},"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.\n\nLe 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.",{"type":36,"title":128,"body":129},"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 \u002Fdev\u002Fvhost-net \u002Fdev\u002Fvhost-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 \u002Fbin\u002Ffalse\\ninstall vhost_vsock \u002Fbin\u002Ffalse\\n' | sudo tee \u002Fetc\u002Fmodprobe.d\u002Fvhost-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é.\n\nCes 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é.",{"type":36,"title":131,"body":132},"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' \u002Fetc\u002Fpasswd` pour les comptes de niveau root, puis les clés de `\u002Froot\u002F.ssh\u002Fauthorized_keys` et les tâches `crontab -l` de root. Cherchez aussi les binaires setuid récents avec `sudo find \u002F -xdev -perm -4000 -mtime -30`.\n\nUn 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.",{"type":36,"title":134,"body":135},"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 `\u002Fvar\u002Frun\u002Freboot-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ù `\u002Fdev\u002Fvhost-*` existe.\n\nL'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.",{"type":36,"title":137,"body":138},"La documentation officielle","Divulgation de Vghost sur oss-security : https:\u002F\u002Fopenwall.com\u002Flists\u002Foss-security\u002F2026\u002F10\u002F14\u002F2\n\nAnalyse technique de Vghost : https:\u002F\u002Fmatrix.tencent.com\u002Fen\u002F2026\u002F10\u002F12\u002Fvghost-cve-2026-74580\n\nEnregistrement CVE de PwnEscape : https:\u002F\u002Fcveawg.mitre.org\u002Fapi\u002Fcve\u002FCVE-2026-99999\n\nArticle du découvreur de PwnEscape : https:\u002F\u002Fpwn.ai\u002Fblog\u002Fpwnescape\n\nTracker Debian pour Vghost : https:\u002F\u002Fsecurity-tracker.debian.org\u002Ftracker\u002FCVE-2026-74580\n\nTracker Debian pour PwnEscape : https:\u002F\u002Fsecurity-tracker.debian.org\u002Ftracker\u002FCVE-2026-99999\n\nTracker Ubuntu pour Vghost : https:\u002F\u002Fubuntu.com\u002Fsecurity\u002FCVE-2026-74580\n\nTracker Ubuntu pour PwnEscape : https:\u002F\u002Fubuntu.com\u002Fsecurity\u002FCVE-2026-99999\n\nFiche Red Hat pour Vghost : https:\u002F\u002Faccess.redhat.com\u002Fsecurity\u002Fcve\u002FCVE-2026-74580\n\nErrata AlmaLinux : https:\u002F\u002Ferrata.almalinux.org\u002F\n\nCanonical Livepatch : https:\u002F\u002Fubuntu.com\u002Fsecurity\u002Flivepatch\n\nOutil needrestart : https:\u002F\u002Fgithub.com\u002Fliske\u002Fneedrestart","Un parc de VPS, un seul créneau de redémarrage","Un parc de serveurs clients se pilote mieux depuis un seul endroit. Dans l'espace agence ServOrbit.com, vous centralisez services et échéances ; l'option administration VPS existe pour qui ne veut pas tenir le noyau lui-même.","Découvrir l'offre agences","\u002Fsolutions\u002Fagences",[144,160,177],{"id":145,"slug":146,"slugs":147,"title":151,"excerpt":152,"readTime":17,"views":153,"isPinned":19,"publishedAt":154,"updatedAt":155,"category":156,"categories":157,"featuredImage":30,"bgImage":31,"posterImage":159,"relatedSolution":30},317,"linux-hardening-vps-checklist",{"fr":146,"en":148,"ar":149,"es":150},"linux-vps-hardening-checklist-for-agencies","قائمة-تصليب-خادم-لينكس-للوكالات-بعد-التسليم","hardening-linux-vps-checklist-para-agencias-tras-la-entrega","Durcissement Linux VPS : checklist agence après livraison","Checklist de durcissement Linux pour agences : auditd, sudo, SSH par clé, UFW, fail2ban et désactivation root — traçabilité et runbook par client.",1,"2026-08-30T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[158],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Flinux-hardening-vps-checklist-poster.svg",{"id":161,"slug":162,"slugs":163,"title":167,"excerpt":168,"readTime":169,"views":170,"isPinned":19,"publishedAt":171,"updatedAt":172,"category":173,"categories":174,"featuredImage":30,"bgImage":31,"posterImage":176,"relatedSolution":30},382,"securite-vps-mises-a-jour-automatiques-debian-ubuntu",{"fr":162,"en":164,"ar":165,"es":166},"vps-automatic-security-updates-debian-ubuntu","تحديثات-أمان-تلقائية-vps-debian-ubuntu","actualizaciones-seguridad-vps-debian-ubuntu","Mises à jour de sécurité automatiques sur VPS Debian\u002FUbuntu","Configurez unattended-upgrades sur vos VPS Debian\u002FUbuntu pour automatiser les patches de sécurité et réduire la surface d'attaque de votre parc client.",10,2,"2026-09-26T00:00:00+00:00","2026-09-29T14:40:42+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[175],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fsecurite-vps-mises-a-jour-automatiques-debian-ubuntu-poster.svg",{"id":178,"slug":179,"slugs":180,"title":184,"excerpt":185,"readTime":186,"views":153,"isPinned":19,"publishedAt":187,"updatedAt":188,"category":189,"categories":190,"featuredImage":30,"bgImage":31,"posterImage":192,"relatedSolution":30},494,"openssh-10-6-mise-a-jour-securite-sshd",{"fr":179,"en":181,"ar":182,"es":183},"openssh-10-6-security-update-sshd","تحديث-openssh-10-6-أمان-sshd","openssh-10-6-actualizacion-seguridad-sshd","OpenSSH 10.6 : mettre à jour sshd sans couper l'accès","Mise à jour de sécurité OpenSSH 10.6 : vérifier la version réellement active, ce qui peut casser (ProxyCommand, Compression) et recharger sshd sans risque.",12,"2026-10-22T00:00:00+00:00","2026-10-23T13:27:02+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[191],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fopenssh-10-6-mise-a-jour-securite-sshd-poster.svg",1793251280987]