Уразливість у ядрі Linux дає змогу атакувати сервер через вхідне TCP-з’єднання
Критична помилка в ядрі Linux дає змогу атакувати сервер через вхідне TCP-з’єднання без пароля. Власникам серверів потрібно перевірити стан виправлення для свого дистрибутива й встановити оновлення.
Розробники ядра Linux 11 і 15 жовтня випустили виправлення для CVE-2026-98432 — помилки, через яку можна атакувати сервер мережею без пароля та дій власника. Як пише Tproger, уразливість стосується обробки вхідних TCP-з’єднань через IPv4 і присутня в ядрі починаючи з версії 4.4. Команда розробників ядра оцінила її критичність у 9,8 бала за шкалою CVSS. Станом на 1 листопада виправлень для Ubuntu та RHEL ще немає. Власникам серверів варто перевірити стан патча для свого дистрибутива й версію запущеного ядра; якщо виправлення доступне — встановити його та перезавантажити сервер.
Чому помилка виникає до перевірки пароля
Під час встановлення TCP-з’єднання ядро може зберегти службові опції із заголовка IPv4-пакета, щоб використати їх у відповіді. У вразливому коді ці дані передаються новому з’єднанню без копіювання. Якщо з’єднання швидко закривається, пам’ять звільняється, хоча інше ядро процесора ще може читати її під час обробки повторного запиту на підключення.
Це помилка типу use-after-free: ділянку пам’яті вже віддано під інші дані, але робота з нею триває. Згідно із записом CVE, зловмисник може домогтися витоку фрагмента пам’яті ядра, запису за межі буфера або збою системи. Обробка відбувається раніше, ніж запит потрапить до вебсервера, SSH чи бази даних. Тому надійний пароль і налаштування застосунку самі собою від неї не захищають.
Виправлення замінює негайне звільнення пам’яті механізмом, який чекає на завершення читання даних. Для підтримуваних гілок Linux названо виправлені версії ядер, зокрема 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113 і 6.18.56. Але дистрибутиви переносять патчі до власних збірок: сам лише номер версії ядра без перевірки даних дистрибутива не дасть надійної відповіді.
27 жовтня Anthropic повідомила, що Claude створила робочий експлойт: під час експерименту компанії він віддалено запускав команди з правами root на сервері з відкритим портом Multipath TCP (MPTCP). На атаку пішло близько 53 хвилин. Компанія не опублікувала код; станом на 1 листопада цієї CVE не було в каталозі CISA KEV, до якого вносять уразливості, що вже використовуються в реальних атаках. Відсутність запису в каталозі не скасовує продемонстрованої можливості експлуатації.
Що перевірити власникам сайтів і адміністраторам
Насамперед це питання для тих, чиї Linux-сервери приймають вхідні TCP-з’єднання через IPv4: VPS, хостів із сайтами та базами даних, вузлів Kubernetes. Контейнер використовує ядро хоста, тож оновлення образу Docker проблему не розв’яже. За контейнерної віртуалізації VPS ядром може керувати провайдер — тоді оновлення залежить від нього.
Станом на 1 листопада виправлення вже доступні для Debian, Amazon Linux і Oracle Linux; у SUSE стан залежить від версії та ядра. Для Ubuntu, а також RHEL 8, 9 і 10 патч ще готується. Перевіряти потрібно стан саме свого дистрибутива й запущеного ядра командою uname -r. Якщо виправлене ядро встановлено, але сервер не перезавантажено, воно ще не захищає систему. Виняток — живе патчування, якщо воно доступне для конкретної конфігурації.
Поки оновлення немає, Red Hat і AlmaLinux пропонують знизити ризик за допомогою правила nftables, яке відкидає вхідні TCP-пакети з опціями в заголовку IPv4. Перед застосуванням його слід перевірити на тестовому сервері: правило може вплинути на маршрутизований трафік і несумісне з мережами, які використовують опції IPv4 для міток CIPSO. До того ж воно не замінює виправленого ядра. Варіант AlmaLinux застосовується на етапі prerouting і охоплює також трафік до контейнерів; правило Red Hat на етапі input захищає лише сам хост.
Ще один тимчасовий захід — вимкнути MPTCP, якщо він не потрібен. За повідомленням команди Go, починаючи з Go 1.24 програми на Linux типово відкривають сокети для прослуховування з MPTCP. Перевірити відкриті порти можна командою ss -Mlnp, а поточний стан механізму — sysctl net.mptcp.enabled. Після вимкнення потрібно перезапустити сервіси з уже відкритими MPTCP-сокетами; в окремих мережевих просторах контейнерів налаштування перевіряють окремо. Важливо: MPTCP був потрібен для експлойту, який показала Anthropic, але сама помилка ядра ним не обмежується.
Моя думка: тимчасовий захист не має стати постійним
Я б почав із переліку хостів, які приймають з’єднання ззовні, і перевірки того, яке ядро насправді запущено на кожному з них. Особливо легко пропустити вузол Kubernetes або VPS, де оновлення ядра залежить не від команди сайту. Для бізнесу це той випадок, коли розмова про оновлення стосується не лише розробників: перезавантаження робочого сервера теж потрібно запланувати.
Вимкнення MPTCP і фільтрація пакетів видаються розумними проміжними кроками там, де патч ще не вийшов. Але я б не вважав завдання виконаним після налаштування nftables: тимчасові заходи мають обмеження, а вразливий код залишається в ядрі. Фінальна перевірка — встановлене виправлення й робота сервера вже на оновленому ядрі.
Джерела
Звідки новина. Текст — переказ своїми словами, факти — з джерела, думка — автора.
Full-stack-розробник
Роблю сайти й внутрішні інструменти для невеликих команд у Польщі. Подобається, коли CMS можна замінити без переписування всієї бізнес-логіки.
Усі публікації автораСхожі статті
У ядрі PHP виправили вразливості, що дають змогу віддалено виконувати код
У ядрі PHP виправили вразливості, які могли призвести до віддаленого виконання коду та читання пам’яті процесу. Власникам сайтів варто перевірити версію PHP і встановити оновлення безпеки.
ISPsystem випустила оновлення VMmanager після атаки через вразливість нульового дня
ISPsystem випустила оновлення безпеки VMmanager і переробила архітектуру захисту після атаки через вразливість нульового дня. Перевірка інфраструктури провайдерів триває.
PHP випустив чотири оновлення для усунення двох критичних вразливостей
PHP випустив чотири оновлення для усунення двох критичних вразливостей: за певних умов зловмисник міг виконати код на сервері. Власникам сайтів і розробникам рекомендують оновити PHP.
Обговорення 4
Заза Кікнадзе
Правильно розумію, що до виходу патча для Ubuntu та RHEL перезавантаження або тимчасове блокування вхідних TCP-з’єднань не усуває саму вразливість? Цікаво, чи є безпечний тимчасовий захист, який не ламає роботу сервера.
Міхал Ковальський Автор публікації
Так, перезавантаження саме по собі вразливість не виправляє, а блокування всіх вхідних TCP-з’єднань фактично зламає звичайний доступ до сервера. Тимчасово варто максимально обмежити доступ до сервісів фаєрволом або allowlist’ом і стежити за патчем дистрибутива; щойно він з’явиться — оновити ядро й перезавантажити сервер. Це лише зниження ризику, не заміна виправленню.
Тимур Рискулов
На запуску нашого магазину я б не розраховував на перезавантаження як на захист: воно не виправляє код, а блокувати весь TCP — легко покласти сайт і роботу з замовленнями. До патча перевірив би версію ядра й чи можна обмежити доступ до непотрібних портів, а після оновлення запланував перезавантаження в тихе вікно. @zaza_kik, у вас сервер має якісь TCP-сервіси, без яких сайт тимчасово може обійтися?
Ларс Ламмерс
У матеріалі згадано ядро від 4.4, але для оцінки ризику на конкретному сервері важлива ще й версія пакета дистрибутива: вона може містити зворотний патч без зміни базового номера ядра. Чи плануєте додати, як адміністраторам перевірити саме наявність виправлення, а не орієнтуватися лише на версію?