vghost-watch

Un helper per il controllo del perimetro e la divulgazione responsabile per CVE-2026-74580 ("Vghost") — un bug reale della cache dei metadati vhost del kernel Linux (record CVE, voce OSV) che consente privesc locale / VM-escape su host vhost/hypervisor esposti.

Caso d'uso principale: controllare il proprio perimetro. Fornisci i tuoi range IP, CIDR o domini (import_list.py) — interni o esterni — e classificali per l'esposizione adiacente a vhost (porte di gestione libvirt/Proxmox/QEMU), quindi ottieni note di remediation per il tuo tracker (run_pipeline.py --self, vedi "Controllare il proprio perimetro" sotto). Nessuna auto-discovery, nessuna ricerca di contatti di massa — l'host è già tuo.

Capacità secondaria: scoperta di terze parti tramite dati di scansione pubblici. Questo progetto non scansiona Internet da solo — può opzionalmente interrogare dataset/API che hanno già effettuato la scansione (Rapid7 Open Data / Sonar, Shodan, Censys) per trovare altri host esposti, e poi aiutarti a redigere notifiche di divulgazione ai loro proprietari. Da sapere prima di investire tempo qui: non c'è alcun bounty per questo (i CSIRT non pagano, e i report del tipo "istanza non patchata con CVE noto" raramente sono idonei al bounty — vedi "Impatto" sotto) — è lavoro di notifica non retribuito da buon cittadino, e la maggior parte dell'uso reale di questo repo è il caso di controllo del perimetro qui sopra, non questo.

Impatto: quando è applicabile / critico?

CVE-2026-74580 è un bug a livello di kernel, locale, non esposto a web/rete -- ne derivano alcune cose che contano per la classificazione:

Applicabile solo se valgono tutte queste condizioni:

• L'host esegue un kernel Linux non patchato (inferiore a 5.10.265, 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9, o il backport della distro).
• Utilizza virtualizzazione basata su vhost (vhost-net/vhost-scsi tramite QEMU/KVM, tipicamente attraverso libvirt o Proxmox). Un host bare-metal senza VM, o VM su semplice virtio senza offload vhost, non è esposto a questo bug indipendentemente dal livello di patch.
• L'esecuzione di codice locale è un prerequisito. Si tratta di privesc/VM-escape, non di esecuzione di codice remoto -- un attaccante deve già stare eseguendo codice da qualche parte che raggiunge l'interfaccia vulnerabile: una VM guest, un container con kernel condiviso, o un account locale sull'host. "Stare già eseguendo codice" non richiede accesso diretto come SSH -- in pratica è più spesso uno dei seguenti:
  • Un tenant legittimo, su un hypervisor multi-tenant/cloud -- un cliente che ha semplicemente noleggiato una VM ha già piena esecuzione di codice al suo interno, per progettazione, senza bisogno di violazioni.
  • Una compromissione non correlata all'interno del guest -- più comunemente un'applicazione web vulnerabile che subisce RCE (un plugin obsoleto, SSRF-to-RCE, bug di deserializzazione, ecc.), ma qualsiasi compromissione lato guest funziona allo stesso modo. Il bug vhost non si cura di come l'attaccante è entrato, solo del fatto che ora ha l'esecuzione di codice da cui pivotare.

Il vero fattore determinante della gravità è chi ha già (o può ottenere) l'esecuzione di codice -- non se l'host è esposto a Internet. L'esposizione a Internet influisce solo su quanto facilmente un attaccante esterno trova il target o raggiunge il punto d'appoggio iniziale da remoto; non cambia nulla sul fatto che il bug sia sfruttabile una volta che qualcuno ha quel punto d'appoggio. Infrastruttura solo interna, privata, non è intrinsecamente a rischio inferiore:

Più critico, indipendentemente dall'esposizione a Internet:

• Qualsiasi hypervisor multi-tenant o multi-utente -- provider di hosting, ma altrettanto un cloud privato interno, una piattaforma interna VM-per-team, o un ambiente condiviso di dev/test con account utente ordinari su VM/app. Ognuno di questi utenti o tenant ha già il prerequisito di esecuzione di codice, per progettazione, senza alcuna violazione necessaria -- esposto a Internet o meno.
• Qualsiasi host su cui un attaccante ha già un punto d'appoggio (VM compromessa, shell interna, un container escape co-locato, un'app interna compromessa) con offload vhost in uso -- questo trasforma "ho una shell a bassi privilegi" in "possiedo l'host", indipendentemente da come quella shell è stata ottenuta.

Dove l'esposizione a Internet conta davvero (un fattore secondario, non quello primario):

• Rende più facile per un attaccante esterno ottenere da remoto il punto d'appoggio iniziale (ad es. un RCE su un'app web, vedi la nota sul WAF qui sotto) e rende l'host più facile da trovare in primo luogo -- le porte di gestione esposte (libvirt 16509/16514, Proxmox 8006) sono un segnale di ricognizione per questo, ed è ciò che lo scoring di merge_and_triage.py cerca. Una porta esposta non prova nulla di per sé, però -- conta solo quando qualcosa controllato dall'attaccante può essere eseguito localmente, cosa che i dati di scansione passiva non possono mostrare (vedi "Perché solo passivo" qui sotto per il motivo per cui questo repo non tenta di confermarlo su host che non possiedi).
• Un host solo interno con la stessa esposizione multi-utente/multi-tenant è ugualmente critico -- ha solo bisogno di un utente interno, di un collaboratore esterno, o di un'app interna compromessa che fornisca il punto d'appoggio invece di uno esposto a Internet. Non interpretare "non esposto a Internet" come "priorità inferiore".

Gravità genuinamente inferiore:

• Single-tenant, senza guest, utenti o app non attendibili -- l'unico "attaccante" saresti tu, quindi il rischio nel mondo reale è molto più basso. Vale comunque la pena applicare la patch affinché una futura compromissione non correlata non possa concatenarsi in questa.
• Nessun vIOMMU -- secondo l'advisory, il percorso di VM-escape richiede specificamente una configurazione con vIOMMU abilitato; senza di esso, l'impatto è probabilmente limitato a un privesc locale all'interno del kernel anziché attraversare il confine guest/host.

Un WAF aiuta? Non direttamente contro questo bug -- un WAF ispeziona il traffico HTTP(S), e questo bug risiede nel percorso della metadata-cache di vhost del kernel, non nel parsing delle richieste. Semplicemente non è nel percorso di esposizione della vulnerabilità stessa.

Dove un WAF conta davvero è un passo prima: la catena reale più comune è RCE su app web → esecuzione di codice all'interno del guest → exploit vhost → escape dall'host → movimento laterale verso ogni altro tenant. Un WAF (o altri controlli di sicurezza web) può bloccare l'RCE dell'app web che fornisce all'attaccante il suo punto d'appoggio iniziale, il che impedisce loro di raggiungere mai il prerequisito per questo bug in primo luogo. Quindi: irrilevante per il bug vhost stesso, ma rilevante per uno dei più comuni percorsi verso il suo prerequisito.

Ciò che riduce davvero il rischio, dall'inizio alla fine: applicare la patch al kernel, disabilitare l'offload vhost dove non è necessario, non esporre le porte di gestione libvirt/Proxmox a Internet, rafforzare le app/servizi web in esecuzione all'interno dei guest (riducendo le probabilità di quell'RCE iniziale), e rafforzare l'isolamento dei tenant (seccomp, namespace) per rendere più difficile ottenere qualsiasi punto d'appoggio.

Perché solo passivo, per progettazione