19.08.2026 — CVE-2026-64564 – SCTPhantom {#CVE-2026-64564}

Идентификатор CVE (CVE ID): CVE-2026-64564

Ссылка на CVE: <https://nvd.nist.gov/vuln/detail/CVE-2026-64564>

Ссылка на NVD: <https://www.cve.org/CVERecord?id=CVE-2026-64564>

SCTPhantom — уязвимость обращения к освобожденной памяти (use-after-free) в подсистеме SCTP ядра Linux, позволяющая локальному непривилегированному процессу получить права суперпользователя (root) на узле. В контейнере с минимальными привилегиями и штатным профилем seccomp, по данным исследователей, возможен выход из контейнера на узел. Вектор доступен только при загруженном модуле sctp; Kubernetes и сетевые плагины SCTP не используют, поэтому блокировка модуля закрывает вектор без потерь для большинства кластеров.

Исследователи Tencent продемонстрировали рабочий эксплойт, поэтому обновление следует считать срочным.

Базовые меры включают:

  • для Managed Service for Kubernetes применение защитного DaemonSet (основная мера — ревизия образа узла с исправлением — еще не выпущена);
  • для Compute Cloud временная блокировка модуля и обновление ядра;
  • ограничение размещения недоверенных нагрузок;
  • контроль конфигурации и обновления.

Описание {#description-CVE-2026-64564}

Уязвимость существует в обработке сообщений протокола SCTP ASCONF (Dynamic Address Reconfiguration, RFC 5061). Ошибка возникает из-за расхождения между адресом, который проверяется при удалении пути, и адресом, который используется для последующей обработки. Это позволяет удалить путь и затем обратиться к уже освобожденной памяти. При наличии локального непривилегированного доступа и загруженного модуля sctp обращение к освобожденной памяти приводит к повышению привилегий до суперпользователя.

По данным исследователей Tencent Zhuque Lab, обнаруживших уязвимость, в контейнерной среде эксплуатация возможна без предоставления контейнеру CAPNETADMIN и CAPSYSADMIN при активном штатном профиле seccomp: ранние версии эксплойта требовали включенных sysctl net.sctp.addipenable и net.sctp.addipnoauth_enable, но затем был найден путь, включающий нужные возможности на уровне отдельного сокета и не затрагивающий эти sysctl. Выход из контейнера — заявление Tencent на основе собственного тестирования; независимо результат пока не воспроизведен. На отдельной виртуальной машине выход из контейнера неприменим — угроза сводится к локальному повышению привилегий до root.

Публичная эксплуатация уязвимости в реальных атаках на момент публикации не зафиксирована; исследователи Tencent продемонстрировали рабочий эксплойт на нескольких дистрибутивах. Вендоры дистрибутивов выпускают бэкпорты исправления, сохраняя прежнюю версию в строке, поэтому версия ядра сама по себе не является признаком уязвимости — необходимо сверяться с бюллетенем вендора.

Уязвимые продукты и версии {#vulnerable-products-and-versions-CVE-2026-64564}

Уязвимы все версии ядра Linux начиная с 2.6.25 (2008 год) до версии с исправлением.

Безопасная версия уязвимого продукта или патч {#safe-version-CVE-2026-64564}

Уязвимость устранена в версиях:

  • 6.6.148 (стабильная ветка 6.6.y)
  • 6.12.101 (стабильная ветка 6.12.y)
  • 6.18.42 (стабильная ветка 6.18.y)
  • 7.1.6 (стабильная ветка 7.1.y)
  • 7.2-rc5 (mainline).

{% note info %}

Вендоры дистрибутивов бэкпортируют исправление, сохраняя прежний номер версии ядра. Сверяйтесь с бюллетенем вашего дистрибутива. Для ядер со встроенной поддержкой SCTP (CONFIGIPSCTP=y, а не модулем) блокировка модуля неприменима, единственная защита — обновление ядра.

{% endnote %}

Уровень опасности согласно CVSS {#severity-level-CVE-2026-64564}

  • CVSS 4.0: 8.5 (High) — оценка Tencent Zhuque Lab — исследователей, нашедших уязвимость.
  • CVSS 3.1: 9.8 (Critical) — оценка CNA kernel.org, вектор AV:N. Сетевой вектор в этой оценке спорен: эксплуатация требует локального доступа.

Собственной оценки и классификации слабости (CWE) NVD на момент публикации не предоставил.

Рекомендации по обнаружению уязвимости {#recommendations-for-detection-CVE-2026-64564}

Проверка состоит из двух частей: необходимо проверить, загружен ли модуль сейчас и заблокирована ли его автозагрузка. Чистого вывода lsmod недостаточно — непривилегированный процесс может сам загрузить модуль, создав SCTP-сокет, поэтому без блокировки автозагрузки узел остается достижимым для атаки.

  • Проверьте, загружен ли модуль sctp сейчас:
<code>  $ lsmod | grep -E '^sctp'</code>

Если строка есть, модуль загружен, узел в экспозиции. Если вывод пуст, модуль сейчас не загружен — проверьте блокировку автозагрузки.

  • Проверьте, заблокирована ли автозагрузка:
<code>  $ cat /etc/modprobe.d/blacklist-sctp.conf 2>/dev/null
  # install sctp /bin/false
  # install sctp_diag /bin/false
  # blacklist sctp
  # blacklist sctp_diag

  $ modprobe sctp</code>

Наличие директив install/blacklist и ошибка при modprobe sctp означают, что блокировка работает. Вектор недоступен, только если модуль не загружен и автозагрузка заблокирована.

  • Проверьте, собрано ли ядро со встроенной поддержкой SCTP:
<code>  $ grep CONFIG_IP_SCTP /boot/config-$(uname -r)</code>

Значение =y — SCTP встроен в ядро, блокировка модуля неприменима, требуется обновление ядра. Значение =m — SCTP собран модулем, блокировка применима.

  • Проверьте нагрузки в кластере Managed Service for Kubernetes, которые используют SCTP и будут затронуты блокировкой модуля:
<code>  $ kubectl get svc -A -o json | jq -r '.items[] | select(.spec.ports[]?.protocol=="SCTP") | "\(.metadata.namespace)/\(.metadata.name)"'
  $ kubectl get pods -A -o json | jq -r '.items[] | select(.spec.containers[].ports[]?.protocol=="SCTP") | "\(.metadata.namespace)/\(.metadata.name)"'
  $ kubectl get netpol -A -o json | jq -r '.items[] | select((.spec.ingress[]?.ports[]?.protocol=="SCTP") or (.spec.egress[]?.ports[]?.protocol=="SCTP")) | "\(.metadata.namespace)/\(.metadata.name)"'</code>
  • Проверьте доступность SCTP-сокета:

{% note alert %}

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

{% endnote %}

<code>  $ python3 -c 'import socket; socket.socket(socket.AF_INET, socket.SOCK_STREAM, 132); print("SCTP available")'</code>

Вывод SCTP available — сокет доступен, вектор в экспозиции. Ошибка OSError: Protocol not supported — SCTP на узле недоступен.

Митигации {#mitigation-CVE-2026-64564}

Основная мера защиты — блокировка модуля sctp, которая полностью отключает SCTP. Для большинства нагрузок это безопасно, но если ваша нагрузка использует SCTP (телеком, VoIP, сигнализация SS7/Diameter), блокировка сломает ее трафик — в этом случае модуль не блокируйте, а обновите ядро. Перед применением проверьте зависимость от SCTP командами из раздела Рекомендации по обнаружению уязвимости.

Managed Service for Kubernetes {#k8s-CVE-2026-64564}

  • Kubernetes и сетевые плагины (Cilium, Calico) SCTP не используют, поэтому для большинства кластеров блокировка безопасна. Проверьте, есть ли в кластере объекты с protocol: SCTP (Service, NetworkPolicy, порты подов) — командами из раздела Рекомендации по обнаружению уязвимости. Если такие объекты есть и SCTP вам нужен, DaemonSet не применяйте — дождитесь ревизии образа узла с исправленным ядром.
  • Ревизия образа узла с исправленным ядром на момент публикации еще не выпущена, поэтому основная мера — защитный DaemonSet из репозитория yc-mk8s-sctphantom-mitigation: kubectl apply -f sctphantom-mitigation-daemonset.yaml. DaemonSet пассивно проверяет состояние модулей, не открывая SCTP-сокет, ставит блокировку и при отсутствии живых SCTP-соединений выгружает модули. Успех — вывод mitigation applied successfully; если модуль уже резидентен и не выгружается — вывод mitigation applied PARTIALLY, блокировка стоит, но до перезагрузки узел остается уязвимым.
  • На узле, где модуль sctp уже загружен, выгрузить его чаще всего не удается: rmmod возвращает ERROR: Module sctp is in use даже при отсутствии активных соединений — ненулевой счетчик ссылок не означает фактического использования модуля. Блокировка сработает только после перезагрузки узла или пересоздания группы узлов Managed Service for Kubernetes. Найти узлы с частичной защитой: kubectl logs -n kube-system -l app=cve-2026-64564-fix -c apply-fix --prefix | grep -E 'PARTIALLY|STILL LOADED'.
  • Постоянное решение — исправленное ядро, которое будет в новой ревизии образа узла в рамках текущей версии Kubernetes (без перехода на новую минорную версию). Обновления безопасности выпускаются только для трех последних версий Kubernetes.

Compute Cloud {#vm-CVE-2026-64564}

  • На отдельной виртуальной машине угроза — локальное повышение привилегий до root. Временная мера до обновления ядра — записать конфигурацию блокировки и выгрузить модули вручную. Нужны обе директивы одновременно: blacklist закрывает автозагрузку по alias, install ... /bin/false — явный вызов modprobe. Порядок выгрузки важен — sctp_diag зависит от sctp:
<code>  # sudo sh -c 'printf "install sctp /bin/false\ninstall sctp_diag /bin/false\nblacklist sctp\nblacklist sctp_diag\n" > /etc/modprobe.d/blacklist-sctp.conf; rmmod sctp_diag 2>/dev/null; rmmod sctp 2>/dev/null; if lsmod | grep -qE "^sctp "; then echo "STILL-LOADED refcnt=$(cat /sys/module/sctp/refcnt)"; else echo "UNLOADED-OK"; fi'</code>

UNLOADED-OK — модули выгружены, мера применена. STILL-LOADED — модуль резидентен, перезагрузите виртуальную машину для полного закрытия.

  • Постоянное решение — обновить ядро до версии с исправлением (6.6.148, 6.12.101, 6.18.42, 7.1.6, 7.2-rc5) или до бэкпорта вендора дистрибутива.

Общие меры {#general}

  • Ограничьте размещение недоверенных нагрузок на узлах с загруженным модулем sctp: эксплойту нужен локальный непривилегированный доступ, поэтому не размещайте недоверенные нагрузки рядом с доверенными и, по возможности, выносите их на отдельные группы узлов.
  • Контролируйте конфигурации и обновления узлов: централизованный сбор журналов через Cloud Logging, аудит изменений через Audit Trails. Проверяйте состояние модулей на узлах после обновлений и масштабирования.
  • При обнаружении проблем создайте обращение в поддержку.

Дополнительные материалы {#references-CVE-2026-64564}