Microsoft выпустила внеплановое обновление для закрытия серьёзной уязвимости в Core, получившей идентификатор CVE-2026-40372. Балл по шкале CVSS составил 9.1 из 10.0, официальный статус — «Important», хотя в ряде публикаций фигурирует слово «Critical». Уязвимость обнаружил анонимный исследователь, сообщение Microsoft опубликовала в один из вторников через официальный advisory.
Корень проблемы — некорректная проверка криптографических подписей в пакете
Уязвимы версии
Чтобы атака стала возможной, должны одновременно выполняться три условия. Первое: приложение использует именно NuGet-версию
Последствия эксплуатации тяжёлые. Злоумышленник получает возможность обойти проверки подлинности DataProtection и в итоге добраться до привилегий уровня SYSTEM. Параллельно открывается доступ к раскрытию файлов и модификации данных. Особую опасность представляет возможность подделки и расшифровки полезных нагрузок из authentication cookies и antiforgery tokens.
Есть ещё один неочевидный сценарий. Если в период действия уязвимости атакующий сумел аутентифицироваться как привилегированный пользователь, приложение могло выдать ему вполне легитимные токены — session refresh tokens, API-ключи, ссылки для сброса пароля. Эти токены подписаны корректно, никаких признаков взлома в них нет.
Microsoft закрыла уязвимость в Core версии 10.0.7. Но здесь начинается самое важное. Обновление само по себе не решает проблему полностью, если система уже была скомпрометирована.
Любые легитимно подписанные токены, выданные атакующему до установки патча, продолжат работать и после обновления до 10.0.7. Сертификаты не отзываются автоматически, сессии не инвалидируются, API-ключи остаются действительными. Администраторы обязаны вручную выполнить ротацию кольца ключей DataProtection — только это обесценит все скомпрометированные токены, выданные в уязвимый период.
Ротация DataProtection key ring — обязательный шаг, который легко пропустить в спешке. Обновиться до 10.0.7 и считать инцидент закрытым — распространённая ошибка. Если приложение работало на Linux или macOS с NuGet-версией пакета от 10.0.0 до 10.0.6, нужно исходить из предположения, что компрометация могла произойти, и ротацию ключей выполнять как минимум превентивно.
Изображение носит иллюстративный характер
Корень проблемы — некорректная проверка криптографических подписей в пакете
Microsoft.AspNetCore.DataProtection. Регрессия в затронутых NuGet-пакетах приводит к тому, что управляемый аутентифицированный шифровальщик вычисляет HMAC-тег валидации над неправильными байтами полезной нагрузки, а затем в ряде случаев и вовсе отбрасывает вычисленный хэш. Это ломает всю логику проверки подлинности данных, которую DataProtection должна обеспечивать. Уязвимы версии
Microsoft.AspNetCore.DataProtection с 10.0.0 по 10.0.6 включительно, а также всё, что от него зависит — в частности, Microsoft.AspNetCore.DataProtection.StackExchangeRedis. Но просто факт наличия уязвимой версии в проекте ещё не означает автоматической угрозы. Чтобы атака стала возможной, должны одновременно выполняться три условия. Первое: приложение использует именно NuGet-версию
Microsoft.AspNetCore.DataProtection 10.0.6, а не системную. Второе: эта NuGet-копия библиотеки реально загружается во время выполнения. Третье: приложение работает не на Windows, а на Linux или macOS. Все три условия должны быть выполнены разом — только тогда атака через сеть становится реалистичной. Последствия эксплуатации тяжёлые. Злоумышленник получает возможность обойти проверки подлинности DataProtection и в итоге добраться до привилегий уровня SYSTEM. Параллельно открывается доступ к раскрытию файлов и модификации данных. Особую опасность представляет возможность подделки и расшифровки полезных нагрузок из authentication cookies и antiforgery tokens.
Есть ещё один неочевидный сценарий. Если в период действия уязвимости атакующий сумел аутентифицироваться как привилегированный пользователь, приложение могло выдать ему вполне легитимные токены — session refresh tokens, API-ключи, ссылки для сброса пароля. Эти токены подписаны корректно, никаких признаков взлома в них нет.
Microsoft закрыла уязвимость в Core версии 10.0.7. Но здесь начинается самое важное. Обновление само по себе не решает проблему полностью, если система уже была скомпрометирована.
Любые легитимно подписанные токены, выданные атакующему до установки патча, продолжат работать и после обновления до 10.0.7. Сертификаты не отзываются автоматически, сессии не инвалидируются, API-ключи остаются действительными. Администраторы обязаны вручную выполнить ротацию кольца ключей DataProtection — только это обесценит все скомпрометированные токены, выданные в уязвимый период.
Ротация DataProtection key ring — обязательный шаг, который легко пропустить в спешке. Обновиться до 10.0.7 и считать инцидент закрытым — распространённая ошибка. Если приложение работало на Linux или macOS с NuGet-версией пакета от 10.0.0 до 10.0.6, нужно исходить из предположения, что компрометация могла произойти, и ротацию ключей выполнять как минимум превентивно.
