Это — самый высокий показатель уязвимости в истории .NET — ошеломляющие 9.9 баллов. Проблема открыта уже неделю, и сообщество разработчиков активно обсуждает происходящее. Давайте подробно разберём, почему вокруг этого такой шум и что это значит для компаний и программистов по всему миру.
Чтобы понять масштаб
Для сравнения стоит вспомнить уязвимость Log4J — настолько серьёзную, что о ней писали даже на BBC News. Тогда рейтинг уязвимости составлял 10.0, то есть максимальный возможный уровень по шкале CVSS. Более того, Microsoft даже профинансировала профессиональный документальный фильм о том, насколько страшным было происшествие с Log4Shell.
Теперь Microsoft объявила об уязвимости в .NET с рейтингом 9.9, почти на уровне Log4J. Естественно, это вызвало волну тревоги, путаницы и бесконечные неловкие разговоры в IT-отделах по всему миру.
Как это выглядит в реальности
Типичный диалог на этой неделе выглядит примерно так:
Руководитель: «Эта новая уязвимость в .NET с рейтингом 9.9 только что появилась на моём супердорогом «Executive Security Dashboard 3000». Помнишь Log4J четыре года назад? Там было 10. Это почти то же самое. Мы уязвимы?»
Full-Stack программист: «Всё в порядке, босс. Команда .NET уже выпустила патч».
Руководитель: «Эта проблема существует в .NET уже годами. Как мы можем быть уверены, что нас уже не взломали?»
Программист: «Мы не знаем…»
И вот в этом основная проблема — нет никаких официальных рекомендаций от команды безопасности .NET. Разработчики просто не знают, где искать признаки атаки, как проверить взлом и вообще — затронута ли их система.
Можно, конечно, проверить логи — если они у вас сохранились — но, по сути, на этом всё.
Отсутствие ясности и ответов
Понимаемо, что такое молчание вызвало возмущение у многих. На GitHub разработчики активно задают вопросы инженерам Microsoft, например Барри Дорансу, но его ответы не добавляют уверенности.
Вот несколько примеров:
- Вопрос: Уязвимо ли приложение, если оно размещено под IIS? Смягчает ли IIS эту проблему?
Ответ: «Это вопрос к команде продукта IIS. Я не могу говорить от их имени.» - Вопрос: Смягчает ли Azure Front Door (веб-аппликационный файрвол Microsoft) эту уязвимость?
Ответ: «Это вопрос к команде Azure Front Door. Я не могу говорить от их имени.» - Вопрос: Когда Azure App Service обновит свой runtime?
Ответ: «Это вопрос к команде Azure App Service. Я не могу говорить от их имени.» - Вопрос: Будет ли выпущен патч для .NET 6?
Ответ: «Нет, этот выпуск больше не поддерживается.»
А когда разработчики попросили привести конкретные примеры возможных атак или сценариев эксплуатации, ответ был лаконичный:
«Как я уже сказал выше — нет.»
Azure App Service до сих пор работает на уязвимой версии
Через неделю после публикации проблемы проверка новых экземпляров Azure App Service показала, что они всё ещё используют .NET 8.0.16, в котором есть уязвимость. Безопасная версия — 8.0.21 — до сих пор не развернута.
Это особенно раздражает, учитывая, насколько быстро Microsoft внедряет обновления в других областях. Например, GitHub Copilot получил доступ к GPT-5 в тот же день, когда OpenAI его выпустила. Так почему же обновление .NET runtime с критическим патчем занимает столько времени, особенно при рейтинге 9.9 CVE?
Что говорит Microsoft официально
Команда App Service опубликовала сообщение, где заявила, что они «тесно работают с командой .NET для устранения проблем, мешающих своевременно доставлять обновления версий .NET runtime, предоставляемых платформой под Windows».
Они также сообщили, что разрабатывают патч для инфраструктуры балансировки нагрузки, чтобы смягчить уязвимость как на Windows-, так и на Linux-инстансах. Однако обновлений о завершении работы над этим патчем пока нет.
А пока Microsoft рекомендует разработчикам использовать self-contained деплой — собирать приложение с параметром --self-contained и вручную выбирать версию runtime. На данный момент это единственный надёжный способ защитить .NET-приложения в Azure.
Как сообщество пытается помочь
Команда HeroDevs, которая продаёт платные патчи для устаревших версий .NET (например, .NET 6), выпустила на GitHub тестовое приложение, позволяющее проверить, уязвим ли ваш runtime.
Это небольшая консольная утилита, которая отправляет “request smuggling” запросы и проверяет, возникает ли исключение. На уязвимой версии .NET 8 тест падает, а на исправленной .NET 10 — проходит.
Но важно отметить: этот тест не демонстрирует реальную эксплуатацию уязвимости. Он лишь показывает, что новая версия .NET по-другому обрабатывает некорректные запросы. Ни о каком обходе авторизации речи не идёт.
Разбор сути уязвимости
Попробуем понять, что вообще происходит.
Судя по всему, речь идёт об HTTP Request Smuggling — методе, когда злоумышленник прячет один HTTP-запрос внутри другого, например DELETE внутри обычного GET, используя HTTP chunking.
Представьте:
GET /user— запрос, доступный любому пользователю с ролью User.DELETE /user— запрос, требующий роль Admin.
Если эти запросы объединены в один, сервер может разделить их и обработать по отдельности. Обычно Kestrel (веб-сервер .NET) выдаёт исключение BadHttpRequestException, что безопасно.
Но если вы вынесли проверку авторизации за пределы приложения (например, в WAF, API Gateway или внешний прокси), то этот внешний сервис может не заметить скрытый DELETE-запрос. В итоге .NET-приложение получит его и выполнит, полагая, что он уже авторизован.
Итак:
- Приложения с внешней авторизацией могут быть под угрозой.
- Приложения с встроенной авторизацией внутри .NET-кода — вероятнее всего, в безопасности.
- WAF при корректной настройке должен отсеивать такие запросы.
Проблема — не только в коде, но и в коммуникации
По сути, самая большая проблема — это не уязвимость, а отсутствие прозрачности.
«Барри, пожалуйста, как глава .NET Security, дайте больше информации. Напишите развёрнутый блог, объясните, что происходит и как проверить, затронуто ли наше приложение.»
Потому что выставив рейтинг 9.9 без конкретных рекомендаций, Microsoft создала две опасные ситуации:
- Похоже, будто компания что-то скрывает.
- Или же — сеет панику без оснований, “крича волк!” там, где его нет.
Если бы рейтинг был 7 или 8, разработчики просто спокойно поставили бы патч. Но 9.9 звучит пугающе — особенно когда сами Azure-сервисы остаются незащищёнными.
Заключение
Эта история наглядно показывает: безопасность — это не только про патчи, но и про доверие и коммуникацию.
Руководству Microsoft по безопасности .NET нужно не просто выпускать CVE и обновления, а объяснять риски и обеспечивать актуальность облачных сервисов Azure.
Пока же единственный надёжный путь для разработчиков — самостоятельно компилировать приложения с обновлёнными runtime и внимательно следить за официальными обновлениями.