CVE-2026-98432 в Linux на Ubuntu: как защитить валидатор Ethereum до патча

Коротко (TL;DR)

• Что случилось. CVE-2026-98432 — ошибка в ядре Linux, в коде, который принимает входящие IPv4 TCP-соединения. Команда ядра оценила её на 9.8 из 10 (Critical): атакующему не нужен ни пароль, ни действие с вашей стороны. Ниже — что сделать сегодня и как обновить ядро Ubuntu, когда исправление станет обычным обновлением.
• Почему это про ноду. Ноде Ethereum нужен открытый P2P-порт (30303, 9000 или 13000 по TCP), а баг срабатывает как раз на открытом TCP-порту. Поэтому «закрыть всё фаерволом» не выйдет.
• Статус на 4 ноября 2026 года. Исправленные ядра для Ubuntu 22.04, 24.04 и 26.04 лежат в тестовом разделе -proposed, в обычном apt upgrade их ещё нет. Debian, RHEL и AlmaLinux уже исправлены.
• Главная временная мера — правило nftables, которое отбрасывает входящие TCP-пакеты с IPv4-опциями. Оно снижает риск, но не заменяет патч и слетает после перезагрузки.
• Перезагрузка валидатора почти бесплатна: по нашему расчёту около $0,035 за пропущенную эпоху (курс ETH на 4 ноября). Дорого стоит другое — второй экземпляр ключей. Это прямой путь к слэшингу.

Что такое CVE-2026-98432 и почему она касается ноды Ethereum

CVE-2026-98432 — это ошибка типа use-after-free в обработке TCP-рукопожатия ядра Linux. Use-after-free значит «использование после освобождения»: ядро уже вернуло кусок памяти системе, а другой процессор ещё читает из него данные. Если атакующий успеет подложить в эту память своё содержимое, он получает рычаг для выполнения кода с правами ядра.

Механика простая. Входящее соединение начинается с пакета SYN — «привет, давай поговорим». Если в SYN вложены IPv4-опции (служебные поля Record Route или Timestamp в заголовке IP-пакета), ядро хранит их копию. Такие запросы ядро обрабатывает без блокировки слушающего сокета, поэтому один процессор может освободить эту копию, пока другой ещё читает её, чтобы собрать ответ SYN-ACK. Ошибка возникла в Linux 4.4, так что задеты почти все живые серверы. IPv6-соединения основная проблема не затрагивает.

Аналогия: IP-опции — это особая пометка на конверте, а баг — привычка почтальона выбрасывать конверт, пока коллега ещё переписывает адрес. Обычные TCP-опции (временные метки, масштабирование окна) лежат внутри письма и к проблеме отношения не имеют.

Уязвимость нашла модель Claude компании Anthropic. 27 октября Anthropic описала рабочий эксплойт: на сервере с MPTCP-слушателем он даёт права root по сети. По данным Anthropic, утечка адреса ядра заняла 48 минут, ещё пять минут ушло до выполнения команды. Сам эксплойт не опубликован.

до выхода на биржу

Binance · Wall Street 24/7OpenAI и Anthropic ещё не на биржеPre-IPOА контракты на их цену уже торгуются на Binance

OpenAIAnthropicNVDA

Смотреть цены

Почему это касается каждой ноды Ethereum. Сеть держится на том, что узлы находят друг друга и принимают входящие соединения. Execution-клиент (Geth, Nethermind, Besu, Reth) слушает TCP-порт 30303, consensus-клиент — 9000 у Lighthouse или 13000 у Prysm. Для бага этого достаточно: ему нужен любой IPv4 TCP-порт, до которого может достучаться атакующий. Если вы держите соло-стейкинг на своём сервере, такой порт у вас открыт по определению.

Изоляция ИИ-агента для кодинга: песочница, контейнер и ключи вне его досягаемости

RTX Spark на Linux в тесте в 4,7 раза медленнее от сети: что в прошивке и что делать

Unstake SOL в Phantom: два шага, ожидание до 26 часов и цена быстрого выхода

