Сингапурская компания STAR Labs опубликовала материал, который наделал шума в среде специалистов по безопасности ядра Linux. Исследователь Ли Цзя Цзе рассказал, как с помощью искусственного интеллекта разработал эксплойт, превращающий обычного локального пользователя в root на CentOS Stream 9. Заявление громкое, но при внимательном чтении технических подробностей выясняется, что речь идёт не о волшебной кнопке «взломать всё», а о довольно узком и требовательном к условиям сценарии атаки.
Уязвимость получила номер CVE-2026-53264 и оценку 7.8 по шкале CVSS — так её классифицировал Linux CNA. По сути это race condition типа use-after-free в подсистеме traffic-control ядра, той самой, что управляет правилами обработки сетевого трафика. Проблема возникает, когда операции RTM_NEWTFILTER и RTM_DELTFILTER выполняются параллельно: один поток может обратиться к объекту действия (action object) уже после того, как другой поток его освободил. Разработчики ядра закрыли эту дыру, отложив момент освобождения памяти до завершения работы всех читателей RCU — механизма read-copy-update, который и должен был предотвращать такие коллизии, но не предотвратил.
Важная деталь: это не удалённое выполнение кода, а классическое повышение привилегий (Local Privilege Escalation). То есть атакующему для начала нужно каким-то образом уже оказаться внутри системы — под непривилегированной учётной записью. Дальше начинается техническая часть, требующая довольно специфического набора условий: включённые непривилегированные пространства имён пользователей, а также параметры конфигурации ядра CONFIG_NET_ACT_GACT и CONFIG_NET_CLS_FLOWER. Плюс собственная ROP-цепочка (Return-Oriented Programming) с жёстко прописанными смещениями под конкретную сборку ядра. Полный код эксплойта уже выложен в открытый доступ.
Механика атаки построена как многоступенчатая цепочка. Сначала процесс создаёт собственные пользовательское и сетевое пространства имён — это даёт локальные права CAP_NET_ADMIN внутри namespace, без реального административного доступа к хосту. Затем через связку clsact qdisc и flower filter эксплойт добирается до уязвимого участка кода. Операции с timerfd и epoll используются, чтобы искусственно расширить окно гонки — тот самый промежуток времени, в который можно успеть вклиниться между освобождением памяти и повторным обращением к ней. Далее нужные payload-аллокации переиспользуют освободившуюся память, ROP-цепочка перезаписывает переменную core_pattern, копия самого процесса размещается в memfd, после чего дочерний процесс намеренно обрушивается. В результате ядро запускает бинарник из memfd как обработчик core-dump с правами root в исходном пространстве имён — классический трюк с подменой core_pattern, только доведённый до автоматизации.
По заявленным цифрам, тестовый прогон на ноутбуке с CentOS Stream 9 дал 10 успешных срабатываний из 10, время выполнения колебалось от 9 до 111 секунд. Стоит сразу оговориться: независимого воспроизведения этих показателей никто не проводил, и жёстко зашитые смещения гаджетов означают, что для других пакетов ядра эксплойт нужно пересобирать заново — на новых сборках он попросту может не сработать без ручной подгонки.
Роль искусственного интеллекта в этой истории, по словам Ли, свелась к трём вещам: поиску самой уязвимости, созданию proof of concept с использованием KASAN (Kernel Address Sanitizer) и оптимизации окна гонки. При этом сам исследователь честно признаёт границы возможностей нейросети: «У ИИ до сих пор много слепых зон и провалов в логике рассуждений». Человеческая проверка и направление процесса оставались обязательными на каждом этапе. Любопытно другое его наблюдение — работа с активным участием ИИ ощущалась не как поиск нового бага, а «больше похоже на n-day-анализ, даже когда баг был свежим». То есть искусственный интеллект как бы превращал незнакомую задачу в что-то более рутинное и предсказуемое.
Проблема в том, что в публикации STAR Labs не раскрыты ни конкретная модель, ни использованные промпты, ни сервис, ни лог взаимодействия с системой. Из-за этого невозможно ни использовать случай как эталон возможностей ИИ, ни отделить реальный вклад машины от собственного опыта и решений самого Ли. The Hacker News направил в STAR Labs запрос с просьбой раскрыть, какая именно система использовалась, в каком окружении проводилось тестирование и какой была хронология раскрытия информации — ответ на момент выхода материала оставался в ожидании.
С патчами ситуация выглядит достаточно упорядоченной. Официальное исправление появилось в ядре 1 июня 2026 года и было портировано на несколько веток стабильных версий. Согласно оценке Linux CNA, диапазон уязвимых версий начинается с Linux 4.14. Исправление получили следующие релизы: 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.94, 6.18.36, 7.0.13, а точкой входа фикса в основную ветку стал 7.1-rc7. Практический совет здесь простой: ориентироваться нужно не на номер версии апстрима, а на конкретный дистрибутивный пакет ядра, в который фикс уже встроен.
По состоянию на 28 июля 2026 года каталог CISA KEV не содержит записи об этой уязвимости, официальных сообщений об эксплуатации в реальных условиях также не зафиксировано. Картина по дистрибутивам неоднородная: Debian уже перечисляет исправленные ядра для поддерживаемых стабильных релизов, Ubuntu на тот же момент продолжает отмечать несколько поддерживаемых пакетов ядра как уязвимые, а SUSE указывает статус проблемы как «pending» сразу по нескольким продуктам. Отдельно любопытна оценка SUSE — там уязвимости присвоили 5.5 балла, что заметно ниже 7.8 от Linux CNA. Разница объясняется вектором оценки: SUSE учитывает только влияние на доступность (availability impact), тогда как Linux CNA смотрит на риск шире.
Отдельный сюжет — вопрос авторства самой находки. Согласно записи в апстримном патче, первым об уязвимости сообщил исследователь Kyle Zeng, известный под ником KyleBot. Ли Цзя Цзе утверждает, что нашёл ту же проблему независимо, и лишь позже узнал, что Зенг направил отчёт незадолго до соревнования TyphoonPwn 2026. Именно Ли впоследствии опубликовал подробный технический разбор и код рабочего эксплойта — что и стало основой всей этой истории про ИИ в разработке эксплойтов.
Если оценивать реальный риск без эмоций, картина получается не такой пугающей, как звучит формулировка «root-эксплойт для Linux». Слишком много условий должно совпасть: конкретные настройки пространств имён, включённые опции конфигурации ядра, совместимая сборка с подходящими смещениями. При этом публикация готового кода эксплойта объективно повышает срочность для тех систем, где все эти условия соблюдаются, а патч ещё не установлен. Главная нерешённая проблема — публичные трекеры дистрибутивов показывают только статус патчей на уровне пакетов, но никак не отражают, сколько реально развёрнутых систем имеют нужную конфигурацию namespaces, соответствующие опции ядра и совместимую сборку. Иными словами, доступные источники не дают ответа на главный вопрос: сколько систем в реальности находятся под непосредственной угрозой.
Уязвимость получила номер CVE-2026-53264 и оценку 7.8 по шкале CVSS — так её классифицировал Linux CNA. По сути это race condition типа use-after-free в подсистеме traffic-control ядра, той самой, что управляет правилами обработки сетевого трафика. Проблема возникает, когда операции RTM_NEWTFILTER и RTM_DELTFILTER выполняются параллельно: один поток может обратиться к объекту действия (action object) уже после того, как другой поток его освободил. Разработчики ядра закрыли эту дыру, отложив момент освобождения памяти до завершения работы всех читателей RCU — механизма read-copy-update, который и должен был предотвращать такие коллизии, но не предотвратил.
Важная деталь: это не удалённое выполнение кода, а классическое повышение привилегий (Local Privilege Escalation). То есть атакующему для начала нужно каким-то образом уже оказаться внутри системы — под непривилегированной учётной записью. Дальше начинается техническая часть, требующая довольно специфического набора условий: включённые непривилегированные пространства имён пользователей, а также параметры конфигурации ядра CONFIG_NET_ACT_GACT и CONFIG_NET_CLS_FLOWER. Плюс собственная ROP-цепочка (Return-Oriented Programming) с жёстко прописанными смещениями под конкретную сборку ядра. Полный код эксплойта уже выложен в открытый доступ.
Механика атаки построена как многоступенчатая цепочка. Сначала процесс создаёт собственные пользовательское и сетевое пространства имён — это даёт локальные права CAP_NET_ADMIN внутри namespace, без реального административного доступа к хосту. Затем через связку clsact qdisc и flower filter эксплойт добирается до уязвимого участка кода. Операции с timerfd и epoll используются, чтобы искусственно расширить окно гонки — тот самый промежуток времени, в который можно успеть вклиниться между освобождением памяти и повторным обращением к ней. Далее нужные payload-аллокации переиспользуют освободившуюся память, ROP-цепочка перезаписывает переменную core_pattern, копия самого процесса размещается в memfd, после чего дочерний процесс намеренно обрушивается. В результате ядро запускает бинарник из memfd как обработчик core-dump с правами root в исходном пространстве имён — классический трюк с подменой core_pattern, только доведённый до автоматизации.
По заявленным цифрам, тестовый прогон на ноутбуке с CentOS Stream 9 дал 10 успешных срабатываний из 10, время выполнения колебалось от 9 до 111 секунд. Стоит сразу оговориться: независимого воспроизведения этих показателей никто не проводил, и жёстко зашитые смещения гаджетов означают, что для других пакетов ядра эксплойт нужно пересобирать заново — на новых сборках он попросту может не сработать без ручной подгонки.
Роль искусственного интеллекта в этой истории, по словам Ли, свелась к трём вещам: поиску самой уязвимости, созданию proof of concept с использованием KASAN (Kernel Address Sanitizer) и оптимизации окна гонки. При этом сам исследователь честно признаёт границы возможностей нейросети: «У ИИ до сих пор много слепых зон и провалов в логике рассуждений». Человеческая проверка и направление процесса оставались обязательными на каждом этапе. Любопытно другое его наблюдение — работа с активным участием ИИ ощущалась не как поиск нового бага, а «больше похоже на n-day-анализ, даже когда баг был свежим». То есть искусственный интеллект как бы превращал незнакомую задачу в что-то более рутинное и предсказуемое.
Проблема в том, что в публикации STAR Labs не раскрыты ни конкретная модель, ни использованные промпты, ни сервис, ни лог взаимодействия с системой. Из-за этого невозможно ни использовать случай как эталон возможностей ИИ, ни отделить реальный вклад машины от собственного опыта и решений самого Ли. The Hacker News направил в STAR Labs запрос с просьбой раскрыть, какая именно система использовалась, в каком окружении проводилось тестирование и какой была хронология раскрытия информации — ответ на момент выхода материала оставался в ожидании.
С патчами ситуация выглядит достаточно упорядоченной. Официальное исправление появилось в ядре 1 июня 2026 года и было портировано на несколько веток стабильных версий. Согласно оценке Linux CNA, диапазон уязвимых версий начинается с Linux 4.14. Исправление получили следующие релизы: 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.94, 6.18.36, 7.0.13, а точкой входа фикса в основную ветку стал 7.1-rc7. Практический совет здесь простой: ориентироваться нужно не на номер версии апстрима, а на конкретный дистрибутивный пакет ядра, в который фикс уже встроен.
По состоянию на 28 июля 2026 года каталог CISA KEV не содержит записи об этой уязвимости, официальных сообщений об эксплуатации в реальных условиях также не зафиксировано. Картина по дистрибутивам неоднородная: Debian уже перечисляет исправленные ядра для поддерживаемых стабильных релизов, Ubuntu на тот же момент продолжает отмечать несколько поддерживаемых пакетов ядра как уязвимые, а SUSE указывает статус проблемы как «pending» сразу по нескольким продуктам. Отдельно любопытна оценка SUSE — там уязвимости присвоили 5.5 балла, что заметно ниже 7.8 от Linux CNA. Разница объясняется вектором оценки: SUSE учитывает только влияние на доступность (availability impact), тогда как Linux CNA смотрит на риск шире.
Отдельный сюжет — вопрос авторства самой находки. Согласно записи в апстримном патче, первым об уязвимости сообщил исследователь Kyle Zeng, известный под ником KyleBot. Ли Цзя Цзе утверждает, что нашёл ту же проблему независимо, и лишь позже узнал, что Зенг направил отчёт незадолго до соревнования TyphoonPwn 2026. Именно Ли впоследствии опубликовал подробный технический разбор и код рабочего эксплойта — что и стало основой всей этой истории про ИИ в разработке эксплойтов.
Если оценивать реальный риск без эмоций, картина получается не такой пугающей, как звучит формулировка «root-эксплойт для Linux». Слишком много условий должно совпасть: конкретные настройки пространств имён, включённые опции конфигурации ядра, совместимая сборка с подходящими смещениями. При этом публикация готового кода эксплойта объективно повышает срочность для тех систем, где все эти условия соблюдаются, а патч ещё не установлен. Главная нерешённая проблема — публичные трекеры дистрибутивов показывают только статус патчей на уровне пакетов, но никак не отражают, сколько реально развёрнутых систем имеют нужную конфигурацию namespaces, соответствующие опции ядра и совместимую сборку. Иными словами, доступные источники не дают ответа на главный вопрос: сколько систем в реальности находятся под непосредственной угрозой.