Американское агентство CISA предупредило, что хакеры уже используют в атаках три уязвимости ядра Linux, одну из них оценивают как критическую. Для русскоязычных команд это не абстрактная новость из федерального реестра США: уязвимости ядра Linux бьют по серверам, контейнерам, сетевым фильтрам и TLS-стеку, то есть по инфраструктуре, на которой обычно держится половина бизнеса.
Как пишет BleepingComputer, CISA добавила три ошибки в каталог Known Exploited Vulnerabilities на прошлой неделе и потребовала от федеральных ведомств США установить доступные обновления и применить меры снижения риска к концу дня 21 сентября 2026 года. Агентство также пометило все три случая как требующие forensic triage: админам нужно не только закрыть дыру, но и проверить затронутые активы на признаки уже состоявшейся эксплуатации.
Самая заметная из трех — CVE-2025-39964. Это состояние гонки в интерфейсе криптографических сокетов AF_ALG в ядре Linux. При одновременных операциях записи ошибка может портить состояние сокета, приводить к сбоям или менять результаты криптографических операций. Неприятная деталь: по данным исследователей, баг прожил в ядре около 14 лет. Его нашла компания STAR Labs, которая отдельно подчеркнула, что исследователи обнаружили проблему без помощи ИИ-систем. В Google kernelCTF они показали эксплуатацию через повышение привилегий и выход из контейнера.
Вторая проблема, CVE-2026-53266, находится в реализации ebtables SNAT. Ошибка записи за пределы допустимой области может приводить к тому, что переписывание ARP-адреса меняет разделяемую file-backed memory без предварительного перевода нужного диапазона пакета в writable-состояние. Red Hat уже подтвердила наличие известного эксплойта. Исследователь Kimmo Suominen опубликовал на GitHub технический разбор и трекер статуса патчей, описав возможный путь к повышению привилегий через изменение file-backed memory. Важная оговорка: предложенная цепочка пока выведена по аналогии с Dirty Pipe и не подтверждена публичным рабочим эксплойтом.
Третья уязвимость, CVE-2025-39682, касается логики приема TLS-записей в ядре Linux при использовании kTLS. Ошибка связана с обработкой записей нулевой длины, которые откладываются для последующей обработки. При определенных условиях это может привести к тому, что разные типы TLS-записей будут обработаны вместе. Для этой уязвимости публичные эксплойты уже существуют, и Red Hat также указала на это в своем бюллетене.
Общая картина выглядит знакомо и оттого раздражающе: ядро Linux снова оказывается не просто системным компонентом, а общей точкой отказа для контейнерных платформ, сетевых устройств, облачных инстансов и on-prem-серверов. Когда баг дает путь к повышению привилегий или выходу из контейнера, патч-менеджмент перестает быть скучной таблицей в Jira. Он становится вопросом, сможет ли атакующий превратить локальный доступ или ограниченный контейнер в контроль над хостом.
CISA не раскрывает, кто именно эксплуатирует эти уязвимости ядра Linux и в каких инцидентах они замечены. Также агентство не связывает их с ransomware-группами. Это не повод расслабляться: отсутствие публичной привязки к вымогателям означает только то, что такой связи пока нет в открытых данных. Для защитников важнее другое: уязвимости уже находятся в активной эксплуатации, а по двум из трех есть подтвержденные или публично доступные материалы, облегчающие работу атакующим.
Практический вывод для разработчиков и инфраструктурных команд простой: проверить версии ядра, бюллетени дистрибутивов, статус патчей у облачного провайдера и наличие kTLS, ebtables и AF_ALG в реальной конфигурации. После обновления стоит посмотреть журналы, контейнерные события, следы неожиданных повышений привилегий и изменения в file-backed memory-сценариях, если это применимо к окружению. CISA явно просит не ограничиваться установкой патча, и в этом случае бюрократия говорит разумную вещь.
История с этими тремя багами хорошо показывает, куда движется эксплуатация Linux-инфраструктуры: атакующим нужны не громкие «нулевые дни» в модных фреймворках, а старые и сложные участки ядра, которые годами лежат под рабочей нагрузкой. Чем плотнее бизнес уходит в контейнеры и managed Linux, тем меньше смысла считать ядро чужой зоной ответственности: патч, мониторинг и расследование после факта теперь живут в одном списке задач.