Falha crítica no Exim expõe builds com GnuTLS a corrupção de memória via `BDAT`

CVE-2026-45185 afeta versões 4.97 a 4.99.2 do Exim compiladas com USE_GNUTLS=yes e pode permitir execução de código após encerramento TLS durante transferência BDAT.

Componente	Parser de corpo de mensagem BDAT do Exim em builds que usam GnuTLS com USE_GNUTLS=yes.
Vetor	Cliente SMTP estabelece conexão TLS, usa a extensão CHUNKING com BDAT, envia close_notify antes de concluir o corpo e depois entrega um byte final em texto claro na mesma conexão TCP.
Impacto	Uso após liberação em buffer de transferência TLS, corrupção de heap e potencial execução remota de código em servidores vulneráveis.
Prioridade	Atualizar para Exim 4.99.3; não há mitigação equivalente que elimine a falha sem aplicar a correção.
Versões	Afeta Exim 4.97 até 4.99.2, inclusive, somente quando compilado com GnuTLS; builds com outras bibliotecas TLS, como OpenSSL, não estão no escopo informado.
Artefatos	CVE-2026-45185, apelidada de Dead.Letter, CVSS 9.8, extensão SMTP CHUNKING, comando BDAT, alerta TLS close_notify, função ungetc().
Mitigação	Aplicar Exim 4.99.3 e validar inventário de binários para confirmar se o serviço em produção foi compilado com USE_GNUTLS=yes.

Resumo técnico

O Exim corrigiu a vulnerabilidade crítica CVE-2026-45185, também identificada como Dead.Letter, em um caminho específico de tratamento de corpo de mensagem SMTP quando a extensão CHUNKING é usada com BDAT sobre uma sessão TLS implementada com GnuTLS. A falha é um uso após liberação no processamento de entrada: durante o encerramento da sessão TLS, o Exim libera o buffer de transferência associado ao TLS, mas uma camada interna ainda relacionada ao recebimento de BDAT pode continuar aceitando bytes e escrever em uma região de memória que já não pertence mais ao fluxo ativo. A condição é crítica porque ocorre antes de autenticação de usuário de e-mail em muitos cenários operacionais de MTA exposto à internet, desde que o servidor permita TLS e anuncie ou aceite CHUNKING.

A exploração exige que o cliente remoto consiga abrir uma conexão TLS com o serviço SMTP e usar o mecanismo BDAT. O fluxo abusado depende de uma sequência precisa: iniciar a transferência do corpo, enviar um alerta TLS close_notify antes do fim do corpo e, em seguida, transmitir um byte final em texto claro sobre a mesma conexão TCP. Essa transição anômala entre encerramento TLS e leitura restante do corpo aciona um estado inconsistente entre o ciclo de vida do buffer e a pilha de processamento de entrada. O resultado confirmado é corrupção de heap, com potencial para execução de código, razão pela qual a vulnerabilidade recebeu CVSS 9.8.

O escopo não cobre todas as instalações do Exim. A falha afeta versões 4.97 até 4.99.2, inclusive, quando o binário foi compilado com USE_GNUTLS=yes. Ambientes que usam outras bibliotecas TLS, como OpenSSL, não estão incluídos no impacto descrito. A versão 4.99.3 introduz a correção, redefinindo corretamente a pilha de processamento de entrada quando um close_notify TLS é recebido durante uma transferência BDAT ativa. Como não há mitigação que resolva a condição de memória sem alterar o código vulnerável, a resposta operacional principal é atualizar o pacote ou reconstruir o binário corrigido.

Fluxo técnico

O ponto vulnerável aparece na interseção entre o protocolo SMTP estendido por CHUNKING, o comando BDAT e o encerramento controlado de uma sessão TLS com GnuTLS. Em uma entrega SMTP tradicional, o corpo pode ser enviado por DATA; com CHUNKING, o cliente pode transmitir partes binárias por BDAT, incluindo metadados de tamanho e o marcador de última parte. Esse caminho exige wrappers de leitura que mantenham controle do corpo em andamento e da quantidade restante de dados. Quando o transporte é protegido por TLS, outra camada administra buffers próprios, estado criptográfico e eventos de fechamento. A vulnerabilidade surge quando essas camadas discordam sobre se ainda existe entrada válida a ser consumida.

