Microsoft подтвердил две проблемы в Defender for Endpoint на Linux, и одна из них бьет по самой неприятной точке: после обновления и перезагрузки часть серверов могла остаться с выключенной защитой. Для компаний, которые используют единый стек Microsoft для серверов и облака, это означает простую вещь: машина в консоли могла выглядеть защищенной, а после ребута уже выпадала из активной защиты.
27 июля 2026 года на проблему обратил внимание The Register со ссылкой на уведомление Microsoft. В официальных release notes компания указала затронутые версии и сборки с исправлениями, так что здесь речь не о слухах, а о вполне конкретном сбое в опубликованных релизах.
Какие версии затронуты и в чем сбой
По данным Microsoft, проблема касается сборок Defender for Endpoint на Linux 101.26042.0000–101.26042.0009 для всех поддерживаемых Linux-дистрибутивов. После обновления или переустановки с последующей перезагрузкой служба Defender на части устройств могла оказаться отключенной.
Это важная деталь для администраторов, которые полагаются на штатный цикл обновлений. Сбой проявляется не в момент установки, а после ребута. Именно поэтому его легко пропустить: сервер перезагрузился по регламенту, агент формально установлен, но защита уже не работает как должна.
Microsoft отдельно предупреждает, что в инфраструктурах с Defender for Servers Plan 1 или Plan 2 и включенной интеграцией с Defender for Cloud автоматические обновления расширения MDE.Linux обычно включены по умолчанию. Иными словами, затронутая версия могла приехать на сервер без отдельного ручного подтверждения со стороны администратора.
Исправление для этой проблемы Microsoft выпустил в сборке 101.26042.0011. Затронутые версии компания уже убрала из production-канала.
Отдельный сбой затронул RHEL 8 и 9 с FIPS
Вторая проблема касается не отключения сервиса, а установки обновления. На системах Red Hat Enterprise Linux 8 и 9 с включенным режимом FIPS обновление ветки 101.26042.x могло не устанавливаться вовсе. В таком сценарии сервер не терял защиту мгновенно, но зависал на старой версии агента и выпадал из нормального цикла обновлений.
Для справки: FIPS — режим, в котором система использует криптографические механизмы по строгим требованиям безопасности. Обычно его включают в чувствительных корпоративных и государственных контурах.
Для этой ошибки Microsoft указывает отдельную исправленную ветку: проблема устранена в версии 101.26052.0011 и новее. Это значит, что администраторам мало просто проверить наличие Defender на сервере. Нужны как минимум три вещи: сверка версии, контроль состояния службы после перезагрузки и отдельная проверка RHEL 8/9 с FIPS.
Почему это важно для инфраструктуры
История неприятна не только для Microsoft, но и для всех, кто строит защиту вокруг одного вендора. Идея единой панели, общей телеметрии и общих политик выглядит разумно до тех пор, пока сбой в обновлении не создает слепую зону сразу на группе серверов.
Для русскоязычной аудитории вывод практический. Если у компании остались международные, унаследованные или гибридные контуры с Defender for Endpoint на Linux, после этой истории стоит перепроверить серверы именно на поведение после ребута, а не только на факт установленного агента. Для DevOps-, SRE- и ИБ-команд это обычная, но важная дисциплина: критичный защитный софт нельзя обновлять по принципу «доедет само», даже если пакет пришел от Microsoft.
Следующий шаг очевиден: крупным поставщикам EDR придется доказывать не только качество детектирования, но и надежность собственных обновлений. Для серверной защиты это уже не второстепенная функция, а часть базового обещания продукта.
Источник: Microsoft Learn, The Register.