Фейковое собеседование как способ взлома: разбор случая Binance и чек-лист защиты

Coinbase держит офлайн больше 99% крипты клиентов: ключи разделены, есть «рубильник»

Проверьте ноду: ядро, открытые порты и MPTCP-слушатели

Что понадобится: доступ к серверу по SSH с правами sudo, 10–15 минут и знание того, какие клиенты у вас стоят. Ничего не останавливаем — только смотрим.

Шаг 1. Узнайте версию ядра

uname -r
dpkg -l 'linux-image*' | grep ^ii
cat /etc/os-release | grep VERSION=

Сравнивайте номер не с upstream, а с таблицей Ubuntu в следующем разделе: дистрибутив переносит исправления в свои сборки, поэтому 5.15.0-202 у Ubuntu ничего не говорит рядом с upstream 5.15.223. Ориентир — число после дефиса (номер ABI): в 5.15.0-203-generic это 203. Сравнивайте его внутри своей серии ядра. Исправленные сборки на 4 ноября: 5.15.0-203 для 22.04, 6.8.0-149 для 24.04 и для HWE-ядра 6.8 на 22.04, 7.0.0-43 для 26.04 и для HWE-ядра 7.0 на 24.04. Если номер меньше, ядро уязвимо. У HWE-ядра 6.17 на 24.04 исправленной сборки на 4 ноября нет.

Шаг 2. Посмотрите, какие TCP-порты слушают снаружи

sudo ss -ltnp

Нас интересуют строки с адресом 0.0.0.0 или *: они принимают соединения из интернета. Строки с 127.0.0.1 доступны только самому серверу. Сверьтесь с таблицей портов из документации клиентов:

Для Teku, Nimbus, Lodestar, Nethermind, Besu и Reth порты смотрите в их документации: часть клиентов использует другие значения по умолчанию. Любой открытый наружу TCP-порт, которого нет в списке «открыть», — первый кандидат на закрытие.

Шаг 3. Найдите MPTCP-слушатели

sudo ss -Mlnp
sysctl net.mptcp.enabled

MPTCP (Multipath TCP) — расширение, которое позволяет одному соединению идти сразу по нескольким каналам. Флаг -M показывает только MPTCP-сокеты. Не добавляйте к нему -t: тогда в выдачу попадут обычные TCP-сокеты, и покажется, что MPTCP всё. На Ubuntu net.mptcp.enabled по умолчанию равен 1 — то есть программы могут открывать такие сокеты.

Почему это важно для стейкера. С Go 1.24 программы на Go по умолчанию открывают слушающие сокеты как MPTCP. Geth написан на Go: в его go.mod стоит go 1.25.0, а P2P-порт открывается обычным вызовом net.Listen. Наш вывод из исходного кода: Geth на Ubuntu, скорее всего, слушает 30303 как MPTCP — ровно в той конфигурации, на которой Anthropic показала эксплойт. Подтверждения от команды Geth нет, поэтому проверьте сами: если в выводе ss -Mlnp есть процесс geth на 30303, вывод верен для вашей машины.

▲ Long▼ Short

Binance · Wall Street 24/7Цена падает? Это тоже шансСделку можно открыть и на рост, и на падение. Начните с плеча 1×

NVDATSLAGOLD

Как это работает

Если клиенты работают в Docker, ss на хосте сокетов внутри контейнеров не покажет: у контейнера своё сетевое пространство имён. Смотрите изнутри: sudo nsenter -t $(docker inspect -f '{{.State.Pid}}' <контейнер>) -n ss -Mlnp.

Пустой вывод ss -Mlnp не значит «я в безопасности». Red Hat прямо называет такую проверку информационной: MPTCP — лишь один из путей, а сам баг сидит в обычном IPv4 TCP.

Патч CVE-2026-98432 для Ubuntu: кто исправлен, а кто в -proposed