A sequência explorável começa com uma sessão TLS funcional. O atacante inicia uma transferência BDAT e não termina o corpo no ponto esperado. Antes da conclusão, envia o alerta TLS close_notify, que faz a camada TLS iniciar o processo de desligamento e liberar o buffer de transferência. O detalhe crítico é que o wrapper de recebimento associado ao BDAT ainda pode tratar bytes posteriores como parte do fluxo lógico pendente. Quando um byte final chega em texto claro na mesma conexão TCP, a rotina de entrada pode chamar ungetc() para devolver um caractere, descrito como \n, ao fluxo de leitura. Essa escrita de um único byte ocorre sobre memória já liberada.

Embora uma gravação de um byte pareça limitada, a região atingida está próxima ou sobre metadados do alocador de heap. Ao corromper a estrutura interna do alocador, o bug deixa de ser apenas uma falha de disponibilidade e passa a oferecer caminho para primitivas de exploração mais avançadas. O impacto real depende de arquitetura, versão do sistema, opções de compilação, endurecimento de memória, layout de heap, comportamento do alocador e condições de processo do daemon SMTP. Mesmo com esses condicionantes, o fato de a pré-condição remota ser apenas conexão TLS mais uso de BDAT torna a falha de alta prioridade para MTAs expostos.

A correção na versão 4.99.3 altera a gestão de estado entre a notificação de fechamento TLS e o processamento de BDAT. Ao receber close_notify durante uma transferência ativa, o Exim passa a limpar a pilha de processamento de entrada de forma consistente, impedindo que ponteiros ou wrappers obsoletos continuem operando sobre buffers liberados. Esse tipo de ajuste é importante porque não basta recusar dados tardios no nível do protocolo; o servidor precisa garantir que nenhuma camada interna mantenha referências antigas depois que a sessão criptográfica destruiu seus recursos.

Superfície afetada

A superfície exposta é composta por servidores Exim nas versões 4.97, 4.98, 4.99, 4.99.1 e 4.99.2, além de quaisquer pacotes de distribuição ou builds locais derivados desses ramos quando compilados com USE_GNUTLS=yes. A presença do pacote Exim por si só não confirma exposição; a biblioteca TLS usada no build é o fator de decisão. Em ambientes Linux e Unix-like, essa diferença pode variar entre distribuição, repositório, backport de segurança e compilação própria. Operadores devem validar o binário efetivamente carregado pelo serviço, não apenas a versão declarada no inventário de pacotes.

O vetor é relevante para servidores SMTP que aceitam conexões de redes não confiáveis, especialmente portas de submissão ou recepção que permitem TLS e anunciam CHUNKING. MTAs na borda de e-mail corporativo, gateways antispam que executam Exim, relays internos acessíveis por múltiplas zonas e servidores de hospedagem compartilhada devem ser avaliados. Mesmo quando o serviço exige autenticação para envio, a fase de negociação SMTP e TLS pode ocorrer antes de credenciais serem verificadas, dependendo da configuração local. O risco aumenta quando o processo do Exim roda com privilégios suficientes para manipular fila, spool, aliases, roteamento e entrega local.

Instalações que usam OpenSSL no lugar de GnuTLS não entram no escopo informado, mas essa exclusão deve ser tratada como uma conclusão de inventário, não como suposição. Em ambientes com imagens de contêiner, appliances de e-mail, compilações empacotadas por terceiros ou servidores antigos, a opção USE_GNUTLS=yes pode não estar documentada no CMDB. A investigação precisa cruzar versão, origem do pacote, flags de build e comportamento do serviço em execução.

• Servidores Exim 4.97 a 4.99.2 compilados com USE_GNUTLS=yes.
• Serviços SMTP que aceitam TLS e permitem a extensão CHUNKING com BDAT.
• Relays de e-mail expostos à internet, gateways de borda, servidores de hospedagem e MTAs internos acessíveis por zonas sem confiança plena.
• Builds com OpenSSL estão fora do impacto informado, mas a biblioteca TLS deve ser confirmada no binário em produção.

Hunting e telemetria

A detecção deve procurar sinais de abuso do fluxo SMTP/TLS, não IoCs estáticos. Não há hash, domínio, endereço IP ou payload público associado no contexto técnico disponível. A telemetria útil está em logs de conexão SMTP, eventos de TLS, quedas do processo Exim, mensagens de falha de heap e padrões de sessão anormais envolvendo BDAT. Um candidato forte é a conexão que negocia TLS, inicia CHUNKING, envia BDAT com corpo incompleto e encerra o TLS com close_notify antes do limite esperado. Se a camada de logging não registra close_notify, a análise pode correlacionar término TLS limpo ou incomum com fechamento de sessão antes do fim lógico da mensagem.

