SCTPhantom (CVE-2026-64564): 18-летняя дыра в ядре Linux SCTP открывает путь к root и выходу из контейнера

Коротко: что произошло

6 августа 2026 года исследователи Corvus AI из Tencent Zhuque Lab публично раскрыли CVE-2026-64564, получившую имя SCTPhantom, — ошибку use-after-free в реализации SCTP (Stream Control Transmission Protocol) в ядре Linux. Уязвимость существует с декабря 2007 года (Linux 2.6.25) и имеет оценку CVSS v4.0: 8.5 (High). Локальный атакующий с минимальными привилегиями может повысить их до root и в ряде конфигураций покинуть изолированный контейнер. Исправление выпущено в стабильных ветках ядра 3–4 августа; в каталоге активно эксплуатируемых уязвимостей CISA KEV SCTPhantom на момент публикации отсутствует, однако публичного кода эксплойта нет ровно до момента, когда он появится.

Для команд, которые управляют Linux-серверами или строят облачную инфраструктуру, это сигнал немедленно проверить версию ядра и обновиться. У большинства организаций на уязвимых версиях SCTP доступен через сокеты без специальных возможностей — барьер входа ниже, чем кажется.

Как работает уязвимость: SCTP ASCONF и висячий указатель

SCTP — протокол транспортного уровня, разработанный для телекоммуникационных приложений; он поддерживает многодомность (multihoming): один сеанс может использовать несколько IP-адресов одновременно. Функция Dynamic Address Reconfiguration (RFC 5061) позволяет участникам сеанса добавлять и удалять транспортные адреса «на лету» через ASCONF-чанки.

Ошибка прячется в логике обработки последовательности параметров внутри одного ASCONF-чанка. Атакующий отправляет пакет с тремя параметрами подряд: ADD-IP L (добавить адрес L), DEL-IP L (удалить тот же адрес L) и DEL-IP 0.0.0.0 (удалить «wildcard»). Ядро удаляет транспорт, освобождает связанную память, но оставляет устаревший (dangling) указатель в полях primary_path и active_path ассоциации. Последующая операция с сокетом — например, getsockopt(SCTP_STATUS) — обращается к уже освобождённой памяти, что открывает классический UAF-примитив для контроля потока выполнения.

Upstream-патч (коммит 9b2854f86f0b) исправляет проблему одной проверкой: если транспорт, подлежащий удалению, совпадает с транспортом, обрабатывающим текущий ASCONF, ядро возвращает SCTP_ERROR_REQ_REFUSED и не трогает память.

Масштаб угрозы: дистрибутивы и версии под ударом

Уязвимый код попал в ядро вместе с коммитом 42e30bf3463c в декабре 2007 года. Это означает, что все ядра от Linux 2.6.25 до выпуска патча подвержены проблеме — почти восемнадцать лет. Исследователи Tencent Zhuque Lab подтвердили успешную эксплуатацию на шести из восьми протестированных конфигураций:

• Debian 13
• Ubuntu 24.04
• Rocky Linux 9
• RHEL 9
• OpenCloudOS

В двух конфигурациях побег из контейнера заблокировали дополнительные политики seccomp и namespace. Атака требует только стандартного сокетного доступа — без CAP_NET_ADMIN и CAP_SYS_ADMIN.

Исправленные версии ядра:

• 7.1.6
• 6.18.42
• 6.12.101
• 6.6.148

Debian выпустил обновление безопасности для Debian 13 с этим и сопутствующим исправлением «Zapscape» (CVE-2026-64531) 7 августа. Дистрибутивы на базе RHEL и Ubuntu выпускают обновления по обычному циклу — следите за уведомлениями от своего вендора.

Что это значит для облачных и DevOps-команд

Первая реакция: обновить ядро. Вторая: понять, почему такая уязвимость вообще существовала восемнадцать лет.

SCTP редко появляется в списках разрешённых портов, но в ядре он присутствует и на большинстве систем не отключён. Любой локальный пользователь или процесс, запущенный в контейнере без строгих ограничений seccomp, потенциально может использовать SCTP-сокет — и тем самым получить путь к root на хосте. В Kubernetes-кластерах, где воркеры разделяют ядро с несколькими подами, цепочка «вредоносный под → root на ноде → горизонтальное перемещение» приобретает реальные очертания.

В контексте информационной безопасности SCTPhantom наглядно иллюстрирует три системные проблемы: старый код без регулярного ревью способен нести уязвимости годами; автоматизированный поиск ошибок (Corvus AI использует агентный пайплайн для анализа ядра) ускоряет обнаружение то, что раньше оставалось невидимым; контейнерная изоляция не равна изоляции от уязвимостей ядра — её дополняют, но не заменяют, seccomp, AppArmor/SELinux и политики сетевых пространств имён.

