Vulnerabilidade crítica no ASP.NET Core e como proteger suas aplicações

Nos últimos tempos, O ASP.NET Core foi abalado por diversas falhas de segurança críticas. que afetam diretamente a autenticação, a proteção de dados e o próprio servidor web Kestrel. Se você desenvolve ou mantém aplicações em .NET, isso não é apenas um detalhe técnico: estamos falando de vulnerabilidades com Pontuações CVSS muito altas (9,1 e até 9,9), capaz de abrir caminho para escalonamento de privilégios, falsificação de identidade de usuários e exposição de informações altamente sensíveis.

Para além do ruído dos boletins de segurança, é fundamental compreender O que exatamente está falhando no ASP.NET Core e quais pacotes e versões são afetados?e como uma equipe de desenvolvimento moderna que trabalha com as melhores práticas de CI/CD e DevSecOps deve reagir, como por exemplo: IDEs e ferramentas essenciais para teste de aplicaçõesVamos analisar os casos mais graves (incluindo CVE-2026-40372 e CVE-2025-55315) e revisar o Medidas de mitigação recomendadas pela Microsoft E já que estamos falando nisso, vamos revisar o modelo de tratamento de erros e exceções no ASP.NET Core, porque uma falha de segurança sem boa observabilidade é como procurar uma agulha em um palheiro.

Vulnerabilidade crítica na proteção de dados: CVE-2026-40372

Um dos incidentes mais graves que atingiu o ecossistema é CVE-2026-40372, uma vulnerabilidade crítica em Microsoft.AspNetCore.DataProtection, corrigido pela Microsoft com uma atualização fora do ciclo na versão .NET 10.0.7. A gravidade não é menor: CVSS 3.1 de 9,1 (Análise) e exploração remota sem autenticação.

Essa vulnerabilidade afeta Versões 10.0.0 a 10.0.6 do pacote NuGet Microsoft.AspNetCore.DataProtection e dependências relacionadas, como Microsoft.AspNetCore.DataProtection.StackExchangeRedis. O problema reside em uma falha muito sutil, porém devastadora, na lógica criptográfica da cifra autenticada gerenciada pelo ASP.NET Core.

O componente vulnerável Calcula a tag de validação HMAC nos bytes incorretos da carga útil. E, em certos casos, chega mesmo a descartar o hash gerado. Essa validação falha quebra completamente o modelo de confiança esperado: um atacante pode construir payloads que parecem legítimos, burlando as verificações de autenticidade do sistema de proteção de dados.

As consequências práticas são especialmente graves.Isso ocorre porque o DataProtection não é usado apenas para criptografar dados arbitrários; ele está no cerne de muitos mecanismos de segurança do ASP.NET Core: cookies de autenticação, tokens antifalsificação, TempData, estado OIDC e outros elementos que dependem desse conjunto de chaves. Se esses objetos puderem ser falsificados ou descriptografados, um invasor terá um caminho muito direto para a escalada de privilégios.

Impacto real: cookies, tokens e identidade comprometida.

A falha no DataProtection permite que um invasor forjar cargas úteis que passem por verificações criptográficas e, em alguns cenários, até mesmo descriptografar dados previamente protegidosEm ambientes onde as APIs de proteção do ASP.NET Core são utilizadas, isso se traduz em uma gama de ataques muito preocupante.

Os dados potencialmente expostos incluem cookies de autenticação, tokens antifalsificação, TempData, status OIDC e outros tokens internosNa pior das hipóteses, um atacante não autenticado poderia falsificar um cookie ou token que o identificasse como um usuário com privilégios elevados, como um administrador de aplicativo ou um administrador de serviço interno.

O cenário se agrava porque, se durante a janela de vulnerabilidade o atacante conseguir obter um alto nível de acessoIsso pode induzir o aplicativo a emitir ativos legítimos, mas obtidos de forma maliciosa: Chaves de API, tokens de atualização de sessão, links de redefinição de senha ou chaves de acesso persistentes.Todos esses artefatos permaneceriam válidos mesmo após a atualização para o .NET 10.0.7, a menos que medidas adicionais sejam tomadas.

Em outras palavras, mesmo que você aplique o adesivo, se não houver uma reação adequada, Seu sistema ainda pode estar exposto a tokens já emitidos em condições comprometidas.É por isso que a Microsoft compara essa falha a vulnerabilidades históricas como a MS10-070, relacionada a problemas de padding-oracle na criptografia legada do ASP.NET.

