КИБЕРБЕЗОПАСНОСТЬ

Патч для Windows Defender открыл путь к переполнению диска

Патч Microsoft для CVE-2026-50656 в Windows Defender мог открыть новый вектор атаки: злоумышленники способны забить диск и ломать работу сервисов.

✍️ Редакция iTech News | 10.07.2026 | ⏱ 5 мин | Источник: Ars Technica
🔑

Microsoft закрыла zero-day в Windows Defender, которая позволяла удаленно получить права администратора на Windows 10 и 11, но почти сразу получила новый удар по репутации. По словам исследователя NightmareEclipse, патч для CVE-2026-50656 добавил поведение, из-за которого уязвимость Windows Defender может превратиться в атаку на свободное место: диск можно забить до отказа, а дальше Windows начинает сыпаться уже без всякой «эксплуатации ради красоты».

Об этом сообщает Ars Technica. Речь идет об уязвимости RoguePlanet, отслеживаемой как CVE-2026-50656. В июне ее публично раскрыл исследователь под псевдонимом NightmareEclipse, причем не только описал проблему, но и выложил код для эксплуатации. По его версии, баг позволял удаленному атакующему получить административный контроль над системой даже в случае, если защита в реальном времени в Defender была отключена. Для корпоративной инфраструктуры это уже неприятно само по себе, но история быстро вышла за рамки обычного цикла «нашли баг, выпустили фикс, разошлись».

Microsoft сообщила, что в среду закрыла RoguePlanet обновлением Microsoft Malware Protection Engine, то есть движка, на котором работает Defender. Обновление должно устанавливаться автоматически, без действий со стороны пользователя. Заодно компания упомянула дополнительные меры защиты по принципу defense-in-depth. Именно к ним и возникли новые вопросы. Уже на следующий день NightmareEclipse написал, что эти доработки могут породить другую проблему: в определенных сценариях модуль mpengine.dll якобы начинает утекать по 8 байт данных при попытке открыть файл, а новая логика, связанная со SpyNet, помогает довести процесс до практической атаки на хранилище.

Сценарий, который описывает исследователь, выглядит не как академическое упражнение, а как вполне прикладная техника для тех, кто умеет работать с инфраструктурой Windows. Defender обычно ограничивает размер файлов, которые он может писать на диск при сканировании и помещении объектов в карантин. Это разумное ограничение: иначе антивирус сам стал бы удобным инструментом для отказа в обслуживании. Но, как утверждает NightmareEclipse, есть исключение, связанное с обработкой Zone.Identifier — скрытого альтернативного потока данных, который Windows привязывает к файлам, полученным из Интернета, почты и других внешних источников. Этот поток хранит метку происхождения файла и его зону безопасности. Если верить исследователю, функции SpyNet в mpengine.dll стремятся локально сохранить копию такого потока независимо от его размера. Иными словами, защита, которая должна фильтровать подозрительные объекты, в особом кейсе может начать кэшировать то, что кэшировать совсем не стоило.

Дальше начинается самое интересное для администраторов и SOC-команд. Для эксплуатации, по описанию исследователя, нужен специально подготовленный SMB-сервер. Он должен отдавать вредоносный файл — в качестве примера приводится исполняемый файл mimikatz — а затем большой поток Zone.Identifier для этого файла. В какой-то момент сервер перестает отвечать на запрос чтения, но соединение не рвет. В результате Defender зависает, удерживает блокировку на связанных файлах и, как утверждается, продолжает занимать все доступное дисковое пространство. Машина при этом не обязательно падает мгновенно. Хуже другое: система с переполненным диском начинает вести себя хаотично, а приложения и службы получают случайные сбои. Для рабочих станций это означает потерю продуктивности, для серверов и VDI-сред — куда более болезненные последствия, вплоть до каскада отказов в зависимых сервисах.

На момент публикации Microsoft, по данным Ars Technica, не подтвердила описанное поведение публично и не ответила на запросы издания по существу нового сценария. Но даже без официального комментария история выглядит симптоматично. Конфликт между Microsoft и NightmareEclipse тянется как минимум с мая. Тогда исследователь заявил, что компания тихо исправила одну из уязвимостей, о которой он сообщил приватно. Дальше спор перешел в публичную фазу: в течение нескольких недель он раскрывал новые zero-day и публиковал детали с кодом до выхода патчей, а Microsoft обвиняла его в безответственном раскрытии и даже намекала на возможные юридические шаги. После негативной реакции со стороны сообщества корпорация от идеи судебного давления отступила, но сама логика противостояния никуда не делась.

Для рынка это важная деталь. Проблема уже не только в конкретной уязвимости Windows Defender, а в том, как устроены отношения между крупным вендором и независимым исследователем, который сознательно действует на грани принятых норм disclosure. Когда диалог разваливается, страдают все: вендор получает меньше времени на спокойный ремонт, исследователь — меньше мотивации играть по процедуре, а клиенты — больше шансов оказаться между двух огней. Особенно это чувствительно в экосистеме Windows, где Defender давно воспринимается как базовый слой защиты по умолчанию, а его обновления накатываются практически незаметно для пользователя. Если такой слой после патча сам становится частью атакующей цепочки, доверие к модели «автоматически обновим и поедем дальше» неизбежно проседает.

Для русскоязычной IT-аудитории здесь есть вполне практический вывод. Командам, которые управляют Windows-парком, мало просто убедиться, что движок Defender обновился. Нужно отдельно смотреть на аномалии по дисковому пространству, зависшие операции вокруг SMB, рост локального кэша и странное поведение служб безопасности после установки последних сигнатур и engine-апдейтов. Разработчикам корпоративного софта и DevOps-командам полезно помнить старую истину: инцидент может начинаться не с RCE и не с шифровальщика, а с банального переполнения диска, после которого ломаются очереди, агенты, логи, сбор телеметрии и резервные задачи. В 2026 году это уже не «техническая мелочь», а вполне рабочий способ устроить дорогостоящий бардак.

История с RoguePlanet показывает неприятную вещь: даже когда zero-day формально закрыт, окно риска не всегда закрывается вместе с ним. Если описание NightmareEclipse подтвердится, Microsoft придется объяснять не только исходный баг, но и то, почему защитный механизм снова оказался удобной точкой давления на систему. А для отрасли это еще один сигнал, что качество патча теперь оценивают не по факту релиза, а по тому, не породил ли он следующую проблему на соседней странице changelog.

Поделиться: Telegram X LinkedIn