CVE-2026-98432: Критична уразливість TCP в ядрі Linux дозволяє віддалене виконання коду

Критична вразливість у стеку мережі IPv4 TCP ядра Linux може дозволити неавтентифікованому віддаленому зловмиснику викликати пошкодження пам’яті, аварійне завершення роботи вразливих систем і, можливо, виконання довільного коду з привілеями root. Відома як CVE-2026-98432, ця вразливість має оцінку CVSS 3.1 на рівні 9.8 і існує в ядрі Linux з версії 4.4.

Вразливість походить від умови змагання, яка може змусити ядро звернутись до даних IP-опцій після того, як відповідна пам’ять вже була звільнена. Зловмисник, який може досягти видимої служби IPv4 TCP, може спробувати викликати цю умову за допомогою спеціально відтворених запитів з’єднання, що містять IP-опції. Аутентифікація, локальні привілеї або взаємодія з користувачем не потрібні.

Інтерес до безпеки значно зріс після того, як Anthropic розкрили, що внутрішня модель дослідження Claude розвинула робочу експлуатацію, здатну досягти віддаленого виконання команд з привілеями root проти сервера Linux зі слухачем Multipath TCP (MPTCP). Експлуатація спочатку видає показник ядра заради обходу KASLR, а потім використовує ту ж умову «використання після звільнення», щоб пошкодити пам’ять і перенаправити потік керування ядром. Anthropic не випустили код експлуатації.

Важливо, що основна вразливість не обмежується MPTCP. Red Hat підтверджує, що системи зі звичайним мережевим підключенням IPv4 TCP залишаються вразливими навіть при вимкненому MPTCP, включаючи звичні конфігурації Red Hat Enterprise Linux.

Зв’язатися з продажами

Станом на 4 листопада 2026 року жоден постачальник Linux, CERT або інше перевірене джерело не повідомили про підтверджене експлуатування вразливості в реальних атаках. Існує публічний код досліджень, що демонструє частини вразливості, але публічно опублікований експлуатаційний код з повною можливістю віддаленого виконання з привілеями root, продемонстрований Anthropic, не був задокументований.

Команди безпеки можуть використовувати платформу виявлення загроз SOC Prime на базі ШІ для посилення своїх оборонних механізмів проти експлуатації нових вразливостей, активізації розвідки загроз та прискорення пошуку загроз серед середовищ SIEM, EDR, XDR та Data Lake.

Виявляйте CVE-2026-98432 шляхом моніторингу незвичайного трафіку IPv4 TCP з IP-опціями, повторних спроб з’єднання, що намагаються викликати умови змагання, аварійних зупинок ядра або подій пошкодження пам’яті, а також підозрілої активності, що може свідчити про успішну пост-експлуатацію.

Вміст для виявлення може бути доступний не для кожного CVE. Перевірте платформу SOC Prime на наявність поточного покриття. Якщо відповідні виявлення ще не доступні, повторно перевірте, оскільки нова розвідка загроз та вміст для виявлення постійно додаються.

Аналіз CVE-2026-98432

CVE-2026-98432 вражає код обробки з’єднань IPv4 TCP у ядрах Linux, що містять вразливу реалізацію, введену в Linux 4.4. Команда Linux kernel CVE класифікує це питання як критичне з оцінкою CVSS 3.1 на рівні 9.8 і вектором AV/AC/PR/UI/S/C/I/A.

Вразливість є умовою “використана після звільнення”, викликаної змаганням під час одночасної обробки з’єднань TCP. Коли встановлюється з’єднання IPv4 TCP, tcp_v4_syn_recv_sock() передає IP-опції, що асоціюються з очікуваним запитом до новоствореного сокету без створення окремої копії.

Інший процесор може одночасно обробляти повторно відправлений SYN, що асоціюється з тим же запитом сокету. Під час цього процесу функції, відповідальні за генерування SYN-ACK, продовжують читати IP-опції, захищені критичною секцією читання RCU.

Однак дочірній сокет може бути знищений, поки ця операція ще триває. Ядро потім звільняє структуру inet_opt, використовуючи kfree(), залишаючи ще один процесор, можливо, у зверненні до пам’яті, яка вже була звільнена. Утворене застаріле посилання створює умову “використання після звільнення” в ip_options_build().

Подібна гонка існує під час міграції сокетів запитів, включаючи конфігурації, що використовують net.ipv4.tcp_migrate_req=1 або на основі BPF SK_REUSEPORT_SELECT_OR_MIGRATE. Впроваджене виправлення замінює небезпечне звільнення пам’яті на RCU-aware звільнення, забезпечуючи, щоб читачі закінчили доступ до об’єкта перед тим, як його пам’ять може бути звільнена.

