В сетевом стеке ядра Linux обнаружена критическая уязвимость CVE-2026-98432, которая при определённых условиях позволяет удалённому злоумышленнику выполнить произвольные команды с правами суперпользователя. Проблема связана с обработкой IPv4 TCP-соединений и ошибкой управления памятью типа use-after-free. По оценке команды CVE Linux Kernel, её серьёзность достигает 9,8 балла из 10 по шкале CVSS.
Особое внимание к проблеме привлекло исследование Anthropic. Компания сообщила, что её экспериментальная модель Claude смогла самостоятельно разработать цепочку эксплуатации, позволяющую атаковать Linux-серверы с включённым Multipath TCP (MPTCP). В результате исследователям удалось добиться удалённого выполнения команд с привилегиями root без предварительной аутентификации и участия пользователя.
Новость важна не только для разработчиков ядра и специалистов по информационной безопасности. Уязвимость затрагивает широкий спектр серверных систем, включая Ubuntu, Red Hat Enterprise Linux и другие дистрибутивы. При этом наличие MPTCP-слушателя является условием продемонстрированной Anthropic атаки, но сама ошибка находится в обычном IPv4 TCP-коде. Поэтому отключение MPTCP нельзя считать полноценным устранением проблемы.
Техническое описание уязвимости доступно в официальном уведомлении команды Linux Kernel CVE, а результаты исследования эксплуатации — в публикации Anthropic.
CVE-2026-98432: что известно об уязвимости
CVE-2026-98432 представляет собой ошибку типа use-after-free в сетевой подсистеме IPv4 ядра Linux. Она связана с тем, как ядро управляет параметрами IP-соединения при одновременной обработке нескольких операций, относящихся к одному TCP-запросу.
Проблема была обнаружена в коде, который обрабатывает установление TCP-соединений. В определённой ситуации ядро передаёт указатель на область памяти от временного объекта запроса новому сокету, не создавая независимую копию данных. При этом другой процессор может продолжать обращаться к той же области памяти во время повторной обработки запроса на соединение.
Если исходный объект уже уничтожен, а другая часть ядра всё ещё использует его данные, возникает обращение к освобождённой памяти. Это и называется use-after-free.
В зависимости от обстоятельств подобная ошибка может приводить к различным последствиям:
- аварийному завершению работы отдельных сетевых операций;
- повреждению данных в памяти ядра;
- раскрытию фрагментов содержимого памяти;
- нарушению нормальной работы системы и отказу в обслуживании;
- при успешной эксплуатации — выполнению произвольного кода с привилегиями ядра.
Официальное описание Linux Kernel CVE указывает, что проблема была внесена в код ещё в Linux 4.4. Таким образом, уязвимость существовала в ядре на протяжении многих лет и затронула несколько поколений поддерживаемых веток.
Исправление связано с изменением порядка освобождения памяти: вместо немедленного удаления объектов ядро должно дождаться завершения операций, которые ещё могут обращаться к соответствующим данным.
Техническое описание механизма ошибки опубликовано в уведомлении Greg Kroah-Hartman от 15 октября 2026 года.
Почему ошибка use-after-free опасна для Linux
Ядро Linux управляет памятью, процессами, устройствами, сетевыми соединениями и аппаратными ресурсами компьютера. Ошибка в пользовательском приложении обычно ограничивается самим приложением или его процессом. Ошибка в ядре потенциально затрагивает всю операционную систему.
Use-after-free возникает, когда программа продолжает использовать объект после освобождения памяти, в которой он находился. Само по себе обращение к освобождённой области не всегда приводит к успешной атаке: результат зависит от того, какие данные оказались на этом месте, когда произошёл повторный доступ и какие операции выполняет ядро.
В случае CVE-2026-98432 проблема связана с конкурирующими операциями на нескольких CPU. Один поток ядра может ещё читать параметры соединения, в то время как другой уже освобождает соответствующую область памяти.
Подобные ошибки особенно сложны для обнаружения при обычном тестировании. Они зависят от точного порядка выполнения операций, времени обработки сетевых запросов и состояния внутренних объектов ядра. Поэтому исправление требует не просто проверки входных данных, а корректного управления временем жизни памяти.
Как работает атака через MPTCP
Anthropic продемонстрировала эксплуатацию CVE-2026-98432 на Linux-сервере, который принимает подключения через Multipath TCP. В опубликованном исследовании описана цепочка, позволяющая сначала получить информацию о расположении объектов в памяти ядра, а затем добиться выполнения команд с привилегиями root.
В общих чертах исследование включает два основных этапа:
- Получение информации о памяти. Эксплуатация ошибки позволяет добиться чтения данных за пределами ожидаемой области. При определённых условиях это раскрывает указатели ядра и помогает обойти защиту KASLR.
- Получение управления выполнением. Используя ту же ошибку управления памятью, исследователи смогли повлиять на ход выполнения кода ядра и добиться запуска подготовленной команды с правами root.
KASLR (Kernel Address Space Layout Randomization) — механизм рандомизации расположения областей памяти ядра. Он затрудняет эксплуатацию уязвимостей, поскольку злоумышленнику сложнее заранее определить адреса нужных объектов и функций.
По данным Anthropic, экспериментальная модель Claude создала рабочую цепочку эксплуатации примерно за 53 минуты: около 48 минут потребовалось на получение указателя ядра и ещё примерно пять минут — на достижение выполнения команды. Это результат конкретного исследовательского эксперимента, а не гарантированное время успешной атаки на любой сервер.
Важно также учитывать, что Anthropic не опубликовала готовый эксплойт для свободного использования. Компания описала исследовательскую демонстрацию и основные этапы атаки, но это не означает, что любой удалённый злоумышленник сможет повторить её с теми же результатами на произвольной системе.
Подробности приведены в исследовании Anthropic о поиске и эксплуатации уязвимостей с помощью Claude.
Что такое MPTCP и почему он важен для этой атаки
Multipath TCP — расширение стандартного TCP, позволяющее использовать несколько сетевых путей в рамках одного логического соединения. Например, устройство может одновременно задействовать Wi-Fi и мобильную сеть, чтобы повысить устойчивость подключения или эффективнее использовать доступную пропускную способность.
Обычный TCP предполагает использование одного сетевого пути для соединения. MPTCP позволяет организовать несколько подсоединений, сохраняя для приложения единый логический канал передачи данных.
Технология может применяться в следующих сценариях:
- мобильные устройства с одновременным использованием Wi-Fi и сотовой сети;
- серверы с несколькими сетевыми интерфейсами;
- инфраструктура, где требуется переключение между сетевыми каналами без разрыва соединения;
- системы, которым необходимо повысить устойчивость передачи данных;
- сетевые приложения, специально поддерживающие Multipath TCP.
В Linux MPTCP реализован на уровне сетевого стека, но его использование зависит от конфигурации ядра и приложений. Наличие поддержки протокола не означает, что абсолютно все TCP-соединения автоматически используют несколько сетевых путей.
Особенность ситуации заключается в том, что некоторые приложения могут включать MPTCP без очевидного для системного администратора изменения конфигурации. В частности, это касается программ, написанных на Go начиная с версии 1.24.
Почему серверы на Go 1.24 и новее требуют особого внимания
Отдельный риск связан с языком программирования Go. Начиная с версии 1.24, стандартная сетевая библиотека Go по умолчанию включает использование MPTCP для входящих TCP-слушателей в Linux, если ядро поддерживает эту функцию.
Это означает, что приложение может создавать MPTCP-слушатель без явного указания такого режима в исходном коде. В результате администратор может не знать, что установленный сетевой сервис использует механизм, необходимый для воспроизведения атаки Anthropic.
Особенно внимательно следует проверить:
- HTTP-серверы и API, написанные на Go;
- прокси-серверы и сетевые шлюзы;
- службы мониторинга и управления инфраструктурой;
- собственные приложения, использующие пакет net;
- контейнерные сервисы, работающие на Go 1.24 и более новых версиях.
Команда безопасности Go 29 октября 2026 года опубликовала отдельное предупреждение. В нём рекомендуется в первую очередь установить исправленное ядро. Временное отключение MPTCP в Go может убрать условие, необходимое для продемонстрированной Anthropic атаки, но не устраняет исходную уязвимость.
Для временного отключения MPTCP по умолчанию в Go-приложении можно использовать переменную окружения:
GODEBUG=multipathtcp=0Её можно задать непосредственно в окружении службы. Например, для systemd это делается через параметр Environment в конфигурации соответствующего сервиса:
[Service]
Environment="GODEBUG=multipathtcp=0"После изменения конфигурации службу необходимо перезапустить. Также настройку можно добавить в основной файл go.mod проекта:
godebug multipathtcp=0У приложения есть возможность управлять MPTCP и отдельно для конкретных сокетов через API Go. Явные настройки сокета могут переопределять глобальное значение GODEBUG.
Команда Go подчёркивает, что отключение MPTCP на уровне отдельных приложений — ненадёжная долгосрочная мера. Достаточно оставить один доступный MPTCP-слушатель, чтобы сохранить условие для описанной атаки. Кроме того, исходная ошибка не ограничивается исключительно MPTCP.
Официальные рекомендации доступны в документации Go по настройке multipathtcp и в предупреждении команды безопасности Go от 29 октября 2026 года.
Какие версии ядра Linux уязвимы
Согласно уведомлению Linux Kernel CVE, ошибка появилась в ядре Linux 4.4. Она затрагивает более поздние версии, в которых присутствует соответствующий код. Исправления были включены в поддерживаемые стабильные ветки.
Основные версии ядра, в которых исправлена CVE-2026-98432:
| Ветка Linux | Исправленная версия |
|---|---|
| 5.10 | 5.10.272 |
| 5.15 | 5.15.223 |
| 6.1 | 6.1.190 |
| 6.6 | 6.6.159 |
| 6.12 | 6.12.113 |
| 6.18 | 6.18.56 |
| 7.2 | 7.2.10 |
| 7.3 | 7.3 |
Эти значения относятся к соответствующим стабильным веткам основного ядра. В дистрибутивах Linux исправления могут переноситься обратно в пакеты с другими номерами версий. Поэтому сравнивать только результат uname -r с приведённой таблицей недостаточно.
Например, дистрибутив может продолжать использовать собственную сборку ядра с более старым основным номером версии, но уже включить исправление безопасности. И наоборот, наличие относительно свежего ядра не гарантирует, что конкретный пакет уже обновлён.
Проверять необходимо версию установленного пакета, статус исправления в системе отслеживания уязвимостей дистрибутива и фактически загруженное ядро.
Перечень исправлений опубликован в официальном уведомлении Linux Kernel CVE.
Какие дистрибутивы Linux уже получили исправления
По состоянию на 31 октября 2026 года ситуация с обновлениями различается в зависимости от дистрибутива и используемой ветки ядра. Debian, Oracle Linux, SUSE и Amazon Linux уже выпустили исправления для некоторых поддерживаемых вариантов своих систем. Для Ubuntu и Red Hat Enterprise Linux обновления на эту дату ещё находились в работе или ожидали публикации.
Сводная информация по основным системам:
| Дистрибутив | Состояние на 31.10.2026 |
|---|---|
| Debian 12 Bookworm | Исправленные пакеты доступны: linux 6.1.190-1 и linux-6.12 6.12.113-1~deb12u1 |
| Debian 13 Trixie | Исправление включено в linux 6.12.113-1 |
| Debian testing и unstable | Исправления опубликованы |
| Ubuntu 22.04, 24.04, 26.04 и 26.10 | Исправления находятся в работе; необходимо следить за Ubuntu Security Tracker |
| Red Hat Enterprise Linux 8, 9 и 10 | Системы затронуты; исправления ожидаются в будущих обновлениях |
| Red Hat Enterprise Linux 7 | Не затронута этой уязвимостью |
| Oracle Linux | Исправленные пакеты опубликованы для ряда поддерживаемых веток |
| Amazon Linux | Исправления доступны для отдельных версий ядра Amazon Linux 2023 |
| SUSE и openSUSE | Исправления доступны для некоторых выпусков; статус зависит от продукта и ядра |
Таблица отражает ситуацию на дату подготовки материала. Перед обновлением необходимо проверять актуальные записи производителя: пакеты для разных выпусков и вариантов ядра могут публиковаться в разное время.
Для Ubuntu используется официальный трекер безопасности Canonical. Для RHEL актуальная информация размещается в Red Hat Customer Portal, а для Debian — в Debian Security Tracker.
Почему разные компании по-разному оценивают серьёзность CVE-2026-98432
Уязвимость получила оценку 9,8 балла CVSS от команды Linux Kernel CVE. Это критический уровень, который указывает на потенциально крайне серьёзные последствия эксплуатации.
Однако некоторые поставщики Linux оценивают риск ниже. Например, Red Hat указывает для своей оценки CVSS 5.9 и рассматривает практическое последствие прежде всего как отказ в обслуживании. В более поздних материалах Red Hat также характеризует проблему как важную для безопасности, указывая на высокую сложность успешной эксплуатации.
Причина расхождения заключается в разных предположениях о практической эксплуатации. Для получения результата злоумышленнику необходимо добиться определённого порядка выполнения операций в ядре. Это существенно сложнее, чем отправить один специально сформированный сетевой пакет и гарантированно получить выполнение кода.
При этом исследование Anthropic демонстрирует, что в конкретных условиях цепочка может приводить к удалённому выполнению команд с правами root. Поэтому низкую оценку одного поставщика нельзя трактовать как доказательство отсутствия серьёзного риска.
При оценке уязвимости администраторам следует учитывать одновременно:
- официальную оценку CVE Linux Kernel;
- оценку производителя используемого дистрибутива;
- наличие доступного сетевого сервиса и MPTCP-слушателя;
- возможность применения обновлённого эксплойта;
- критичность конкретного сервера и обрабатываемых им данных.
Официальную позицию Red Hat можно посмотреть в карточке CVE-2026-98432 в Red Hat Customer Portal.
Как проверить сервер Linux на наличие уязвимости
Первый шаг — определить версию работающего ядра и установленного пакета. Для этого достаточно стандартных команд Linux.
Проверка текущей версии ядра:
uname -r
Для Debian и Ubuntu можно дополнительно посмотреть установленный пакет ядра:
dpkg-query -W 'linux-image*' 2>/dev/null
Проверка наличия обновлений:
sudo apt update
apt list --upgradable
На системах с RHEL, AlmaLinux, Rocky Linux и совместимыми дистрибутивами используются другие средства управления пакетами. Например:
rpm -qa 'kernel*' | sort
Также полезно проверить, разрешено ли создание MPTCP-сокетов в ядре:
sysctl net.mptcp.enabled
Значение 1 означает, что ядро разрешает создание MPTCP-сокетов, а 0 — что эта возможность отключена на уровне соответствующего параметра.
Дополнительно можно проверить настройку миграции TCP-запросов:
sysctl net.ipv4.tcp_migrate_req
Если параметр отсутствует, это не следует считать доказательством отсутствия уязвимости. Аналогично, выключенный MPTCP не означает, что сервер защищён от самой ошибки IPv4 TCP.
Как устранить CVE-2026-98432
Основной способ устранения уязвимости — установка исправленного ядра, предоставленного разработчиком используемого дистрибутива. После обновления необходимо перезагрузить сервер, чтобы система действительно начала работать на новой версии ядра.
Рекомендуемый порядок действий:
- Определить дистрибутив и точную версию установленного ядра.
- Проверить состояние CVE-2026-98432 в официальном трекере безопасности производителя.
- Установить исправленные пакеты ядра, когда они доступны для конкретного выпуска системы.
- Проверить, что пакет установлен без ошибок и новая версия присутствует в загрузчике.
- Перезагрузить сервер в согласованное окно обслуживания.
- Повторно выполнить uname -r и убедиться, что загружено исправленное ядро.
- Проверить работу сетевых служб, контейнеров, виртуальных машин и приложений.
Для Debian и Ubuntu стандартная процедура обновления пакетов выглядит следующим образом:
sudo apt update
sudo apt full-upgrade
После установки обновлений следует проверить, требуется ли перезагрузка:
test -f /var/run/reboot-required && cat /var/run/reboot-required
Если обновление ядра установлено, но сервер продолжает работать на старой версии, уязвимость остаётся актуальной для работающего ядра. Сам факт наличия исправленного пакета на диске ещё не означает, что исправление уже применяется.
В некоторых корпоративных системах можно использовать live patching — технологию установки исправлений ядра без полной перезагрузки. Но наличие такого механизма не гарантирует, что для конкретной CVE уже подготовлен соответствующий патч. Необходимо проверять поддержку именно CVE-2026-98432 у поставщика live patching.
Можно ли временно защититься без обновления ядра
На системах, для которых исправленный пакет ещё не выпущен, администраторам приходится использовать временные меры снижения риска. Однако для CVE-2026-98432 важно не путать уменьшение поверхности атаки с устранением ошибки.
Наиболее разумные временные действия:
- ограничить доступ к сетевым службам с помощью межсетевого экрана;
- разрешать подключения к административным портам только из доверенных сетей;
- проверить приложения, которые создают MPTCP-слушатели;
- временно отключить MPTCP там, где он не используется и это не нарушает работу приложений;
- отслеживать публикацию обновлений безопасности для конкретного дистрибутива;
- усилить мониторинг сетевых подключений и событий ядра.
Некоторые поставщики обсуждают дополнительные сетевые ограничения, например фильтрацию IPv4-пакетов с IP Options. Но подобные правила могут влиять на сетевую совместимость и не должны внедряться без тестирования. На дату подготовки материала нет универсального временного решения, которое можно считать полноценной заменой исправлению ядра.
Особенно важно: отключение MPTCP само по себе не устраняет CVE-2026-98432. Исходная ошибка находится в обычной обработке IPv4 TCP, а Go Security Team отдельно предупреждает, что похожие варианты атаки могут быть возможны и без MPTCP-слушателя.
Red Hat также указывает, что универсальная мера снижения риска, отвечающая требованиям простоты, применимости и стабильности, для затронутых систем не определена. Поэтому временные ограничения не должны становиться причиной откладывать установку исправленного ядра.
Есть ли подтверждённые случаи эксплуатации CVE-2026-98432 в интернете
На момент подготовки материала BleepingComputer и другие источники не сообщали о подтверждённых массовых атаках с использованием CVE-2026-98432 в реальных условиях. Anthropic продемонстрировала работоспособность эксплойта в исследовательской среде, но это не равнозначно подтверждению эксплуатации уязвимости злоумышленниками в интернете.
Тем не менее отсутствие публичных сообщений об атаках не означает, что риск можно игнорировать. После публикации технических подробностей уязвимость становится более доступной для анализа специалистам по безопасности и потенциальным злоумышленникам.
Важную роль играет и развитие автоматизированного поиска уязвимостей. Исследование Anthropic показывает, что современные ИИ-модели способны не только находить ошибки в программном обеспечении, но и помогать строить сложные цепочки эксплуатации. Это может сократить время между обнаружением уязвимости и появлением рабочих атакующих инструментов.
Для администраторов это означает необходимость быстрее реагировать на критические уведомления, особенно когда проблема затрагивает сетевой стек и может быть доступна удалённому атакующему.
Почему эта уязвимость важна для будущего серверной безопасности
CVE-2026-98432 демонстрирует сразу несколько тенденций, которые будут влиять на администрирование Linux-серверов в ближайшие годы.
Первая — сложность современных сетевых стеков. Даже давно существующий механизм TCP может содержать ошибки, которые остаются незамеченными в течение многих лет. Особенно опасны проблемы управления памятью, возникающие при параллельной обработке сетевых запросов.
Вторая — увеличение роли автоматизированного анализа кода. ИИ-инструменты уже способны помогать исследователям разбирать сложные участки программного обеспечения и искать способы эксплуатации ошибок. В перспективе это может ускорить как обнаружение уязвимостей, так и разработку защитных механизмов.
Третья — необходимость учитывать поведение приложений, а не только настройки операционной системы. Пример Go 1.24 показывает, что обновление языка программирования или стандартной библиотеки может изменить сетевое поведение приложения без очевидного изменения конфигурации сервера.
В ближайшем будущем администраторам Linux придётся уделять больше внимания следующим направлениям:
- контролю фактически работающих версий ядра;
- инвентаризации сетевых протоколов и слушающих сокетов;
- проверке изменений поведения приложений после обновления runtime;
- автоматизации установки критических обновлений;
- использованию live patching там, где оно действительно поддерживается;
- сегментации сетей и сокращению доступности административных интерфейсов.
Подобные меры не заменяют обновление ядра, но помогают уменьшить последствия будущих уязвимостей и сократить время реакции на новые угрозы.
Выводы
CVE-2026-98432 — серьёзная уязвимость ядра Linux, связанная с ошибкой use-after-free в обработке IPv4 TCP. Она присутствует в коде, который используется с Linux 4.4, а её эксплуатация при определённых условиях может привести к удалённому выполнению команд с правами root.
Исследование Anthropic показало, что экспериментальная модель Claude способна построить рабочую цепочку атаки на сервер с MPTCP-слушателем. Это особенно важно для администраторов сетевых сервисов на Go 1.24 и новее, поскольку в этой версии MPTCP по умолчанию включён для входящих слушателей на Linux.
Исправления уже включены в ряд стабильных веток ядра, а некоторые дистрибутивы выпустили обновлённые пакеты. Для Ubuntu и RHEL на 31 октября 2026 года обновления ещё находились в работе. Поэтому администраторам необходимо следить за официальными уведомлениями своих поставщиков и устанавливать исправленные ядра сразу после их публикации.
Главный вывод: отключение MPTCP может уменьшить риск именно продемонстрированной цепочки эксплуатации, но не устраняет саму уязвимость. Надёжная защита достигается установкой исправленного ядра и загрузкой системы с обновлённой версией. До этого момента следует ограничить доступ к сетевым службам, проверить Go-приложения и внимательно отслеживать изменения статуса CVE.
Часто задаваемые вопросы
Это критическая уязвимость ядра Linux типа use-after-free в обработке IPv4 TCP-соединений. При определённых условиях она может привести к удалённому выполнению команд с привилегиями root.
Команда Linux Kernel CVE присвоила проблеме оценку CVSS 9.8 из 10. Некоторые поставщики Linux используют более низкие оценки, учитывая сложность успешной эксплуатации и наиболее вероятные последствия.
Уязвимый код появился в Linux 4.4. Проблема затрагивает более поздние ветки, в которых присутствует соответствующий код. Исправления опубликованы для стабильных веток 5.10, 5.15, 6.1, 6.6, 6.12, 6.18, 7.2 и 7.3.
Anthropic продемонстрировала удалённую эксплуатацию без аутентификации и взаимодействия пользователя на Linux-сервере с MPTCP-слушателем. Однако это исследовательская демонстрация, а не гарантия успешной атаки на любой сервер с уязвимым ядром.
Multipath TCP — расширение TCP, позволяющее одному логическому соединению использовать несколько сетевых путей. Оно может повышать устойчивость подключения и эффективнее использовать несколько сетевых интерфейсов.
Нет. Это может убрать условие, необходимое для продемонстрированной Anthropic цепочки атаки, но исходная ошибка находится в обычной обработке IPv4 TCP. Команда Go отдельно предупреждает, что возможны и другие варианты эксплуатации. Необходимо установить исправленное ядро.
Начиная с Go 1.24, MPTCP по умолчанию включён для входящих TCP-слушателей в Linux, если ядро поддерживает этот механизм. Поэтому некоторые Go-сервисы могут использовать MPTCP без отдельной настройки со стороны администратора.
Можно установить переменную окружения GODEBUG=multipathtcp=0 или добавить строку godebug multipathtcp=0 в основной go.mod проекта. Это временная мера, которая не заменяет обновление ядра.
Выполните команду sysctl net.mptcp.enabled. Значение 1 означает, что создание MPTCP-сокетов разрешено на уровне ядра. Однако этот параметр не показывает, какие именно приложения используют MPTCP.
Нужно проверить версию установленного пакета ядра в официальном трекере безопасности дистрибутива, установить исправление и перезагрузить систему. После перезагрузки следует проверить фактически загруженную версию командой uname -r.
Обычное обновление пакета ядра не заменяет ядро, которое уже работает в памяти. Для применения исправления необходимо загрузиться с новой версией либо использовать поддерживаемый поставщиком механизм live patching.
Основная проблема с повторной обработкой SYN-запросов относится к IPv4. В официальном уведомлении Linux Kernel CVE указано, что аналогичная проблема для основного сценария IPv6 отсутствует, поскольку соответствующие параметры копируются при создании нового сокета. Отдельный риск миграции запросов IPv6 описан как вопрос для отдельного исправления.
На 31 октября 2026 года публичных подтверждений массовой эксплуатации в реальных атаках не было. Anthropic продемонстрировала работоспособность эксплойта в исследовательской среде, что само по себе требует серьёзного отношения к уязвимости.
