Наприкінці квітня 2026 року в спільноті Linux заговорили про діру в модулі ядра algif_aead. Проблема локальна, але критична: зловмисник із мінімальними правами в системі може піднятися до root. На практиці це означає втрату контролю над сервером. Отримавши root-доступ, сторонній користувач може забирати бази даних, конфігураційні файли, SSH-ключі або взагалі перебудувати систему під свої потреби. Ситуація стала значно небезпечнішою, оскільки готова інструкція та інструменти для зламу з’явилися у відкритому доступі майже одночасно з новиною про саму вразливість. Скрипт-кіді чи автоматизовані сканери зазвичай починають використовувати такі речі в перші ж дні.
Чому kernel-вразливості небезпечніші за баги в CMS
Зламана WordPress чи дірявий плагін зазвичай обмежуються ізольованим сайтом або каталогом вебсервера. З ядром історія інша. Оскільки воно керує пам’яттю, процесами та мережею на найнижчому рівні, помилка копіювання даних у algif_aead компрометує весь хост.
Ризик максимальний для систем, де крутяться ізольовані на перший погляд процеси або працюють кілька людей. Сюди відносяться:
- Ноди Docker, де прорив із контейнера означає доступ до сусідніх проєктів
- Сервери CI/CD, що збирають чужий код
- Термінальні сервери із доступом до командного рядка (shell)
- Shared-хостинги та корпоративні VPN-шлюзи
Шкідливий процес може спокійно працювати у фоні, не викликаючи kernel panic чи стрибків навантаження, тому візуально сервер здаватиметься абсолютно здоровим.
Проблемні дистрибутиви та підвох із перезавантаженням
Під загрозою опинилися майже всі популярні системи, на яких зазвичай тримають інфраструктуру: Ubuntu, Debian, AlmaLinux, Rocky Linux, CentOS Stream, openSUSE та Fedora. Патчі безпеки від мейнтейнерів вийшли швидко, але автоматично проблема не зникла.
У багатьох проектах VPS працюють місяцями без ребуту. Адміністратор міг запустити оновлення пакетів, але якщо сервер не перезавантажували, у пам’яті залишається старе вразливе ядро. Система звітує про встановлені копії нових бінарників, проте фактично працює на загроженому kernel.
Варіанти локалізації загрози
Найбільш надійний шлях – закрити питання кардинально, оновивши пакунки та запланувавши перезапуск.
Варіант 1. Оновлення та ребут
Для систем на базі Debian або Ubuntu:
apt update
apt upgrade -y
rebootДля Red Hat-подібних дистрибутивів (AlmaLinux, Rocky, CentOS):
dnf update -y
rebootВаріант 2. Гаряче відключення модуля
Якщо аптайм критичний і ребут прямо зараз неможливий, можна спробувати вивантажити модуль algif_aead з пам’яті вручну. Це спрацює, якщо криптографічні функції модуля не використовуються поточними сервісами:
modprobe -r algif_aeadДля запобігання його підняттю після випадкового перезапуску, додайте модуль до конфігу заборон:
echo "blacklist algif_aead" >> /etc/modprobe.d/blacklist.confЦе лише тимчасовий костиль, який знижує ризик, але не скасовує необхідність повноцінного патчу.
Контроль поточної версії
Перевірити, яке саме ядро виконується в цю хвилину, дозволяє команда:
uname -rЇї варто виконати як до оновлення, так і обов’язково після ребуту, щоб переконатися, що цифри в індексі змінилися. Якщо після команди ви бачите стару версію, ребут або не відбувся, або завантажувач Grub вибрав не той пункт.
Практика безпечного оновлення продуктових VPS
Будь-які маніпуляції з ядром на “живих” серверах несуть ризик. Перед тим як вводити команди, перевірте базові речі:
- Наявність свіжого бекапу чи знімка (snapshot) у панелі хостингу
- Вільне місце в розділі
/boot(якщо він забитий старими ядрами, нове просто не встановиться повністю) - Альтернативний доступ до консолі (VNC або IPMI) на випадок, якщо після ребуту «впаде» мережа чи SSH
Для Ubuntu і Debian під час планового обслуговування краще використовувати повний цикл оновлення, щоб підтягнути всі залежності ядра:
apt update
apt upgrade -y
apt full-upgrade -y
rebootЩо зазвичай відмовляє після ребуту
Коли сервер повертається в мережу, перевірки одного лише пігу недостатньо. Потрібно зайти по SSH і переконатися, що піднялися всі сервіси, особливо ті, які рідко перезапускаються вручну. Часто саме після ребуту вилазять приховані помилки в конфігах Nginx, Apache або баз даних.
Швидкий чек-лист для перевірки статусів:
systemctl status nginx
systemctl status mysql
systemctl status dockerЯкщо якісь сервіси автоматично не стартували, дивіться логи через journalctl -xe.
Масштаб проблеми
Copy Fail став помітним не через унікальну архітектурну помилку, а через присутність коду в екосистемі протягом тривалого часу. Є підстави вважати, що цей баг знаходився в ядрі ще з 2017 року. Весь цей час сервери вважалися захищеними, оскільки закривалися зовнішні порти та налаштовувалися брандмауери.
Цей випадок вкотре доводить, що стабільна робота VPS без перезавантажень роками – це скоріше безпековий ризик, ніж привід для гордості. Безпека периметра втрачає сенс, якщо внутрішні механізми ядра дозволяють перехопити керування зсередини системи.
Залишити відповідь