vghost-watch

Un assistant de vérification de périmètre et d'aide à la divulgation responsable pour CVE-2026-74580 (« Vghost ») — un véritable bug du cache de métadonnées vhost du noyau Linux (fiche CVE, entrée OSV) qui permet une élévation de privilèges locale / évasion de VM sur les hôtes vhost/hyperviseur exposés.

Cas d'usage principal : vérifier votre propre périmètre. Fournissez vos propres plages d'IP, CIDR ou domaines (import_list.py) — internes ou externes — et triez-les pour détecter une exposition liée à vhost (ports de gestion libvirt/Proxmox/QEMU), puis obtenez des notes de remédiation pour votre propre outil de suivi (run_pipeline.py --self, voir « Vérification de votre propre périmètre » ci-dessous). Pas de découverte automatique, pas de recherche massive de contacts — vous possédez déjà l'hôte.

Capacité secondaire : découverte de tiers via des données de scan publiques. Ce projet ne scanne pas lui-même l'internet — il peut optionnellement interroger des jeux de données/API qui ont déjà effectué le scan (Rapid7 Open Data / Sonar, Shodan, Censys) pour trouver d'autres hôtes exposés, puis vous aider à rédiger des avis de divulgation à leurs propriétaires. À savoir avant d'y investir du temps : il n'y a pas de prime pour cela (les CSIRT ne paient pas, et les signalements de type « CVE connue, instance non corrigée » sont rarement éligibles à une prime — voir « Impact » ci-dessous) — c'est un travail de notification bénévole et citoyen, et l'usage réel principal de ce dépôt est le cas de vérification de périmètre ci-dessus, pas celui-ci.

Impact : quand est-ce applicable / critique ?

CVE-2026-74580 est un bug au niveau du noyau, local, et non orienté web/réseau — plusieurs conséquences en découlent, importantes pour le triage :

Applicable uniquement si toutes ces conditions sont réunies :

• L'hôte exécute un noyau Linux non corrigé (inférieur à 5.10.265, 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9, ou le rétroportage de la distribution).
• Il utilise une virtualisation adossée à vhost (vhost-net/vhost-scsi via QEMU/KVM, généralement à travers libvirt ou Proxmox). Un hôte bare-metal sans VM, ou des VM sur du virtio simple sans déport vhost, n'est pas exposé à ce bug quel que soit le niveau de correctif.
• L'exécution de code locale est un prérequis. Il s'agit d'une élévation de privilèges/évasion de VM, pas d'une exécution de code à distance — un attaquant doit déjà exécuter du code quelque part qui atteint l'interface vulnérable : une VM invitée, un conteneur à noyau partagé, ou un compte local sur l'hôte. « Exécuter déjà du code » ne nécessite pas un accès direct comme SSH — en pratique, c'est le plus souvent l'un des cas suivants :
  • Un locataire légitime, sur un hyperviseur multi-locataire/cloud — un client qui a simplement loué une VM dispose déjà d'une exécution de code complète à l'intérieur, par conception, sans aucune intrusion nécessaire.
  • Une compromission sans rapport à l'intérieur de l'invité — le plus souvent une application web vulnérable obtenant une RCE (un plugin obsolète, une SSRF menant à une RCE, un bug de désérialisation, etc.), mais toute compromission côté invité fonctionne de la même manière. Le bug vhost ne se soucie pas de la façon dont l'attaquant est entré, seulement du fait qu'il dispose désormais d'une exécution de code à partir de laquelle pivoter.

Le véritable facteur de gravité est qui dispose déjà (ou peut obtenir) d'une exécution de code — et non si l'hôte est exposé à internet. L'exposition internet n'affecte que la facilité avec laquelle un attaquant extérieur trouve la cible ou atteint le point d'ancrage initial à distance ; cela ne change rien au fait que le bug soit exploitable une fois ce point d'ancrage obtenu. Une infrastructure privée, interne uniquement, n'est pas intrinsèquement moins risquée :

Les plus critiques, indépendamment de l'exposition à Internet :

• Tout hyperviseur multi-tenant ou multi-utilisateur -- les fournisseurs d'hébergement, mais tout autant un cloud privé interne, une plateforme interne de VM par équipe, ou un environnement partagé de dev/test avec des comptes utilisateurs ordinaires sur des VM/apps. Chacun de ces utilisateurs ou tenants dispose déjà du prérequis d'exécution de code, par conception, sans aucune compromission nécessaire -- exposé à Internet ou non.
• Tout hôte sur lequel un attaquant dispose déjà d'un point d'ancrage (VM compromise, shell interne, évasion de conteneur co-localisé, app interne compromise) avec l'offload vhost en usage -- cela transforme « j'ai un shell à faibles privilèges » en « je possède l'hôte », quelle que soit la manière dont ce shell a été obtenu.

Là où l'exposition à Internet compte réellement (un facteur secondaire, pas le principal) :

• Elle facilite l'obtention du point d'ancrage initial à distance pour un attaquant externe (par ex. une RCE d'application web, voir la note sur le WAF ci-dessous) et rend l'hôte plus facile à trouver dès le départ -- les ports de gestion exposés (libvirt 16509/16514, Proxmox 8006) sont un signal de reconnaissance pour cela, ce que le scoring de merge_and_triage.py recherche. Un port exposé ne prouve rien en lui-même, cependant -- il ne compte que lorsqu'un élément contrôlé par l'attaquant peut s'exécuter localement, ce que les données de scan passif ne peuvent pas montrer (voir « Pourquoi passif uniquement » ci-dessous pour savoir pourquoi ce dépôt n'essaie pas de le confirmer sur des hôtes qui ne vous appartiennent pas).
• Un hôte interne uniquement présentant la même exposition multi-utilisateur/multi-tenant est tout aussi critique -- il a simplement besoin d'un utilisateur interne, d'un prestataire ou d'une app interne compromise pour fournir le point d'ancrage au lieu d'un point d'ancrage exposé à Internet. Ne lisez pas « non exposé à Internet » comme « priorité plus faible ».

Réellement de gravité moindre :

• Mono-tenant, sans aucun invité, utilisateur ou app non fiable -- le seul « attaquant » serait vous, donc le risque réel est bien plus faible. Cela vaut tout de même la peine d'être corrigé pour qu'une future compromission sans rapport ne puisse pas s'enchaîner avec celle-ci.
• Pas de vIOMMU -- selon l'avis, le chemin d'évasion de VM nécessite spécifiquement une configuration avec vIOMMU activé ; sans cela, l'impact est probablement limité à une élévation de privilèges locale dans le noyau plutôt qu'à un franchissement de la frontière invité/hôte.

Un WAF aide-t-il ? Pas directement contre ce bug -- un WAF inspecte le trafic HTTP(S), et ce bug réside dans le chemin du cache de métadonnées vhost du noyau, pas dans l'analyse des requêtes. Il n'est simplement pas dans le chemin d'exposition de la vulnérabilité elle-même.

Là où un WAF compte réellement, c'est une étape plus tôt : la chaîne la plus courante dans le monde réel est RCE d'application web → exécution de code dans l'invité → exploitation vhost → évasion de l'hôte → mouvement latéral vers tous les autres tenants. Un WAF (ou d'autres contrôles de sécurité web) peut bloquer la RCE de l'application web qui fournit à un attaquant son point d'ancrage initial, ce qui l'empêche d'atteindre ne serait-ce que le prérequis de ce bug. Donc : sans importance pour le bug vhost lui-même, mais pertinent pour l'un des chemins les plus courants vers son prérequis.