Осень 2026 выдалась для администраторов Linux нервной. Сначала критическая уязвимость в PHP, потом дыра в обработке сетевых соединений ядра, а между ними тихая ошибка в PHP-сессиях, которая при совпадении условий заканчивается выполнением чужого кода. Патчи есть почти на всё. Вопрос в том, у кого они уже стоят.
Что случилось
В октябре вышло обновление PHP, закрывающее цепочку PHP2Shell (CVE-2026-109618 и CVE-2026-109619). Уязвимость позволяет выполнить код на сервере. Исправления пришли в пакетах PHP 8.3.6-0ubuntu0.24.04.13 для Ubuntu 24.04 и PHP 8.4.27 для Debian 13 (USN-8948-1).
Следом всплыла CVE-2026-115560: ошибка в механизме session.upload_progress. Чтобы её использовать, нужно совпадение нескольких условий, но если они совпали, чужой код может выполниться через сессию. Готового патча на тот момент не было (advisory PHP), поэтому защита свелась к настройке: session.upload_progress.enabled = Off.
Главный сюрприз пришёл от ядра. CVE-2026-98432, CVSS 9.8: use-after-free в обработке IPv4 TCP. Простыми словами, ядро освобождает участок памяти, а потом продолжает его читать. Атака удалённая, без пароля, затрагивает ядра, начиная с 4.4. Исправления вышли для Debian 13 (6.12.113-1), Ubuntu 24.04 (6.8.0-149) и Ubuntu 22.04 (5.15.0-203).
Почему это опаснее, чем кажется
Выполнение кода на сервере означает полный контроль: чтение файлов, доступ к базе, установка майнера, участие в ботнете, рассылка спама. Для ядерной уязвимости не нужен ни логин, ни пароль: достаточно открытого порта. Сканеры находят такие серверы за дни, а иногда и за часы.
Обновление ядра требует перезагрузки. Именно поэтому её откладывают: страшно уронить сервис. В итоге заплатка установлена, а уязвимость остаётся активной, потому что работает старое ядро. Каждый день отсрочки даёт чужому сканеру ещё один шанс оказаться быстрее.
Что делаем мы
Наш парк работает на Ubuntu и Debian. Автоматические обновления настроены только на безопасность: обычные пакеты сами не ставятся, чтобы не ломать сервисы внезапно.
Раз в месяц проходит окно обновлений: сначала проверяем, что ждёт установки, затем обновляем по одному серверу, перезагружаем и смотрим, поднялись ли службы. Перезагрузка одного хоста не роняет остальные. Перед окном есть свежие резервные копии, после окна проверяем сайты, базы и контейнеры.
Отдельно мы смотрим на ядро. Сравниваем установленную версию не с тем, что лежит в /boot, а с кандидатом в репозитории. Разница бывает показательной.
Кроме обновлений есть базовая гигиена: вход по ключам, отдельные учётки под задачи, закрытые наружу панели управления, фильтрация запросов, защита от перебора, ежедневный скан на вредоносный код и журналы, которые кто-то читает.
Урок, который дорого дался
Один сервер выпал из схемы обновлений ядра. Автообновления работали, ошибок не было, версия ядра выглядела прилично. Проблема была в мета-пакете: его не было в системе, а автообновления ставят только то, что уже установлено. Новые ядра просто не приходили с мая 2024 года.
Такое не ловится взглядом на uname -r. Ловится сверкой с тем, что предлагает репозиторий. Теперь это обязательный пункт проверки, а сервер получил мета-пакет, свежее ядро и перезагрузку.
Что будет с теми, кто не обновится
Сценарии примерно одинаковые. Сначала сервер начинает странно тормозить: чужой майнер ест процессор. Потом появляются письма о спаме с вашего адреса. Дальше попытка шифрования данных или тихая кража базы. Если резервные копии лежат на той же машине, они уходят вместе с ней.
Бывает и тише: сервер месяцами живёт с чужой учёткой и участвует в атаках, а владелец узнаёт об этом от хостера или из чёрного списка. Репутация IP восстанавливается долго, письма в спам уходят ещё дольше.
Что сделать прямо сейчас
- Проверить версии: uname -r, apt-cache policy linux-image-generic, версию PHP.
- Поставить обновления безопасности и перезагрузиться, если обновилось ядро.
- После перезагрузки проверить службы, сайты и базы, а не только ping.
- Включить автообновления безопасности и убедиться, что они действительно ставятся.
- Убрать лишние службы и закрыть наружу админки, phpMyAdmin и тестовые стенды.
- Проверить, что резервная копия снимается и восстанавливается, а не числится в отчёте.
- Настроить журналы и оповещения, чтобы узнавать о проблеме не от клиента.
Как дальше быть
Обновления не разовая акция, а привычка. Раз в месяц выделить окно, пройти по парку, перезагрузить то, что требует перезагрузки, и записать, что осталось. Раз в квартал проверить, нет ли машин с просроченной ОС или забытым мета-пакетом. Раз в год стоит попробовать восстановить бэкап на чистой машине.
Это скучно. Но патч занимает двадцать минут, а разбор инцидента занимает недели. И это если повезёт и данные найдутся в бэкапе.