На 4 ноября 2026 года исправленные ядра для Ubuntu 22.04, 24.04 и 26.04 собраны, но лежат в разделе -proposed, а 26.10 уже исправлена. Это значит: обычный sudo apt upgrade патч на LTS-версии пока не принесёт. Обновить ядро Ubuntu 24.04 или 22.04 до исправленной сборки сегодня можно только одним способом — явно взять пакет из -proposed. Как это сделать и чем это рискованно — в разделе про обновление.

-proposed — тестовый «карман» архива Ubuntu. Туда кладут готовые пакеты до того, как Canonical закончит проверку и переложит их в -updates, откуда берёт обычный apt upgrade. Canonical пишет 2 ноября, что прогоняет сборки на более чем 2 000 сертифицированных серверов и устройств и выпустит их в -updates сразу после тестов.

У трекера и блога Ubuntu расхождение. Трекер безопасности, обновлённый 4 ноября, пишет «Vulnerable, work in progress» для всех четырёх свежих релизов, включая 26.10. Блог от 2 ноября называет 26.10 исправленной, а для LTS пишет «Fix available in -proposed». Для LTS это разные слова об одном и том же: пакет собран и проходит тесты, но в -updates его нет. По 26.10 трекер просто отстаёт: по данным Atlas, её ядро попало в -updates ещё 28 октября.

На кадре трекера рамкой отмечены строки пакета linux для четырёх поддерживаемых релизов: рядом со статусом указан номер сборки, в которой исправление уже лежит. Ниже видно, что 20.04 и старше пока без номера, а 14.04 не затронута: её ядро старше Linux 4.4.

Отдельно про HWE-ядра (Hardware Enablement — более новые ядра для LTS-версий). Перейти на HWE ради защиты не получится: на 4 ноября у них тот же статус, что у основного ядра. linux-hwe-7.0 для 24.04 и linux-hwe-6.8 для 22.04 значатся «Vulnerable, work in progress» с готовыми сборками, а linux-hwe-6.17 для 24.04 — просто «Vulnerable», без исправленной сборки. Mainline-ядра с kernel.org в обход репозитория Ubuntu для боевой ноды мы не рекомендуем: без тестов Canonical и без автоматических обновлений безопасности.

Что у соседей на ту же дату: Debian 13 исправлен в 6.12.113-1, Debian 12 — в 6.1.190-1, Red Hat 1 ноября выпустила ядра для RHEL 8, 9 и 10 (бюллетени RHSA-2026:93414, :93412 и :93413, по сводкам Kernelpost и Atlas), AlmaLinux перенесла исправление в обычные обновления 2 ноября. Утверждение из обсуждений «у Ubuntu почти три недели нет патча» устарело наполовину: CVE вышла 15 октября, сборки в -proposed появились в конце октября, но до обычных обновлений LTS на 4 ноября действительно не дошли.

Как защитить ноду валидатора до патча: пять мер и их цена

До выхода ядра в -updates ноду закрывают слоями: правило против IPv4-опций, минимум открытых портов, отключённый MPTCP и, если готовы, ядро из -proposed. Ни одна мера, кроме исправленного ядра, не устраняет баг. Они уменьшают шанс, что атакующий до него доберётся.

Мера 1. Правило nftables против IPv4-опций

Это главная временная мера, её дают Red Hat, Ubuntu и AlmaLinux. Нормальный заголовок IPv4 занимает 5 слов по 4 байта (ihl=5). Всё, что длиннее, несёт опции, а без опций баг не срабатывает. Правило отбрасывает такие TCP-пакеты до того, как они дойдут до любого сокета, поэтому клиенты перезапускать не нужно.

На кадре трекера Ubuntu рамкой выделены оговорка «снижает риск, но не предотвращает эксплуатацию полностью» и само правило. Создайте файл с тем же содержимым, что в бюллетене Red Hat RHSB-2026-016:

sudo tee /etc/cve-2026-98432.nft >/dev/null <<'EOF'
table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}
EOF
sudo nft --check --file /etc/cve-2026-98432.nft
sudo nft --file /etc/cve-2026-98432.nft
sudo nft list table inet cve_2026_98432

