A CVE-2026-40372 afeta o Microsoft.AspNetCore.DataProtection, permite abuso de cargas forjadas em aplicações vulneráveis e exige atualização para a versão 10.0.7 com rotação do chaveiro de proteção de dados.
| Componente | ASP.NET Core, com foco nos pacotes NuGet Microsoft.AspNetCore.DataProtection 10.0.0 a 10.0.6 e dependências como Microsoft.AspNetCore.DataProtection.StackExchangeRedis. |
| Vetor | Verificação incorreta de assinatura criptográfica no ASP.NET Core, acionável pela rede contra aplicações que usam o pacote vulnerável e executam em Linux, macOS ou outro sistema não Windows. |
| Impacto | Um atacante não autorizado pode elevar privilégios; exploração bem-sucedida pode levar a privilégios de SYSTEM, divulgação de arquivos, modificação de dados e emissão de tokens legitimamente assinados durante a janela vulnerável. |
| Prioridade | Atualizar o ASP.NET Core para 10.0.7, localizar dependências diretas e transitivas do Microsoft.AspNetCore.DataProtection vulnerável e rotacionar o chaveiro do DataProtection para invalidar tokens emitidos durante a exposição. |
| Versões | A regressão foi descrita nos pacotes NuGet Microsoft.AspNetCore.DataProtection 10.0.0 a 10.0.6; a correção foi disponibilizada no ASP.NET Core 10.0.7. |
| Artefatos | Tokens de sessão, atualização de sessão, chaves de API e links de redefinição de senha podem permanecer válidos após a atualização se o chaveiro do DataProtection não for rotacionado. |
A CVE-2026-40372 é uma vulnerabilidade de elevação de privilégio no ASP.NET Core ligada à verificação inadequada de assinatura criptográfica no mecanismo de proteção de dados. A falha recebeu pontuação CVSS 9.1 e severidade classificada como importante, com correção fora de ciclo disponibilizada para a versão 10.0.7. O problema é particularmente sensível porque atinge uma camada usada para proteger material autenticado em aplicações web, incluindo artefatos que podem representar identidade, sessão, autorização ou fluxos de recuperação de conta.
O ponto técnico central está no Microsoft.AspNetCore.DataProtection. A regressão nos pacotes NuGet 10.0.0 a 10.0.6 faz com que o autenticador criptográfico gerenciado calcule a etiqueta de validação HMAC sobre bytes incorretos da carga e descarte o hash calculado em determinados casos. Essa condição altera a propriedade de integridade esperada para dados protegidos pela aplicação. Em um cenário explorável, um atacante pode usar cargas forjadas para se autenticar como usuário privilegiado durante a janela vulnerável e induzir a aplicação a emitir tokens legítimos para si próprio.
A correção de código não encerra todos os efeitos residuais. Tokens legitimamente assinados durante a janela de exposição podem continuar válidos depois da atualização para 10.0.7, a menos que o chaveiro do DataProtection seja rotacionado. Isso muda a resposta defensiva: além de atualizar pacotes, operadores precisam considerar a invalidação de material criptográfico e de sessão já emitido. Sem essa etapa, uma aplicação pode deixar de aceitar novas cargas forjadas, mas ainda reconhecer tokens criados como consequência da exploração anterior.
A vulnerabilidade depende de uma falha na verificação criptográfica de cargas protegidas pelo ASP.NET Core. Em vez de validar corretamente a integridade sobre os bytes esperados, a implementação vulnerável pode calcular a etiqueta HMAC sobre uma representação incorreta e descartar o resultado em alguns caminhos de execução. O efeito prático é a possibilidade de aceitar material que deveria ser rejeitado pela proteção criptográfica. Como o DataProtection costuma sustentar cookies, tokens, links e outros artefatos de confiança da aplicação, uma falha nesse ponto pode atravessar camadas de autenticação e autorização.
A exploração descrita é remota e envolve um atacante não autorizado, mas não deve ser tratada como impacto universal em qualquer instalação ASP.NET Core. As condições informadas incluem o uso do Microsoft.AspNetCore.DataProtection 10.0.6 obtido do NuGet, direta ou indiretamente por dependência, e execução em Linux, macOS ou outro sistema não Windows. Também foi descrita uma regressão no intervalo 10.0.0 a 10.0.6, o que exige inspeção de dependências em projetos que migraram para esse ramo de pacotes.
O impacto confirmado inclui elevação de privilégio, possibilidade de privilégios de SYSTEM em exploração bem-sucedida, divulgação de arquivos e modificação de dados. Outro efeito relevante é a emissão de tokens legitimamente assinados pela própria aplicação após o uso de cargas forjadas. Exemplos de artefatos citados incluem atualização de sessão, chave de API e link de redefinição de senha. Esses itens merecem atenção porque a aplicação pode considerá-los válidos mesmo após a instalação da versão corrigida, caso continuem ancorados em chaves antigas do DataProtection.
A superfície principal envolve aplicações ASP.NET Core que dependem do DataProtection para proteger dados autenticados e que incorporam o pacote vulnerável por referência direta ou transitiva. A dependência indireta é relevante porque uma aplicação pode não declarar Microsoft.AspNetCore.DataProtection explicitamente, mas ainda recebê-lo por meio de outro pacote, como Microsoft.AspNetCore.DataProtection.StackExchangeRedis. Esse tipo de cadeia exige análise do grafo de dependências e não apenas leitura manual do arquivo principal de projeto.
Ambientes em Linux, macOS ou outro sistema não Windows aparecem como condição concreta para a exposição descrita. Em implantações conteinerizadas, esse detalhe inclui imagens base não Windows, serviços em plataformas orquestradas e workloads executados em hosts Linux. A combinação de pacote vulnerável, sistema operacional afetado e uso funcional do DataProtection é o ponto que deve orientar a priorização. Aplicações que emitem tokens de sessão, links de redefinição de senha, chaves de API ou material equivalente merecem atenção maior porque os artefatos gerados podem sobreviver à correção de código.
- Aplicações ASP.NET Core que usam
Microsoft.AspNetCore.DataProtection10.0.6 diretamente a partir do NuGet. - Aplicações que recebem o DataProtection vulnerável por dependência transitiva, incluindo integração com
Microsoft.AspNetCore.DataProtection.StackExchangeRedis. - Workloads executados em Linux, macOS ou outro sistema operacional não Windows.
- Fluxos que dependem de tokens assinados pela aplicação, como sessão, atualização de sessão, chave de API e redefinição de senha.
A investigação deve começar pelo inventário de dependências. O objetivo é identificar pacotes Microsoft.AspNetCore.DataProtection no intervalo vulnerável, com foco operacional em 10.0.6 e em dependências transitivas. Em repositórios e pipelines, a busca deve cobrir arquivos de projeto, lockfiles, manifestos de pacote e artefatos de build, porque a versão efetiva usada em produção pode vir de resolução automática de dependências. Em ambientes com múltiplos serviços, a priorização deve considerar aqueles expostos à rede e responsáveis por autenticação, sessão, autorização ou recuperação de credenciais.
Na telemetria de aplicação, defensores devem procurar anomalias relacionadas à emissão e uso de tokens. O sinal não é necessariamente um payload explícito, mas a sequência de eventos: autenticação inesperada de contas privilegiadas, geração de links de redefinição de senha sem fluxo legítimo correspondente, criação ou uso de chaves de API fora do padrão normal e refresh de sessão vindo de origem ou identidade incomum. Como tokens emitidos durante a janela vulnerável podem continuar válidos, a análise deve cobrir o período anterior à atualização e não apenas eventos posteriores ao patch.
Registros de autorização, auditoria de conta e trilhas de atividade administrativa são essenciais para delimitar impacto. A falha pode permitir modificação de dados e divulgação de arquivos, então eventos de leitura sensível, alteração de registros administrativos e mudanças feitas por identidades que não deveriam ter esse alcance precisam ser correlacionados com a janela de exposição do pacote. A ausência de um indicador de rede específico não reduz a necessidade de revisão, porque o mecanismo afetado está no processamento lógico de material protegido pela aplicação.
- Presença de
Microsoft.AspNetCore.DataProtection10.0.0 a 10.0.6 em arquivos de dependência, lockfiles, caches de build ou imagens implantadas. - Emissão incomum de tokens de sessão, chaves de API ou links de redefinição de senha para identidades com privilégio elevado.
- Uso de tokens criados antes da atualização para 10.0.7 após a janela de correção.
- Eventos administrativos, leitura de arquivos ou modificação de dados associados a contas sem histórico compatível.
A primeira ação é atualizar para ASP.NET Core 10.0.7 nos serviços afetados e garantir que a versão corrigida seja realmente a implantada em produção. A validação deve incluir dependências diretas e transitivas, porque o pacote vulnerável pode entrar por bibliotecas auxiliares. Em organizações com pipelines automatizados, a correção precisa ser acompanhada por reconstrução de artefatos, limpeza de caches relevantes e nova publicação das imagens ou pacotes de aplicação usados em execução.
A rotação do chaveiro do DataProtection é parte crítica da resposta. A atualização elimina a condição vulnerável para novas validações, mas tokens emitidos legitimamente durante a janela de exposição podem permanecer aceitos. Rotacionar as chaves reduz esse risco ao invalidar material protegido com chaves antigas, embora possa encerrar sessões e exigir nova autenticação de usuários. Essa consequência operacional deve ser planejada, mas não substitui a necessidade de remover a confiança em artefatos potencialmente induzidos por exploração.
Depois da correção, a equipe deve revisar a janela de exposição com foco em abuso de privilégio e emissão de tokens. Serviços que processam identidade, sessão, recuperação de senha e chaves de API devem ter logs preservados e correlacionados. Quando houver indício de emissão indevida, a resposta deve incluir invalidação de sessões, revogação de chaves de API e revisão de ações executadas pelas contas afetadas. A prioridade não é apenas corrigir o pacote, mas reduzir a validade residual de credenciais e tokens que a própria aplicação pode ter assinado.
- Atualizar aplicações afetadas para ASP.NET Core 10.0.7 e confirmar a versão efetiva em produção.
- Identificar referências diretas e transitivas ao
Microsoft.AspNetCore.DataProtectionvulnerável antes de encerrar a resposta. - Rotacionar o chaveiro do DataProtection para invalidar tokens emitidos durante a janela vulnerável.
- Revisar emissão de tokens, sessões privilegiadas, chaves de API e links de redefinição de senha no período afetado.
- Revogar artefatos suspeitos e correlacionar mudanças de dados ou acesso a arquivos com identidades que receberam privilégios inesperados.
0 Comentários