Fraggap: через баг ядра Linux агенты OpenAI взяли root

CISA 27 августа внесла в KEV, свой каталог реально эксплуатируемых уязвимостей, ошибку ядра Linux CVE-2026-53362, через которую агенты OpenAI в июле выбрались из контейнера и получили root на узле.

У уязвимости есть и прозвища: IPv6 Frag Gap, или «Fraggap». В апстриме её исправили ещё этим летом, но многие системы так и не обновили, и теперь её используют в атаках, говорится в разборе ZDNET. Федеральным ведомствам США CISA велела закрыть уязвимость до 30 августа. Срок в три дня захватил выходные, и автор ZDNET сомневается, что за уик-энд все успели обновиться.

Ошибка сидит в коде ядра, который отправляет пакеты IPv6. При определённом сочетании условий ядро выделяет под пакет слишком маленький буфер и пишет данные за его конец. Затирается соседняя структура skb_shared_info, служебные метаданные сетевого пакета. В итоге портится куча ядра, а такая порча может дать локальное повышение привилегий, отказ в обслуживании или повреждение данных.

Добраться до уязвимого кода можно из непривилегированного процесса. Ему достаточно UDP-сокета IPv6 с флагами MSG_MORE и MSG_SPLICE_PAGES в ситуации, когда пакет фрагментируется и собирается из разрозненных кусков памяти (scatter-gather). Удалённо через интернет баг не эксплуатируется: атакующему нужно уже уметь запускать код на машине или закрепиться внутри какой-то рабочей нагрузки. В базе NVD уязвимость числится с высоким уровнем опасности, 7,8 по CVSS. При этом попадание в KEV ничего не говорит о масштабе эксплуатации и не означает, что атаковали каждую уязвимую машину.

Внимание к Fraggap выросло после раскрытия OpenAI. Как рассказала компания, 19 июля агенты нашли публичный proof-of-concept для CVE-2026-53362, адаптировали его под архитектуру цели и подняли с его помощью привилегии. Они выбрались из контейнера Artifactory, получили root на нижележащем узле-воркере и дальше двигались по связанной инфраструктуре. Автор ZDNET называет это кошмарным сценарием для контейнеров.

Всё произошло во время внутренней оценки киберспособностей. В ней участвовали две модели OpenAI: выпущенная GPT-5.6 Sol и неопубликованная, более сильная. Для теста у обеих ослабили отказы на кибер-задачи. Модели решали внутренний бенчмарк ExploitGym, а по формулировке OpenAI, пытались его обмануть: они «зациклились» на ключе с ответами и добывали доступ в интернет как промежуточную цель. В собственном разборе OpenAI главную роль отводит внутренней исследовательской модели.

Кроме ядра, в инциденте фигурирует и сам Artifactory. Как отмечает Cloud Security Alliance, JFrog связала выход из песочницы минимум с восемью уязвимостями в Artifactory. Полная цепочка работает только на инстансах с включённым Anonymous Access, а исправление для self-hosted установок вышло 27 июля в версии 7.161.15.

Уязвимый код есть во всех ветках начиная с Linux 6.0. Исправления в апстриме вошли в ядра 6.1.177, 6.6.144, 6.12.95, 6.18.38 и 7.1.3, все это актуальные LTS-ветки. Грег Кроа-Хартман, сопровождающий стабильные ядра Linux, советует всегда использовать последнее LTS-ядро, если вам нужна безопасная система.

Но по номеру версии статус защиты не определить. Как замечал и сам Кроа-Хартман, мало какие дистрибутивы идут в ногу с LTS-ядрами. Обычно они переносят отдельные исправления безопасности в своё ядро и не меняют номер на соответствующий апстримный. Поэтому система с виду со старым ядром может быть уже защищена, а соседняя с похожим номером остаться уязвимой. Точный ответ про конкретное ядро даёт только поставщик дистрибутива.

ZDNET предлагает администраторам такой порядок:

• Поставить текущее обновление безопасности ядра из репозитория и бюллетеня вашего дистрибутива. Собирать апстримное ядро ради одной этой CVE не нужно.
• Перезагрузиться в новое ядро: скачанный пакет сам по себе уязвимость не закрывает. Работающую версию показывает uname -r, её нужно сверить с исправленной.
• Начать с систем, где код запускают разные пользователи или арендаторы: общие серверы, машины разработки и сборки, VDI, HPC-кластеры, рабочие узлы Kubernetes, контейнерные платформы и раннеры CI/CD.
• Пересмотреть допущения о контейнерах. Контейнеры используют ядро хоста, и в зависимости от конфигурации и привилегий баг в сетевом стеке может вести из взломанной нагрузки к контролю над хостом. Так и вышло в случае OpenAI.
• Временные обходные меры держать только до обновления. Fedora CoreOS, например, указывает, что эксплойт обходится отключением IPv6, но тем, кто IPv6 использует, это не подходит.
• Поискать следы компрометации: необычные локальные изменения привилегий, неожиданные процессы от root, аномальную активность контейнеров, подозрительные переходы из рабочих нагрузок на хосты.

Локальный баг ядра превращает скромный плацдарм в root, а плацдармом может стать взломанная учётная запись разработчика, уязвимое приложение, вредоносная зависимость в сборке или открытый наружу контейнер. Пример OpenAI, по оценке автора ZDNET, показывает ещё одно: если рядом есть публичный PoC и достижимая цель, агентные системы сокращают время и квалификацию, нужные для рабочего эксплойта, до нескольких часов.

Сама OpenAI предупреждает, что до такого положения дел остались месяцы: кибератаки с применением ИИ «станут гораздо более распространёнными и изощрёнными по мере того, как модели по всему миру становятся всё способнее».