Em endpoint e sistema operacional, operadores devem revisar reinicializações do daemon, sinais de crash, dumps de núcleo, mensagens do alocador e eventos de supervisores como systemd indicando falhas repetidas do serviço SMTP. Corrupção de heap pode se manifestar como abortos por verificação interna do alocador, violações de memória ou comportamento instável sem entrega de mensagem correspondente. Em sensores de rede, a característica mais relevante é a mesma conexão TCP contendo encerramento TLS e bytes subsequentes que já não seguem o fluxo criptografado esperado. Esse padrão é incomum em clientes SMTP legítimos e deve ser priorizado quando combinado com comandos BDAT.

A investigação histórica deve cobrir o período anterior à atualização, sobretudo em servidores expostos publicamente. Como a falha foi reportada em 1º de maio de 2026 e corrigida na versão 4.99.3, o intervalo entre adoção de versões vulneráveis e aplicação da correção deve ser tratado como janela de exposição. Não é correto concluir comprometimento apenas por falha de conexão BDAT, mas tentativas repetidas com encerramento TLS durante corpo incompleto justificam análise de processo, fila de e-mail, integridade de binários e atividade pós-exploração no host.

• Sessões SMTP com TLS seguido de uso de CHUNKING e comando BDAT sem conclusão normal do corpo.
• Encerramento TLS por close_notify durante transferência BDAT ativa, especialmente com dados posteriores na mesma conexão TCP.
• Crashes, reinícios inesperados do Exim, dumps de núcleo ou mensagens de corrupção de heap em logs do sistema.
• Conexões repetidas de uma mesma origem tentando combinações de BDAT, fechamento TLS e término anômalo antes da aceitação da mensagem.
• Filas de e-mail, arquivos de spool e processos filhos do Exim com comportamento incompatível com o volume normal de entrega.

Mitigação

A ação de contenção efetiva é atualizar para Exim 4.99.3 ou aplicar o backport equivalente fornecido pelo mantenedor da distribuição, desde que o pacote realmente inclua a correção para CVE-2026-45185. Antes da mudança, o operador deve identificar todos os servidores que executam Exim, confirmar a versão em execução e determinar se o build usa GnuTLS. Depois da atualização, o serviço precisa ser reiniciado de forma controlada para garantir que o processo antigo não permaneça carregado em memória. Em ambientes com alta disponibilidade, a ordem deve preservar fluxo de e-mail, mas não deve manter nós vulneráveis recebendo tráfego externo após a correção estar disponível.

Como não há mitigação equivalente que elimine a vulnerabilidade, controles compensatórios devem ser tratados apenas como redução temporária de exposição. Restringir acesso SMTP a origens confiáveis, isolar relays internos, reduzir superfície de recepção direta e monitorar BDAT podem diminuir a probabilidade de exploração, mas não corrigem o uso após liberação. Desabilitar funcionalidades ou trocar biblioteca TLS sem uma reconstrução validada pode introduzir regressões operacionais e não deve substituir a atualização. A validação final precisa confirmar versão corrigida, biblioteca TLS do binário ativo, reinício do daemon e ausência de processos antigos aceitando conexões.

Após aplicar a correção, a resposta defensiva deve incluir revisão retrospectiva de telemetria. Servidores que apresentaram crashes recentes, erros de heap, conexões SMTP anormais ou tentativas BDAT incompletas merecem análise adicional. Se houver indício de exploração, a contenção deve incluir preservação de logs, coleta de memória quando possível, verificação de integridade de binários, revisão de contas locais, análise de tarefas persistentes, inspeção de fila e spool do Exim e rotação de credenciais que possam ter sido expostas no host. A prioridade é distinguir falhas operacionais comuns de um fluxo compatível com a condição técnica da vulnerabilidade.

• Atualizar para Exim 4.99.3 ou pacote de distribuição que incorpore a correção de CVE-2026-45185.
• Confirmar se o binário em produção foi compilado com USE_GNUTLS=yes; não depender apenas do nome do pacote.
• Reiniciar o serviço Exim e verificar que nenhum processo antigo continua aceitando conexões SMTP.
• Revisar logs de SMTP, TLS, sistema operacional e supervisão de serviço para crashes ou sessões BDAT anômalas antes da atualização.
• Preservar evidências e iniciar análise de comprometimento se houver corrupção de heap, dumps de núcleo ou sequência compatível com close_notify durante BDAT.