CVE-2026-98432: для Ubuntu и RHEL по-прежнему нет патча, а модель Claude уже написала эксплойт

Два факта о CVE-2026-98432 плохо сочетаются друг с другом. Это use-after-free в рукопожатии TCP/IPv4 ядра Linux, доступная по сети без входа в систему и без взаимодействия, и команда CVE ядра оценила её в 9.8. По состоянию на 30 октября 2026 года у Ubuntu нет выпущенного исправления для 22.04, 24.04, 26.04 или 26.10, а Red Hat перечисляет RHEL 8, 9 и 10 как уязвимые без исправления и без одобренного способа смягчения. Второй факт: 27 октября Anthropic опубликовала исследование, в котором говорится, что невыпущенная модель Claude создала работающий proof of concept для удалённого получения root-доступа без аутентификации на сервере с MPTCP-листенером — примерно 48 минут на утечку адреса ядра и ещё пять минут до выполнения команд.

Уязвимость, которую два крупнейших корпоративных поставщика Linux пока не могут закрыть, вместе с рабочим эксплойтом, частично написанным машиной, — это не рядовой «вторник патчей». Это тот случай, который решает, связаны ли вообще ваш процесс обновления ядра и ваша политика доступа агентов друг с другом.

Баг, в одном абзаце.

При установке TCP-соединения IP-параметры, прикреплённые к входящему пакету, передаются новому сокету, а не копируются. Если рукопожатие повторяется, пакет может быть обработан на другом CPU, не на том, который владеет буфером параметров, — и этот второй CPU может прочитать память, которую первый уже освободил. Аналогичная гонка существует и на пути миграции запросов. Затронутый диапазон начинается с ядра 4.4, то есть на большинстве машин, всё ещё работающих под поддерживаемым ядром. Исправление в upstream, коммит code>e3f33b0a1d89/code>, откладывает освобождение буферов параметров до тех пор, пока ни одно другое ядро не сможет удерживать ссылку.

Эксплуатируемость вытекает из самой механики: нет аутентификации, нет взаимодействия с пользователем, путь доступен по сети, а гонку можно повторять. Собственное объяснение Anthropic о том, почему PoC практичен, сводится именно к этому свойству — проигранная гонка означает неудачу одного рукопожатия, а не падение машины, так что атакующий просто пробует снова.

Три поставщика, три числа серьёзности

Разбивка по баллам — это та часть, которую стоит усвоить, потому что от неё зависит, откроет ли ваш сканер заявку на этой неделе.

• Команда CVE ядра — 9.8, критический. Доступно по сети, привилегии не требуются, взаимодействие не требуется.

• Red Hat — 8.1, важно. Позиция компании состоит в том, что на практике эту гонку трудно выиграть.

• Ubuntu — Высокий приоритет, при этом на проверенных страницах числовая оценка не опубликована.

Разрыв между 9,8 и 8,1 — это не разногласие насчёт бага, а разногласие насчёт вероятности выиграть гонку. Обе позиции защитимы, и разница имеет операционное значение: 9,8 с публичным PoC — это аварийная ситуация, а 8,1 со сложной гонкой — это плановое исправление. Пока кто-нибудь не опубликует показатели воспроизводимости на реальном железе, честная интерпретация такова, что гонку можно выиграть, поскольку, по сообщениям, передовая модель её выиграла.

У кого есть исправление, а у кого нет

По состоянию на 29–30 октября картина неоднородна — в том смысле, что это застаёт врасплох тех, кто считает, будто стабильное ядро означает пропатченное.

• Debian 12 bookworm — исправлено в 6.1.190-1 посредством DLA-4841-1.

• Debian 13 trixie — исправлено в 6.12.113-1 посредством DSA-6568-1.

• Ubuntu 22.04, 24.04, 26.04, 26.10 — выпущенного исправления нет; работа ведётся.

• Ubuntu 16.04, 18.04, 20.04 — уязвимы, исправление не выпущено.

• RHEL 8, 9, 10 и OpenShift 4 — затронуты, исправления нет, и нет одобренного Red Hat способа устранения.

• RHEL 6 и 7 — не затронуты.

• Amazon Linux 2023 — ядро 6.18, по сообщениям, исправлено; Oracle Linux UEK — по сообщениям, исправлен; SUSE сообщает, что некоторые выпуски исправлены, а другие всё ещё тестируются, без указания версий.

Стабильные выпуски upstream, содержащие это исправление: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 и 7.3 — именно с этим списком нужно сверять собственную сборку, если вы компилируете ядро самостоятельно, а не берёте пакет дистрибутива.

Почему MPTCP постоянно всплывает

Эта ошибка не специфична для MPTCP, и именно здесь многое в освещении идёт не так. Red Hat рассматривает любой доступный TCP-сервис как возможный триггер. MPTCP предоставляет демонстрируемый путь, а трафик обеспечивает Go: версия 1.24 и более поздние включают multipath TCP по умолчанию для прослушивающих сокетов Linux, когда в ядре включён MPTCP. Команда безопасности Go предупредила об этой комбинации 29 октября.