Последняя команда показывает счётчик отброшенных пакетов. Таблица живёт отдельно и уживается с правилами UFW и Docker на Ubuntu 22.04 и новее.

Если клиенты работают в Docker (например, через eth-docker) и порты опубликованы из сети bridge, как у Docker по умолчанию, правило на хуке input трафик к ним не видит: хост не принимает такие пакеты сам, а пересылает их в сеть контейнера. Если контейнеры запущены с network_mode: host, хватает первого варианта. Ubuntu прямо пишет, что контейнерам с отдельной сетью правило нужно отдельно. AlmaLinux предлагает вариант на хуке prerouting: он срабатывает раньше и, по их проверке, защищает хост и контейнеры, которые получают трафик через него (это поведение Docker и Podman по умолчанию):

sudo nft -f - <<'EOF'
add table ip cve_2026_98432
delete table ip cve_2026_98432
table ip cve_2026_98432 {
    chain prerouting {
        type filter hook prerouting priority -300; policy accept;
        meta l4proto tcp ip hdrlength > 5 counter drop
    }
}
EOF
sudo nft list table ip cve_2026_98432

AlmaLinux тестировала его на своих системах; синтаксис nftables на Ubuntu тот же, но после применения сверьте счётчик и число пиров. Трафик между контейнерами одного хоста может обойти оба варианта.

Правило не переживает перезагрузку. Если сервер перезагрузится раньше, чем вы поставите исправленное ядро, защита пропадёт молча. Ubuntu предлагает подключить файл через /etc/nftables.conf и включить nftables.service, но оговаривает, что инструкция рассчитана на хосты без UFW и firewalld. На ноде с UFW или Docker проверьте /etc/nftables.conf до включения сервиса: в стандартном файле Ubuntu первой командой стоит flush ruleset. Она очищает все таблицы nftables, в том числе правила UFW и Docker. Это сработает при загрузке, если сервис стартует после UFW, и при любом перезапуске nftables.service на работающей ноде, а при остановке сервис сбрасывает весь набор правил. Надёжнее для такой ноды — после каждой перезагрузки до патча вручную повторить sudo nft --file /etc/cve-2026-98432.nft.

Мера 2. Закройте лишние TCP-порты и SSH от мира

Каждый открытый TCP-порт — ещё одна дверь для бага. По выводу sudo ss -ltnp из прошлого раздела уберите наружу всё, кроме P2P-портов клиентов: RPC 8545, Engine API 8551, API бикон-ноды, метрики и панели мониторинга должны слушать 127.0.0.1 или быть закрыты фаерволом. SSH тоже TCP-порт: разрешите его только со своего адреса или спрячьте за VPN вроде WireGuard или Tailscale. Перед правкой правил держите вторую открытую SSH-сессию или консоль провайдера — так проще не запереть себя снаружи.

Мера 3. Отключите MPTCP и перезапустите клиенты

echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/90-disable-mptcp.conf
sudo sysctl -w net.mptcp.enabled=0
sudo ss -Mlnp

Настройка запрещает только новые MPTCP-сокеты, уже открытые остаются. Поэтому после неё перезапустите клиенты, которые показал ss -Mlnp, и повторите проверку — список должен стать пустым. Перезапуск execution-клиента обходится в несколько пропущенных аттестаций, если валидатор зависит от него; цену считаем ниже. Red Hat называет эту меру неполной: она закрывает показанный путь эксплойта, но не сам баг.

В Docker настройка хоста контейнеры не закрывает: net.mptcp.enabled действует отдельно в каждом сетевом пространстве имён, и у контейнера с собственной сетью MPTCP остаётся включённым. Задайте настройку самому контейнеру (--sysctl net.mptcp.enabled=0 при запуске или ключ sysctls в docker-compose) и пересоздайте его.

Мера 4. Временно уберите входящий TCP на P2P-порт

