Copy Fail: 732 Байти Python проти Кожного Linux-Вузла Крипто з 2017 року

Дев'ять років. Приблизно стільки вразливість підвищення привілеїв, яку тепер називають Copy Fail, існувала в основному Linux, за даними дослідників, які розкрили її цієї весни. Експлойт вміщується у 732 байти Python — приблизно десять рядків коду — і надає зловмиснику права root на будь-якому вразливому хості, де вже є виконання коду. 1 травня 2026 року CISA внесла його до каталогу відомих експлуатованих вразливостей (Known Exploited Vulnerabilities), що означає: це вже не теорія.

Для операторів крипто-інфраструктури ключовий показник — не кількість байтів, а поверхня розгортання: кожен великий дистрибутив Linux, випущений з 2017 року. Це охоплює більшість бірж, флотилій валідаторів, RPC-провайдерів і кастодіальних підписантів у виробничому середовищі сьогодні.

Що Сталося

Хронологія розкриття інформації є надзвичайно стислою для помилки ядра такого масштабу. Як повідомила біржа MEXC, проблему було приватно повідомлено команді безпеки ядра Linux 23 березня, патчі потрапили в основну гілку 1 квітня, CVE було присвоєно 22 квітня, а публічний опис із робочим proof of concept з'явився 29 квітня. CISA додала вразливість до KEV два дні потому.

Від приватного повідомлення до патча в основній гілці минуло дев'ять днів, а від патча до публічного PoC — 28 днів. За стандартами розкриття вразливостей ядра це дуже швидко, і сама швидкість є сигналом: підтримувачі та дослідники вважали проблему достатньо серйозною, щоб встановити жорстке ембарго і швидко включити патч в основну гілку, а не проводити типовий багатомісячний координований процес розкриття.

Механіка, за даними джерела, — це вразливість підвищення привілеїв, що ґрунтується на невеликій логічній помилці, як описують дослідники. Передумовою для експлойту є попереднє виконання коду на цілі, тому це не віддалений неавтентифікований захват. Це другий етап. Щойно зловмисник отримує будь-яке закріплення на рівні користувача — через скомпрометовану залежність, витік SSH-ключа, обробник webhook або шкідливий контейнер — Python-пейлоад підіймає його від цього закріплення до root. Один із дослідників, цитованих у джерелі, сказав прямо: «10 рядків Python можуть бути всім, що потрібно для отримання прав root на будь-якій вразливій системі».

Пейлоад описується як платформонезалежний, що у цьому контексті означає: його не потрібно перекомпілювати під кожну архітектуру або дистрибутив. Той самий скрипт працює в усьому діапазоні вразливих ядер. Джерело не розкриває, який підсистем ядра містить помилку або конкретний ідентифікатор CVE, що важливо: операторам, які зараз визначають рівень ризику, потрібні ці дані, щоб оцінити статус патчів у різнорідних флотах.

Технічна Анатомія

Якщо відкинути маркетингові формулювання, Copy Fail — це класичне локальне підвищення привілеїв, тієї самої категорії, що Dirty COW (2016) і Dirty Pipe (2022). Шаблон знайомий: логічна помилка в низькорівневому примітиві ядра, яку можна використати з непривілейованого простору користувача, перетворена на зброю через короткий скрипт. Різниця кожного разу — у тривіальності ланцюжка експлойту та широті діапазону версій ядра. Діапазон Copy Fail — усі дистрибутиви з 2017 року — є одним із найширших.

Показник у 732 байти Python заслуговує на увагу. Пейлоад такого розміру, написаний інтерпретованою мовою без нативної компіляції, свідчить про те, що помилку можна викликати через високорівневі системні виклики або файлові операції, а не через маніпуляції з регістрами чи підготовку купи ядра. Це має два наслідки. По-перше, виявлення засобами EDR ускладнюється, оскільки зловмисник не скидає ELF-бінарники й не виконує шелл-код, що виглядає аномально. По-друге, експлойт є переносимим через межі контейнерів: скомпрометований pod навіть зі стандартним інтерпретатором Python і можливостями на рівні CAP_SYS_PTRACE (або іншим базовим примітивом) може перейти до root хоста.

Для крипто-інфраструктури зокрема архітектурна проблема полягає в нашаруванні. Типовий стек біржі або кастодія складається з Linux-хостів, оркестрації контейнерів поверх них і робочих навантажень підпису або відповідного рушія всередині цих контейнерів. Якщо Copy Fail долає межу ядра хоста зсередини контейнера, то ізоляція контейнерів — припущення, на якому ґрунтується більшість мультитенантних блокчейн RPC-провайдерів і спільної валідаторної інфраструктури, — суттєво послаблюється до моменту застосування патчів.

Оператори валідаторів на таких мережах, як Solana або клієнти виконання Ethereum на Ubuntu LTS, Debian stable чи похідних RHEL, усі перебувають у зоні ураження. Той факт, що вразливість існувала приблизно дев'ять років, означає, що вона передує поточному поколінню конфіденційних обчислень і розгортань у стилі gVisor-сендбоксів — тобто помилка старіша за більшість засобів захисту, на які розраховують оператори.

Джерело не уточнює, чи профілі AppArmor, SELinux або seccomp суттєво нейтралізують експлойт. Ця прогалина важлива: якщо стандартні профілі захисту блокують шлях системного виклику, операційна терміновість для захищених розгортань різко знижується, тоді як голі стандартні ядра залишаються повністю вразливими. Поки це не уточнено, оператори повинні вважати, що жодного пом'якшення немає.