Для команд, использующих живые ядра в production, сценарий обновления прост: проверить текущую версию (uname -r), обновиться через пакетный менеджер дистрибутива, при невозможности немедленного обновления — заблокировать загрузку модуля sctp через blacklist sctp в /etc/modprobe.d/.

Как проверить и закрыть уязвимость

Шаг 1. Проверьте версию ядра. Выполните uname -r. Если версия ниже 6.6.148 / 6.12.101 / 6.18.42 / 7.1.6 — система уязвима.

Шаг 2. Обновите ядро через пакетный менеджер. На Debian/Ubuntu: apt update && apt upgrade linux-image-$(uname -r). На RHEL/Rocky: dnf update kernel. Перезагрузка обязательна — ядро не обновляется «горячим» способом без специального инструментария (kpatch/livepatch), и в данном случае patch-политика вашего вендора является источником истины по срокам доступности.

Шаг 3. Временная мера — отключить SCTP. Если немедленная перезагрузка невозможна: добавьте install sctp /bin/true в файл /etc/modprobe.d/disable-sctp.conf и убедитесь, что модуль не загружен (lsmod | grep sctp). Важно: это не защищает, если модуль уже загружен в памяти — остановить его безопасно без перезагрузки нельзя.

Шаг 4. Проверьте политики seccomp и namespace. Tencent установила, что строгие seccomp-профили в двух из восьми тестов заблокировали эксплойт. Включённый seccomp:RuntimeDefault в Kubernetes-подах и unconfined_seccomp в Docker — разные вещи; убедитесь, что ваши рабочие нагрузки не работают в режиме --security-opt=seccomp=unconfined.

Шаг 5. Настройте мониторинг.} Добавьте CVE-2026-64564 в реестр отслеживаемых уязвимостей; включите алерты SIEM или системы управления уязвимостями на появление публичного эксплойта. Сейчас его нет — это временное преимущество, а не постоянная гарантия.

Часто задаваемые вопросы

Это эксплуатируется в реальных атаках? По состоянию на 7 августа 2026 года публичного кода эксплойта нет и CVE-2026-64564 отсутствует в каталоге CISA KEV. Исследователи Tencent Zhuque Lab описали техническую возможность побега, не публикуя рабочий exploit. Это даёт временное окно для обновления — воспользуйтесь им.

Затронуты ли облачные виртуальные машины? Да. Если ВМ работает на ядре Linux версии до 6.6.148 / 6.12.101 / 6.18.42 / 7.1.6, она уязвима. Управляемые Kubernetes-сервисы (EKS, GKE, AKS) как правило обновляют ядра нод быстрее самостоятельных кластеров — проверяйте версии нод через API своего облачного провайдера.

SCTP нигде не используется в нашем стеке. Мы безопасны? Уязвимость не требует, чтобы ваш сервис использовал SCTP. Достаточно, чтобы модуль был загружен в ядре. По умолчанию на большинстве дистрибутивов SCTP доступен любому процессу через стандартные syscall. Единственная надёжная защита — обновить ядро или выгрузить модуль.

Как давно эта уязвимость существовала? Уязвимый код попал в ядро в декабре 2007 года вместе с Linux 2.6.25. CVE был присвоен 4 августа 2026 года после трёхнедельного координированного раскрытия (первое обнаружение — 12 июля). Почти 18 лет.

Помогает ли контейнеризация защититься? Частично. Контейнер, использующий отдельное сетевое пространство имён, ограничивает некоторые векторы. Seccomp-профиль, запрещающий создание SCTP-сокетов, блокировал эксплойт в тестах Tencent. Однако контейнер разделяет ядро с хостом: пользователь host-системы или другой контейнер с более свободными правами по-прежнему уязвимы. Обновление ядра — единственная полная защита.

Источники

The Hacker News — 18-Year-Old Linux SCTP Flaw Could Let Local Users Gain Root and Escape Containers (6 августа 2026).

Tencent Zhuque Lab (Corvus AI) — SCTPhantom: An 18-Year-Old SCTP ASCONF Transport Use-After-Free (6 августа 2026; первичный технический анализ).

GBHackers — 18-Year-Old Linux Kernel SCTP Vulnerability Lets Attackers Gain Root and Escape Containers (2026).

9to5Linux — New Debian 13 Kernel Security Update Fixes Zapscape and SCTPhantom (7 августа 2026).