Это крайняя мера на несколько дней. Lighthouse в документации пишет, что продолжит работать за NAT вообще без проброса портов, но пиров станет меньше, а Prysm отмечает, что проброс помогает валидатору заработать чуть больше. Закрывайте только TCP: UDP-порты для поиска пиров и QUIC этот баг не задевает. Учтите, что Lighthouse умеет сам открывать порты на роутере через UPnP. Для Geth и других EL-клиентов поведение без входящих соединений мы не проверяли — следите за числом пиров и за эффективностью аттестаций.

Мера 5. Поставьте ядро из -proposed

Единственная мера, которая устраняет баг. Её цена — сборка ещё не прошла все тесты Canonical. Порядок действий — в следующем разделе.

Что не защищает ноду от CVE-2026-98432

• UFW с политикой deny incoming. Политика закрывает то, что вы не разрешили, а P2P-порты вы разрешили сами. Баг срабатывает именно на них.
• Переход на HWE-ядро. В трекере Ubuntu оно тоже уязвимо на 4 ноября.
• Параметр загрузки init_on_free=1. Инженер CIQ в рассылке oss-security 3 ноября написал, что против этой CVE он не делает ничего существенного.
• GODEBUG=multipathtcp=0 для отдельных программ. Команда Go сама называет такое отключение хрупким: один забытый сервис — и MPTCP-слушатель снова открыт. Системная настройка sysctl надёжнее.
• Запуск клиентов в контейнерах. Баг сидит в ядре хоста, общем для всех контейнеров.

Как обновить ядро Ubuntu: -proposed сейчас или ждать -updates

Как обновить ядро Ubuntu от CVE-2026-98432 на 4 ноября 2026 года: либо явно поставить сборку из -proposed, либо держать временные меры и обновиться через apt upgrade, когда пакет переедет в -updates. Оба пути заканчиваются перезагрузкой. Новое ядро начинает работать только после неё.

Вариант A: ядро из -proposed сегодня

Команды — из блога Ubuntu от 2 ноября. Первая подключает раздел -proposed для компонента main, в котором лежат ядра:

sudo add-apt-repository --component main --pocket proposed http://archive.ubuntu.com/ubuntu
sudo apt update
dpkg-query -W -f '${source:Package}\t${binary:Package}\n' | awk '$1 ~ "^linux-meta" { print $2 }' | xargs sudo apt install -t $(. /etc/os-release && echo $VERSION_CODENAME)-proposed --only-upgrade

По словам Ubuntu, пакеты из -proposed не ставятся при обычном обновлении: третья команда находит мета-пакет вашего ядра и явно берёт его из -proposed для вашего релиза. Так ядро Linux на Ubuntu обновляется точечно: из тестового раздела приходят только пакеты ядра, а остальные, как и раньше, берутся из обычных обновлений. Перед перезагрузкой проверьте вывод apt: в нём должен быть номер из таблицы выше. Сама перезагрузка валидатора — по порядку из следующего раздела, не сразу.

Если новое ядро не загрузится или клиент поведёт себя странно, предыдущее ядро остаётся в системе: его можно выбрать в меню GRUB «Advanced options for Ubuntu». На VPS для этого нужна консоль провайдера — проверьте, что она у вас есть, до обновления. Когда исправление выйдет в -updates, раздел -proposed лучше отключить той же командой add-apt-repository с флагом --remove.

Вариант B: дождаться -updates

Держите меры 1–4, следите за трекером безопасности Ubuntu (страница ubuntu.com/security/CVE-2026-98432) и после смены статуса на «Released» выполните:

sudo apt update && sudo apt upgrade
ls /var/run/reboot-required 2>/dev/null && echo "нужна перезагрузка"

Если на сервере включены автоматические обновления, ядро может установиться само, но заработает только после перезагрузки. Файл /var/run/reboot-required подскажет, что она нужна. Ubuntu 20.04 и 18.04 получат исправление через Expanded Security Maintenance в Ubuntu Pro (подписка бесплатна до 5 машин), 16.04 — только через ESM с дополнением Legacy.

Livepatch на Ubuntu: закроет ли он CVE-2026-98432 без перезагрузки