Хто Постраждає

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

Централізовані біржі зі зрілими командами безпеки застосують патчі найшвидше. У них є конвеєри управління змінами, інструменти живого патчингу ядра на кшталт kpatch або Ksplice та SOC-моніторинг, який виявить сигнатури публічного PoC. Ризик протягом 90 днів для цих операторів є помірним: вікно між публічним PoC (29 квітня) і повним застосуванням патчів на всьому флоті — саме тут атакуватимуть масові зловмисники, але Tier-1 майданчики мають закрити його протягом кількох тижнів.

Складніша проблема — у валідаторах середнього рівня, RPC-провайдерів і самостійно утримуваної інфраструктури, якою керують невеликі команди. Багато з них використовують довгоживучі bare-metal вузли, де оновлення ядра вимагає скоординованих перезавантажень, вікон ризику слешингу та перезапуску consensus-клієнтів. Оператор валідатора, який відкладає перезавантаження ядра, щоб уникнути простою, — це саме той профіль, якого шукає зловмисник Copy Fail: тривалий аптайм, привілейовані ключі на диску або в процесах, суміжних з HSM, і, ймовірно, застаріле ядро.

Кастодіани перебувають у найгіршому становищі, якщо вони використовують Linux-інфраструктуру підпису без суворої повітряної ізоляції. Підвищення привілеїв саме по собі не витягує ключі, захищені HSM, але root на оркестраторі підпису надає зловмиснику можливість ставити шкідливі транзакції через легітимні шляхи підпису. Поки невідомо, чи були вже атаковані кастодіани у реальних умовах, але межа така: між PoC від 29 квітня і внесенням до KEV 1 травня кожен добре фінансований суб'єкт загрози, який має крипто у списку цілей, уже має робочий код.

DeFi-протоколи як такі — рівень смарт-контрактів — здебільшого захищені. Ризик стосується позаланцюгових операторів: хостів фронтенду, оракульної інфраструктури, машин з multisig-підписом. Скомпрометований підписант Safe на незапатченому Linux-ноутбуці — це конкретний, реальний сценарій атаки протягом наступного кварталу.

Дії для Крипто та DeFi

Дії цього тижня у порядку пріоритетності. Проінвентаризуйте версії ядра на кожному хості, який торкається ключів, підписує транзакції, запускає програмне забезпечення валідатора або обслуговує публічний RPC-ендпоінт. Усе на ядрі з 2017 року і пізніших версій умовно потрапляє в зону ризику, доки не доведено інше за допомогою присвоєного CVE (який оператори мають зараз отримати з трекерів безпеки свого дистрибутива).

Застосуйте патчі основної гілки від 1 квітня через бекпорти дистрибутивів. Для Ubuntu, Debian, RHEL і Amazon Linux рекомендації з безпеки вже мають містити посилання на виправлення. Живий патчинг є кращим за перезавантаження для хостів валідаторів, щоб уникнути вікон слешингу, але заплановане перезавантаження краще за незапланований компроміс.

Розгляньте будь-який хост з попередніми нез'ясованими сповіщеннями про виконання коду з березня як потенційно вже скомпрометований. Експлойт передує публічному PoC для дослідників, і вважати, що до 29 квітня не було реального використання, — це оптимізм. Змініть SSH-ключі, API-токени та будь-які облікові дані, що зберігалися на цих хостах. Для інфраструктури підпису змінюйте операційні ключі там, де це дозволяє модель загроз; для кореневих ключів холодного зберігання проведіть аудит журналів доступу.

Посильте вимогу-передумову. Copy Fail потребує попереднього виконання коду, тому ланцюжок експлойту залежить від закріплення першого етапу. Цей тиждень — слушний момент для аудиту конвеєрів залежностей, базових образів контейнерів і CI/CD-раннерів. Захищений перший етап нейтралізує більшість ризику другого етапу незалежно від статусу патчів.

Нарешті, стежте за ритмом каталогу KEV. Федеральний перелік CISA створює регуляторний тиск на американські регульовані організації, і крипто-компанії, що працюють за державними трастовими ліцензіями або реєстраціями MSB, мають очікувати, що на наступному аудиті перевіряючі запитають про усунення Copy Fail.

Прогноз, який можна перевірити: якщо Copy Fail повторить траєкторію Dirty Pipe, протягом 90 днів після внесення до KEV 1 травня слід очікувати принаймні одного публічно розкритого компромісу крипто-інфраструктури, пов'язаного з цим CVE, — майже напевно RPC-провайдера або валідатора середнього рівня, а не Tier-1 біржі.

Ключові Висновки

• Copy Fail — це локальне підвищення привілеїв у Linux, присутнє в дистрибутивах з 2017 року, яке використовується через 732-байтний Python-пейлоад після отримання зловмисником початкового виконання коду.
• Розкриття було стислим: приватне повідомлення 23 березня, патч в основній гілці 1 квітня, CVE 22 квітня, публічний PoC 29 квітня, внесення до KEV 1 травня 2026 року.
• Крипто-біржі, вузли валідаторів і кастодіальна інфраструктура підпису прямо названі цілями підвищеного ризику; найбільше вразливі менші валідатори з тривалим аптаймом.
• Джерело не розкриває уражений підсистем ядра або те, чи профілі SELinux/AppArmor нейтралізують експлойт — це наступний критичний момент для триажу.
• Захист закріплення першого етапу (CI/CD, залежності, образи контейнерів) є не менш важливим, ніж патчинг ядер, оскільки Copy Fail вимагає попереднього виконання коду.