Исследователи Nebula Security рассказали об уязвимости GhostLock, которая получила идентификатор CVE-2026-43499 и затрагивает ядро Linux. Проблема оказалась особенно серьезной, потому что позволяет непривилегированному локальному пользователю повысить права до root и выполнить побег из контейнера на хостовую систему. Фактически это означает, что обычный пользователь или процесс внутри контейнера может превратиться в администратора всей системы, если сервер работает на уязвимом ядре.
Опасность GhostLock усиливается тем, что ошибка присутствовала в ядре Linux с 2011 года. Она появилась еще в Linux 2.6.39 после переработки подсистемы rtmutex, которая отвечает за блокировки с наследованием приоритетов. За прошедшие годы уязвимый код попал во множество веток ядра и затронул основные дистрибутивы Linux. Поэтому речь идет не о редкой проблеме в узком компоненте, а о давней ошибке в базовой части операционной системы.
Для кибербезопасности это важный пример того, что критические уязвимости могут годами оставаться в фундаментальном коде, который используется миллионами систем. Linux считается зрелой и хорошо изученной платформой, но даже в ней могут сохраняться сложные ошибки синхронизации, которые трудно заметить обычным аудитом. Чем глубже ошибка находится в ядре, тем серьезнее последствия после ее обнаружения.
GhostLock относится к локальным уязвимостям повышения привилегий. Это значит, что атакующему уже нужен некоторый доступ к системе: например, учетная запись обычного пользователя, выполнение кода через веб-приложение, компрометация контейнера, вредоносный процесс или результат другой атаки. Но после этого CVE-2026-43499 может стать вторым этапом, который позволяет получить root-права и полностью контролировать сервер.
Такой сценарий часто встречается в реальных атаках. Злоумышленник сначала попадает в систему через уязвимое приложение, украденные учетные данные, фишинг, небезопасный контейнер или ошибку в веб-сервисе. На этом этапе его права могут быть ограничены. Но если в ядре есть локальная уязвимость повышения привилегий, атакующий может быстро выйти из ограниченного режима, отключить защиту, читать любые файлы, устанавливать бэкдоры и двигаться дальше по сети.
Технически проблема связана с функцией remove_waiter(), которая удаляет ожидающий поток из очереди блокировки и сбрасывает связанное с ним состояние. Ошибка проявляется при откате операции futex_requeue() после обнаружения дедлока. В этот момент код должен работать с waiter «спящего» потока, но вместо этого по ошибке обращается к текущей задаче. В результате в структуре спящего потока остается указатель на объект waiter, расположенный в стеке ядра.
Когда поток возвращается в userspace, участок стека ядра, на который все еще указывает старая ссылка, уже может быть переиспользован. Это приводит к use-after-free — классу ошибок, при котором программа продолжает обращаться к объекту после того, как он уже считается освобожденным или недействительным. В ядре такие ошибки особенно опасны, потому что неверная ссылка может дать возможность вмешаться в выполнение кода на самом привилегированном уровне системы.
Use-after-free в ядре — это не просто сбой или падение процесса. Если атакующий умеет контролировать повторное использование памяти, он может превратить ошибку в выполнение произвольного кода. В случае GhostLock исследователи смогли добиться контроля над выполнением в ядре и получить root-права. Это показывает, что баг не является теоретической проблемой: для него уже существует рабочий эксплойт.
По данным исследователей, разработанный эксплойт срабатывал в 97% случаев и занимал около пяти секунд. Для атаки не требовались дополнительные привилегии, нестандартные настройки ядра или сетевой доступ. Это делает уязвимость особенно неприятной для серверов, где локальное выполнение кода может получить даже ограниченный пользователь, контейнеризированное приложение или сервис с минимальными правами.
Отдельно важно, что GhostLock позволяет выполнить побег из контейнера. Контейнеры часто воспринимаются как безопасная изоляция, но они используют общее ядро хостовой системы. Если внутри контейнера есть возможность эксплуатировать уязвимость ядра, граница между контейнером и хостом может быть нарушена. В таком случае атакующий выходит из ограниченной среды и получает доступ к самой системе, где запущены другие контейнеры и сервисы.
Для Kubernetes, Docker, контейнерных хостов, CI/CD-платформ и облачных сред это особенно опасно. Внутри контейнера может работать приложение с низкими правами, но если оно способно вызвать уязвимый код ядра, безопасность всей ноды оказывается под вопросом. Атака на один контейнер может привести к компрометации хоста, соседних контейнеров, секретов, томов, сервисных токенов и внутренней сети кластера.
Это напоминает важный принцип контейнерной безопасности: контейнер — не виртуальная машина. Он не имеет собственного отдельного ядра, а разделяет ядро с хостом. Поэтому обновление ядра хоста, ограничение системных вызовов, seccomp-профили, AppArmor, SELinux, user namespaces и минимальные привилегии контейнера имеют ключевое значение. Если хост работает на уязвимом ядре, изоляция контейнеров может оказаться недостаточной.
GhostLock также опасен для multi-tenant-сред, где на одном сервере работают приложения разных пользователей или клиентов. Если один пользователь получает возможность выполнить локальный код и поднять права до root, он может поставить под угрозу данные других пользователей. Поэтому хостинг-провайдеры, облачные платформы, CI-сервисы и корпоративные кластеры должны относиться к таким уязвимостям как к критическим, даже если они формально «локальные».
Исследователи получили за демонстрацию атаки вознаграждение в размере 92 337 долларов США в рамках программы bug bounty kernelCTF от Google. Это крупная сумма, которая отражает серьезность уязвимости и ценность рабочего эксплойта. kernelCTF предназначена для поиска и демонстрации реальных проблем в ядре, а успешная эксплуатация GhostLock показала, что баг можно использовать не только для краша, но и для практического повышения привилегий.
Интересно, что уязвимость помог обнаружить ИИ-инструмент VEGA, разработанный Nebula Security. Это еще один пример того, как ИИ начинает менять поиск уязвимостей в сложном системном коде. Ошибки синхронизации, состояния гонки, неверные ссылки и use-after-free в ядре трудно находить вручную, потому что они зависят от редких последовательностей событий. Автоматизированный анализ может помогать исследователям замечать такие цепочки быстрее.
Но роль ИИ здесь не стоит понимать как полную замену экспертов. Инструмент может подсказать подозрительный участок, найти необычный паттерн или помочь проверить гипотезу, но превращение бага в надежный эксплойт требует глубокого понимания ядра, памяти, планировщика, синхронизации и механизмов защиты. В случае GhostLock важна именно комбинация автоматизированного поиска и человеческой экспертизы.
Исправление для GhostLock было включено в ядро Linux еще в апреле 2026 года. Однако администраторам рекомендуют устанавливать не первый пропатченный билд, а самое свежее доступное ядро из своей ветки. Причина в том, что первоначальный патч привел к появлению отдельной проблемы CVE-2026-53166, которая могла вызывать сбои в работе системы. Это важный практический момент: иногда первое исправление закрывает одну угрозу, но приносит новую ошибку стабильности.
Поэтому правильная стратегия обновления — не просто найти «любой патч после апреля», а поставить актуальное ядро, которое включает как исправление GhostLock, так и последующие корректировки. Для продакшн-серверов это особенно важно. Администратор должен проверить рекомендации своего дистрибутива, изучить changelog, протестировать обновление на совместимость и затем развернуть его на рабочих системах.
Альтернативных решений для полной защиты от GhostLock нет. Некоторые параметры сборки ядра, включая RANDOMIZE_KSTACK_OFFSET и STATIC_USERMODE_HELPER, могут усложнить эксплуатацию, но не устраняют саму уязвимость. Это значит, что компенсирующие меры полезны, но не заменяют обновление. Если ядро уязвимо, атакующий может адаптировать эксплойт под конкретные условия, особенно если у него есть время и доступ к локальному выполнению кода.
RANDOMIZE_KSTACK_OFFSET помогает усложнять предсказание расположения данных в стеке ядра, а STATIC_USERMODE_HELPER ограничивает некоторые механизмы запуска пользовательских помощников из ядра. Но такие настройки не меняют корневую причину ошибки в обработке waiter и remove_waiter(). Они повышают стоимость атаки, но не дают гарантии, что эксплуатация невозможна. Для критической LPE-уязвимости это слишком слабая защита.
Администраторам Linux-систем первым делом нужно определить версии ядра на всех серверах, рабочих станциях, контейнерных хостах и виртуальных машинах. Особенно важно проверить системы, где есть локальные пользователи, веб-приложения, контейнеры, Kubernetes-ноды, CI/CD-раннеры, терминальные серверы и shared hosting. Если на хосте возможно выполнение кода не полностью доверенным пользователем, риск GhostLock становится намного выше.
После инвентаризации нужно установить актуальные обновления ядра из официальных репозиториев дистрибутива. Для Debian, Ubuntu, Red Hat, AlmaLinux, Rocky Linux, Fedora, SUSE, Arch и других систем процесс будет отличаться, но общий принцип один: использовать исправления от поставщика, а не случайные патчи из интернета. В корпоративной среде также нужно проверить совместимость с драйверами, модулями, средствами защиты, контейнерной платформой и виртуализацией.
Важно помнить, что обновление ядра обычно требует перезагрузки. На серверах это часто откладывают, потому что администраторы не хотят останавливать сервисы. Но если патч установлен, а система не перезагружена, старое уязвимое ядро продолжает работать. Поэтому после установки обновления нужно убедиться, что сервер действительно загрузился с новой версией, а не просто получил пакет в файловую систему.
Для Kubernetes и контейнерных платформ обновление хостового ядра требует планирования. Ноды нужно выводить из кластера, переносить нагрузки, обновлять и возвращать обратно. Это сложнее, чем обновить один сервер, но откладывать такой патч опасно. Если в кластере есть workload от разных команд, внешние контейнеры, CI-задачи или приложения с большим количеством зависимостей, вероятность локального выполнения кода внутри контейнера достаточно высока.
CI/CD-раннеры заслуживают отдельного внимания. Они часто запускают чужой или полу-доверенный код: тесты, сборки, скрипты, pull request, контейнеры и зависимости. Если раннер работает на уязвимом Linux-ядре, атакующий может попытаться использовать GhostLock из сборочного задания, выйти на хост, украсть секреты CI, токены репозиториев, ключи деплоя и доступы к облаку. Поэтому раннеры должны обновляться в одном из первых приоритетов.
Shared hosting и серверы с несколькими локальными пользователями также находятся в зоне риска. Если разные клиенты или сотрудники имеют shell-доступ к одной системе, локальная уязвимость повышения привилегий может разрушить модель разделения. Один пользователь может получить root и прочитать чужие файлы, базы данных, конфигурации и ключи. Для провайдеров это не просто техническая проблема, а риск массового нарушения доверия клиентов.
Для рабочих станций Linux GhostLock тоже опасен, особенно если пользователь открывает недоверенные файлы, запускает контейнеры, использует браузер, устанавливает пакеты или работает с внешним кодом. В связке с браузерной уязвимостью локальное повышение привилегий может превратить компрометацию одного приложения в полный контроль над системой. Поэтому обновлять ядро нужно не только на серверах, но и на пользовательских машинах.
Именно такая связка была продемонстрирована Nebula Security в цепочке IonStack. На первом этапе атака использовала CVE-2026-10702 в JIT-движке Firefox, а затем GhostLock применялся для получения root-доступа в ядре Linux. В результате исследователи показали полный сценарий компрометации Android: от перехода по вредоносной ссылке до полного захвата системы. Это показывает, что локальная уязвимость может быть частью удаленной цепочки, если ее соединить с ошибкой в браузере.
Связанная уязвимость CVE-2026-10702 была исправлена в Firefox 151.0.3. Поэтому защита от подобных цепочек требует обновления не только ядра, но и браузеров. Если браузер остается уязвимым, злоумышленник может получить первичное выполнение кода. Если ядро тоже уязвимо, следующий этап дает root. Если обновить только один компонент, но оставить другой, часть риска сохраняется.
Для Android-среды вывод особенно важен. Android использует ядро Linux, а браузер является одним из главных каналов удаленной атаки. Если в цепочке есть JIT-уязвимость и локальное повышение привилегий в ядре, пользователь может быть скомпрометирован после перехода по вредоносной ссылке. Поэтому обновления безопасности Android, браузера и системных компонентов нужно устанавливать быстро, а не откладывать на месяцы.
Для защитников важно понимать, что GhostLock сам по себе не является удаленной уязвимостью, но в составе цепочки он может давать эффект удаленного полного захвата. Это типичная логика современных атак: одна ошибка дает выполнение кода в ограниченной среде, другая снимает ограничения, третья обеспечивает закрепление или обход песочницы. Поэтому оценивать CVE нужно не только по отдельности, но и по тому, как они могут комбинироваться.
Мониторинг эксплуатации GhostLock может быть сложным. Локальные LPE-эксплойты часто работают быстро, оставляют мало явных сетевых следов и могут выполняться до того, как EDR или SIEM успеют заметить подозрительность. Тем не менее полезно отслеживать необычные падения ядра, попытки эксплуатации futex, неожиданные root-shell, запуск неизвестных бинарных файлов пользователями с низкими правами, странные изменения в системных файлах и внезапное повышение привилегий процессов.
Для контейнерных сред нужно дополнительно отслеживать попытки выхода за пределы контейнера: необычные обращения к namespace, cgroups, mount, procfs, sysfs, загрузку модулей, доступ к сокетам Docker или containerd, появление процессов на хосте, связанных с контейнером, и попытки чтения секретов кластера. Если после запуска контейнера на хосте появляются подозрительные процессы с root-правами, это должно немедленно проверяться.
Seccomp, AppArmor и SELinux могут снизить вероятность успешной эксплуатации или последствия атаки, но не заменяют патч. Seccomp позволяет ограничить набор системных вызовов, доступных контейнеру или процессу. AppArmor и SELinux задают политики доступа. User namespaces могут уменьшить последствия root внутри контейнера. Но если уязвимость находится в ядре, всегда остается риск обхода ограничений через другой путь, особенно при наличии рабочего эксплойта.
Для облачных провайдеров и крупных организаций важны live patching и ускоренный цикл обновления ядра. Технологии live patching могут закрывать часть уязвимостей без перезагрузки, но применимы не всегда и зависят от поставщика. Если live patch недоступен или не закрывает конкретную проблему полностью, перезагрузка остается обязательной. Плановая доступность сервисов не должна превращаться в постоянное откладывание критических kernel-патчей.
После обновления стоит проверить, не осталось ли старых ядер в загрузчике как вариант по умолчанию. Иногда пакет нового ядра установлен, но система загружается в старую версию из-за настроек GRUB, проблем с модулем или ручного выбора. Нужно использовать команды проверки текущего ядра, сравнить его с исправленной версией дистрибутива и убедиться, что все ноды кластера действительно обновлены.
Также важно удалить или ограничить доступ к старым образам контейнерных хостов, виртуальным шаблонам и golden images, где осталось уязвимое ядро. Если команда обновила текущие серверы, но новые машины продолжают разворачиваться из старого образа, проблема будет возвращаться снова. Управление образами должно быть частью патч-менеджмента, особенно в облаке и Kubernetes.
Для компаний с регламентированными средами стоит провести оценку рисков и зафиксировать сроки обновления. GhostLock затрагивает фундаментальный компонент системы, поэтому отсрочка должна быть обоснована технически, а не привычкой. Если обновление невозможно сразу, нужно временно ограничить локальный доступ, остановить запуск недоверенных контейнеров, усилить мониторинг, проверить настройки seccomp и AppArmor, а также изолировать наиболее рискованные сервисы.
Но главная рекомендация остается неизменной: установить свежее ядро. Если на системе есть непривилегированные пользователи, контейнеры или приложения с возможностью локального выполнения кода, откладывание патча создает прямой риск получения root. Особенно опасно оставлять уязвимыми интернет-сервисы, где эксплуатация веб-приложения может быстро перейти в эксплуатацию ядра.
Для разработчиков дистрибутивов и мейнтейнеров этот случай показывает важность аккуратного исправления сложных синхронизационных ошибок. Первый патч привел к новой проблеме CVE-2026-53166, что говорит о сложности ядра и необходимости глубокого тестирования. Исправления в низкоуровневом коде могут иметь неожиданные побочные эффекты, особенно когда они касаются futex, блокировок, очередей ожидания и многопоточности.
Для организаций это означает, что обновления ядра нужно тестировать, но не бесконечно задерживать. Лучше иметь быстрый staging-контур, где проверяются основные сервисы, драйверы и нагрузки, чем ждать недели на продакшене. Критические kernel-LPE уязвимости требуют ускоренного процесса: тест, плановое окно, обновление, перезагрузка, проверка, мониторинг. Без такого процесса каждый новый баг ядра превращается в кризис.
GhostLock также показывает, что bug bounty и публичные исследовательские программы реально улучшают безопасность. Исследователи нашли давнюю ошибку, подготовили эксплойт, получили вознаграждение, а уязвимость была исправлена. Это лучше, чем ситуация, когда такой баг первым находит преступная группа и использует его в закрытых атаках годами. Но после раскрытия информации ответственность переходит к администраторам: патч нужно действительно установить.
Для обычных пользователей Linux выводы проще. Нужно обновить систему через штатный менеджер пакетов, установить актуальное ядро, перезагрузить компьютер и обновить браузер Firefox как минимум до версии, где закрыта связанная JIT-уязвимость. Если используются контейнеры Docker или Podman, важно обновить именно хостовую систему, а не только образы контейнеров. Контейнер не исправит уязвимое ядро хоста.
Для серверов с публичными веб-приложениями стоит проверить, нет ли признаков уже состоявшейся компрометации. Если до обновления на сервере была уязвимость в приложении, атакующий мог использовать ее для локального запуска кода, а затем применить GhostLock. Нужно смотреть неизвестные root-процессы, новые SSH-ключи, изменения в sudoers, cron-задачи, системные службы, подозрительные файлы в /tmp, /dev/shm и пользовательских каталогах.
Особенно внимательно нужно проверять /tmp и /dev/shm. Эксплойты локального повышения привилегий часто запускаются из временных каталогов, потому что туда может писать обычный пользователь или сервис. Если в этих каталогах есть неизвестные исполняемые файлы, скрипты, бинарники без понятного происхождения или следы компиляции, это повод для расследования. После инцидента такие артефакты нужно сохранять до анализа, а не сразу удалять.
Для SSH-доступа стоит проверить authorized_keys у всех пользователей, особенно root. После повышения привилегий атакующий может добавить свой ключ и возвращаться в систему уже без повторной эксплуатации GhostLock. Также нужно проверить sudoers, systemd-сервисы, cron, shell-профили, модули ядра, LD_PRELOAD и другие механизмы закрепления. Патч закрывает уязвимость, но не удаляет уже созданные бэкдоры.
Если сервер используется как контейнерный хост, нужно проверить секреты оркестратора. В Kubernetes после выхода на хост атакующий может получить kubelet-конфигурации, сервисные токены, доступ к etcd, сертификаты, kubeconfig и другие чувствительные данные. После подтвержденной компрометации одной ноды может потребоваться ротация токенов, пересоздание ноды, проверка pod’ов и анализ событий кластера.
Главный вывод состоит в том, что GhostLock — это давняя уязвимость ядра Linux, существовавшая с 2011 года и затронувшая основные дистрибутивы. Она позволяет непривилегированному локальному пользователю получить root-права и выйти из контейнера на хостовую систему. Исследователи Nebula Security подготовили эксплойт с успешностью 97% и временем выполнения около пяти секунд, а за демонстрацию атаки получили 92 337 долларов США в рамках kernelCTF. Исправление появилось в ядре еще в апреле 2026 года, но администраторам нужно ставить самые свежие версии ядра, потому что первый патч вызвал отдельную проблему CVE-2026-53166. Полноценных обходных мер нет: параметры RANDOMIZE_KSTACK_OFFSET и STATIC_USERMODE_HELPER только усложняют эксплуатацию, но не заменяют обновление. В приоритете должны быть серверы с локальными пользователями, контейнерные хосты, Kubernetes-ноды, CI/CD-раннеры, shared hosting и рабочие станции, где локальная LPE может стать вторым этапом удаленной атаки.