На 4 ноября 2026 года подтверждённого livepatch для CVE-2026-98432 нет: уведомления Livepatch по этой уязвимости мы не нашли, а трекер Ubuntu про Livepatch не упоминает. Рассчитывать на исправление без перезагрузки рано.

Livepatch — сервис Canonical, который вносит исправления в работающее ядро без перезагрузки. Он входит в Ubuntu Pro и включается двумя командами:

sudo pro attach <ТОКЕН>
sudo pro enable livepatch

Что важно знать про Livepatch на Ubuntu, прежде чем ждать его для ноды:

• Canonical выпускает livepatch для уязвимостей с высокой и критической оценкой — формально эта CVE подходит, но решение по ней не объявлено.
• Livepatch приходит вместе с уведомлением Livepatch Security Notice. Нет уведомления — нет и патча.
• Canonical прямо пишет, что Livepatch не заменяет перезагрузку: он откладывает её до удобного окна.

Практический вывод для стейкера: Livepatch полезно включить на будущее, но в этой истории план всё равно должен включать перезагрузку на исправленное ядро.

Перезагрузка валидатора без слэшинга: порядок действий и цена простоя

Перезагрузить валидатор ради нового ядра безопасно, если ключи работают в одном экземпляре. Простой при нормальной финализации сети не приводит к слэшингу: ethereum.org пишет, что за пропущенную эпоху начисляется небольшой штраф, чуть меньше награды, которую валидатор получил бы.

Порядок перезагрузки по шагам

1. Посмотрите в своём мониторинге или эксплорере, нет ли у валидатора ближайшего предложения блока. Если есть — дождитесь его.
2. Поставьте новое ядро заранее (раздел выше): установка идёт без остановки клиентов.
3. Остановите валидатор-клиент, затем бикон-ноду и execution-клиент: sudo systemctl stop <ваши юниты>.
4. Сделайте копию истории подписей — базы защиты от слэшинга. У Lighthouse это lighthouse account validator slashing-protection export filename.json, у Prysm — команда slashing-protection-history export. Это страховка на случай, если диск или ОС придётся восстанавливать.
5. Перезагрузитесь: sudo reboot.
6. После загрузки проверьте uname -r и убедитесь, что клиенты поднялись на ЭТОЙ машине.

Главное правило: никогда не запускайте ключи на втором сервере, «чтобы не терять аттестации» на время перезагрузки. ethereum.org называет причиной прошлых слэшингов именно ключи, которые одновременно работали на двух машинах. Lighthouse Book предупреждает, что база защиты от слэшинга от этого не спасает и что даже с защитой doppelganger два экземпляра одного валидатора запускать небезопасно. Doppelganger protection — функция, при которой валидатор после старта 2–3 эпохи молчит и проверяет, не подписывает ли кто-то тем же ключом. Если она включена, перезагрузка обойдётся на эти 2–3 эпохи дороже.

Не включайте вслепую автоматическую перезагрузку после обновлений (Unattended-Upgrade::Automatic-Reboot "true"), которую советуют общие гайды по этой CVE. Она не знает расписания ваших обязанностей и может перезагрузить ноду в неудачный момент.

Сколько стоит перезагрузка валидатора: расчёт на 4 ноября

Формулы — из спецификации консенсуса Ethereum (обновление Altair) и методики Rated. На ethereum.org базовая награда записана в старом виде, с делителем 4, и по ней выйдет вчетверо меньше. С фактической доходностью сети 2,44% годовых (validatorqueue.com) сходится именно расчёт по Altair. Вводные на 4 ноября 2026 года: в стейкинге около 44,4 млн ETH и 812 219 активных валидаторов (validatorqueue.com), курс ETH $2 417,87 (CoinGecko). Базовая награда валидатора с 32 ETH — около 9 719 gwei за эпоху. Пропущенная аттестация — это штраф 0,625 от базовой награды плюс упущенная награда 0,84375 от неё.

Это наш расчёт по формулам спецификации. Он не учитывает пропуск слота с предложением блока: для валидатора с 32 ETH такой шанс за 1–2 эпохи около 0,002–0,005%, но сам блок стоит дороже аттестации. Подробнее о том, из чего складываются награды и штрафы валидатора, — в отдельном разборе.

