Microsoft срочно патчит ASP.NET Core: подделка cookie даёт SYSTEM

Если у вас прод на ASP.NET Core 10 — остановите любую работу и проверьте, какую версию Microsoft.AspNetCore.DataProtection тянет ваше приложение. CVE-2026-40372 с CVSS 9,1 уже закрывают — дочитайте, пока обновляетесь.

21 апреля 2026 года Microsoft выпустила внеплановое обновление .NET 10.0.7 и опубликовала security advisory CVE-2026-40372. Регрессия в пакете Microsoft.AspNetCore.DataProtection версий 10.0.0–10.0.6 позволяет атакующему без аутентификации подделать auth-cookie и залогиниться под админом приложения — а на Windows-деплоях это открывает путь и к SYSTEM-привилегиям на сервере.

Что такое ASP.NET Core Data Protection

Data Protection — встроенная в ASP.NET Core подсистема симметричной криптографии. Её задача — аутентифицированно шифровать небольшие полезные нагрузки, которые уходят к клиенту и возвращаются обратно.

Конкретно — это auth-cookie для логина пользователя, CSRF-токены (antiforgery — защита от межсайтовых запросов), промежуточный TempData (временные данные между двумя запросами одного пользователя), state-параметр в OIDC-флоу (OpenID Connect — протокол авторизации поверх OAuth 2.0), ссылки на сброс пароля и так далее. Всё это — «доверенные конверты», где сервер должен быть уверен, что клиент не подменил содержимое.

Работает по схеме encrypt-then-MAC: данные шифруются AES-256-CBC, а к шифру добавляется HMAC-SHA256-тег целостности, посчитанный по IV и шифртексту. При расшифровке сервер сначала проверяет HMAC — если тег не сходится, payload отбрасывается как подделанный. Именно в этой проверке и обнаружился баг.

В чём баг CVE-2026-40372

В версиях 10.0.0–10.0.6 managed-реализация authenticated encryptor в ряде случаев вычисляет HMAC-тег не по тем байтам payload — а затем отбрасывает уже посчитанный хеш. В результате атакующий может сконструировать payload, у которого валидный на вид тег совпадёт с содержимым подделки.

Microsoft описывает последствия в release notes 10.0.7 коротко: поломанная валидация позволяет «подделывать payloads, проходящие проверки подлинности DataProtection, и расшифровывать ранее защищённые данные». На практике это значит, что cookie аутентификации, antiforgery-токены, OIDC state и ссылки сброса пароля перестают быть доверенными контейнерами.

Почему это повышение привилегий: через подделанную auth-cookie атакующий логинится в приложение под привилегированным пользователем — обычно это аккаунт администратора. Дальше приложение само выдаёт ему уже легитимные токены: session-refresh, API-ключи, ссылки сброса пароля. На Windows-деплоях эти токены часто дают доступ к ресурсам, запущенным под NT AUTHORITY\SYSTEM — отсюда и SYSTEM-привилегии в заголовке advisory. CVSS-вектор уязвимости: AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:N — сеть, низкая сложность, без привилегий и взаимодействия.

Кого конкретно задевает

• ASP.NET Core 10-приложения, у которых NuGet-копия Microsoft.AspNetCore.DataProtection версий 10.0.0–10.0.6 действительно загружается в рантайме — это и есть ключевое условие, проверьте lock-файл.
• Linux- и macOS-деплои — на них NuGet-копия пакета подтягивается чаще, чем на Windows: там реже полагаются на shared framework .NET-рантайма. Advisory Microsoft прямо указывает, что Windows-приложения без явной NuGet-зависимости не задеты.
• IdentityServer-решения вроде Duende, которые используют Data Protection для хранения OIDC-state и refresh-токенов.

«Shared framework» — это общий рантайм .NET, который ставится в систему отдельно от приложения (Microsoft.AspNetCore.App). «NuGet-копия» — это когда пакет Microsoft.AspNetCore.DataProtection указан в зависимостях проекта напрямую и загружается отдельно, переопределяя версию из shared framework. Разница критична: под уязвимость попадает именно NuGet-копия.

Почему одного обновления пакета мало

Тонкий момент из advisory, который легко пропустить: если атакующий успел выдать себе легитимные токены во время уязвимого окна (с 14 по 21 апреля для тех, кто накатил 10.0.6 на апрельский Patch Tuesday), эти токены продолжают работать и на 10.0.7. Подписи настоящие, DataProtection key ring тот же.

