Descubrimiento pasivo en todo internet + asistente de divulgación responsable para CVE-2026-74580 (error de caché de metadatos de vhost en Linux): consulta datos de escaneo existentes (Sonar/Shodan/Censys), clasifica la exposición y redacta (nunca envía automáticamente) avisos a los propietarios.
Un asistente de verificación de perímetro y divulgación responsable para
CVE-2026-74580 ("Vghost") — un error real en la caché de metadatos de
vhost del kernel de Linux (registro CVE,
entrada OSV) que permite
escalada de privilegios local / escape de VM en hosts vhost/hipervisor expuestos.
Caso de uso principal: verificar tu propio perímetro. Introduce tus propios
rangos de IP, CIDR o dominios (import_list.py) — internos o externos — y
clasifícalos para detectar exposición adyacente a vhost (puertos de gestión de
libvirt/Proxmox/QEMU), y luego obtén notas de remediación para tu propio
sistema de seguimiento (run_pipeline.py --self, consulta "Verificar tu propio
perímetro" más abajo). Sin autodescubrimiento, sin búsquedas masivas de
contactos — el host ya es tuyo.
Capacidad secundaria: descubrimiento de terceros mediante datos de escaneo públicos. Este proyecto no escanea internet por sí mismo — opcionalmente puede consultar conjuntos de datos/API que ya realizaron el escaneo (Rapid7 Open Data / Sonar, Shodan, Censys) para encontrar otros hosts expuestos, y luego ayudarte a redactar avisos de divulgación a sus propietarios. Conviene saberlo antes de invertir tiempo aquí: no hay recompensa por esto (los CSIRT no pagan, y los informes de "CVE conocido, instancia sin parchear" rara vez son elegibles para recompensas — consulta "Impacto" más abajo) — es trabajo de notificación ciudadana no remunerado, y el uso real más habitual de este repositorio es el caso de verificación de perímetro anterior, no este.
CVE-2026-74580 es un error a nivel de kernel, local, no uno orientado a web/red — de ello se derivan varias cosas que importan para el triaje:
Aplicable solo si se cumplen todas estas condiciones:
vhost-net/vhost-scsi vía
QEMU/KVM, normalmente a través de libvirt o Proxmox). Un host bare-metal sin
VMs, o VMs sobre virtio simple sin offload de vhost, no está expuesto a
este error independientemente del nivel de parcheo.El verdadero factor de gravedad es quién ya tiene (o puede obtener) ejecución de código — no si el host está expuesto a internet. La exposición a internet solo afecta a la facilidad con que un atacante externo encuentra el objetivo o alcanza el punto de apoyo inicial de forma remota; no cambia nada sobre si el error es explotable una vez que alguien tiene ese punto de apoyo. La infraestructura solo interna y privada no es inherentemente de menor riesgo:
Más crítico, independientemente de la exposición a internet:
Dónde la exposición a internet realmente importa (un factor secundario, no el principal):
merge_and_triage.py. Un puerto
expuesto no prueba nada por sí mismo, sin embargo -- solo importa una vez
que algo controlado por el atacante puede ejecutarse localmente, lo que
los datos de escaneo pasivo no pueden mostrar (véase "Por qué solo
pasivo" más abajo para saber por qué este repositorio no intenta
confirmarlo contra hosts que no son tuyos).Genuinamente de menor gravedad:
¿Ayuda un WAF? No contra este fallo directamente -- un WAF inspecciona el tráfico HTTP(S), y este fallo reside en la ruta de caché de metadatos de vhost del kernel, no en el análisis de solicitudes. Simplemente no está en la ruta de exposición de la vulnerabilidad en sí.
Donde un WAF sí importa es un paso antes: la cadena del mundo real más común es RCE en aplicación web → ejecución de código dentro del invitado → exploit de vhost → escape del host → movimiento lateral a todos los demás inquilinos. Un WAF (u otros controles de seguridad web) puede bloquear el RCE de la aplicación web que proporciona al atacante su punto de apoyo inicial, lo que evita que lleguen siquiera al requisito previo de este fallo. Así que: irrelevante para el fallo de vhost en sí, pero relevante para una de las rutas hacia la precondición del mismo más comunes.