Перспектива: одно только мгновенное списание при слэшинге равно примерно 2,4 суткам простоя, а дальше к нему добавляются потери за 36 дней принудительного выхода. Поэтому правильная осторожность — «один экземпляр ключей», а не «лучше не перезагружаться». Массовая перезагрузка нод в один день тоже не страшна: штрафы за офлайн растут, только если одновременно отключаются многие валидаторы, а критичной становится ситуация, когда сеть перестаёт финализировать блоки.

Проверка ноды после обновления: ядро, правило, пиры, аттестации

После перезагрузки проверьте четыре вещи: версию ядра, правило фаервола, MPTCP-слушатели и работу клиентов.

1. Ядро. uname -r должен показать исправленную сборку своей серии: 5.15.0-203 для 22.04, 6.8.0-149 для 24.04 и для HWE-ядра на 22.04, 7.0.0-43 для 26.04 и для HWE-ядра 7.0 на 24.04.
2. Правило. Если ядро ещё старое (перезагрузка была до патча), выполните sudo nft list table inet cve_2026_98432. Пустой ответ — правило слетело, примените его снова. Если ядро уже исправленное, правило можно снять: sudo nft delete table inet cve_2026_98432 (у варианта для Docker — sudo nft delete table ip cve_2026_98432).
3. MPTCP. sudo ss -Mlnp покажет, вернулись ли MPTCP-слушатели после рестарта. Это информация, а не вердикт: на исправленном ядре MPTCP-слушатель опасности не несёт.
4. Клиенты. Число пиров у execution- и consensus-клиента должно вернуться к привычному уровню, а аттестации — снова проходить в каждой эпохе. Смотрите в логах клиентов, в Grafana или на странице валидатора в эксплорере.

Если сервер был открыт с уязвимым ядром и у вас есть причины беспокоиться, проведите короткую проверку на взлом. Индикаторов компрометации для этой CVE никто не публиковал, поэтому это стандартный разбор сервера, на который мог зайти root:

cat /proc/sys/kernel/tainted
sudo dmesg | grep -iE 'general protection|BUG:|Oops|ip_options|use-after-free'
ps -eo user,pid,ppid,lstart,args --forest | grep -v '\[.*\]$'
sudo ls -la /var/spool/cron/crontabs /etc/cron.d
systemctl list-timers --all
sudo ls -la --time-style=full-iso /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys

tainted со значением 0 — хороший знак, сообщения об ошибках памяти в dmesg — повод разобраться. Незнакомые процессы, задания cron, таймеры и SSH-ключи ищите вручную. Если на сервере лежат ключи валидатора и следы взлома есть, безопаснее пересобрать сервер с нуля, чем чистить его.

Риски CVE-2026-98432 на 4 ноября: что остаётся неизвестным

Реальных атак на валидаторы Ethereum через эту уязвимость на 4 ноября 2026 года не зафиксировано, но и спокойствие преждевременно. Вот что известно и чего пока нет:

• Эксплойт не опубликован. Anthropic описала его, но код не выложила. Atlas насчитал на 4 ноября 70 репозиториев на GitHub с упоминанием CVE, из них не меньше десяти заявляют о триггере гонки или PoC (проверочном коде). Мы их не проверяли.
• Сканирование — один источник. Исследователь Маркус Хатчинс 3 ноября сообщил о сканировании порта 443 по MPTCP и предположил, что ищут именно эту CVE. Это пересказ Atlas, независимого подтверждения нет. Порт 443 на ноде обычно не открыт, но это сигнал, что окно до патча сужается.
• В каталоге CISA KEV записи нет на 4 ноября: эксплуатация в атаках официально не подтверждена.
• Команды клиентов Ethereum молчат. Заявлений Geth, Lighthouse, Prysm, Teku, Nimbus или Lodestar по этой CVE мы не нашли. В соседней сети реакция была: Intersect 30 октября призвала операторов пулов Cardano проверить ядра и обновиться, как только выйдут исправления (по данным The Defiant).
• MPTCP у других клиентов не проверен. Вывод про MPTCP-слушатель сделан только для Geth и только по исходному коду. Для Prysm, тоже написанного на Go, мы его не утверждаем: P2P там идёт через библиотеку libp2p. Его, как и Erigon (тоже на Go), проверьте тем же sudo ss -Mlnp.
• Решение по Livepatch не объявлено, дата выхода ядер в -updates — тоже.

