Вразливість Copy Fail (CVE-2026-31431) у Linux: локальне підвищення привілеїв до root

CISA додала вразливість CVE-2026-31431 (Copy Fail) у ядрі Linux до свого каталогу експлуатованих вразливостей CISA KEV, підтвердивши її активну експлуатацію: помилка з оцінкою CVSS 7.8 дозволяє будь-якому локальному непривілейованому користувачу отримати права root шляхом пошкодження кешованих у пам’яті виконуваних файлів, зокрема setuid бінарників, що робить критично важливим негайне оновлення дистрибутивів Linux (особливо в хмарних і контейнерних середовищах) до версій ядра з виправленням.

Технічні деталі вразливості

Copy Fail (CVE-2026-31431), описана в записі NVD CVE-2026-31431, є вразливістю локального підвищення привілеїв у підсистемі криптографічних шаблонів автентифікації ядра Linux. CISA формулює її як некоректну «передачу ресурсів між сферами», що на практиці призводить до можливості користувацького процесу впливати на об’єкти в більш привілейованій області.

Ключові факти щодо вразливості:

• Ідентифікатор: CVE-2026-31431 (Copy Fail)
• Оцінка: CVSS 7.8 (висока небезпека)
• Тип: локальне підвищення привілеїв (LPE) до рівня root
• Вектор: локальний (AV:L), низькі вимоги до привілеїв, відсутність взаємодії з користувачем
• Уразливі системи: дистрибутиви Linux, що постачаються з 2017 року
• Виправлення: ядро Linux версій 6.18.22, 6.19.12 і 7.0

Дослідники Theori і Xint показали, що проблема виникла не через один помилковий коміт, а внаслідок трьох окремо «безпечних» змін у ядрі, зроблених у 2011, 2015 і 2017 роках. У сукупності вони призвели до логічної помилки в обробці криптографічного шаблону автентифікації, яку можна надійно експлуатувати за допомогою дуже компактного (близько 732 байт) експлойта на Python. На основі цього варіанта вже з’явилися реалізації на Go та Rust, виявлені у відкритих репозиторіях.

Критична особливість Copy Fail — цільовий об’єкт атаки: page cache, тобто кеш сторінок у пам’яті, в якому ядро зберігає вміст файлів. Вразливість дозволяє непривілейованому користувачу спотворювати вміст кешованих сторінок будь-якого доступного для читання файла, включно із setuid бінарниками. Як підкреслює Wiz, сторінка в кеші є тим, що фактично виконується процесором під час запуску бінарника, тому зміна page cache фактично модифікує програму «на льоту» без жодних записів на диск.

Звідси випливає типовий сценарій експлуатації:

• зловмисник із локальним доступом до системи використовує вразливість для зміни сторінок у cache, що відповідають привілейованому бінарнику (наприклад, /usr/bin/su);
• в змінені сторінки вбудовується довільний код;
• під час запуску привілейованого бінарника виконується вже модифікований код, що дає зловмиснику права root.

Експлойт використовує лише легітимні системні виклики і не спирається на гонки чи вгадування адрес у пам’яті. Це одразу знижує складність експлуатації та ускладнює виявлення поведінковими засобами: з погляду системи це виглядає як звичайна робота застосунку з криптографічною підсистемою та файлами.

За даними Microsoft Defender Security Research Team, уже фіксується «попередня тестова активність» навколо CVE-2026-31431, а CISA, включивши вразливість до каталогу KEV, прямо вказує на наявність експлуатації «в дикій природі».

За своєю суттю ця техніка відповідає типовому сценарію експлуатації вразливості для підвищення привілеїв, який у термінах MITRE ATT&CK належить до експлуатації локальних вразливостей привілеїв (Exploitation for Privilege Escalation).

Оцінка впливу та профіль ризику

Потенційний вплив Copy Fail визначається не стільки балом CVSS, скільки реальним контекстом застосування Linux:

• Хмари та віртуалізація. Linux домінує в хмарних інфраструктурах. Будь-який сценарій, де зловмисник може запустити код на віртуальній машині або в контейнері (наприклад, через витік ключів SSH або вразливий вебзастосунок), може бути ескальований до повного контролю над операційною системою гостя і, за певних умов, до атак на хостову платформу.
• Контейнерні платформи (Docker, LXC, Kubernetes). За оцінкою Kaspersky, Copy Fail становить підвищений ризик для контейнеризованих середовищ, оскільки процеси всередині контейнера за замовчуванням отримують доступ до підсистеми AF_ALG, якщо модуль algif_aead завантажено в ядро хоста. У такому разі експлуатація всередині контейнера може призвести до виходу за межі контейнера та отримання контролю над фізичним (або віртуальним) хостом, тобто до руйнування моделі ізоляції.
• Сервери спільного користування та multi-tenant системи. Платформи для навчання, хостинг-провайдери та будь-які середовища, де різні користувачі отримують shell-доступ до одного й того самого Linux-хоста, стають особливо вразливими: один неконтрольований користувач може отримати root і скомпрометувати дані інших клієнтів.
• Критична інфраструктура та держоргани. Для федеральних агентств США (FCEB) CISA встановила жорсткий термін встановлення виправлень — до 15 травня 2026 року. Це відображає ризик порушення цілісності та доступності критичних сервісів у разі успішної локальної компрометації.

