Уязвимость SCTPhantom в сетевом коде SCTP ядра Linux почти 18 лет оставалась незамеченной. Ошибка появилась в Linux 2.6.25, выпущенном в 2008 году, и присутствовала во всех последующих версиях вплоть до исправления. Исследователи Tencent Zhuque Lab сообщили, что состояние use-after-free позволяет локальному пользователю получить полные права root. В их опытах атака из контейнера завершалась выходом на базовую систему и захватом root-доступа. Уязвимости присвоили обозначение CVE-2026-64564, а название SCTPhantom дали сами исследователи.
Исправления вышли 3 августа 2026 года в стабильных ядрах Linux 7.1.6, Linux 6.18.42, Linux 6.12.101 и Linux 6.6.148. По имеющимся данным, команда Linux CVE зарегистрировала CVE-2026-64564 4 августа, за два дня до публичного раскрытия 6 августа. Номер версии ядра сам по себе мало что доказывает: Debian, Ubuntu, Red Hat и другие поставщики часто переносят исправления в старые ветки, не меняя их на новую основную версию. Проверять статус нужно по бюллетеню безопасности или трекеру уязвимостей конкретного дистрибутива.
SCTP, или протокол управления передачей потоков, работает на транспортном уровне и допускает использование нескольких сетевых путей в рамках одного соединения. Механизм динамической перенастройки адресов разрешает узлу добавлять и удалять адреса прямо во время активного сеанса. SCTPhantom считается локальной уязвимостью: злоумышленнику нужен доступ к системе, а SCTP должен быть доступен для создания и настройки сокета. Это заметно сужает круг целей по сравнению с сетевой атакой без авторизации. Если SCTP на сервере не используется, блокировка его модуля ядра полностью убирает данный участок поверхности атаки.
Ошибка возникла из-за того, что ядро опиралось сразу на два представления об адресе сетевого пути. Запрос на удаление проверялся относительно исходного адреса пакета, но сама операция выполнялась над путем, выбранным по другому адресу внутри сообщения. Согласно бюллетеню ядра Linux, одно сообщение могло последовательно содержать адрес, команду удаления этого же адреса и запрос удаления по шаблону. В результате сетевой путь освобождался, после чего код снова обращался к указателю на уже освобожденный объект. Соединение продолжало ссылаться на память, которую ядро считало свободной: классический use-after-free, также называемый висячим указателем или состоянием dangling transport.
Патч запрещает удалять тот сетевой путь, относительно которого в данный момент обрабатывается сообщение. Тем самым объект нельзя освободить посреди операции, а затем повторно использовать через устаревший указатель. До установки исправления повреждение памяти теоретически способно закончиться аварийным завершением ядра, отказом в обслуживании либо, при управляемом размещении объектов в памяти, выполнением действий с правами ядра.
Tencent Zhuque Lab заявила об успешном получении root на протестированных сборках Debian 13, Ubuntu 24.04, Rocky Linux 9, Red Hat Enterprise Linux 9 (RHEL 9) и OpenCloudOS. Во всех случаях исследователи работали в условиях, где SCTP был доступен. Эти результаты не означают, что любая установка перечисленных систем заведомо эксплуатируема: итог зависит от примененных дистрибутивом патчей, конфигурации ядра и возможности открыть подходящий SCTP-сокет.
Первая версия эксплойта Tencent требовала включенных параметров net.sctp.addip_enable и net.sctp.addip_noauth_enable. Их изменение обычно требует расширенных прав управления сетью, поэтому сначала обязательным условием считалась capability CAP_NET_ADMIN. Позже исследователи нашли другой путь: нужная функция SCTP включалась отдельно для сокета, без изменения обоих sysctl-параметров. В испытании контейнер сохранил стандартный профиль seccomp и не получил ни CAP_NET_ADMIN, ни CAP_SYS_ADMIN. Root-доступ к хосту удалось захватить в шести из восьми попыток, то есть в 75% случаев.
Контейнерный результат пока опирается лишь на тесты Tencent Zhuque Lab. Независимого воспроизведения на момент раскрытия не было, а использованный контейнерный runtime компания не назвала. Сама Tencent указала, что практическая возможность атаки зависит от доступа к SCTP-сокетам, профиля seccomp, политики пользовательских пространств имен и прочих ограничений контейнера и хоста. Бюллетень openKylin описал последствия осторожнее: паника ядра и отказ в обслуживании, без подтверждения повышения привилегий и выхода из контейнера. Tencent оценила SCTPhantom в 8,5 балла по CVSS 4.0.
По состоянию на 7 августа 2026 года общедоступного кода эксплойта не появилось. The Hacker News не обнаружило CVE-2026-64564 в каталоге Known Exploited Vulnerabilities (KEV) американского агентства CISA. В National Vulnerability Database (NVD) тогда отсутствовали и оценка критичности, и классификация типа слабости. Поэтому сообщение о рабочем повышении привилегий нельзя путать с доказательством атак в реальной инфраструктуре.
В том же SCTP-коде нашли еще одну отдельную ошибку use-after-free с висячим транспортным объектом. Ее исправили 6 августа 2026 года, уже после выпуска четырех стабильных ядер от 3 августа. Следовательно, Linux 7.1.6, 6.18.42, 6.12.101 и 6.6.148 закрывают SCTPhantom, но не содержат патч для второй SCTP-уязвимости. Упоминание, что эти четыре выпуска несут «оба исправления», относится к SCTPhantom и Zapscape. Zapscape раскрыли в тот же день; это не связанная с SCTP уязвимость выхода из виртуальной машины KVM.
Обнаружение SCTPhantom Tencent приписывает Corvus AI, собственной многоагентной исследовательской системе для анализа ядра Linux. В 2026 году это уже не первая долго спавшая ошибка ядра, найденная при машинной поддержке: в июле 2026 года таким примером стала GhostLock. Источником сведений о публикации указан Fourier в X.
На уязвимых системах с доступным SCTP требуется обновление ядра либо дистрибутивного пакета с перенесенным патчем. Если протокол не нужен, разумнее запретить загрузку модуля SCTP, а не надеяться на отсутствие подходящего приложения. Для контейнерных хостов отдельно проверяют возможность создания SCTP-сокетов, правила seccomp, политику user namespace и выданные Linux capabilities. После установки выпусков от 3 августа следует также выяснить, добавил ли поставщик более позднее исправление второй SCTP-ошибки от 6 августа.[/final]
Изображение носит иллюстративный характер
Исправления вышли 3 августа 2026 года в стабильных ядрах Linux 7.1.6, Linux 6.18.42, Linux 6.12.101 и Linux 6.6.148. По имеющимся данным, команда Linux CVE зарегистрировала CVE-2026-64564 4 августа, за два дня до публичного раскрытия 6 августа. Номер версии ядра сам по себе мало что доказывает: Debian, Ubuntu, Red Hat и другие поставщики часто переносят исправления в старые ветки, не меняя их на новую основную версию. Проверять статус нужно по бюллетеню безопасности или трекеру уязвимостей конкретного дистрибутива.
SCTP, или протокол управления передачей потоков, работает на транспортном уровне и допускает использование нескольких сетевых путей в рамках одного соединения. Механизм динамической перенастройки адресов разрешает узлу добавлять и удалять адреса прямо во время активного сеанса. SCTPhantom считается локальной уязвимостью: злоумышленнику нужен доступ к системе, а SCTP должен быть доступен для создания и настройки сокета. Это заметно сужает круг целей по сравнению с сетевой атакой без авторизации. Если SCTP на сервере не используется, блокировка его модуля ядра полностью убирает данный участок поверхности атаки.
Ошибка возникла из-за того, что ядро опиралось сразу на два представления об адресе сетевого пути. Запрос на удаление проверялся относительно исходного адреса пакета, но сама операция выполнялась над путем, выбранным по другому адресу внутри сообщения. Согласно бюллетеню ядра Linux, одно сообщение могло последовательно содержать адрес, команду удаления этого же адреса и запрос удаления по шаблону. В результате сетевой путь освобождался, после чего код снова обращался к указателю на уже освобожденный объект. Соединение продолжало ссылаться на память, которую ядро считало свободной: классический use-after-free, также называемый висячим указателем или состоянием dangling transport.
Патч запрещает удалять тот сетевой путь, относительно которого в данный момент обрабатывается сообщение. Тем самым объект нельзя освободить посреди операции, а затем повторно использовать через устаревший указатель. До установки исправления повреждение памяти теоретически способно закончиться аварийным завершением ядра, отказом в обслуживании либо, при управляемом размещении объектов в памяти, выполнением действий с правами ядра.
Tencent Zhuque Lab заявила об успешном получении root на протестированных сборках Debian 13, Ubuntu 24.04, Rocky Linux 9, Red Hat Enterprise Linux 9 (RHEL 9) и OpenCloudOS. Во всех случаях исследователи работали в условиях, где SCTP был доступен. Эти результаты не означают, что любая установка перечисленных систем заведомо эксплуатируема: итог зависит от примененных дистрибутивом патчей, конфигурации ядра и возможности открыть подходящий SCTP-сокет.
Первая версия эксплойта Tencent требовала включенных параметров net.sctp.addip_enable и net.sctp.addip_noauth_enable. Их изменение обычно требует расширенных прав управления сетью, поэтому сначала обязательным условием считалась capability CAP_NET_ADMIN. Позже исследователи нашли другой путь: нужная функция SCTP включалась отдельно для сокета, без изменения обоих sysctl-параметров. В испытании контейнер сохранил стандартный профиль seccomp и не получил ни CAP_NET_ADMIN, ни CAP_SYS_ADMIN. Root-доступ к хосту удалось захватить в шести из восьми попыток, то есть в 75% случаев.
Контейнерный результат пока опирается лишь на тесты Tencent Zhuque Lab. Независимого воспроизведения на момент раскрытия не было, а использованный контейнерный runtime компания не назвала. Сама Tencent указала, что практическая возможность атаки зависит от доступа к SCTP-сокетам, профиля seccomp, политики пользовательских пространств имен и прочих ограничений контейнера и хоста. Бюллетень openKylin описал последствия осторожнее: паника ядра и отказ в обслуживании, без подтверждения повышения привилегий и выхода из контейнера. Tencent оценила SCTPhantom в 8,5 балла по CVSS 4.0.
По состоянию на 7 августа 2026 года общедоступного кода эксплойта не появилось. The Hacker News не обнаружило CVE-2026-64564 в каталоге Known Exploited Vulnerabilities (KEV) американского агентства CISA. В National Vulnerability Database (NVD) тогда отсутствовали и оценка критичности, и классификация типа слабости. Поэтому сообщение о рабочем повышении привилегий нельзя путать с доказательством атак в реальной инфраструктуре.
В том же SCTP-коде нашли еще одну отдельную ошибку use-after-free с висячим транспортным объектом. Ее исправили 6 августа 2026 года, уже после выпуска четырех стабильных ядер от 3 августа. Следовательно, Linux 7.1.6, 6.18.42, 6.12.101 и 6.6.148 закрывают SCTPhantom, но не содержат патч для второй SCTP-уязвимости. Упоминание, что эти четыре выпуска несут «оба исправления», относится к SCTPhantom и Zapscape. Zapscape раскрыли в тот же день; это не связанная с SCTP уязвимость выхода из виртуальной машины KVM.
Обнаружение SCTPhantom Tencent приписывает Corvus AI, собственной многоагентной исследовательской системе для анализа ядра Linux. В 2026 году это уже не первая долго спавшая ошибка ядра, найденная при машинной поддержке: в июле 2026 года таким примером стала GhostLock. Источником сведений о публикации указан Fourier в X.
На уязвимых системах с доступным SCTP требуется обновление ядра либо дистрибутивного пакета с перенесенным патчем. Если протокол не нужен, разумнее запретить загрузку модуля SCTP, а не надеяться на отсутствие подходящего приложения. Для контейнерных хостов отдельно проверяют возможность создания SCTP-сокетов, правила seccomp, политику user namespace и выданные Linux capabilities. После установки выпусков от 3 августа следует также выяснить, добавил ли поставщик более позднее исправление второй SCTP-ошибки от 6 августа.[/final]