Что устареет первым: статус ядер Ubuntu. Он может смениться в любой день, поэтому перед действиями сверяйтесь с трекером Ubuntu, а не с таблицей выше. Цены в расчёте простоя меняются вместе с курсом ETH и объёмом стейкинга.

FAQ

Нужно ли выключать валидатор, пока нет исправленного ядра?

Нет. Выключение не устраняет баг, если сервер остаётся в сети, а сутки простоя стоят около $7,8 по курсу на 4 ноября 2026 года. Разумнее оставить валидатор работать, применить правило nftables против IPv4-опций, закрыть лишние порты и отключить MPTCP. Когда ядро выйдет в -updates или вы решитесь на -proposed, перезагрузитесь по порядку из статьи.

Защитит ли UFW с политикой deny incoming ноду Ethereum от CVE-2026-98432?

Нет. Политика deny incoming блокирует только то, что вы не разрешили, а P2P-порты 30303 и 9000 или 13000 по TCP ноде нужны открытыми. Баг срабатывает на любом доступном IPv4 TCP-порту, включая SSH. UFW полезен, чтобы закрыть всё лишнее, но против самой уязвимости работает правило nftables, которое отбрасывает пакеты с IPv4-опциями.

Достаточно ли отключить MPTCP, чтобы нода была в безопасности?

Нет. Отключение MPTCP закрывает путь, на котором Anthropic показала эксплойт, но сам баг сидит в обычном IPv4 TCP. Red Hat и команда Go прямо пишут, что MPTCP не является обязательным условием. К тому же настройка действует только на новые сокеты, поэтому клиенты нужно перезапустить. Используйте её вместе с правилом nftables, а не вместо него.

Сколько стоит перезагрузка валидатора и можно ли получить слэшинг?

По нашему расчёту на 4 ноября 2026 года перезагрузка на 5–10 минут стоит около $0,035–0,07, с защитой doppelganger — до $0,17. Слэшинг за перезагрузку не дают: ethereum.org пишет, что офлайн при нормальной финализации не наказывается слэшингом. Риск появляется, только если ключи одновременно работают на двух машинах или в двух клиентах.

Можно ли ставить ядро из -proposed на боевую ноду?

Можно, если вы готовы к откату. Сборки в -proposed — это исправленные ядра, которые Canonical ещё проверяет на более чем 2 000 устройств, и адресует их Ubuntu тем, кто сам тестирует ядра перед выкаткой. Регрессия возможна, поэтому до установки убедитесь, что у вас есть консоль провайдера и старое ядро в меню GRUB. Без запасного доступа к серверу надёжнее держать временные меры и дождаться -updates.

Затронуты ли Lighthouse и Nimbus, если они написаны на Rust и Nim, а не на Go?

Да, потому что баг в ядре Linux, а не в клиенте: под угрозой любой IPv4 TCP-порт, независимо от языка программы. Разница только в MPTCP. Включать его по умолчанию стал Go начиная с версии 1.24, поэтому вывод про MPTCP-слушатель мы делаем для Geth. Проверить свою машину можно командой sudo ss -Mlnp.

Грозит ли уязвимость ноде, которая стоит дома за роутером?

За роутером без проброса портов входящие TCP-соединения из интернета до ноды не доходят, и риск заметно ниже. Но многие стейкеры пробрасывают P2P-порты вручную, а Lighthouse умеет открыть их сам через UPnP. Проверьте настройки проброса на роутере. Если TCP-порт открыт, нужны те же меры: правило nftables, отключение MPTCP и обновление ядра.