vghost-watch

Помощник для проверки периметра и ответственного раскрытия информации о CVE-2026-74580 («Vghost») — реальной ошибке кэша метаданных vhost в ядре Linux (запись CVE, запись OSV), которая даёт локальное повышение привилегий / побег из VM на уязвимых хостах с vhost/гипервизором.

Основной сценарий использования: проверка собственного периметра. Передайте свои IP-диапазоны, CIDR или домены (import_list.py) — внутренние или внешние — и проведите их триаж на предмет экспозиции, связанной с vhost (порты управления libvirt/Proxmox/QEMU), а затем получите заметки по устранению для своего трекера (run_pipeline.py --self, см. «Проверка собственного периметра» ниже). Без автообнаружения, без массового поиска контактов — хост уже принадлежит вам.

Дополнительная возможность: обнаружение сторонних хостов через публичные данные сканирования. Этот проект не сканирует интернет самостоятельно — он может опционально запрашивать наборы данных/API, которые уже выполнили сканирование (Rapid7 Open Data / Sonar, Shodan, Censys), чтобы найти другие открытые хосты, а затем помочь вам составить уведомления о раскрытии их владельцам. Стоит знать до того, как вы потратите на это время: за это не платят вознаграждение (CSIRT не платят, а отчёты вида «известная CVE, непропатченный экземпляр» редко подходят под программы вознаграждений — см. «Влияние» ниже) — это неоплачиваемая работа добросовестного уведомления, и большая часть реального использования этого репозитория — это сценарий проверки периметра выше, а не этот.

Влияние: когда это применимо / критично?

CVE-2026-74580 — это ошибка уровня ядра, локальная, а не сетевая/веб-ориентированная — из этого следует несколько вещей, важных для триажа:

Применимо только если выполняются все условия:

• Хост работает на непропатченном ядре Linux (ниже 5.10.265, 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9 или бэкпорта дистрибутива).
• Используется виртуализация на базе vhost (vhost-net/vhost-scsi через QEMU/KVM, обычно через libvirt или Proxmox). Хост на голом железе без VM или VM на чистом virtio без vhost-разгрузки не подвержены этой ошибке независимо от уровня патчей.
• Локальное выполнение кода — обязательное условие. Это повышение привилегий/побег из VM, а не удалённое выполнение кода — атакующему нужно уже выполнять код где-то, откуда доступен уязвимый интерфейс: гостевая VM, контейнер с общим ядром или локальная учётная запись на хосте. «Уже выполняющийся код» не требует прямого доступа вроде SSH — на практике это чаще всего одно из:
  • Легитимный арендатор на мультитенантном/облачном гипервизоре — клиент, который просто арендовал VM, уже имеет полное выполнение кода внутри неё по замыслу, без всякого взлома.
  • Несвязанная компрометация внутри гостя — чаще всего уязвимое веб-приложение, на котором получен RCE (устаревший плагин, SSRF-to-RCE, ошибка десериализации и т. п.), но любая компрометация на стороне гостя работает так же. Ошибке vhost неважно, как атакующий попал внутрь, — важно лишь, что у него теперь есть выполнение кода для дальнейшего развития атаки.

Реальную серьёзность определяет то, у кого уже есть (или может появиться) выполнение кода, — а не то, обращён ли хост в интернет. Экспозиция в интернете влияет лишь на то, насколько легко внешний атакующий найдёт цель или удалённо получит начальную точку опоры; это никак не меняет того, эксплуатируема ли ошибка, когда у кого-то уже есть эта точка опоры. Внутренняя, частная инфраструктура не является по своей природе менее рискованной:

Наиболее критично, независимо от доступности из интернета:

• Любой многопользовательский или мультитенантный гипервизор — хостинг-провайдеры, но в равной степени и внутреннее частное облако, внутренняя платформа «одна VM на команду» или общая среда разработки/тестирования с обычными пользовательскими учётными записями на VM/приложениях. У каждого из этих пользователей или тенантов уже есть предпосылка для выполнения кода — по замыслу, без какого-либо взлома — доступен он из интернета или нет.
• Любой хост, где у атакующего уже есть точка опоры (скомпрометированная VM, инсайдерский shell, побег из соседнего контейнера, скомпрометированное внутреннее приложение) при использовании vhost offload — это превращает «у меня есть shell с низкими привилегиями» в «я владею хостом», независимо от того, как этот shell был получен.

Где доступность из интернета действительно имеет значение (вторичный фактор, а не основной):

• Она облегчает внешнему атакующему получение первоначальной точки опоры удалённо (например, RCE в веб-приложении, см. примечание о WAF ниже) и делает хост проще найти в принципе — открытые порты управления (libvirt 16509/16514, Proxmox 8006) служат для этого сигналом разведки, и именно это ищет скоринг в merge_and_triage.py. Открытый порт сам по себе ничего не доказывает — он важен только когда что-то контролируемое атакующим может выполняться локально, а данные пассивного сканирования этого показать не могут (см. «Почему только пассивно» ниже — почему этот репозиторий не пытается подтвердить это на хостах, которыми вы не владеете).
• Внутренний хост с той же многопользовательской/мультитенантной экспозицией столь же критичен — ему просто нужен внутренний пользователь, подрядчик или скомпрометированное внутреннее приложение, чтобы обеспечить точку опоры вместо доступного из интернета. Не воспринимайте «не доступен из интернета» как «низкий приоритет».

Действительно более низкая серьёзность:

• Один тенант, вообще нет недоверенных гостей, пользователей или приложений — единственным «атакующим» были бы вы сами, поэтому реальный риск гораздо ниже. Всё равно стоит пропатчить, чтобы будущая несвязанная компрометация не могла выстроиться в цепочку с этим.
• Нет vIOMMU — согласно рекомендации, путь побега из VM конкретно требует конфигурации с включённым vIOMMU; без него воздействие, вероятно, ограничивается локальным повышением привилегий внутри ядра, а не пересечением границы гость/хост.

Помогает ли WAF? Не против этой уязвимости напрямую — WAF инспектирует трафик HTTP(S), а эта уязвимость живёт в пути кэша метаданных vhost в ядре, а не в разборе запросов. Она просто не находится в пути экспозиции для самой уязвимости.

Где WAF действительно важен — это на шаг раньше: наиболее распространённая в реальном мире цепочка — это RCE в веб-приложении → выполнение кода внутри гостя → эксплойт vhost → побег на хост → боковое перемещение ко всем остальным тенантам. WAF (или другие средства веб-безопасности) может заблокировать RCE в веб-приложении, который даёт атакующему первоначальную точку опоры, что не позволяет ему вообще достичь предпосылки для этой уязвимости. Итак: не имеет отношения к самой уязвимости vhost, но имеет отношение к одному из наиболее распространённых путей к предпосылке для неё.

Что действительно снижает риск, от начала до конца: патчинг ядра, отключение vhost offload там, где он не нужен, недопущение открытия портов управления libvirt/Proxmox в интернет, укрепление веб-приложений/сервисов, работающих внутри гостей (снижение вероятности того первоначального RCE), и укрепление изоляции тенантов (seccomp, namespaces), чтобы любую точку опоры было сложнее получить.

Почему только пассивно, по замыслу