Итак, «disable MPTCP» устраняет путь, который продемонстрировала Anthropic, а не саму уязвимость. Это оправданная временная мера с конкретной оговоркой: её стоит применять в Go-сервисах уже сегодня, и она не заменяет ядро с исправлением.

Проверки короткие:

• code>ss -Mltnp/code> — список сокетов, которые сейчас используют MPTCP.

• code>net.mptcp.enabled/code> — включена ли эта функция ядра вообще.

• code>net.ipv4.tcp_migrate_req/code> — по умолчанию выключено; если вы его включили, выключите снова.

В частности, для Go code>GODEBUG=multipathtcp=0/code> во время выполнения или строка code>godebug/code> в code>go.mod/code> отключает эту возможность для бинарного файла.

Ни одно из этих решений не одобрено производителем. Red Hat прямо заявляет, что у него нет средства устранения уязвимости, соответствующего его собственному стандарту, — и это куда более полезная формулировка, чем перечень обнадёживающих обходных путей.

Что на самом деле опубликовал Anthropic

Исследование узкое и конкретное. Невыпущенная модель Claude, получив CVE и цель с MPTCP-слушателем, построила цепочку, которая привела к утечке адреса ядра примерно за 48 минут, а ещё примерно через пять минут дошла до выполнения команд. Anthropic не опубликовала эксплойт, и по состоянию на 29 октября ни поставщики, ни запись CVE не сообщали об атаках в реальных условиях; уязвимость отсутствует в каталоге KEV CISA. 30 октября сторонний репозиторий GitHub опубликовал лабораторные инструменты для запуска состояния гонки и утечки памяти — стенд для воспроизведения, не доводящий до полного выполнения кода.

Интересна именно эта комбинация. Возможность продемонстрирована, оружие не раскрыто, а ключевая деталь — свойство повторной попытки, превращающее хрупкую гонку в надёжную, — открыто изложена в тексте. Любой, кто может воспроизвести эту гонку, теперь знает, почему стоит продолжать попытки.

Что делать на этой неделе

• Установите патч и перезагрузитесь, если исправление доступно. Исправление ядра, которое установлено, но не применено после перезагрузки, не является исправлением; проверьте с помощью code>uname -r/code>.

• Если для вашего дистрибутива патча нет — Ubuntu 22.04–26.10, RHEL 8–10 — решите прямо сейчас: установить live-патч от вендора, перейти на исправленную версию или принять этот риск, отключив MPTCP на сервисах на Go.

• Проведите инвентаризацию использования {{1}}MPTCP{{/1}}, а не предполагайте, что он отключён. Значение по умолчанию изменилось в Go, а не в вашей конфигурации, и изменение значения по умолчанию не видно в диффе конфигурации.

• Репетируйте перезагрузку. Такой класс исправлений требует полной перезагрузки, и больше всего времени потеряют те организации, которые обнаружат свой сценарий отработки отказа во время окна обслуживания.

Два вопроса, которые этот CVE на самом деле поднимает

Первое касается генерации эксплойтов, и это не философия. Модель нашла последовательность, которую не нашли очень многие исследователи-люди, на цели с конкретной конфигурацией, обеспечивающей такую возможность, менее чем за час. Опубликован эксплойт или нет, но временная шкала изменилась: окно между публичным уведомлением об уязвимости и работающим эксплойтом теперь измеряется с поправкой на модели, которые читают это уведомление.

Второй — о том, что означает выпуск исправлений, когда поставщики не могут выпустить патч. Дистрибутив, который поставляет вам ядро, и ядро, в котором есть исправление, — не один и тот же объект, и разрыв между ними — это ровно то место, где эта уязвимость существует для большинства читателей этого поста. OrcaRouter AI Incident Archive индексирует подобные инциденты по их первоисточникам, серьёзности и уверенности, и это та версия этой истории, которую стоит сохранить, когда новостной цикл сдвинется.

Чего точно не стоит делать — так это относить это к категории «подождать вендора». На собственной странице вендора сказано, что ждать пока нечего.

Примечание об источниках: механизм, диапазон затронутых версий начиная с ядра 4.4, коммит в upstream code>e3f33b0a1d89/code>, список стабильных версий и рекомендации по снижению риска взяты из записи CVE и бюллетеней дистрибутивов, прочитанных 30 октября 2026 года. Оценки 9.8, 8.1 и High от Ubuntu принадлежат соответственно команде CVE по ядру, Red Hat и Canonical. Статус патчей для каждого дистрибутива взят из DLA-4841-1 и DSA-6568-1 Debian, страниц CVE Red Hat и Ubuntu и заявлений вендоров от той же даты. Хронология proof-of-concept, показатели в 48 минут и пять минут и свойство повторных попыток — из исследования Anthropic от 27 октября, в котором эксплойт не раскрывался. Лабораторный репозиторий от 30 октября описывается как сторонний и не является нашим.