Две уязвимости Xen позволяют злоумышленнику из одной гостевой виртуальной машины читать и изменять память любой другой ВМ на том же хосте — включая управляющий домен dom0. Для команд, которые используют Xen в облаке, VDI или изолированных рабочих средах, это означает, что граница между арендаторами может исчезнуть из-за одного скомпрометированного гостя.
Проблемы получили идентификаторы CVE-2026-102703 и CVE-2026-102704 и описаны в бюллетене XSA-523, сообщает The Hacker News. Xen Project выпустил исправления 3 ноября и прямо указал: известного способа снизить риск без установки обновления нет. Затронуты все версии Xen, начиная с 4.6; ветки 4.5 и старше этой ошибке не подвержены.
Уязвимости находятся в механизме grant copy — операции, через которую Xen копирует данные между виртуальными машинами. В нормальной схеме гость явно предоставляет доступ к определённым страницам своей памяти, а гипервизор проверяет права перед копированием. Чтобы не тратить ресурсы на повторяющиеся проверки при серии операций в пределах одной страницы, Xen переиспользует уже полученный результат. В отдельных сценариях повторная проверка должна была произойти, но её не было. Этого достаточно, чтобы вредоносная ВМ получила доступ к памяти, на которую ей никто не выдавал разрешения.
Самая неприятная часть истории — dom0. Это привилегированная виртуальная машина, которая по умолчанию управляет остальными доменами и имеет широкие права на хосте. Если атакующий может читать или менять её память, речь идёт уже не о локальном нарушении изоляции, а о потенциальном захвате всей платформы виртуализации. Проект XCP-ng, построенный вокруг Xen, в примечаниях к обновлению описал эффект без дипломатии: один скомпрометированный гость способен выйти из собственной изоляции и завладеть хостом.
Публичных сведений об эксплуатации пока нет. Xen Project также не уточнил, какой именно уровень доступа внутри гостевой системы потребуется атакующему. Это не повод откладывать работы: в подобных случаях отсутствие готового публичного эксплойта лишь даёт защитникам короткий запас времени. Особенно это касается хостов, где гостевые ВМ принадлежат разным командам, клиентам или средам разработки: модель доверия «гость не может повлиять на соседа» здесь оказывается под вопросом.
Исправления доступны не для всех поколений Xen. Патчи опубликованы для xen-unstable, ветки 4.19.x и веток с 4.18.x до 4.17.x. Для Xen 4.6–4.16 исправлений в XSA-523 нет; поддержка безопасности Xen 4.16 закончилась 2 декабря 2024 года. Это делает инвентаризацию особенно важной: организация может обнаружить не просто отложенный патч, а платформу, для которой штатного обновления уже не будет. В таком случае придётся планировать обновление версии Xen, а не искать точечный пакет.
У XCP-ng 8.3 исправление вышло 3 ноября в пакете xen-4.17.7-4.2.xcpng8.3, и для его применения требуется перезагрузка хоста. Компания Vates, поддерживающая XCP-ng, оценила серьёзность как критическую. В Qubes OS, где Xen используется для разделения приложений по отдельным qubes, затронуты все поддерживаемые релизы и конфигурации. Для поддерживаемой Qubes 4.3 подготовлены пакеты Xen 4.19.6-3: нужно перезапустить dom0, а пользователям Anti Evil Maid — заново запечатать секретную парольную фразу, поскольку новые бинарные файлы Xen меняют значения PCR18 и PCR19.
По состоянию на 4 ноября Debian помечал пакеты xen в bookworm, trixie и forky как уязвимые; в sid исправление уже было доступно. Это полезное напоминание для российских команд, которые держат Xen не только в явном виде. Гипервизор может быть частью платформы виртуализации, внутреннего облака, защищённой рабочей станции или готового appliance, а обновление часто проходит через поставщика дистрибутива, а не через прямую установку Xen.
Администраторам стоит начать с простой, но не всегда приятной проверки: определить версии Xen на всех хостах, сверить их с XSA-523, получить обновления от поставщика платформы и запланировать контролируемую перезагрузку. Заодно имеет смысл пересмотреть, какие гостевые ВМ допускают запуск недоверенного кода и какие из них имеют сетевой или административный доступ к критичным сервисам. Уязвимости Xen не отменяют сегментацию и контроль доступа внутри гостя, но делают их недостаточной страховкой от выхода за пределы ВМ.
Это уже второй раскрытый в 2026 году дефект в grant copy: предыдущий, XSA-500, Xen Project опубликовал 28 июля, и для него выпустили отдельные патчи. Новую проблему обнаружили с помощью модели Claude компании Anthropic, затем находку проверил Стефан Липп из Ada Logics, а команда CodeAnt AI Security Research Team независимо сообщила о той же ошибке. Для индустрии здесь важны оба сигнала: уязвимости Xen требуют срочного операционного ответа, а AI-инструменты всё заметнее становятся источником реальных результатов в аудите низкоуровневого системного кода.