Поэтому фикс — это не только обновление NuGet-пакета, но и принудительная ротация DataProtection key ring. Без ротации вы закрываете будущие атаки, но старые уже выпущенные токены продолжат давать доступ.

Что делать с CVE-2026-40372 прямо сейчас

1. Обновите версию пакета в csproj или Directory.Packages.props до 10.0.7 — команда в блоке ниже.
2. Запустите restore и проверьте уязвимые зависимости. Флаг --include-transitive обязателен: без него вы не увидите пакет, который тянется транзитивно через Identity, Authentication.Cookies и прочие.
3. Пересоберите и передеплойте приложение — без dotnet build/publish и повторного деплоя фикс в рантайм не попадёт.
4. Ротируйте DataProtection key ring. Программно — вызов IKeyManager.CreateNewKey и затем RevokeAllKeys с текущим временем. Для Redis/Azure Blob Storage — форс-ротация через управляющий интерфейс провайдера. Учтите: ротация инвалидирует активные сессии пользователей, так что готовьте сотрудников к повторному входу.
5. Просмотрите логи аутентификации за период с 14 по 21 апреля. Куда смотреть: Azure AD sign-in logs, ELK/Serilog-индексы с cookie-auth событиями, IIS-логи со 200-ответами на /admin-эндпоинтах. Аномалии: логины без прохождения MFA, неожиданные session-refresh, массовые password-reset-запросы.
6. Инвалидируйте долгоживущие секреты, выданные в окне: API-ключи, personal access tokens, refresh-токены, integration-webhooks. Если есть подозрение на компрометацию — вращайте DB-пароли и service-account-credentials.

			# 1. Обновить пакет до 10.0.7
dotnet add package Microsoft.AspNetCore.DataProtection --version 10.0.7

# 2. Проверить уязвимые зависимости (включая транзитивные)
dotnet restore
dotnet list package --vulnerable --include-transitive

# 3. Пересобрать и передеплоить
dotnet build
dotnet publish
		

Не можете обновиться прямо сейчас? Временные меры: включите MFA на всех административных аккаунтах (это не закрывает подделку cookie, но добавляет барьер при использовании выписанных токенов), сократите срок жизни auth-cookie до минимума через ExpireTimeSpan в настройках CookieAuthenticationOptions, и форсируйте повторный вход всем пользователям через принудительный logout. Это митигация, не фикс — обновиться всё равно придётся.

Если приложение использует shared framework .NET и не тянет пакет из NuGet напрямую, уязвимость на него не распространяется. Проверяется двумя командами — dotnet --info покажет версию Microsoft.AspNetCore.App, а вторая команда подтвердит, тащит ли проект NuGet-копию:

			# Версия shared framework
dotnet --info

# Наличие NuGet-копии пакета
dotnet list package --include-transitive | grep DataProtection
		

В каком ряду это находится

Для ASP.NET Core это вторая серьёзная уязвимость за полгода. В октябре 2025 года Microsoft патчила CVE-2025-55315 — HTTP request smuggling в веб-сервере Kestrel с рейтингом «highest ever severity» для ASP.NET. Текущий CVE-2026-40372 бьёт в другое звено — в криптографию на уровне приложения, не веб-сервера — и открывает путь к эскалации привилегий без авторизации.

Формально Microsoft классифицирует severity как «Important», несмотря на CVSS 9,1 — внутренняя MSRC-шкала учитывает эксплуатируемость и требования к окружению, а не только CVSS-вектор. BleepingComputer и The Hacker News используют слово «critical», ориентируясь на CVSS. Публичного PoC-эксплойта пока нет, но out-of-band релиз 10.0.7 сам по себе сигнализирует, что эксплуатация считается реалистичной.

Если ваше приложение использует ASP.NET Core Data Protection, обновите пакет Microsoft.AspNetCore.DataProtection до 10.0.7 как можно скорее — это закроет и регрессию дешифровки, и саму уязвимость.

Рахул БхандариProgram Manager, .NET team, Microsoft — в .NET Blog, 21 апреля 2026

Если вы ведёте ASP.NET Core 10-приложение — сегодня же обновитесь до 10.0.7, передеплойтесь и ротируйте DataProtection key ring. Порядок действий — в разделе «Что делать» выше. Тянуть нельзя: атака одноходовая, а окно уже открылось.

Источники: BleepingComputer, dotnet/announcements, The Hacker News, .NET Blog, release notes 10.0.7.