Перше питання специфічно впливає на IPv4. У рекомендаціях ядра зазначається, що IPv6 не є вразливим до цієї конкретної гонки, оскільки tcp_v6_syn_recv_sock() дублює відповідні опції замість їх передачі тим же чином.

Віддалена експлуатація вимагає спеціально сконструйованого мережевого трафіку та точного маніпулювання умовою гонки. Red Hat зауважує, що можливими наслідками можуть бути аварійне завершення ядра, пошкодження пам’яті та потенційно віддалене виконання коду. Відсутність аутентифікації та взаємодії з користувачем суттєво збільшує ризик для систем, що забезпечують доступ до TCP-сервісів у недовірених мережах.

Anthropic продемонстрували, що вразливість може бути трансформована в повну експлуатацію з привілеями root. Їх модель дослідження націлювала сервер Linux, що приймає з’єднання Multipath TCP, і використовувала два етапи для досягнення виконання команд.

Під час першого етапу експлуатація багаторазово викликає гонку та маніпулює значенням довжини, щоб ядро повернуло додаткову примикаючу пам’ять у відповіді мережі. Згодом одна з цих відповідей містить показник ядра. Це розкриття виявляє інформацію про розташування пам’яті ядра і дозволяє експлуатації обійти рандомізацію розташування адресного простору ядра (KASLR).

Під час другого етапу експлуатація використовує ту ж вразливість, щоб викликати переповнення буфера і перезаписати зворотний вказівник. Вказівник перенаправляється на корисне навантаження, що було попередньо розміщене в пам’яті ядра, використовуючи легітимну протокольну функціональність. Коли ядро викликає змінений зворотний дзвінок, існуючі функції ядра комбінуються до тих пір, поки не виконується вибрана зловмисником команда оболонки з правами root.

Особливо важливою характеристикою експлуатації є те, що програш гонки не обов’язково викликає аварійне завершення сервера. Замість цього спроба з’єднання може просто провалитися, дозволяючи зловмиснику повторювати спроби багаторазово. У тестовому середовищі Anthropic отримання корисного показника ядра вимагало приблизно 48 хвилин, за яким слідували ще п’ять хвилин для досягнення виконання команди root.

Це демонстрація не повинна тлумачитися як вимога до MPTCP для експлуатації. Anthropic продемонстрували один успішний шлях експлуатації з MPTCP-слухачем, але вразливий код присутній у звичайній обробці IPv4 TCP. Red Hat спеціально попереджає, що відключення MPTCP не повністю вирішує вразливість і що звичайні установки RHEL залишаються вразливими, навіть якщо MPTCP за замовчуванням відключений.

Також важливо розрізняти ситуацію з доказом концепції CVE-2026-98432 від існування повністю узброєного експлуатаційного коду. Anthropic розробили функціональний доказ концепції з віддаленими правами root внутрішньо, але не публікували його. Публічний код, повідомлений дослідниками безпеки, може демонструвати або виявляти аспекти основної гонки й розкриття пам’яті, але перевірені джерела не документують загальнодоступний код, що відтворює повний ланцюжок віддаленого виконання коду Anthropic.

Вразливість була повідомлена дослідником Anthropic Сіньян Ґе. Виправлення від upstream Linux було застосовано 5 жовтня 2026 року, а запис CVE ядра Linux був опублікований 15 жовтня. Anthropic публічно описали своє повне дослідження експлуатації 27 жовтня.

Проект ядра Linux ідентифікує такі виправлені версії upstream:

• Linux 5.10.272
• Linux 5.15.223
• Linux 6.1.190
• Linux 6.6.159
• Linux 6.12.113
• Linux 6.18.56
• Linux 7.2.10
• Linux 7.3

Команда ядра рекомендує оновитися до останньої стабільної версії ядра, а не вибірково зобов’язувати коміти.

Вразливість та усунення відмінні у різних дистрибуціях, оскільки постачальники Linux підтримують власні ядра і зворотно застосовують виправлення безпеки. Red Hat наразі оцінює це питання як критичне на рівні 9.8 і випустили виправлення для кількох потоків RHEL 8, 9 і 10. Продукти OpenShift і продукти, що залежні від уражених ядер RHEL, також потребують уваги.

Ubuntu також оцінює вразливість як критичну на рівні 9.8. Ubuntu 26.10 отримала виправлене загальне ядро, тоді як виправлення для Ubuntu 22.04 LTS, 24.04 LTS і 26.04 LTS були доступні в пропонованій тестовій кишені на початок листопада, з додатковими підтримуваними релізами, що очікують на виправлення. Адміністратори повинні використовувати CVE-сторінку Canonical, а не покладатися виключно на номери версій ядра upstream.

