КИБЕРБЕЗОПАСНОСТЬ

Januscape: 16-летняя брешь в Linux открыла выход из виртуальной машины

16-летняя уязвимость Januscape в Linux позволяет выйти из виртуальной машины и выполнить код на хосте, создавая риск для KVM и облаков.

✍️ Редакция iTech News | 08.07.2026 | ⏱ 4 мин | Источник: BleepingComputer
💀

В Linux закрыли уязвимость Januscape, которая прожила в ядре около 16 лет и позволяет атакующему выйти из гостевой виртуальной машины на хост. Для команд, которые держат KVM-инфраструктуру или арендуют мощности в публичных облаках, это не академическая история про «где-то там в ядре», а прямой риск компрометации сервера и соседних VM.

О проблеме CVE-2026-53359 сообщает BleepingComputer. По данным издания, баг нашел исследователь Hyunwoo Kim: он связан с use-after-free в механизме shadow MMU emulation в KVM/x86, то есть в штатной подсистеме виртуализации Linux для архитектур x86 и x86_64. Уязвимость существовала примерно 16 лет, а исправление попало в ядро только в июне 2026 года. При успешной эксплуатации атакующий, уже имеющий root-доступ внутри гостевой VM, может выполнить произвольный код на хосте с привилегиями root.

Практический смысл у этого бага неприятно прост. Если злоумышленник арендует всего один инстанс в публичном облаке и получает root внутри гостевой машины, дальше он теоретически может атаковать физический сервер, на котором эта VM запущена. В худшем сценарии это уже не проблема одного клиента: компрометированным оказывается хост и все виртуальные машины на нем. Более «мягкий» сценарий тоже мало кого порадует: исследователь показал, что через Januscape можно уронить хостовое ядро и положить остальные VM на этом же сервере. Для многоарендных сред это звучит ровно так плохо, как и должно.

Kim отдельно подчеркивает деталь, из-за которой уязвимость Januscape выглядит особенно заметной на фоне привычных багов в виртуализации: эксплойт срабатывает и на Intel, и на AMD. Обычно истории про guest-to-host escape чаще упираются в одну платформу или конкретную реализацию. Здесь речь идет о более универсальной поверхности атаки в KVM/x86. Именно поэтому исследователь называет Januscape первым guest-to-host-эксплойтом такого типа, который можно триггерить на обеих архитектурах, а главной зоной риска считает публичные облака с многоарендной моделью, включая инфраструктуры уровня Google Cloud и Amazon Web Services.

Есть и еще одна неприятная развилка. На некоторых дистрибутивах Linux, в частности на Red Hat Enterprise Linux, устройство /dev/kvm может быть доступно на запись всем пользователям. В такой конфигурации, как отмечается в материале, даже непривилегированный локальный атакующий на непатченной системе способен надежно поднять себе права до root. То есть уязвимость бьет не только по классическому облачному сценарию «гость выходит на хост», но и по локальным инсталляциям, где KVM доступен слишком щедро. Для администраторов это напоминание о том, что права на /dev/kvm и вообще модель доступа к виртуализации давно пора считать частью базовой поверхности атаки, а не «внутренней технической деталью».

Технические детали у истории тоже показательные. Исследователь опубликовал подробный разбор и proof-of-concept, который вызывает панику ядра на хосте, но полноценный эксплойт для выхода из гостя на хост обещает пока не выкладывать. Это стандартный, но разумный компромисс: артефактов достаточно, чтобы сообщество и вендоры могли проверить проблему и подтвердить риск, но недостаточно, чтобы раздавать готовый инструментарий для моментального массового abuse. При этом иллюзий быть не должно: если опубликован технический разбор и демонстрация, окно для спокойного «обновим как-нибудь потом» быстро закрывается.

Что делать на практике, тоже сформулировано довольно прямо. Администраторам KVM/x86-хостов, особенно тех, где крутятся multi-tenant-нагрузки, нужно проверить, применен ли в хостовом ядре патч с коммитом 81ccda30b4e8. Ключевое слово здесь именно «в хостовом». Если смотреть на проблему глазами обычной инфраструктурной рутины, велик соблазн сосредоточиться на гостевых образах, агенте, hardening внутри VM и EDR. Но Januscape ломает эту логику: даже идеально вылизанный guest не поможет, если уязвим слой виртуализации под ним. Для облачных провайдеров и частных платформ это еще один аргумент в пользу ускоренного цикла обновления гипервизорных узлов и более жесткой сегментации workloads по уровню доверия.

Контекст у находки тоже не из приятных. Это уже не первая заметная Linux-уязвимость, которую Hyunwoo Kim раскрывает в 2026 году. В мае он рассказал о цепочке Dirty Frag, где комбинировались баги CVE-2026-43284 и CVE-2026-43500 для локального повышения привилегий на крупных дистрибутивах, включая Ubuntu, RHEL, CentOS Stream и Fedora. Самое важное здесь не набор названий, а возможность комбинировать такие ошибки: если у атакующего изначально нет root-доступа внутри целевой VM или хоста, цепочка локального privesc плюс уязвимость Januscape уже дает сценарий полной компрометации. И вот это для ИБ-команд особенно неприятно: граница между «локальная проблема внутри инстанса» и «захват физического узла» становится куда тоньше, чем хотелось бы.

Для разработчиков, платформенных инженеров и IT-руководителей вывод довольно приземленный. Виртуализация долго воспринималась как надежная стенка между арендаторами, командами и средами. Januscape показывает, что эта стенка по-прежнему держится не на магии, а на качестве кода в ядре и скорости патч-менеджмента. Если баг, способный перевести root в госте в root на хосте, живет 16 лет, значит главный дефицит здесь не в новых угрозах, а в дисциплине проверки старых слоев стека. Подробности исследования и демонстрацию можно посмотреть в материале BleepingComputer.

Поделиться: Telegram X LinkedIn