У свіжому випуску подкасту IBM Security Intelligence експерти з кібербезпеки обговорюють одну з найнеприємніших новин для світу Linux за останні роки: виявлення вразливості Copy Fail (CVE‑2026‑31431). Дослідники, які використовували AI‑сканер вразливостей Xint Code, знайшли помилку, що зародилася ще в 2011 році в коді ядра, але стала реально експлуатованою лише після оптимізації 2017 року. Сьогодні вона дозволяє звичайному локальному користувачу отримати root‑доступ на більшості популярних дистрибутивів за лічені секунди — за допомогою компактного Python‑скрипта.
Ця історія — не просто про ще один CVE. Вона показує, як роками накопичені зміни в ядрі Linux можуть несподівано скластися в ідеальний ланцюжок для експлойта, чому AI‑інструменти вже змінюють пошук вразливостей і як спільноті доводиться відмотувати оптимізації назад, аби повернути безпеку.
Вразливість, що ховалася майже десятиліття
Copy Fail отримала власне ім’я не випадково. Її суть — у неправильному поводженні з копіюванням даних у сторінковий кеш (page cache) ядра Linux. Формально вразливість відстежується як CVE‑2026‑31431, але важливіше те, що вона зачіпає більшість дистрибутивів, які постачаються з ядрами, випущеними з 2017 року.
Модель загрози виглядає особливо тривожно для реальних середовищ:
локальний, але непривілейований користувач може отримати повний root‑доступ, не маючи жодних спеціальних прав чи доступу до конфігураційних файлів. Для цього достатньо запустити приблизно 732‑байтний Python‑скрипт. Експлуатація не вимагає складних гонок процесів чи тонкого таймінгу, не змінює файли на диску й не залишає помітних артефактів у файловій системі. На практиці дослідники продемонстрували отримання root‑прав за секунди на основних корпоративних платформах — Red Hat, SUSE, Ubuntu, а також у хмарних середовищах на базі AWS.
Така комбінація — простота, надійність, відсутність слідів на диску — робить Copy Fail особливо привабливою для зловмисників, які вже мають будь-який локальний доступ: від скомпрометованого контейнера до обмеженого облікового запису розробника чи сервісного користувача.
Як працює Copy Fail: чотири байти, що змінюють усе
Технічно Copy Fail — це не класичний «дірявий» буфер чи очевидний use‑after‑free. Її сила в тому, що вона дозволяє зробити те, що в Linux суворо заборонено: змінити вміст файлу, не маючи до нього прав на запис.
Ключовий механізм — сторінковий кеш. Ядро Linux тримає вміст файлів у пам’яті у вигляді сторінок, щоб прискорити доступ. Зазвичай, якщо процес не має прав на запис, він не може змінити ці сторінки. Copy Fail порушує це правило.
Вразливість дає непривілейованому користувачу можливість записати чотири контрольовані байти у сторінковий кеш файлу, до якого він не має прав на запис. Цього, на перший погляд, небагато. Але в сучасних системах чотири байти — це, наприклад, ціле 32‑бітне значення, вказівник, прапор доступу чи частина структури, що визначає поведінку процесу з підвищеними привілеями.
Далі сценарій розвивається за класичною схемою локального підвищення привілеїв. Зловмисник обирає цільовий файл, який:
з одного боку, використовується root‑процесом або механізмом із підвищеними правами, а з іншого — має передбачувану структуру в пам’яті. Після ін’єкції чотирьох байтів у сторінковий кеш цей root‑процес читає вже модифіковані дані, що дозволяє змінити його поведінку: підмінити конфігураційне значення, обійти перевірку прав, змінити адресу повернення чи вказівник на функцію. Оскільки змінюється лише пам’ять, а не сам файл на диску, класичні засоби контролю цілісності файлів, журнали файлової системи чи антивірусні сканери не бачать жодних аномалій.
Саме тому експлойт можна реалізувати у вигляді компактного, детермінованого Python‑скрипта без гонок — він працює стабільно й передбачувано, що нетипово для багатьох складних локальних експлойтів ядра.
Еволюція багу: від IPsec у 2011‑му до експлойта в 2017‑му
Copy Fail не з’явилася раптово. Це класичний приклад того, як кілька на перший погляд безпечних змін у різних частинах ядра з часом складаються в повноцінну вразливість.
Перший крок стався ще у 2011 році. У коді, пов’язаному з IPsec, з’явився коміт, який заклав фундамент майбутньої проблеми. На цьому етапі помилка ще не дозволяла зробити нічого небезпечного: це був радше логічний дефект у тому, як обробляються певні криптографічні операції.
У 2015 році відбувся другий важливий етап: механізм authencesn було переведено на новий інтерфейс AEAD (Authenticated Encryption with Associated Data). Саме тоді з’явилася можливість виходу за межі коректного зсуву запису — out‑of‑bounds write offset. Проте навіть у такому вигляді помилка залишалася теоретичною: шлях від цього зсуву до реального контролю над пам’яттю ядра був занадто непрямим, а практична експлуатація — нереалістичною.
Критичним став 2017 рік. У шарі AF_ALG AEAD, який надає користувацьким процесам інтерфейс до криптографічних примітивів ядра через сокети, було проведено оптимізацію. Замість використання механізму splice, що працює з даними у відносно безпечний спосіб, розробники перейшли до моделі з «записом у призначення, яке можна змінювати» — фактично, до більш прямого й гнучкого керування сторінковим кешем.
Саме ця оптимізація зробила Copy Fail практично експлуатованою. Поєднання:
історичної помилки в IPsec‑коді, зміни інтерфейсу authencesn на AEAD у 2015‑му та нового способу роботи AF_ALG AEAD зі сторінковим кешем у 2017‑му відкрило шлях до контрольованого запису чотирьох байтів у кеш файлу без прав на запис. З погляду розробників, оптимізація виглядала логічною: менше копіювань, краща продуктивність криптографічних операцій. Але в поєднанні з попередніми змінами вона створила саме той ланцюжок, який і шукають досвідчені дослідники безпеки.
У підсумку вразливість роками жила в ядрі, не привертаючи уваги, поки AI‑підсилений аналіз коду не допоміг її виявити.
AI у пошуку вразливостей і «відкат» оптимізацій як виправлення
Copy Fail цікава ще й тим, як її знайшли. Дослідники використовували Xint Code — AI‑орієнтований сканер вразливостей, який аналізує великі масиви коду, шукаючи нетривіальні патерни потенційно небезпечної поведінки. У контексті ширшої дискусії про «Y2K‑момент» для кібербезпеки це показовий приклад: ті самі потужні моделі, які можуть допомагати зловмисникам, дедалі активніше використовуються й захисниками для виявлення глибинних, історичних помилок.
Виправлення Copy Fail виявилося водночас простим і показовим. Основний патч фактично відміняє ту саму оптимізацію AF_ALG AEAD 2017 року, яка зробила баг експлуатованим. Іншими словами, спільноті ядра довелося пожертвувати частиною продуктивності криптографічного шару заради відновлення безпечної моделі роботи зі сторінковим кешем.
На момент запису подкасту патчі вже розгорталися в основних гілках ядра Linux. Це означає, що:
оновлення ядра, яке включає виправлення CVE‑2026‑31431, стає ключовим кроком для всіх дистрибутивів, що підтримують ядра, випущені після 2017 року. постачальники дистрибутивів мають інтегрувати ці зміни у свої стабільні гілки та LTS‑версії, а адміністратори — оперативно планувати оновлення, особливо на багатокористувацьких серверах, віртуальних хостах, CI/CD‑інфраструктурі та хмарних середовищах.
Цей випадок ще раз підкреслює, що оптимізації на рівні ядра, особливо в зонах, пов’язаних із пам’яттю й кешами, мають проходити не лише функціональне, а й глибоке моделювання загроз. У світі, де AI‑інструменти здатні швидко аналізувати складні ланцюжки змін за багато років, «невинні» мікрооптимізації можуть обернутися масштабними ризиками.
Реальний ризик для дистрибутивів і хмарних середовищ
З практичного погляду Copy Fail — це класичний «масовий» локальний root‑експлойт. Він не дає віддаленого доступу сам по собі, але в сучасних архітектурах цього часто й не потрібно.
Уявімо кілька типових сценаріїв.
На багатокористувацькому Linux‑сервері, де розробники мають shell‑доступ із обмеженими правами, один скомпрометований обліковий запис достатній, щоб за секунди отримати повний контроль над системою, обійти SELinux/AppArmor‑політики й захопити всі інші облікові записи. У хмарному середовищі на базі AWS, де один віртуальний інстанс може виконувати десятки контейнерів, вразливість дозволяє вийти за межі контейнера, отримати root усередині гостьової ОС і далі атакувати інші сервіси, ключі доступу, метадані інстанса. У CI/CD‑інфраструктурі, де агенти збірки працюють під непривілейованими користувачами, експлойт відкриває шлях до компрометації всієї ланки постачання: від підписів артефактів до секретів розгортання.
Те, що експлойт не залишає слідів на диску, ускладнює форензику. Якщо зловмисник обмежиться тим, щоб отримати root, витягнути секрети з пам’яті й очистити журнали, класичні методи аналізу інцидентів можуть не виявити жодних змін у файловій системі. Це підвищує цінність телеметрії на рівні ядра, моніторингу системних викликів і поведінкових EDR‑рішень, здатних помічати аномальні операції з AF_ALG чи нетипові патерни доступу до криптографічних інтерфейсів.
Водночас локальний характер вразливості означає, що вона найнебезпечніша там, де вже існує ризик початкового проникнення: фішинг, вразливі веб‑додатки, скомпрометовані ключі доступу до серверів. Copy Fail перетворює будь-який такий початковий foothold на повний контроль над системою з мінімальними зусиллями.
Що означає Copy Fail для безпеки Linux у довгостроковій перспективі
Copy Fail вписується в довгу історію локальних root‑експлойтів для Linux, але має кілька рис, які роблять її показовою для поточного етапу розвитку екосистеми.
По‑перше, це демонстрація того, як довгоживучі помилки можуть роками залишатися безпечними, поки зміни в інших підсистемах не зроблять їх небезпечними. Це ускладнює класичну модель рев’ю коду: навіть ретельна перевірка окремого патча не гарантує, що через кілька років інша оптимізація не перетворить його на частину експлойта.
По‑друге, історія Copy Fail підкреслює роль AI‑інструментів у пошуку складних вразливостей. Xint Code, який використовувався дослідниками, є прикладом того, як великі моделі можуть аналізувати взаємодію між підсистемами, відстежувати еволюцію коду й виявляти нетривіальні ланцюжки, що ведуть до контролю над пам’яттю. У контексті того, що великі гравці ринку — від Anthropic до OpenAI і CrowdStrike — говорять про «Y2K‑момент» для кібербезпеки, Copy Fail виглядає як практичне підтвердження: фронтирні моделі вже знаходять те, що роками вислизало від очей людей.
По‑третє, реакція спільноти — відкат оптимізації AF_ALG AEAD — показує, що іноді єдиний реалістичний шлях до безпеки полягає в тому, щоб пожертвувати частиною продуктивності. Для Linux, який часто обирають саме через його ефективність, це непросте, але необхідне рішення.
Нарешті, Copy Fail нагадує, що локальні вразливості не можна недооцінювати. У світі контейнеризації, мікросервісів і хмарних платформ межа між «локальним» і «віддаленим» розмивається: один успішний локальний експлойт усередині віртуальної машини може стати трампліном для ланцюжка атак, що охоплюють цілі кластери й регіони.
Висновок: старі баги, нові інструменти й відповідальність спільноти
Copy Fail — це історія про те, як невелика помилка в IPsec‑коді 2011 року, посилена змінами 2015‑го й оптимізацією 2017‑го, перетворилася на тривіальний root‑експлойт у 2020‑х. Це також історія про те, як AI‑підсилені інструменти на кшталт Xint Code здатні знаходити такі ланцюжки й виводити їх на світло, поки зловмисники не встигли масово ними скористатися.
Для адміністраторів і розробників висновок очевидний: оновлення ядра з патчем CVE‑2026‑31431 має стати пріоритетом, особливо в середовищах із багатьма локальними користувачами чи контейнерами. Для спільноти ядра Linux — це ще один аргумент на користь глибшого моделювання загроз при будь-яких змінах, що стосуються пам’яті, кешів і криптографічних інтерфейсів.
А для всієї екосистеми безпеки Copy Fail — нагадування, що «Y2K‑момент» кібербезпеки — це не лише про майбутні AI‑загрози, а й про давно написаний код, який у поєднанні з новими оптимізаціями й новими інструментами аналізу може раптово стати найслабшою ланкою.