Для виявлення CVE-2026-98432 команди з безпеки повинні поєднувати телеметрію мережі та хоста. Потенційні сигнали полювання на рівні мережі включають незвичайні вхідні пакети IPv4 TCP, що містять опції IP, особливо повторювані запити на з’єднання з параметрами Record Route або Timestamp, і ненормальні моделі повторних SYN. Присутність такого трафіку самостійно не підтверджує експлуатацію, але надає корисну точку опори для полювання при зіставленні з вразливими системами.

Моніторинг на рівні хоста повинен включати аварійні зупинки ядра Linux, попередження ядра, індикатори пошкодження пам’яті, несподівані перезапуски сервісів і аномальну активність безпосередньо після підозрілого мережевого трафіку. Оскільки успішне використання вразливості може теоретично забезпечити виконання коду з привілеями root, захисники також повинні стежити за несподіваними привілейованими процесами, новоствореними файлами, змінами конфігурації, механізмами стійкості та необґрунтованими вихідними підключеннями.

В даний час немає специфічних IOCs для CVE-2026-98432, таких як підтверджені шкідливі IP-адреси, домени або хеші шкідливого ПЗ, оскільки перевірені джерела не повідомляють про реальне експлуатування. Захисники повинні тому зосередитися на поведінковому виявленні та оцінюванні експозиції, а не на статичних індикаторах.

Пом’якшення CVE-2026-98432

Остаточним рішенням є встановлення ядра, наданого постачальником, що містить виправлення безпеки. Команда CVE ядра Linux рекомендує перейти до останньої підтримуваної стабільної версії ядра, тоді як користувачі розподілів Linux повинні встановлювати пакети, які надають конкретно їхні постачальники, оскільки виправлення часто застосовуються не замінюючи upstream-версію ядра.

Адміністратори повинні надавати пріоритет інтернет-зверненим серверам Linux та іншим системам, що приймають вхідні з’єднання IPv4 TCP. Поверхня атаки є широкою, оскільки вразливість існує в мережевому стеку ядра, а не у окремому додатку чи серверному продукті.

Організації повинні зробити наступні кроки:

1. Інвентаризуйте сервери Linux і визначте запущене ядро за допомогою таких інструментів, як uname -r.
2. Перевірте відповідний консультативний документ з безпеки дистрибуції Linux, а не визначайте експозицію виключно за номером версії upstream.
3. Встановіть виправлене ядро, надане постачальником, як тільки воно стане доступним.
4. Перезавантажте уражені системи після встановлення оновленого ядра, щоб переконатися, що працює патчове ядро.
5. приємний час
6. Огляньте послуги TCP, що піддаються впливу ззовні, і обмежте необов’язкову мережеву доступність.
7. Продовжуйте моніторити радники постачальників, оскільки доступність виправлень відрізняється серед дистрибуцій Linux, варіантів ядер, хмарних ядер і каналів підтримки.

Red Hat та Ubuntu також задокументували проміжний підхід до фільтрації пакетів, що відбраковує вхідні пакети IPv4 TCP, що містять IP-опції. Рекомендований стан nftables перевіряє наявність довжини заголовка IPv4 більше п’яти і відбраковує відповідні пакети TCP до їх досягнення вразливого шляху обробки сокета.

Ця міра може зменшити експозицію, оскільки відомий шлях експлуатації вимагає IP-опцій IPv4. Однак обидва постачальники попереджають, що фільтрація пакетів не є повним замінником встановлення виправленого ядра. Вона також може заважати робочим навантаженням, які легітимно залежать від IP-опцій IPv4, тому слід її тестувати перед впровадженням у виробництво.

Відключення MPTCP саме по собі не повинно вважатися достатнім захистом. Хоча робоча експлуатація Anthropic націльовувалася на слухача MPTCP, основна вразливість існує в звичайній обробці IPv4 TCP. Red Hat особливо зауважує, що RHEL залишається вразливим у своїй звичайній конфігурації, навіть якщо MPTCP за замовчуванням відключений.

Для середовищ, що використовують програми Go, вимкнення автоматичної поведінки MPTCP може зменшити експозицію для конкретної експлуатації, продемонстрованої Anthropic, але це залишається неповною мірою зменшення ризику. Системи без слухача MPTCP не повинні автоматично вважатися безпечними, оскільки інші техніки експлуатації можуть націлюватися на ту ж основну гонку.

Оскільки жодна реальна компромісна кампанія не була підтверджена, керівництво інцидент-відповіді наразі повинно зосереджуватися на ідентифікації потенційно вразливих систем і підозрілої поведінки експлуатації, а не на пошуку відомого набору інфраструктури зловмисника. Організації, що спостерігають незвичайний TCP-трафік, за яким слідує нестабільність ядра або несподіване виконання команд з привілеями, повинні вважати цю активність потенційно шкідливою і зберігати мережеву та хостову телеметрію для розслідування.