Исследователь безопасности опубликовал крайне надёжный рабочий эксплойт для уязвимости в ядре Linux, который позволяет обычному пользователю без каких-либо привилегий получить полный контроль над машиной в статусе root - без пароля и без социальной инженерии, только через локальное выполнение кода. Уязвимость класса Local Privilege Escalation (LPE), получившая обозначение CVE-2026-46242 и название "Bad Epoll", затрагивает Linux-серверы, десктопы и Android-телефоны на ядре версии 6.4 и новее. Патч для неё уже существует, но пока установлен далеко не везде.
Как работает use-after-free в Bad Epoll
Баг живёт в epoll - механизме ядра Linux, который позволяет одной программе одновременно следить за тысячами открытых файлов или сетевых соединений. На нём держится практически любой веб-сервер, база данных и VPN-демон. Исследователь Jaeyoung Chung из Computer Security Lab Сеульского национального университета обнаружил, что когда две внутренние процедуры очистки epoll внутри функции ep_remove() выполняются одновременно, одна из них может освободить участок памяти ядра, пока другая всё ещё пишет в него. Это окно use-after-free шириной всего примерно в шесть машинных инструкций, но публичный proof-of-concept Chung, уже выложенный на GitHub, использует повреждённую память для построения ROP-цепочки (return-oriented programming), которая перехватывает выполнение ядра и выдаёт атакующему root.
Кто в зоне риска
- Linux-серверы и десктопы: уязвим любой дистрибутив на основном ядре версии 6.4 и выше.
- Android-устройства: подтверждена работа на Google Pixel 10 (ядро 6.6); более старые устройства на ветке 6.1 long-term-support не затронуты.
- Браузер как точка входа: поскольку эксплойту нужно только локальное выполнение кода, исследователи отмечают, что теоретически его можно запустить изнутри изолированного процесса вроде рендерера Chrome, превратив обычный баг браузера в полный захват устройства.
Первая попытка мейнтейнеров ядра исправить проблему, выпущенная после патча более ранней связанной уязвимости (CVE-2026-43074), не закрыла дыру полностью - потребовалось ещё около двух месяцев, прежде чем корректное исправление попало в основную ветку ядра. Именно этот медленный, двухэтапный процесс патчинга объясняет, почему так много систем остаются уязвимыми: дистрибутивы и производители Android часто отстают от mainline на несколько циклов обновлений, а самостоятельно администрируемые серверы отстают ещё сильнее.
Как проверить, затронуты ли вы
Выполните в терминале команду uname -r, чтобы узнать версию своего ядра. Если она 6.4 или выше, а ваш дистрибутив или устройство не получали обновление безопасности с начала июля 2026 года, считайте систему уязвимой и как можно скорее установите последний патч ядра или обновление от производителя.
Почему это касается не только личных компьютеров
Bad Epoll не требует сетевого подключения для срабатывания - ему нужно только локальное выполнение кода, что на первый взгляд звучит успокаивающе. Но "локальное" сегодня охватывает очень многое: серверы с общим хостингом, CI/CD-раннеры сборки, облачные VPS, самостоятельно управляемые сетевые устройства и вообще любую Linux-машину, которая хоть раз выполняет недоверенный код - будь то скачанный скрипт, побег из контейнера или скомпрометированная вкладка браузера. Стоит атакующему получить хоть какую-то, пусть самую ограниченную, точку опоры - и Bad Epoll превращает её в полный административный контроль.
Более широкая картина
Bad Epoll - ещё одно напоминание о том, насколько современная сетевая инфраструктура, включая Linux-машины, на которых работают VPN-шлюзы, самостоятельно развёрнутые прокси и домашние роутеры, зависит от подсистемы ядра, о существовании которой большинство пользователей даже не подозревает. Один непропатченный сервер в общей сети или VPN-провайдер, медленно раскатывающий обновления ядра на своём парке серверов, способны превратить "чисто локальный" баг в серьёзную угрозу для всех, чей трафик через него проходит. Эта история продолжает тему, повторяющуюся весь этот год: от кражи учётных данных через FortiGate до Citrix Bleed - самым слабым звеном инфраструктуры приватности снова и снова оказывается непропатченный, скучно звучащий код ядра и прошивок, а не сам механизм шифрования.