З погляду бізнес-ризиків наслідки бездіяльності включають:

• повне захоплення сервера з можливістю подальшого горизонтального та вертикального переміщення всередині інфраструктури;
• підрив довіри до цілісності застосунків: вбудовування коду в привілейовані бінарники може використовуватися як малопомітний механізм довготривалого закріплення та обходу засобів контролю цілісності, що працюють лише з файловою системою;
• скомпрометовані конвеєри CI/CD: наявність у зловмисника прав root на агентах збірки дозволяє непомітно модифікувати створювані артефакти;
• регуляторні наслідки у випадку інцидентів, де доступ root використано для витоку або знищення даних, що належать до критичних чи персональних.

Практичні рекомендації із захисту

1. Оцінка вразливості середовища

Першочергове завдання — визначити, які системи можуть бути вразливими:

• перевірте версію ядра командою uname -r на серверах і робочих станціях під керуванням Linux;
• зіставте отримані версії з тими, до яких уже інтегровано виправлення (6.18.22, 6.19.12, 7.0), або з оновленнями, випущеними вашим постачальником дистрибутиву;
• проаналізуйте середовища, де є можливість запуску коду від імені неповнопривілейованих користувачів: контейнерні кластери, сервери з SSH-доступом для розробників, машини CI.

У разі сумнівів доцільно звіритися з інформацією про CVE-2026-31431 в базі NVD та з документацією постачальника дистрибутиву або ядра (наприклад, офіційним сайтом kernel.org).

2. Патч-менеджмент і пріоритезація

Рекомендований порядок дій з оновлення:

1. Найвищий пріоритет (терміново): вузли, де можливий доступ сторонніх або шкідливих процесів до локального shell: сервери з публічним SSH-доступом, вузли Kubernetes, вузли з запущеними зовнішніми контейнерами, сервери спільного користування.
2. Високий пріоритет: агенти CI/CD, інфраструктурні сервіси та бази даних, де компрометація root призведе до каскадних наслідків.
3. Інші системи: включити оновлення ядра до найближчого планового вікна обслуговування.

Для FCEB-агентств дедлайн заданий CISA — до 15 травня 2026 року. Для комерційних організацій розумно орієнтуватися на подібні строки: рахунок іде на дні, а не місяці.

3. Тимчасові заходи за неможливості негайного оновлення

Якщо оперативне оновлення ядра неможливе (наприклад, через обмеження у вікнах простою):

• Вимкніть уразливу функціональність. CISA рекомендує тимчасово вимкнути відповідну функціональність. На практиці це означає обмеження використання підсистеми AF_ALG і пов’язаних модулів (зокрема, algif_aead) відповідно до рекомендацій постачальника дистрибутиву.
• Посильте мережеву ізоляцію. Зведіть до мінімуму можливість отримання зловмисником локального доступу: обмежте SSH лише через VPN або з довірених адрес, посильте політику доступу до бастіонних хостів.
• Перегляньте політику доступу в контейнерних кластерах. Обмежте запуск неперевірених контейнерів на вузлах, де ще не встановлено оновлене ядро, і по можливості уникайте запуску контейнерів із зайвими привілеями та доступом до криптографічних підсистем ядра.
• Посильте контроль облікових записів. Мінімізуйте кількість користувачів з інтерактивним доступом до систем і застосуйте принцип найменших привілеїв для сервісних облікових записів.

4. Моніторинг і виявлення

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

• посилити аудит запуску привілейованих бінарників (особливо setuid) та аномальної поведінки процесів із правами root;
• відстежувати нетипове використання криптографічних підсистем ядра та AF_ALG там, де вони зазвичай не задіяні прикладним програмним забезпеченням;
• переглянути правила поведінкового аналізу в рішеннях EDR та подібних для Linux, додавши фокус на неочікувану ескалацію привілеїв застосунків, що працюють від непривілейованих користувачів.

Ключовий висновок: будь-яке середовище, де потенційний зловмисник може запустити код на вразливому Linux-хості, слід розглядати як таке, що перебуває під ризиком повного захоплення, доки ядро не оновлено до версії з виправленням CVE-2026-31431 або не вимкнено відповідну функціональність. Найпрактичніший крок — у найближче вікно обслуговування оновити ядро (або пакети ядра дистрибутиву) до версій, що містять патч, із пріоритетом для хостів із контейнерами, публічним SSH і багатокористувацькими сценаріями.