vghost-watch

A perimeter-check and responsible-disclosure helper for CVE-2026-74580 ("Vghost") — a real Linux kernel vhost metadata-cache bug (CVE record, OSV entry) that gives local-privesc / VM-escape on exposed vhost/hypervisor hosts.

Primary use case: check your own perimeter. Feed in your own IP ranges, CIDRs, or domains (import_list.py) — internal or external — and triage them for vhost-adjacent exposure (libvirt/Proxmox/QEMU management ports), then get remediation notes for your own tracker (run_pipeline.py --self, see "Checking your own perimeter" below). No auto-discovery, no mass contact lookup — you already own the host.

Secondary capability: third-party discovery via public scan data. This project does not scan the internet itself — it can optionally query datasets/APIs that already did the scanning (Rapid7 Open Data / Sonar, Shodan, Censys) to find other exposed hosts, then help you draft disclosure notices to their owners. Worth knowing before you invest time here: there's no bounty for this (CSIRTs don't pay, and "known CVE, unpatched instance" reports are rarely bounty-eligible — see "Impact" below) — it's unpaid, good-citizen notification work, and most real usage of this repo is the perimeter-check case above, not this one.

Impact: when is this applicable / critical?

CVE-2026-74580 is a kernel-level, local bug, not a web/network-facing one -- a few things follow from that which matter for triage:

Applicable only if all of these hold:

• The host runs an unpatched Linux kernel (below 5.10.265, 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9, or the distro backport).
• It uses vhost-backed virtualization (vhost-net/vhost-scsi via QEMU/KVM, typically through libvirt or Proxmox). A bare-metal host with no VMs, or VMs on plain virtio without vhost offload, isn't exposed to this bug regardless of patch level.
• Local code execution is a prerequisite. This is privesc/VM-escape, not remote code execution -- an attacker needs to already be running code somewhere that reaches the vulnerable interface: a guest VM, a shared-kernel container, or a local account on the host. "Already running code" doesn't require direct access like SSH -- in practice it's most often one of:
  • A legitimate tenant, on a multi-tenant/cloud hypervisor -- a customer who simply rented a VM already has full code execution inside it, by design, no breach needed.
  • An unrelated compromise inside the guest -- most commonly a vulnerable web app getting RCE'd (an outdated plugin, SSRF-to-RCE, deserialization bug, etc.), but any guest-side compromise works the same way. The vhost bug doesn't care how the attacker got in, only that they now have code execution to pivot from.

The real severity driver is who already has (or can get) code execution -- not whether the host is internet-facing. Internet exposure only affects how easily an outside attacker finds the target or reaches the initial foothold remotely; it changes nothing about whether the bug is exploitable once someone has that foothold. Internal-only, private infrastructure is not inherently lower risk:

Most critical, regardless of internet exposure:

• Any multi-tenant or multi-user hypervisor -- hosting providers, but just as much an internal private cloud, an internal VM-per-team platform, or a shared dev/test environment with ordinary user accounts on VMs/apps. Every one of those users or tenants already has the code-execution prerequisite, by design, with zero breach required -- internet-facing or not.
• Any host where an attacker already has a toehold (compromised VM, insider shell, a co-located container escape, a compromised internal app) with vhost offload in use -- this turns "I have a low-priv shell" into "I own the host," regardless of how that shell was obtained.

Where internet exposure actually matters (a secondary factor, not the primary one):

• It makes the initial foothold easier for an external attacker to get remotely (e.g. a web app RCE, see the WAF note below) and makes the host easier to find in the first place -- exposed management ports (libvirt 16509/16514, Proxmox 8006) are a reconnaissance signal for that, which is what merge_and_triage.py's scoring looks for. An exposed port proves nothing by itself, though -- it only matters once something attacker-controlled can execute locally, which passive scan data can't show (see "Why passive-only" below for why this repo doesn't try to confirm that against hosts you don't own).
• An internal-only host with the same multi-user/multi-tenant exposure is equally critical -- it just needs an internal user, a contractor, or a compromised internal app to supply the foothold instead of an internet-facing one. Don't read "not internet-facing" as "lower priority."

Genuinely lower severity:

• Single-tenant, no untrusted guests, users, or apps at all -- the only "attacker" would be you, so real-world risk is much lower. Still worth patching so a future unrelated compromise can't chain into this.
• No vIOMMU -- per the advisory, the VM-escape path specifically needs a vIOMMU-enabled setup; without it, impact is likely capped at local privesc inside the kernel rather than crossing the guest/host boundary.

Does a WAF help? Not against this bug directly -- a WAF inspects HTTP(S) traffic, and this bug lives in the kernel's vhost metadata-cache path, not in request parsing. It's simply not in the exposure path for the vulnerability itself.

Where a WAF does matter is one step earlier: the most common real-world chain is web app RCE → code execution inside the guest → vhost exploit → host escape → lateral movement to every other tenant. A WAF (or other web-security controls) can block the web-app RCE that hands an attacker their initial foothold, which prevents them from ever reaching the prerequisite for this bug in the first place. So: irrelevant to the vhost bug itself, but relevant to one of the most common paths into the precondition for it.

What actually reduces risk, end to end: patching the kernel, disabling vhost offload where it's not needed, not exposing libvirt/Proxmox management ports to the internet, hardening the web apps/services running inside guests (reducing the odds of that initial RCE), and tenant-isolation hardening (seccomp, namespaces) to make any foothold harder to get.

Why passive-only, by design

Actively port-scanning or SSH-probing systems you don't own or have written authorization for is unauthorized access in most jurisdictions (in the EU, this falls under Directive 2013/40/EU implementations; Czech law covers it under § 230 trestního zákoníku) and a ToS violation for most hosts/clouds — regardless of good intent. This repo only ever reads data that third-party scanners already collected and published/sold access to under their own authorization. See SCOPE.md.

If you want to verify a specific finding (confirm a host is actually vulnerable, not just "looks exposed"), that requires the owner's permission — see the disclosure template, which asks for exactly that.

Pipeline