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-порт, до якого може дістатися нападник. Якщо ви тримаєте соло-стейкінг на власному сервері, такий порт у вас відкритий за визначенням.

Пісочниця для ШІ-агента (AI agent sandbox): контейнер і ключі поза досяжністю

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, висновок справджується для вашої машини.

частка, а не ціла акція

Binance · Wall Street 24/7Частка Nvidia — від7 USDTЦілу акцію купувати не треба. Почніть із маленької суми — ризик під контролем

NVDATSLAAAPL

Перша угода за 5 кроків

Якщо клієнти працюють у 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, вистачає першого варіанта. 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 та оновлення ядра.