Сервер смотрит в интернет одним открытым портом. Пароля у нападающего нет, учётной записи нет, и никто на самой машине ничего не нажимает. Именно такой сценарий описала Anthropic 27 октября 2026 года, рассказав о цепочке, которая заканчивается командой от имени root. За ней стоит ошибка в обработке TCP-рукопожатия, и сидит она в ядре Linux с версии 4.4, то есть с 2016 года. Запись в базе уязвимостей появилась 15 октября, оценку по шкале CVSS 3.1 получила 9,8 из 10, а исправления разошлись по стабильным веткам. Одни дистрибутивы успели выпустить обновления почти сразу, другие закончили только в первых числах ноября. Ниже разобрано, как устроена ошибка, при чём здесь MPTCP и язык Go, какие версии ядра уже закрыты и что стоит проверить на своих серверах сегодня.
Что именно сломано в обработке TCP-рукопожатия и откуда берётся гонка состояний
Когда клиент открывает соединение, сервер сначала получает пакет SYN и отвечает пакетом SYN-ACK. Полноценный сокет в этот момент ядро не создаёт: иначе злоумышленник мог бы дёшево исчерпать память потоком поддельных запросов. Вместо этого появляется лёгкий объект, запрос соединения, хранящий минимум состояния. Когда приходит завершающий ACK, из него вырастает полноценный дочерний сокет, и часть данных переезжает в него.
Проблема спрятана в этом переезде. Среди переносимых данных есть указатель на параметры IP-опций, нужные для построения ответа. Функция tcp_v4_syn_recv_sock передаёт его дочернему сокету, но не копирует сам объект. В итоге на один и тот же кусок памяти смотрят два владельца. Тем временем на другом процессоре может обрабатываться повторно присланный SYN (для TCP ретрансмиссия дело обычное), и этот путь, пройдя через tcp_check_req, строит очередной SYN-ACK, читая параметры из того же объекта. Читает он их внутри RCU-секции, то есть полагаясь на правило "пока есть читатели, память не освободят".
Дочерний сокет в это время может пойти на разрушение, а функция inet_sock_destruct освобождает блок опций сразу, не дожидаясь окончания RCU-периода ожидания. Один процессор освободил объект, другой продолжает с ним работать. Это классическое использование после освобождения (use-after-free), да ещё и порождённое гонкой: всё решает порядок событий на двух ядрах за считаные микросекунды. Исправление в основной ветке ядра сводится к простой идее: освобождать блоки опций только после RCU-периода ожидания, когда все читатели гарантированно закончили.
У той же ошибки есть второй путь. Если включена миграция запросов (параметр net.ipv4.tcp_migrate_req=1 или eBPF-программа типа BPF_SK_REUSEPORT_SELECT_OR_MIGRATE), ядро может клонировать запрос, и старый объект с клоном временно делят один блок опций. Описание исправления отдельно упоминает этот случай, так что закрывается он тем же патчем.
Как освобождённая память превращается в утечку и контроль над сервером
Опасность ошибки такого класса зависит от того, что ляжет на освобождённое место. Если ничего, чтение даст старые байты и всё пройдёт незаметно. Если память уже выдана под другие нужды или помечена как недоступная, будет сбой. А если нападающий умеет влиять на то, чем заполнится освобождённая область, картина меняется: устаревшая ссылка начинает читать или менять чужие данные ядра. В описании уязвимости это выражено конкретно: при повторном использовании объекта в SYN-ACK копируются соседние данные кучи ядра, и они уходят обратно тому, кто прислал пакет. То есть утечка памяти ядра происходит прямо по сети.
Anthropic описала две стадии своей цепочки. Первая нужна, чтобы обойти KASLR, защиту, которая размещает ядро в памяти по случайному адресу: через утечку добывается указатель, по которому можно вычислить раскладку. Вторая использует полученные знания для выполнения команды от имени root. По заявлению компании, на первую стадию ушло около 48 минут, на вторую ещё 5, всего 53 минуты. Простая арифметика показывает, где основное время: 48 из 53 минут, то есть примерно 91 процент, тратится на разведку раскладки памяти, а сам запуск команды занимает около 9 процентов.
Работу выполнила, по словам Anthropic, внутренняя исследовательская модель, которая ещё не вышла: после первоначальной постановки задачи она сама написала эксплойт. Код, версии ядра и конфигурацию стенда компания не опубликовала. Подробные шаги здесь намеренно не раскрываются: для администратора важны условия, при которых цепочка работает, а не рецепт её повторения. А условия таковы, что 53 минуты это время, заявленное на неизвестном лабораторном стенде, и ждать такой же цифры на реальной машине с другим ядром, другим процессором и другими настройками защиты нет оснований. Это скорее показатель "возможно", чем "обязательно".
Почему главный риск связан с MPTCP и какую роль играет Go 1.24
Демонстрация Anthropic проводилась против сервера со слушающим сокетом MPTCP. Это расширение TCP, которое позволяет вести одно соединение сразу по нескольким путям, например по Wi-Fi и мобильной сети одновременно. Заметная деталь: связь с MPTCP следует именно из рассказа Anthropic. Ни запись об уязвимости, ни коммит с исправлением Multipath TCP не называют. Сама ошибка живёт в обычной обработке IPv4 TCP, и вопрос о том, можно ли получить root на сервере без MPTCP, остаётся открытым.
Почему тогда MPTCP вызвал столько шума? Потому что он включается без ведома администратора. Начиная с Go 1.24, программы на Go на Linux по умолчанию создают слушающие сокеты с MPTCP: значение настройки multipathtcp стало равным 2, то есть расширение включено для принимающих соединения сокетов. Любой сервис на Go, собранный свежей версией языка, мог оказаться в этом положении, даже если его автор об MPTCP не слышал. В частности, это касается веб-серверов вроде Caddy, написанных на Go.
Команда безопасности Go рассмотрела вопрос и не стала менять поведение по умолчанию. Её довод таков: отключать MPTCP отдельно в каждой программе хрупко, ведь достаточно одного забытого слушающего сокета, а сама защита опирается на допущение, что любая рабочая цепочка обязательно использует MPTCP. Поэтому и команда ядра, и команда Go рекомендуют одно и то же: установить исправленное ядро. Отключение MPTCP уменьшает видимую поверхность, но не устраняет дефект в TCP.
Проверить, какой версией Go собран конкретный бинарный файл, можно командой go version -m, которая выводит сведения о сборке. Если версия 1.24 или новее, а программа принимает входящие соединения, её слушающий сокет с высокой вероятностью работает через MPTCP, пока автор или администратор явно не задал иное. Для парка из десятков сервисов такой обход занимает вечер, а результатом становится честный список машин, которым нужно обновление в первую очередь.
Почему оценки опасности расходятся и как их правильно читать
Команда ядра выставила 9,8 по CVSS 3.1: удалённо, без аутентификации, с высоким влиянием на конфиденциальность, целостность и доступность. Red Hat смотрит спокойнее, и её оценки в разных документах расходились от 5,9 до 8,1. Причина в том, что дистрибутив оценивает не абстрактную ошибку, а то, что реально поставляет: свой код, настройки и меры смягчения, а гонка состояний считается трудно воспроизводимой. NVD к концу октября собственного анализа ещё не опубликовала.
Спорить о том, какая цифра "настоящая", бессмысленно. Это три разных вопроса: насколько плох дефект в худшем случае, насколько он опасен в конкретном продукте и что показал один исследовательский стенд. Ни одну из оценок не стоит выбрасывать, и ни одну не стоит растягивать за пределы её смысла. Практический вывод от этого не меняется: авторитетные источники не подтверждают массового использования в интернете, но успешная демонстрация удалённого root сильнее, чем просто сбой, и поэтому серверы с MPTCP стоит ставить в начало очереди обновлений.
Какое ядро уже содержит исправление в основных ветках и популярных дистрибутивах
Для основных стабильных веток записи в базе ядра называют такие минимальные исправленные версии: 5.10.272 для ветки 5.10, 5.15.223 для 5.15, 6.1.190 для 6.1, 6.6.159 для 6.6, 6.12.113 для 6.12, 6.18.56 для 6.18, 7.2.10 для 7.2, а в ветке 7.3 исправление есть с самого выпуска. Любая более новая точечная версия той же ветки тоже содержит правку, в том числе серия стабильных ядер, выпущенная 30 октября.
С дистрибутивами сложнее: производители переносят исправления в свои ядра, не меняя номер базовой версии, поэтому сравнивать цифры выше с результатом uname -r на серверах с корпоративными дистрибутивами бесполезно. Смотреть нужно на рекомендации поставщика. Состояние на 2-4 ноября выглядело так. В Debian 13 исправление вошло в пакет linux 6.12.113-1, в Debian 12 в linux 6.1.190-1 и в пакет linux-6.12. У Oracle Linux на ядрах UEK исправленные версии вышли ещё 16 октября. Для RHEL 8, 9 и 10 исправленные ядра выпущены 1 ноября, после установки нужна перезагрузка. У Ubuntu 22.04, 24.04 и 26.04 исправления с 2 ноября лежат в канале proposed и проходят проверку, а для выпусков 16.04, 18.04 и 20.04 исправление ожидается, причём старые версии требуют расширенной поддержки.
Статусы обновляются быстро, поэтому перед работой полезно заглянуть на страницу поставщика. И заметьте дистанцию: с публикации записи 15 октября до исправленных ядер для RHEL прошло 17 суток, до тестовых пакетов Ubuntu 18. Для уязвимости с оценкой 9,8 это большой срок.
Чек-лист проверки серверов на MPTCP и непатченные ядра
Порядок действий для администратора можно уложить в небольшой план, где у каждого шага есть измеримый результат:
- Составить список машин, доступных из интернета, и для каждой выяснить, какое ядро запущено сейчас командой uname -r, а не какое установлено, ведь без перезагрузки запущенное ядро остаётся старым;
- Сверить версию с рекомендацией поставщика вашего дистрибутива, а не с общей таблицей веток, и убедиться, что исправленный пакет вообще доступен, например по списку dpkg -l 'linux-image*' на Debian и Ubuntu или по rpm -q kernel на RHEL;
- Проверить, где включён MPTCP: значение sysctl net.mptcp.enabled, перечень сокетов из ss -M и сборки приложений на Go версии 1.24 и новее, которые принимают входящие соединения;
- Узнать, не включена ли миграция запросов (sysctl net.ipv4.tcp_migrate_req) и не используются ли eBPF-программы выбора сокета с миграцией, ведь это второй путь к той же ошибке.
Как временная мера допустимо отключить MPTCP там, где он не нужен: это убирает именно ту конфигурацию, на которой Anthropic показала свою цепочку. Но Red Hat прямо оговаривает, что обходные правила фильтрации пакетов с IP-опциями блокируют известный путь запуска гонки, не защищают полностью и способны сломать нагрузку, которая использует эти опции. Настоящим исправлением остаётся обновление ядра с перезагрузкой, а после неё стоит ещё раз выполнить uname -r и убедиться, что машина действительно загрузилась с новой версией.
Отдельно стоит сказать про наблюдение. Признаки эксплуатации гонки в сети выглядят необычно, например как повторяющиеся SYN от одного адреса к одному порту, но сами по себе они ничего не доказывают: ретрансмиссия для TCP нормальное явление, а использование после освобождения происходит внутри ядра и по сетевой картинке не видно. Сигнал из сети годится для расстановки приоритетов и для поиска машин, на которые смотреть в первую очередь, а вывод о том, что случился взлом, требует сопоставления с версией ядра, настройками и симптомами вроде сбоев ядра или неожиданных процессов с правами root. Поэтому порядок такой: сначала патч и перезагрузка, затем мониторинг, а не наоборот.
Что эта история говорит о скорости, с которой теперь надо закрывать уязвимости
Рабочий эксплойт для гонки в ядре обычно считается трудом опытного специалиста, на который уходит много времени. Здесь, по рассказу Anthropic, основную работу сделала модель, а цифры из демонстрации говорят о том, что на всю цепочку ушёл неполный час. Даже учитывая лабораторные условия и то, что публичного кода нет, это сдвигает расчёт. Окно между записью в базе уязвимостей и появлением рабочей атаки сжимается, а у отдельных дистрибутивов исправление приходит через две с половиной недели.
Вывод для DevOps простой, и в нём нет ничего эффектного: нужен инвентарь машин, видимых из интернета, понятный список того, что у них включено по умолчанию (сюрприз с Go 1.24 хорошо это показал), и процесс, в котором обновление ядра с перезагрузкой занимает дни, а не месяцы. Тот, у кого эти три вещи готовы, прочитает такую новость спокойно, проверит версии за пару часов и вернётся к обычной работе. Остальным она послужит напоминанием, что внимательнее всего надо смотреть не на громкие цифры оценки, а на собственные серверы.