В Linux нашли баг почти музейного возраста: уязвимость Linux SCTP просидела в ядре с 2008 года и теперь описывается как путь от локального доступа к полному root. В тестах Tencent история дошла еще дальше: исследователи заявили о выходе из контейнера на хост, а для команд, которые держат shared-серверы, CI-раннеры и контейнерные платформы, это уже не экзотика про редкий протокол, а вопрос обновления ядра.
Речь идет о CVE-2026-64564, которую авторы назвали SCTPhantom. Как пишет The Hacker News, публично баг раскрыли 6 августа, а исправления в стабильных ветках ядра вышли еще 3 августа: 7.1.6, 6.18.42, 6.12.101 и 6.6.148. Формально уязвимость локальная, а не удаленная, и требует доступного SCTP на целевой машине, что сужает круг жертв. Но если эти условия выполняются, последствия уже выглядят не как «неприятный краш», а как полноценное повышение привилегий. По состоянию на 7 августа публичного эксплойта не было, в каталог CISA KEV проблема не попала, а NVD еще не выставила ни оценку, ни классификацию слабости; Tencent при этом оценила риск в 8,5 балла по CVSS 4.0.
SCTP сам по себе не самый массовый транспортный протокол, поэтому у многих админов и разработчиков он проходит где-то между «настроили давно» и «надеюсь, никто не трогает». Ошибка сидит в механике динамической перенастройки адресов: одно сообщение может сначала добавить адрес, затем запросить его удаление, а потом отправить wildcard-удаление. Ядро в этой последовательности освобождает структуру пути, а затем продолжает работать уже с мертвым указателем. Получается классический use-after-free, только с особенно неприятным финалом: соединение продолжает ссылаться на память, которую ядро уже отдало обратно. Исправление довольно прозаичное и потому обидное: патч просто запрещает удалять тот путь, на котором в данный момент обрабатывается сообщение. След баг тянется к Linux 2.6.25, то есть к релизу 2008 года, и, если верить таймлайну, он жил практически во всех последующих выпусках ядра.
Самая громкая часть истории пришла не от описания бага, а от тестов Tencent Zhuque Lab. Исследователи утверждают, что получили root на проверенных сборках для Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 и OpenCloudOS, а затем использовали уязвимость для побега из контейнера. В ранней версии их цепочки требовалось включить sysctl-параметры net.sctp.addip_enable и net.sctp.addip_noauth_enable, из-за чего казалось, что без CAP_NET_ADMIN ничего не выйдет. Позже, по словам лаборатории, они обошли это ограничение, активируя нужные возможности на уровне сокета. В отчете сказано, что эксперимент с контейнером проходил при стандартном seccomp-профиле и без выдачи CAP_NET_ADMIN и CAP_SYS_ADMIN; из восьми попыток шесть завершились root-доступом на хосте. При этом независимого воспроизведения пока нет, а контейнерный runtime в публикации не назван, так что эту часть истории разумно читать без лишнего героизма. Не случайно advisory openKylin по той же проблеме ограничивается куда более скучным сценарием: panic ядра и отказ в обслуживании.
С практической стороны уязвимость Linux SCTP неприятна сразу по двум причинам. Первая: строка версии ядра сама по себе мало что доказывает. Дистрибутивы регулярно бэкпортят исправления, не меняя апстрим-номер, поэтому одного uname -r здесь недостаточно; смотреть надо в трекер и advisory своего вендора. Вторая: если SCTP в инфраструктуре не нужен, дешевле и честнее просто убрать поверхность атаки и заблокировать модуль, чем рассуждать о том, насколько «локальной» является локальная уязвимость на multi-tenant-хосте. Для Kubernetes-нод, self-hosted CI и любых сред, где в контейнере может оказаться чужой код, разница между локальным багом и инцидентом на всем сервере обычно измеряется не терминологией, а временем до первого рут-шелла.
Есть и еще один технический нюанс, который не дает расслабиться после установки патча от 3 августа. Уже 6 августа в том же SCTP-коде закрыли второй use-after-free с висящим транспортом, и в стабильные релизы 7.1.6, 6.18.42, 6.12.101 и 6.6.148 он еще не вошел. Параллельно Tencent приписывает находку Corvus AI, своему мультиагентному конвейеру для исследования ядра. На фоне июльского GhostLock картина складывается довольно ясная: старые подсистемы Linux получают все меньше шансов тихо стареть в углу, потому что автоматизированный поиск ошибок добирается туда, куда раньше месяцами не доходили человеческие руки.
Главный вопрос теперь не в том, можно ли раскрутить 18-летний баг до root, а в том, сколько еще таких «спящих» ошибок осталось в редко трогаемых сетевых подсистемах ядра. Даже локальная уязвимость Linux SCTP быстро перестает быть локальной, когда речь идет о контейнерах, shared-инфраструктуре и чужом коде на одной машине. Для команд эксплуатации это плохая, но полезная новость: проверять придется не только самые популярные компоненты, но и те, которые годами считались нишевыми и потому безопасными по умолчанию. Подробности таймлайна и первичного разбора собраны в .