A Microsoft descobriu essa regressão como resultado de Relatos de clientes que enfrentam falhas de descriptografia após a instalação do .NET 10.0.6 durante a atualização de segurança de abril (Patch Tuesday). Ao investigar o incidente (inicialmente documentado na issue #66335 do aspnetcore), a equipe descobriu que não se tratava apenas de um bug funcional, mas sim de uma falha de segurança significativa que exigia uma correção urgente fora do ciclo regular.

Condições operacionais e ambientes afetados

Embora a falha seja crítica, Nem todos os ambientes são expostos por padrão.Segundo informações oficiais, para explorar a vulnerabilidade CVE-2026-40372, diversas condições específicas relacionadas aos pacotes e ao ambiente de execução devem ser atendidas.

Por um lado, o aplicativo deve estar usando as versões vulneráveis ​​do pacote Microsoft.AspNetCore.DataProtection (10.0.0 a 10.0.6) ou bibliotecas que o carregam em tempo de execução. Além disso, a vulnerabilidade tem um impacto maior em sistemas operacionais que não sejam Windows, como... Linux e macOSIsso se encaixa perfeitamente na implantação típica do ASP.NET Core em contêineres, orquestradores e plataformas de nuvem.

O vetor de ataque é normalmente executado. pela rede, sem a necessidade de autenticação prévia.Isso aumenta o perigo em aplicações expostas à internet. O atacante pode enviar payloads especialmente criados como se fosse um cliente comum do sistema, sem exigir credenciais válidas.

Na prática, isto significa que Infraestruturas baseadas em microsserviços, contêineres Docker e plataformas PaaS. Sistemas que dependem do DataProtection para compartilhar chaves ou estado de autenticação entre instâncias são alvos prioritários. Se o conjunto de chaves não tiver sido atualizado e rotacionado, existe um risco real de que uma única violação de segurança possa se transformar em um acesso persistente e difícil de detectar.

Por todos os motivos acima, as equipes de segurança de aplicativos precisam Analise detalhadamente quais serviços carregam o pacote vulnerável. e em quais sistemas operacionais eles são executados, em vez de presumir que o problema afeta apenas cenários muito específicos.

Ações urgentes: atualização para o .NET 10.0.7 e rotação de chaves.

A principal recomendação da Microsoft é clara: Atualize imediatamente o pacote Microsoft.AspNetCore.DataProtection para a versão 10.0.7. e recompilar os aplicativos com os runtimes e SDKs corrigidos (por exemplo, .NET SDK 10.0.203 e seus runtimes associados).

Para confirmar se o ambiente está devidamente atualizado, você deve executar o seguinte comando: Execute o comando `dotnet --info` e verifique se a versão do runtime é 10.0.7. correspondente. Não basta instalar o ambiente de execução no servidor; é essencial reconstruir e reimplantar aplicativos Utilizando imagens ou pacotes de contêiner atualizados para garantir que o código de produção esteja vinculado aos binários corrigidos.

No entanto, como mencionado anteriormente, a aplicação da atualização não corrigirá, por si só, nenhum dano já ocorrido. A Microsoft desaconselha veementemente essa prática. Gire o chaveiro DataProtection Em ambientes que foram expostos, a fim de invalidar qualquer token, cookie ou credencial gerada maliciosamente durante o período de vulnerabilidade.

Além de atualizar e rotacionar as chaves, é prudente forçar o encerramento de sessões ativas (revogação de cookies de login, tokens de acesso, etc.), exigir reautenticações e ativar um auditoria detalhada de logs Analisar atividades suspeitas, especialmente acessos administrativos atípicos, criação de chaves de API, redefinições de senha e operações privilegiadas.

Do ponto de vista DevSecOps, este incidente reforça a importância de incorporar scanners de dependência na cadeia CI/CD e para habilitar alertas automáticos quando vulnerabilidades críticas surgirem em pacotes de terceiros. Com o DataProtection, assim como com qualquer biblioteca criptográfica, uma pequena mudança de comportamento pode comprometer todo o modelo de segurança se não for rigorosamente validada.

Outra vulnerabilidade crítica: falsificação de requisições HTTP no Kestrel (CVE-2025-55315)

Além da vulnerabilidade no DataProtection, outra foi relatada. Falha de segurança extremamente grave no ASP.NET CoreDesta vez, o foco foi no servidor web Kestrel. Identificado como CVE-2025-55315Foi classificado como um erro de falsificação de solicitação HTTP com uma pontuação de gravidade de 9,9 de 10.

A essência do problema é que Um atacante pode injetar uma segunda solicitação HTTP maliciosa dentro de uma solicitação aparentemente legítima.Isso é típico dos chamados ataques de contrabando de requisições ou manipulação de frames HTTP. Essa técnica pode ser usada para burlar os controles de segurança presentes em proxies, balanceadores de carga ou no próprio servidor, fazendo com que o backend processe dados que nunca deveria ter aceitado.

De acordo com o alerta da Microsoft, o impacto potencial envolve Acesso a informações confidenciais, roubo de credenciais, modificação não autorizada de arquivos. e até mesmo a possibilidade de causar falhas no servidor que afetam a disponibilidade. Ao impactar diretamente a camada de transporte HTTP, o leque de ataques é muito amplo, desde burlar a autenticação até desviar o tráfego para rotas internas.

A vulnerabilidade afeta especificamente Microsoft.AspNetCore.Server.Kestrel.Core Essa vulnerabilidade existe em certas versões do ASP.NET Core e é considerada um dos problemas de segurança mais graves que a plataforma enfrentou nos últimos anos. Novamente, trata-se de um vetor explorável por atacantes não autenticados, o que aumenta significativamente a superfície de ataque.

Barry Dorrans, líder técnico de segurança da .NET, explicou que o Uma pontuação tão alta reflete o pior cenário possível.Como o impacto real depende em grande parte de como cada aplicação é construída, a avaliação baseia-se na premissa de uma violação dos mecanismos de segurança com alterações de escopo, que é o tipo de falha considerada inaceitável em ambientes corporativos.

Versões e patches afetados para Kestrel e ASP.NET Core

Para solucionar a vulnerabilidade CVE-2025-55315, a Microsoft lançou uma nova versão. Atualizações de segurança específicas para diferentes versões do .NET e ASP.NET Core., abrangendo versões mais antigas e mais recentes, incluindo ASP.NET Core 2.3, 8.0 e 9.0.

Em ambientes onde é utilizado .NET 8 ou superiorA mitigação recomendada envolve a aplicação de todas as correções disponíveis através de Microsoft Update e, posteriormente, validar se os ambientes de execução e os pacotes estão na versão corrigida. É especialmente importante verificar se os aplicativos foram recompilados com essas versões e se as imagens de produção não contêm mais binários vulneráveis.

No caso de projetos que ainda estão sendo realizados em .NET 2.3A Microsoft indica que é essencial. Atualize a referência do pacote Microsoft.AspNet.Server.Kestrel.Core para a versão 2.3.6.Recompile a solução e reimplemente as implantações. Caso contrário, o Kestrel continuará processando solicitações com a lógica defeituosa que permite a falsificação de solicitações HTTP.

As implantações que usam aplicativos independentes ou aplicativos empacotados como um único arquivo Eles também têm a obrigação de compilar do zero com os runtimes corrigidos; caso contrário, o executável ainda conterá o código vulnerável. É fácil esquecer esse detalhe se você depender demais apenas da atualização do host.

Juntamente com as atualizações da própria estrutura, a Microsoft lançou Correções para Microsoft.AspNetCore.Server.Kestrel.Core e outros componentes relacionados.O objetivo é fortalecer a robustez da análise e do processamento de requisições HTTP. Em resumo, não se trata de uma correção isolada, mas sim de uma melhoria coordenada em diversos pontos da pilha do ASP.NET Core.

Atualizações críticas adicionais no ASP.NET Core e risco global

Além desses casos específicos, a Microsoft tem lançado Correções críticas para outras vulnerabilidades no ASP.NET Core Essas vulnerabilidades podem levar à execução remota de código (RCE), escalonamento de privilégios e ataques de negação de serviço (DoS). A combinação dessas falhas deixa claro que a estrutura, por mais madura que seja, não está imune a regressões perigosas.

Essas falhas afetam Componentes principais do ambiente de execução ASP.NET CoreIsso inclui o processamento de requisições HTTP, middleware de autenticação e autorização, e APIs relacionadas à serialização e desserialização de dados. Em muitos casos, os atacantes podem explorar essas vulnerabilidades. entradas malformadas ou cargas úteis manipuladas para desencadear comportamentos inesperados.

As versões afetadas geralmente correspondem a versões anteriores às correções de segurança publicadas em abril de 2026Portanto, uma auditoria de versões é obrigatória em todos os ambientes de produção que continuam executando versões antigas. Manter os servidores desatualizados é, hoje em dia, uma receita para o desastre.

Do ponto de vista empresarial, a não implementação dessas correções pode ter consequências muito graves: perda de confidencialidade dos dados, integridade comprometida, indisponibilidade de serviços essenciais e um impacto na reputação que leva anos para ser superado. Organizações que dependem do ASP.NET Core para aplicações de missão crítica devem encarar o gerenciamento de patches como um processo contínuo, e não como uma tarefa pontual.

A recomendação geral da Microsoft é que Aplique as correções assim que estiverem disponíveis e revise as configurações de segurança dos ambientes.Reforçar o monitoramento de atividades suspeitas e revisar os processos de desenvolvimento seguro para minimizar a probabilidade de introduzir vulnerabilidades no próprio código do aplicativo.

Tratamento de erros e exceções no ASP.NET Core: uma peça fundamental do quebra-cabeça.

Quando falamos de segurança, muitas vezes pensamos apenas em patches e criptografia, mas Um bom sistema de tratamento de erros é essencial no ASP.NET Core. Para detectar, investigar e mitigar incidentes, a estrutura oferece múltiplos mecanismos para lidar com exceções, retornar códigos de status apropriados e expor respostas padrão, como ProblemDetails, em APIs.

Em ambientes de desenvolvimento, o ASP.NET Core habilita por padrão o Página de Exceções do Desenvolvedor Quando certas condições são atendidas (geralmente estar no ambiente de Desenvolvimento). Esta página é acionada pelo middleware DeveloperExceptionPageMiddleware, que é colocado no início do pipeline HTTP para Interceptar exceções não tratadas, tanto síncronas quanto assíncronas.e exibir informações detalhadas.

A página de exceções do desenvolvedor pode incluir rastreamentos de pilha, parâmetros de string de consulta, cookies, cabeçalhos HTTP e metadados de endpoint.É uma ferramenta magnífica durante o desenvolvimento, mas, logicamente, Não deve ser ativado em produção.Porque expor detalhes internos facilita a vida dos atacantes.

Em um ambiente de produção, a prática recomendada é configurar um Página de erro personalizada usando UseExceptionHandlerEste middleware captura exceções não tratadas, registra-as e reexecuta a solicitação por meio de um pipeline alternativo, normalmente apontando para uma rota como /Error.

Ao reinstalar a tubulação, é importante ter em mente que Os middlewares podem ser invocados novamente com o mesmo HttpContext.Portanto, é recomendável limpar os estados internos, armazenar em cache os resultados ou reutilizar os dados já lidos (por exemplo, o corpo da requisição) para evitar erros adicionais. Além disso, os serviços com escopo permanecem os mesmos durante a reexecução.

Acesso a exceções e controle centralizado com IExceptionHandler

Para obter informações detalhadas sobre a exceção que acionou a página de erro, o ASP.NET Core expõe o recurso. IExceptionHandlerPathFeature. Via HttpContext.Features.Get É possível recuperar tanto o caminho da solicitação original quanto o próprio objeto de exceção.

Um padrão comum nas Razor Pages consiste em Armazene o RequestId e uma mensagem de erro amigável no modelo da página.O uso da interface IExceptionHandlerPathFeature permite personalizar a mensagem com base no tipo de exceção (por exemplo, FileNotFoundException) ou no caminho que causou a falha. Isso possibilita exibir erros mais úteis para o usuário sem filtrar detalhes internos.

Além da abordagem baseada em páginas ou específica do controlador, o ASP.NET Core oferece a interface IExceptionHandler como um mecanismo centralizado de tratamento de exceções. Implementações dessa interface são registradas com AddExceptionHandler. e são executadas em ordem, retornando verdadeiro quando tratam a exceção e falso quando preferem delegar ao comportamento padrão.

Este sistema facilita, por exemplo, Registrar erros em um sistema externo e aplicar lógica condicional de acordo com o tipo de exceção. ou modificar a resposta HTTP global sem precisar acessar cada controlador individualmente. A partir do .NET 10, o middleware de exceção também permite configurar o SuppressDiagnosticsCallback para decidir quando suprimir métricas e logs em caso de exceções já tratadas.

Outra opção muito flexível é usar um lambda em UseExceptionHandlerIsso envolve acessar diretamente o contexto, definir o código de status e o Content-Type e escrever a resposta manualmente. Você pode até usar o IProblemDetailsService dentro dessa função Lambda para emitir uma resposta ProblemDetails padrão que descreva claramente o problema.

Páginas de código de status e respostas ProblemDetails

Por padrão, um aplicativo ASP.NET Core Não exibe páginas compatíveis com códigos de status HTTP, como o 404.Ele simplesmente retorna o código e um corpo vazio. Para enriquecer essa experiência e facilitar a depuração, você pode habilitar o middleware de página de código de status usando `UseStatusCodePages`.

UseStatusCodePages suporta vários modos: Texto simples com uma mensagem genérica, funções lambda para personalizar totalmente a resposta. ou variantes que redirecionam ou reexecutam o pipeline para um endpoint alternativo, como UseStatusCodePagesWithRedirects e UseStatusCodePagesWithReExecute.

Com UseStatusCodePagesWithRedirects, o middleware Ele retorna um código 302 Found e redireciona o cliente para uma URL que normalmente oferece uma visualização mais amigável ao usuário., geralmente retornando um código 200 OK. Essa abordagem faz sentido quando você deseja que a barra de endereços reflita o caminho final do erro e não quer preservar o código de status original.

UseStatusCodePagesWithReExecute, por outro lado, O código de estado inicial não muda.Em vez disso, ele reexecuta a solicitação em uma rota diferente para gerar o corpo da resposta. A URL original é preservada na barra de endereços do navegador, e o ponto de erro pode recuperar a rota e a consulta originais por meio do IStatusCodeReExecuteFeature, o que é muito útil para registro e depuração.

No âmbito das APIs, o ASP.NET Core adotou o padrão. Detalhes do problema como formato padrão para respostas de erroAo registrar o AddProblemDetails no contêiner de serviços, o middleware pode gerar automaticamente respostas JSON com campos como tipo, título, status e traceId quando ocorrerem erros no cliente ou no servidor sem um corpo de resposta.

Esse comportamento pode ser personalizado por Detalhes do ProblemaOpções.PersonalizarDetalhes do ProblemaIsso envolve a adição de extensões como um identificador de nó (por exemplo, nome da máquina) ou outros metadados que ajudam a rastrear problemas em ambientes distribuídos. Também é possível implementar um IProblemDetailsWriter personalizado que decide quais estados devem ser tratados e como serializar os detalhes.

Lições para DevSecOps e melhores práticas contínuas

A cascata de vulnerabilidades no ASP.NET Core e em seu ecossistema .NET apresenta diversas lições importantes para qualquer equipe de desenvolvimento séria: A dependência de terceiros é um vetor crítico; a criptografia mal implementada quebra todo o modelo de confiança. E os mecanismos de autenticação se tornaram um alvo principal para os atacantes.

Do ponto de vista DevSecOps, isso se torna essencial. integrar análise de dependência Em pipelines de CI/CD, execute testes de segurança contínuos e mantenha visibilidade clara de todos os componentes de terceiros incorporados ao projeto. Ferramentas de Análise de Composição de Software (SCA) e scanners de vulnerabilidades não devem mais ser opcionais, mas sim parte do fluxo de trabalho de integração padrão.

É também vital reforçar Auditorias de logs e monitoramento de eventos de segurançaIsso é especialmente verdadeiro em relação à autenticação, emissão de tokens, criação de sessões, alterações de permissões e operações administrativas. Sem um bom sistema de registro e alertas, uma vulnerabilidade como a CVE-2026-40372 ou a CVE-2025-55315 pode ser explorada silenciosamente por meses.

Apesar de sua complexidade e do volume de bugs recentes, o ASP.NET Core continua sendo um framework robusto, desde que seja atualizado corretamente e configurado de forma segura. A combinação de Aplicação rápida de patches, rotação de chaves quando necessário, boas práticas de tratamento de erros e uma abordagem proativa à segurança. Isso faz toda a diferença entre uma plataforma robusta e um alvo fácil para atacantes.

Todo esse conjunto de vulnerabilidades e mecanismos de mitigação nos lembra que A segurança no ASP.NET Core não se resume apenas à aplicação de patches ocasionais.mas sim assumir uma disciplina contínua: monitorar as versões de pacotes e de tempo de execução, cuidar do tratamento de erros e exceções, revisar as respostas HTTP e os detalhes dos problemas que expomos e dar suporte a tudo isso com processos DevSecOps maduros que nos permitam reagir rapidamente sempre que uma nova falha crítica surgir no ecossistema .NET.

Artigo relacionado:

Lista de verificação das principais ações a serem tomadas após um incidente de cibersegurança.

Isaac

Escritor apaixonado pelo mundo dos bytes e da tecnologia em geral. Adoro compartilhar meu conhecimento por meio da escrita, e é isso que farei neste blog, mostrar a vocês tudo o que há de mais interessante sobre gadgets, software, hardware, tendências tecnológicas e muito mais. Meu objetivo é ajudá-lo a navegar no mundo digital de uma forma simples e divertida.