10 августа 2026 года разбираю июльский архив linux-cve-announce на Openwall: в нём 838 сообщений, причём 431 письмо приходится на 19 июля, ещё 274 на 25 июля. Это большой поток объявлений об уязвимостях ядра Linux, но не свидетельство сотен одновременных атак на каждый сервер.
Здесь легко перепутать три разных вещи: публикацию письма, присвоение номера CVE и наличие опасного дефекта в работающей системе. Между ними есть связь, но нет равенства. Чтобы понять последствия для своего сервера, нужны сведения о версии ядра, сборке дистрибутива и условиях конкретной уязвимости.
Число писем не равно числу актуальных угроз
Помесячный индекс показывает именно сообщения. В нём встречаются не только обычные объявления, но и записи REJECTED, то есть уведомления об отклонённых CVE. Например, 10 июля опубликовано сообщение с таким обозначением для CVE-2026-53166. Поэтому складывать строки архива и называть результат числом действующих уязвимостей некорректно.
Даже у действующего CVE важно читать описание. Ошибка может относиться к драйверу определённого устройства, отдельной архитектуре или включённой возможности ядра. Для сервера без соответствующего компонента и для машины, где он используется, практический риск будет разным.
Календарь архива помогает оценить объём рассылки. Он не показывает число заражённых машин, наличие готового эксплойта и срочность обновления конкретного VPS. Пиковый день в рассылке прежде всего означает большой объём опубликованных сообщений, который нужно разбирать по содержанию.
Рассылка и уведомление дистрибутива решают разные задачи
В linux-cve-announce публикуют технические сведения о дефектах ядра. Это полезно для анализа конкретного CVE и истории исправлений. Но такое письмо не является инструкцией по установке пакета для вашей версии Ubuntu, Debian или другой системы.
Дистрибутив может перенести исправление в поддерживаемую ветку, сохранив привычный основной номер ядра. Поэтому простого сравнения с номером из новости недостаточно. Надёжнее смотреть уведомление поставщика системы, статус CVE для используемого выпуска и версию установленного пакета.
Обратная ошибка тоже опасна: наличие свежего пакета в репозитории не означает, что сервер уже работает на новом ядре. Между доступным обновлением, установленным пакетом и реально загруженной версией есть несколько отдельных шагов. Их нужно проверять, а не предполагать по дате последнего запуска менеджера пакетов.
Начните с того, что действительно запущено
Для первичной диагностики достаточно посмотреть версию работающего ядра и сведения о системе. Эти команды ничего не меняют:
uname -r cat /etc/os-release
Затем найдите пакет, из которого установлено ядро, и его журнал изменений средствами своего дистрибутива. Для стандартного серверного образа это обычно понятнее и безопаснее, чем вручную выбирать сотни коммитов из рассылки. Для собственного ядра, наоборот, понадобятся конфигурация сборки и точная история включённых исправлений.
Если обновление требует перезагрузки, заранее продумайте доступ к консоли и способ восстановления. После перезапуска снова проверьте uname -r и работу служб. Если система использует исправления без перезагрузки, ориентируйтесь на документацию именно этого механизма: его наличие не означает автоматического покрытия всех будущих ошибок.
Условия эксплуатации важнее громкого числа
Для хоста, на котором запускается чужой код, особое значение имеют локальные уязвимости и границы изоляции. Наличие контейнера само по себе не превращает ошибку общего ядра в проблему только одного приложения. Но и объявлять любую ошибку драйвера побегом из контейнера нельзя: нужны конкретные условия из описания.
Для одного веб-сервиса также полезно знать, кто может получить локальный доступ, какие расширения и службы работают с недоверенными данными и насколько быстро применяются security-обновления. Такой список помогает определить приоритеты лучше, чем общее число писем за месяц.
В обновлениях ClamAV действует похожий принцип: важно обновить работающий компонент и проверить его состояние. Новость о патче сама по себе ничего не меняет на сервере. Контроль установленной версии и проверка после обслуживания остаются обязательной частью работы.
Июльский архив полезен как технический справочник и показатель объёма опубликованных объявлений. Для повседневного администрирования главное другое: поддерживаемая система, понятный источник обновлений и проверка того, что исправления действительно применены к работающему ядру.
