vghost-watch

Ein Helfer zur Perimeter-Prüfung und für verantwortungsvolle Offenlegung zu CVE-2026-74580 („Vghost") — einem echten Metadaten-Cache-Fehler im Linux-Kernel-vhost (CVE-Eintrag, OSV-Eintrag), der auf exponierten vhost/Hypervisor-Hosts lokale Rechteausweitung / VM-Escape ermöglicht.

Primärer Anwendungsfall: den eigenen Perimeter prüfen. Geben Sie Ihre eigenen IP-Bereiche, CIDRs oder Domains ein (import_list.py) — intern oder extern — und triagieren Sie sie auf vhost-nahe Exposition (libvirt/Proxmox/QEMU- Management-Ports), und erhalten Sie anschließend Hinweise zur Behebung für Ihren eigenen Tracker (run_pipeline.py --self, siehe „Den eigenen Perimeter prüfen" unten). Keine automatische Erkennung, keine massenhafte Kontaktsuche — der Host gehört bereits Ihnen.

Sekundäre Fähigkeit: Discovery von Drittanbietern über öffentliche Scan-Daten. Dieses Projekt scannt nicht selbst das Internet — es kann optional Datensätze/APIs abfragen, die das Scannen bereits durchgeführt haben (Rapid7 Open Data / Sonar, Shodan, Censys), um andere exponierte Hosts zu finden, und Ihnen dann helfen, Offenlegungsschreiben an deren Eigentümer zu entwerfen. Wissenswert, bevor Sie hier Zeit investieren: Für dieses Thema gibt es kein Bug-Bounty (CSIRTs zahlen nicht, und Meldungen zu „bekannte CVE, ungepatchte Instanz" sind selten bounty-berechtigt — siehe „Impact" unten) — es ist unbezahlte Benachrichtigungsarbeit als guter Bürger, und die meiste tatsächliche Nutzung dieses Repos ist der oben beschriebene Perimeter-Prüfungsfall, nicht dieser.

Impact: Wann ist dies anwendbar / kritisch?

CVE-2026-74580 ist ein Fehler auf Kernel-Ebene, lokal, kein web-/netzwerkseitiger — daraus folgen einige Dinge, die für die Triage wichtig sind:

Nur anwendbar, wenn alle folgenden Bedingungen zutreffen:

• Der Host läuft mit einem ungepatchten Linux-Kernel (unter 5.10.265, 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9 oder dem Distro-Backport).
• Er nutzt vhost-gestützte Virtualisierung (vhost-net/vhost-scsi über QEMU/KVM, typischerweise über libvirt oder Proxmox). Ein Bare-Metal-Host ohne VMs oder VMs auf reinem virtio ohne vhost-Offload ist diesem Fehler unabhängig vom Patch-Stand nicht ausgesetzt.
• Lokale Codeausführung ist Voraussetzung. Dies ist Privesc/VM-Escape, kein Remote-Code-Execution — ein Angreifer muss bereits Code ausführen, irgendwo, wo er die verwundbare Schnittstelle erreicht: eine Gast-VM, ein Container mit geteiltem Kernel oder ein lokales Konto auf dem Host. „Führt bereits Code aus" erfordert keinen direkten Zugriff wie SSH — in der Praxis ist es meist eines von:
  • Ein legitimer Mandant, auf einem Multi-Tenant-/Cloud-Hypervisor — ein Kunde, der einfach eine VM gemietet hat, verfügt darin bereits per Design über vollständige Codeausführung, ohne dass eine Kompromittierung nötig ist.
  • Eine unabhängige Kompromittierung innerhalb des Gasts — am häufigsten eine verwundbare Web-App, die RCE erleidet (ein veraltetes Plugin, SSRF-zu-RCE, ein Deserialisierungsfehler usw.), aber jede gastseitige Kompromittierung funktioniert auf dieselbe Weise. Der vhost-Fehler interessiert nicht, wie der Angreifer hineingekommen ist, sondern nur, dass er nun über Codeausführung verfügt, von der aus er pivotieren kann.

Der eigentliche Schweregrad-Treiber ist, wer bereits über Codeausführung verfügt (oder sie erlangen kann) — nicht, ob der Host aus dem Internet erreichbar ist. Internet-Exposition beeinflusst nur, wie leicht ein externer Angreifer das Ziel findet oder den ersten Fußabdruck aus der Ferne erreicht; sie ändert nichts daran, ob der Fehler ausnutzbar ist, sobald jemand diesen Fußabdruck hat. Rein interne, private Infrastruktur ist nicht grundsätzlich weniger riskant:

Am kritischsten, unabhängig von der Internet-Exposition:

• Jeder Multi-Tenant- oder Multi-User-Hypervisor – Hosting-Anbieter, aber genauso eine interne Private Cloud, eine interne VM-pro-Team- Plattform oder eine gemeinsame Dev/Test-Umgebung mit gewöhnlichen Benutzerkonten auf VMs/Apps. Jeder dieser Benutzer oder Tenants hat die Voraussetzung zur Code-Ausführung bereits, per Design, ohne dass eine Kompromittierung nötig wäre – ob internetseitig erreichbar oder nicht.
• Jeder Host, auf dem ein Angreifer bereits Fuß gefasst hat (kompromittierte VM, Insider-Shell, ein Co-Located-Container-Escape, eine kompromittierte interne App) mit aktiviertem vhost-Offload – dies verwandelt „Ich habe eine Shell mit geringen Rechten" in „Ich besitze den Host", unabhängig davon, wie diese Shell erlangt wurde.

Wo Internet-Exposition tatsächlich eine Rolle spielt (ein sekundärer Faktor, nicht der primäre):

• Sie erleichtert es einem externen Angreifer, den initialen Fußabdruck remote zu erlangen (z. B. eine Web-App-RCE, siehe die WAF-Anmerkung unten), und macht den Host überhaupt erst leichter auffindbar – exponierte Management- Ports (libvirt 16509/16514, Proxmox 8006) sind dafür ein Reconnaissance- Signal, wonach das Scoring von merge_and_triage.py sucht. Ein exponierter Port beweist für sich genommen jedoch nichts – er ist erst dann relevant, wenn etwas Angreiferkontrolliertes lokal ausgeführt werden kann, was passive Scan-Daten nicht zeigen können (siehe „Warum nur passiv" unten, warum dieses Repo nicht versucht, das gegen Hosts zu bestätigen, die Ihnen nicht gehören).
• Ein rein interner Host mit derselben Multi-User-/Multi-Tenant- Exposition ist gleichermaßen kritisch – er benötigt lediglich einen internen Benutzer, einen Auftragnehmer oder eine kompromittierte interne App, um den Fußabdruck zu liefern, statt eines internetseitig erreichbaren. Lesen Sie „nicht internetseitig erreichbar" nicht als „niedrigere Priorität".

Wirklich geringere Schwere:

• Single-Tenant, überhaupt keine nicht vertrauenswürdigen Gäste, Benutzer oder Apps – der einzige „Angreifer" wären Sie selbst, sodass das reale Risiko deutlich geringer ist. Dennoch lohnt sich das Patchen, damit eine künftige unabhängige Kompromittierung nicht in dieses Problem verkettet werden kann.
• Kein vIOMMU – laut Advisory benötigt der VM-Escape-Pfad speziell ein vIOMMU-fähiges Setup; ohne dieses ist die Auswirkung wahrscheinlich auf lokale Rechteausweitung innerhalb des Kernels begrenzt, statt die Gast-/Host-Grenze zu überschreiten.

Hilft eine WAF? Nicht direkt gegen diesen Bug – eine WAF inspiziert HTTP(S)-Traffic, und dieser Bug liegt im vhost-Metadaten-Cache-Pfad des Kernels, nicht im Request-Parsing. Er liegt schlicht nicht im Expositionspfad für die Schwachstelle selbst.

Wo eine WAF doch relevant ist, ist einen Schritt früher: Die häufigste reale Kette ist Web-App-RCE → Code-Ausführung innerhalb des Gasts → vhost-Exploit → Host-Escape → laterale Bewegung zu jedem anderen Tenant. Eine WAF (oder andere Web-Sicherheitskontrollen) kann die Web-App-RCE blockieren, die einem Angreifer den initialen Fußabdruck verschafft, was verhindert, dass er jemals die Voraussetzung für diesen Bug erreicht. Also: irrelevant für den vhost- Bug selbst, aber relevant für einen der häufigsten Wege in die Voraussetzung dafür.