CVE-2026-40372 в ASP.NET Core: критическая дыра в Data Protection и срочный патч 10.0.7
---------------------------------------------------------------------
Microsoft выпустила внеплановый релиз .NET 10.0.7, закрывающий критическую уязвимость CVE-2026-40372 в ASP.NET Core Data Protection. Оценка по CVSS - 9,1, и это не формальность: ошибка в реализации HMAC позволяет атакующему подделать защищённые сервером данные, включая auth-cookie, и залогиниться как администратор. На Windows-деплоях при типичной конфигурации это часто означает прямой путь к получению прав SYSTEM на сервере.
Речь идёт не о теоретическом риске: баг затрагивает реальные продовые инсталляции, особенно те, где ASP.NET Core развёрнут на Linux и Data Protection используется по умолчанию без отдельной жёсткой настройки.
Какие версии уязвимы
Под уязвимость попадает не весь ASP.NET Core, а конкретный NuGet-пакет:
- уязвимы версии `Microsoft.AspNetCore.DataProtection` 10.0.0 - 10.0.6;
- исправление - версия 10.0.7, выпущенная 21 апреля 2026 года как out-of-band обновление;
- проблема затрагивает именно NuGet-пакет, а не копию Data Protection, встроенную в shared framework `Microsoft.AspNetCore.App`.
Если ваше приложение использует только shared framework и не подтягивает `Microsoft.AspNetCore.DataProtection` напрямую из NuGet, вы, с высокой вероятностью, вне зоны поражения. Но это нужно проверить, а не предполагать.
Почему это вторая критическая дыра ASP.NET Core за полгода
За последние полгода это уже вторая уязвимость уровня CVSS ~9 в ASP.NET Core. Вновь в фокусе - подсистема аутентифицированного шифрования небольших полезных нагрузок. Особо болезненно уязвимость бьёт по Linux-деплоям: там Data Protection часто хранит ключи локально на диске, а админские cookie и токены живут дольше и менее тщательно контролируются, чем в изолированных Windows-средах с доменными политиками.
В отличие от многих багов, которые дают лишь отказ в обслуживании или ограниченное повышение привилегий, CVE-2026-40372 позволяет атакующему создавать заведомо доверенные сервером токены, минуя аутентификацию. Это делает проблему ближе к классу "полный захват учёток и приложений", а не к простому DoS.
---
Что такое ASP.NET Core Data Protection
Data Protection в ASP.NET Core - это встроенная подсистема симметричной криптографии, которая:
- шифрует и аутентифицирует небольшие куски данных;
- выдаёт их клиенту (браузеру, внешнему сервису);
- затем проверяет и расшифровывает полученное обратно содержимое, удостоверяясь, что его никто не подменял.
Типичные сценарии использования:
- auth-cookie аутентификации пользователя;
- CSRF-токены (antiforgery) для защиты от межсайтовых запросов;
- TempData - временные данные между двумя запросами одного пользователя;
- параметр state в OpenID Connect-потоках;
- ссылки для сброса пароля и прочие одноразовые защитные токены.
То есть Data Protection - это механизм "доверенных конвертов": сервер кладёт в них критичные данные и ожидает, что при возврате содержимое будет либо идентично исходному, либо помечено как подделка.
Как это должно работать
Используется типовая схема encrypt-then-MAC:
1. Данные шифруются симметричным алгоритмом (в данном случае AES-256-CBC).
2. По комбинации IV + шифротекст вычисляется HMAC-SHA256.
3. На выходе формируется пакет: `IV + шифротекст + HMAC-тег`.
4. При расшифровке:
- сначала проверяется HMAC;
- если тег не совпадает, пакет считается подделанным и отбрасывается;
- только после успешной проверки происходит расшифровка.
Вся безопасность завязана на корректность HMAC-проверки. Именно это место и оказалось сломано.
---
В чём суть бага CVE-2026-40372
В версиях 10.0.0-10.0.6 в managed-реализации authenticated encryptor закралась регрессия:
- HMAC-тег в ряде случаев вычисляется не по тем байтам полезной нагрузки;
- уже рассчитанный корректный хеш может быть отброшен;
- из-за этого появляется возможность подобрать или сконструировать такой payload, при котором тег выглядит валидным для поддельного содержимого.
На практике это означает:
- подделка auth-cookie без знания ключей;
- фальсификация antiforgery-токенов;
- подмена OIDC state и прочих защищённых структур;
- возможность расшифровывать ранее защищённые данные (при определённых условиях).
Microsoft в заметках к релизу 10.0.7 описывает эффект лаконично: ошибка валидации даёт возможность "подделывать полезные нагрузки, проходящие проверки DataProtection, и расшифровывать уже защищённые данные". Если убрать эвфемизмы, это означает потерю доверия ко всем токенам и cookie, выпущенным через Data Protection за уязвимый период.
---
Кого конкретно задевает уязвимость
Важно понимать разницу между:
- shared framework `Microsoft.AspNetCore.App`, который ставится вместе с .NET Runtime;
- и NuGet-пакетом `Microsoft.AspNetCore.DataProtection`, подключенным явно в проект.
Под удар попадает именно NuGet-версия пакета 10.0.0-10.0.6. Сценарии:
1. Приложение использует только shared framework, без прямой зависимости от `Microsoft.AspNetCore.DataProtection`.
- В большинстве таких случаев уязвимость не затрагивает приложение.
2. Приложение явно указывает `Microsoft.AspNetCore.DataProtection` в `csproj`, NuGet-менеджере или аналогичной системе зависимостей.
- В этом случае NuGet-пакет переопределяет версию, встроенную в shared framework.
- Если там стоит версия 10.0.0-10.0.6, приложение уязвимо.
По платформам:
- Windows: при типичной конфигурации IIS + Windows Authentication компрометация auth-cookie админа может означать доступ к функционалу, позволяющему выполнить код от имени системы, а в ряде случаев - прямое получение прав SYSTEM.
- Linux: часто используют cookie-аутентификацию без интеграции с доменом, ключи крутятся локально. Успешная подделка токенов даёт полный доступ к админским разделам приложений, API, DevOps-интерфейсам и сервисам, развёрнутым рядом.
---
Почему одного обновления пакета мало
На первый взгляд кажется: достаточно обновиться на `Microsoft.AspNetCore.DataProtection` 10.0.7 - и всё. Но это лишь половина работы.
Ключевой момент: все токены и cookie, выпущенные во время уязвимого окна (например, когда у вас стояла версия 10.0.6), остаются криптографически корректно подписанными:
- Data Protection key ring тот же;
- подписи с точки зрения новой версии валидны;
- приложение продолжит принимать их как доверенные.
Даже после установки 10.0.7:
- уже выданные злоумышленнику поддельные токены продолжают работать;
- злоумышленник может использовать их до истечения срока действия или принудительной инвалидации.
Поэтому реальный фикс состоит из трёх шагов:
1. Обновить NuGet-пакет до версии 10.0.7.
2. Провести ротацию Data Protection key ring (сделать старые ключи непригодными).
3. Очистить или принудительно инвалидировать все критичные токены (auth-cookie, refresh-токены, сессии и т.п.).
---
Что делать с CVE-2026-40372 прямо сейчас
При наличии прод-среды на ASP.NET Core 10:
1. Проверить версию Data Protection:
- убедиться, что в проекте нет явной зависимости на `Microsoft.AspNetCore.DataProtection` 10.0.0-10.0.6;
- если зависимость есть - обновить до 10.0.7.
2. Убедиться, что деплой действительно поднялся с новой версией:
- проверить артефакты билда;
- удостовериться, что старые библиотеки не кэшируются контейнерами или окружением.
3. Ротировать Data Protection key ring:
- сгенерировать новый набор ключей;
- отключить или удалить старые ключи;
- учесть, что после ротации старые cookie и токены станут недействительными.
4. Принудительно перелогинить пользователей:
- инвалировать существующие сессии;
- сбросить auth-cookie;
- по возможности, сделать принудительный logout.
Если обновиться прямо сейчас невозможно, допустимы только временные меры смягчения, но не полноценный фикс.
---
Временные митигации, если обновление задерживается
Если по организационным причинам сразу поставить 10.0.7 нельзя, имеет смысл:
1. Включить MFA для всех админских и чувствительных аккаунтов.
Это не мешает подделывать auth-cookie, но добавляет дополнительный барьер на этапе эксплуатации полученных прав.
2. Сократить срок жизни auth-cookie до минимума:
- через `ExpireTimeSpan` в `CookieAuthenticationOptions`;
- при необходимости уменьшить также время жизни refresh-токенов и других долговечных токенов.
3. Принудительно разлогинить всех пользователей:
- при старте новой версии приложения;
- при первом запросе после обновления настроек;
- через централизованный механизм инвалидации сессий.
4. Ограничить доступ к административным интерфейсам:
- по IP (VPN, корпоративные сети);
- через отдельный reverse-proxy с дополнительной проверкой.
5. Повысить уровень логирования и мониторинг аномалий:
- отслеживать аномальные логины под админскими аккаунтами;
- мониторить необычную активность с одного IP или сетей общего доступа;
- настроить алерты по резким всплескам ошибок авторизации или подозрительных запросам к чувствительным endpoint.
Эти шаги не устраняют уязвимость, но сокращают окно для её успешной эксплуатации и позволяют быстрее отреагировать.
---
Как проверить, задет ли ваш деплой
1. Проверка shared framework
Выполните команду `dotnet --info` на сервере:
- посмотрите, какая версия `Microsoft.AspNetCore.App` установлена;
- если вы не используете явную NuGet-зависимость, велика вероятность, что проблемный пакет не подключён отдельно.
2. Проверка зависимостей проекта
Откройте файл проекта (`.csproj`) или используемый менеджер зависимостей и найдите:
```xml
```
Если версия попадает в диапазон 10.0.0-10.0.6 - приложение уязвимо и требует обновления до 10.0.7 с последующей ротацией ключей.
3. Анализ среды исполнения
- На контейнеризованных деплоях убедитесь, что образы действительно пересобраны;
- на серверах без контейнеров проверьте, нет ли side-by-side установки разных версий пакетов и не подхватывается ли старая версия из локального кэша.
---
Ротация Data Protection key ring: что важно учесть
Ротация - критический шаг, без него токены, украденные или подделанные во время уязвимого периода, останутся валидными. Основные моменты:
- Где хранятся ключи:
- в файловой системе;
- в Redis;
- в базе данных;
- в специальном хранилище секретов.
- Как выполняется ротация:
- генерация нового master-ключа;
- перевод старых ключей в статус "только для расшифровки" или полное их отключение;
- удаление или архивация старых ключей при необходимости.
После ротации:
- старые cookie и токены перестанут нормально расшифровываться;
- пользователи будут разлогинены;
- возможно возникновение всплеска ошибок аутентификации и жалоб пользователей - это нужно заранее учесть в плане коммуникации.
---
Организационные шаги: что стоит сделать помимо технического фикса
1. Оценить возможный ущерб
- определить, какие системы и окружения использовали уязвимую версию;
- оценить, были ли среди них критичные админские панели, платежные модули, внутренние DevOps-инструменты.
2. Провести анализ логов
- поискать аномальные входы в админские учётки;
- проверить попытки доступа к конфиденциальным разделам с необычных IP.
3. Обновить процессы управления зависимостями
- ужесточить политику обновления инфраструктурных пакетов (вроде Data Protection);
- внедрить автоматическую проверку уязвимостей в цепочке зависимостей;
- наладить регулярный аудит версий критичных компонентов.
4. Подготовить план экстренных обновлений
- описать единый сценарий действий при выходе таких out-of-band патчей;
- назначить ответственных за оперативную оценку риска и принятие решения об обновлении.
---
Где в общем ряду угроз находится CVE-2026-40372
Эта уязвимость - не очередной "косметический" баг уровня DoS. По сути, это:
- компрометация доверенной криптосистемы внутри фреймворка;
- возможность создавать ложные, но валидные с точки зрения сервера токены;
- прямой путь к захвату аккаунтов, включая админские;
- в Windows-сценариях - потенциальная ступенька к получению прав SYSTEM.
С учётом частоты и объёма деплоев ASP.NET Core, массового использования Data Protection "по умолчанию" и сложности быстрой ротации ключей, CVE-2026-40372 вполне можно отнести к классу инцидентов, к которым стоит относиться на уровне "немедленного реагирования".
---
Подведём итог: если ваше приложение на ASP.NET Core явно тянет `Microsoft.AspNetCore.DataProtection` версий 10.0.0-10.0.6, необходимо не только обновить пакет до 10.0.7, но и принудительно ротировать Data Protection key ring и инвалидировать выданные токены. Без этого риск эксплуатации уязвимости сохранится даже после установки патча.
