Grave vulnerabilidade em ASP.NET Core (CVE-2026-40372) pode permitir elevação de privilégios: atualiza a 10.0.7 e rota o anel de chaves

A Microsoft publicou atualizações fora de ciclo para corrigir uma vulnerabilidade crítica em ASP.NET Core que poderia permitir a um atacante elevar seus privilégios em sistemas afetados. Registrada como CVE-2026-40372 e qualificada com escore CVSS de 9.1/10.0, a falha tem sido considerada de gravidade importante e foi relatada por um pesquisador anônimo.

A raiz do problema está na implementação do subsistema de proteção de dados (Data Protection) da ASP.NET Core: uma regressão em algumas versões dos pacotes NuGet causava que o mecanismo autenticado de criptografia gerenciado calculasse a etiqueta de validação HMAC sobre bytes incorretos do payload e, em certos casos, rejeitar o hash calculado. Essa falha na verificação da assinatura criptográfica abre a porta a que entradas manipuladas pareçam autênticas e, em situações concretas, também permite decifrar dados que antes estavam protegidos. Entre os objetos afetados incluem cookies de autenticação, tokens anti-falsificação e outros dados assinados ou criptografados pela livraria.

A Microsoft libertou a correção no ramo de ASP.NET Core 10. 0. 7. De acordo com a empresa, um atacante que explorou com sucesso a vulnerabilidade poderia obter privilégios do sistema (SYSTEM em ambientes Windows equivalentes em sistemas Unix-like), acessar arquivos e alterar informações. No entanto, a exploração não é universal: requer vários pré-requisitos simultâneos para que seja viável.

Para que a vulnerabilidade possa ser explorada é necessário que a aplicação use a versão afetada do pacote Microsoft.AspNetCore.DataProtection(as regresões estiveram presentes nas versões 10.0.0 até 10.0.6), que a cópia do pacote obtida a partir do NuGet é realmente carregada em tempo de execução pela aplicação e que o serviço é executado sobre um sistema diferente do Windows (por exemplo, Linux ou macOS). Se esses requisitos forem cumpridos, um atacante poderia forjar payloads que passem as verificações de integridade do Data Protection ou até decifrar conteúdo previamente protegido. Além disso, se durante a janela vulnerável um atacante conseguir autenticar-se como um utilizador com privilégios, a aplicação poderá emitir tokens legitimamente assinados (atualizações de sessão, chaves de API, ligações de restauração de senha, etc.) que continuariam a ser válidos após a aplicação da actualização para 10.0.7, a menos que o anel de chaves de Data Protection seja rote.

A recomendação imediata é aplicar a versão corrigida o mais rapidamente possível: atualizar os projetos e implantaçãos para Microsoft.AspNetCore.DataProtection 10.0.7 e à versão do ASP.NET Core 10.0.7 correspondente. A Microsoft publicou os detalhes técnicos e a mitigação no seu aviso de segurança e nas notas da versão; é importante rever ambas as fontes para compreender o alcance em cada ambiente. Veja o aviso da Microsoft aqui: MSRC – CVE-2026-40372 e as notas da versão no repositório oficial: aspnetcore v10.0.7.

Além do adesivo, há outra medida crítica: rodar o anel de chaves (key ring) de Data Protection. Como as chaves usadas para assinar e criptografar dados são as que determinam a validade de tokens e cookies, uma rotação forçada invalida material assinado previamente por chaves comprometidas e evita que um atacante use tokens emitidos durante a janela vulnerável. A documentação oficial explica como administrar e rodar as chaves do Data Protection: Gestão de Chaves em Data Protection.

Para equipamentos de desenvolvimento e operações, convém verificar se as suas aplicações realmente carregam a versão vulnerável do pacote em tempo de execução. Uma forma prática é rever as dependências com as ferramentas de .NET (por exemplo,dotnet list package -- include- transitive) e verificar as versões empacotadas nos artefatos ou contentores que se desdobram. A página do pacote NuGet fornece informações sobre as versões publicadas: Microsoft.AspNetCore.DataProtection em NuGet. Também é recomendável inspeccionar imagens de contentor, builds publicados ou binários implantados para confirmar o que seria realmente carregado.

Se você administra ambientes em Linux ou macOS, prioriza atualizações e gira as chaves o mais rapidamente possível. Depois de aplicar adesivos e rodar chaves, verifique os registos de autenticação e procura atividade incomum que possa indicar que alguém explodiu a falha antes do adesivo. Se detectar possíveis acessos ou emissão de tokens suspeitos durante a janela vulnerável, procede como se tivessem sido comprometidos os segredos afetados: revoga tokens, força restabelecimentos e audita acessos a dados sensíveis.

Na prática, esta incidência lembra duas ideias importantes: as regressões em livrarias críticas de segurança podem ter impacto transversal e, portanto, é imprescindível manter políticas de atualização, âncoras de confiança e processos de gestão de chaves adequados. Para mais contexto técnico sobre o funcionamento da Data Protection e das melhores práticas, o guia da Microsoft sobre o sistema de proteção de dados em ASP.NET Core é um recurso excelente: ASP.NET Core Data Protection. Para verificar o registo CVE e detalhes de gravidade, consultar a entrada pública na NVD: NVD – CVE-2026-40372.

Se você gerencia aplicativos em produção, ele já atua: atualiza 10.0.7, roda o anel de chaves se seu ambiente estava exposto e revisa logs e tokens emitidos durante a janela vulnerável. A combinação de adesivos e gestão de chaves é a forma mais eficaz de fechar esta porta antes de causar mais danos.