A maioria das falhas de injeção de e-mail cobertas aqui começa em um canto estreito da internet: um plugin do WordPress, uma biblioteca Java. A CVE-2026-50659 não. Ela está dentro do System.Net.Mail, o cliente SMTP embutido em toda versão do .NET nas últimas duas décadas, ainda conectado a incontáveis formulários de contato, sistemas de tickets e serviços de notificação que não têm nenhum motivo para ser reescritos.
O que é a CVE-2026-50659, na prática
Divulgada como parte das atualizações de segurança do .NET de julho de 2026, a CVE-2026-50659 é uma vulnerabilidade de falsificação na implementação do SmtpClient dentro do System.Net.Mail. Ela afeta o .NET 8.0.0 até 8.0.28, o .NET 9.0.0 até 9.0.17 e o .NET 10.0.0 até 10.0.9, além da linha .NET 6.0, que chegou ao fim de vida e não receberá correção. As versões corrigidas são 8.0.29, 9.0.18 e 10.0.10. A Microsoft classifica com CVSS 6.5, severidade média, e como CWE-116, codificação ou escape incorreto da saída.
A Microsoft vem dizendo aos desenvolvedores há anos que o System.Net.Mail não é recomendado para novos projetos. Essa orientação não fez nada para tirá-lo de produção. Ele continua sendo uma das formas mais comuns de uma aplicação .NET enviar e-mail, justamente porque funciona, já vem pronto de fábrica e ninguém reserva tempo para substituir código que já funciona.
Como um erro de duplicação de pontos vira um erro de contrabando de e-mail
O SMTP marca o fim do corpo de uma mensagem com uma linha contendo um único ponto. Para evitar que uma linha legítima que começa com ponto seja confundida com esse marcador de fim, o protocolo exige a duplicação de pontos: qualquer linha do corpo da mensagem que comece com ponto recebe um ponto extra na frente antes da transmissão, e é removida de volta ao ser recebida.
O codificador do SmtpClient rastreia em que ponto da linha atual ele está para saber quando aplicar essa duplicação. A falha está em como ele lida com conteúdo entregue em mais de uma chamada de escrita. Quando um retorno de carro encerra uma escrita e a quebra de linha correspondente chega no início da próxima, o codificador não consegue transportar corretamente seu rastreamento de posição de linha através dessa fronteira. Uma linha que começa com ponto logo após uma divisão assim não recebe a duplicação.
Uma aplicação que constrói uma mensagem de saída a partir de texto influenciado por um atacante, o corpo de um ticket de suporte, um campo de “mensagem” em um formulário de contato, um comentário encaminhado por e-mail, e escreve isso no fluxo SMTP em mais de uma chamada, pode ser induzida a colocar exatamente esse tipo de divisão em um ponto que o atacante controla. O resultado é que uma linha com um único . chega ao servidor como um marcador real de fim de mensagem no meio do que deveria ser um único e-mail. Tudo o que o atacante forneceu depois desse ponto deixa de ser conteúdo da mensagem. Vira um novo conjunto de comandos SMTP, incluindo um segundo MAIL FROM, RCPT TO e bloco DATA, contrabandeado na mesma sessão de uma mensagem que a aplicação nunca teve intenção de enviar.
Onde o DMARC se encaixa nessa cadeia
Este é o detalhe que mais importa para quem administra política de autenticação. A mensagem contrabandeada não é enviada falsificando cabeçalhos em uma conexão separada. Ela viaja pela mesma sessão SMTP de saída que a aplicação vulnerável já havia aberto, para o mesmo relay que a aplicação já está autorizada a usar, seja um servidor Exchange interno, Amazon SES, SendGrid ou qualquer outro provedor ao qual o app se autentique normalmente.
O SPF verifica o IP de conexão contra o domínio do remetente do envelope. O DKIM verifica uma assinatura criptográfica aplicada pela infraestrutura de envio. O DMARC verifica se os dois se alinham. Nenhuma dessas verificações olha dentro da sessão SMTP para perguntar se ela secretamente contém duas mensagens em vez de uma. Se o relay assina e encaminha a mensagem contrabandeada da mesma forma que assina e encaminha a legítima, porque do ponto de vista do relay não há diferença visível, a mensagem contrabandeada passa por SPF, DKIM e DMARC sem problemas. Não por vencê-los. Por nunca entrar no campo de visão deles como algo diferente de e-mail de saída comum e autorizado.
É o mesmo padrão por trás das falhas de injeção do Netty e de plugins do WordPress cobertas aqui antes, agora um nível acima, dentro do framework do qual milhões de aplicações .NET corporativas dependem silenciosamente para enviar e-mail em nome de sua organização.
O que isso significa para o seu programa
Corrija primeiro, esta é uma atualização direta. Migre para o .NET 8.0.29, 9.0.18 ou 10.0.10, ou as versões de SDK correspondentes. Se você mantém uma implantação autocontida, ela precisa ser recompilada e reimplantada contra o runtime corrigido; atualizar apenas o runtime compartilhado não vai resolver isso.
Audite todo lugar onde suas aplicações constroem e-mails a partir de entrada de usuário. Formulários de contato, portais de suporte, sistemas de convite e qualquer coisa que encaminhe por e-mail texto enviado por usuários são as aplicações que importam aqui. Confirme que o corpo da mensagem é escrito no fluxo SMTP de uma forma que sua biblioteca trata com segurança, e trate qualquer código ainda no .NET 6.0 como algo que precisa de um plano de migração, não apenas da espera por uma correção que não vai chegar.
Não espere que o monitoramento de DMARC detecte isso sozinho. Uma mensagem contrabandeada enviada pelo seu próprio relay autenticado aparece, nos seus relatórios agregados de DMARC, idêntica a uma mensagem que você realmente queria enviar. Detectar esse abuso depende de capturá-lo na camada da aplicação, por meio de validação de entrada e atualização de bibliotecas, não pelos seus relatórios de autenticação.
Trate código de e-mail “antigo, mas funcional” como superfície de ataque, não como infraestrutura resolvida. O System.Net.Mail está marcado como não recomendado para novos projetos há muito tempo. Essa vulnerabilidade é um lembrete de que o código que já roda em produção é exatamente onde uma falha assim causa mais dano, porque é o código que ninguém está olhando.
A conclusão
A CVE-2026-50659 não é uma falha do SPF, do DKIM ou do DMARC. É um lembrete de que os protocolos de autenticação protegem a relação entre um domínio e sua infraestrutura de envio autorizada, não a integridade do que se pede a essa infraestrutura para enviar. Uma única quebra de linha mal tratada em um cliente SMTP de duas décadas foi suficiente para que texto fornecido por um atacante virasse um segundo e-mail, totalmente autenticado, saindo pela porta da frente que a sua própria aplicação já tinha aberto.
A Excello Mail oferece visibilidade contínua sobre seus relatórios DMARC, para que você sempre saiba qual infraestrutura está se autenticando sob seu domínio, mesmo quando as aplicações que enviam esse e-mail carregam vulnerabilidades que a autenticação sozinha nunca foi projetada para detectar. Cadastre-se gratuitamente na Excello Mail e sustente com monitoramento real a camada de autenticação que você realmente controla.