Uma vulnerabilidade divulgada em junho de 2026 no plugin WordPress Gravity SMTP ilustra uma categoria de falhas de segurança de e-mail que o DMARC nunca foi projetado para endereçar. O CVE-2026-4020 é uma falha de divulgação não autenticada de informações na API REST do plugin. Um atacante que encontre um site WordPress executando uma versão vulnerável pode obter as credenciais de API do provedor de e-mail armazenadas no site com uma única requisição HTTP, sem necessidade de autenticação.
O Gravity SMTP é um plugin de gerenciamento de entrega de e-mail com mais de 100.000 instalações ativas no WordPress. Ele integra o WordPress a serviços de envio de terceiros – provedores como SendGrid, Mailgun, Postmark e Amazon SES – e armazena essas credenciais de API no banco de dados do WordPress para uso sempre que o site envia e-mail. A vulnerabilidade expõe essas credenciais por meio de um endpoint que não verifica se o solicitante tem permissão para lê-las.
A consequência direta é precisa: um atacante de posse da sua chave de API do ESP pode enviar e-mails do seu domínio usando sua própria infraestrutura de envio configurada. Esse e-mail passará pelo SPF, pelo DKIM e pelo DMARC porque a camada de autenticação não tem como distinguir uma mensagem enviada por você de uma enviada por alguém usando suas credenciais roubadas.
O Que É a Falha e Como Ela Funciona
O Gravity SMTP fornece ao WordPress uma interface centralizada para gerenciar a entrega de e-mails transacionais e de notificações. Em vez de usar o wp_mail() integrado do WordPress com um relay SMTP genérico, o plugin permite que administradores configurem conexões nomeadas a provedores de e-mail específicos, testem essas conexões e roteiem diferentes tipos de e-mail gerados pelo site por meio de diferentes contas de provedores.
Para habilitar esses recursos, o plugin armazena as credenciais do provedor na tabela de opções do WordPress. Para a maioria das integrações, essas credenciais são chaves de API emitidas pelo provedor de envio. A vulnerabilidade – classificada como divulgação não autenticada de informações – existe em um endpoint de API REST que o plugin registra para suportar sua interface administrativa. O endpoint é acessível sem autenticação e sua resposta inclui as credenciais do provedor armazenadas.
Um atacante que descobre um site WordPress executando uma versão vulnerável do Gravity SMTP precisa apenas enviar uma requisição HTTP GET para um caminho de endpoint conhecido. A resposta retorna as chaves de API configuradas em texto simples. O ataque não requer conta no WordPress, cookie de sessão ou engenharia social. É uma extração de credenciais em uma única etapa de qualquer instalação WordPress que tenha o plugin vulnerável instalado e ativo.
Por Que o DMARC Não Consegue Detectar Este Ataque
Quando você configura uma conta de provedor de serviços de e-mail, realiza várias etapas que vinculam seu domínio à infraestrutura de envio desse provedor. Você adiciona os IPs ou nomes de host de envio do provedor ao seu registro SPF. Você configura a assinatura DKIM, seja concedendo ao provedor permissão para assinar em nome do seu domínio, seja adicionando a chave pública DKIM ao seu DNS. Você pode definir sua política DMARC como p=reject para bloquear qualquer envio que não se alinhe com essas fontes autorizadas.
Toda essa configuração cria um conjunto de sinais de autenticação que os servidores receptores usam para verificar que uma mensagem recebida que afirma ser do seu domínio foi realmente enviada por uma parte autorizada. Quando um atacante usa sua chave de API roubada para enviar pelo seu ESP, ele é uma parte autorizada do ponto de vista da camada de autenticação. A mensagem se origina dos IPs de envio do seu ESP, que estão no seu registro SPF. A mensagem é assinada com a chave DKIM do seu domínio, porque seu ESP assina todas as mensagens de saída em seu nome. O domínio do cabeçalho From coincide. O DMARC avalia tudo isso e emite uma aprovação.
Não há falha de autenticação a detectar porque nada na autenticação está falhando. As credenciais são reais. A infraestrutura é autorizada. As assinaturas são válidas. O DMARC foi projetado para verificar que uma mensagem passou por uma infraestrutura autorizada – não para verificar se a pessoa que iniciou a mensagem por meio de uma API tinha permissão para fazê-lo.
Este é um limite arquitetônico fundamental da autenticação em nível de domínio: ela opera na camada de transporte e assinatura, não na camada de credenciais da aplicação. Uma vez que o roubo de credenciais transpõe essas camadas, os sinais de autenticação se tornam evidência de um ataque em vez de uma defesa contra ele.
O Dano à Entregabilidade É Imediato
Além da ameaça direta de ataques de personificação, o abuso de envio baseado em credenciais causa dano colateral à entregabilidade do remetente legítimo.
Quando um atacante usa uma chave de API de ESP roubada para enviar phishing ou spam em volume, o padrão de comportamento da sua conta muda dramaticamente. O volume de envio dispara. Destinatários fora da sua lista normal recebem mensagens. As taxas de reclamação de spam sobem. As taxas de rejeição por endereços inválidos aumentam. Esses sinais alimentam os sistemas de reputação mantidos pelo Gmail, Microsoft e outros grandes provedores de caixa de entrada – não para a infraestrutura do atacante, mas para sua conta ESP e domínio de envio.
O dano à reputação decorrente de um incidente de abuso de credenciais persiste após a remediação da violação. Mesmo após rotacionar a chave de API comprometida e interromper o envio não autorizado, o histórico de comportamento permanece nos sistemas de reputação dos provedores receptores. A recuperação da entregabilidade após um incidente sustentado de abuso de credenciais pode levar semanas.
Organizações que não monitoram seu comportamento de envio não têm visibilidade sobre se sua conta ESP está sendo usada por outra pessoa até que os provedores de caixa de entrada comecem a adiar ou rejeitar seus próprios e-mails legítimos. Os relatórios agregados de DMARC podem não detectar isso se o envio não autorizado estiver passando na autenticação, porque os relatórios agregados contabilizam taxas de aprovação e reprovação de autenticação em vez de detectar comportamento anômalo dentro do tráfego aprovado.
O Que Sites Usando Gravity SMTP Precisam Fazer
Atualize o plugin imediatamente. A vulnerabilidade existe em versões específicas do Gravity SMTP anteriores ao lançamento com correção. Qualquer site WordPress executando uma versão afetada está exposto independentemente de outras configurações de segurança. As atualizações de plugins do WordPress estão disponíveis pelo painel de administração padrão do WordPress.
Rotacione todas as chaves de API. Mesmo sem evidências de exploração, qualquer site que tenha executado uma versão vulnerável enquanto estava publicamente acessível deve tratar suas credenciais ESP armazenadas como comprometidas e rotacioná-las. A maioria dos provedores de serviços de e-mail permite a rotação de credenciais sem interrupção do serviço: novas chaves podem ser emitidas, configuradas e testadas antes que as antigas sejam revogadas.
Audite os registros de atividade da sua conta ESP. Todos os principais provedores de serviços de e-mail mantêm registros de atividade que registram eventos de envio, chamadas de API e eventos de autenticação por credencial. Após rotacionar as credenciais, revise o registro de atividade do período anterior. Padrões de envio incomuns, listas de destinatários inesperadas ou eventos de envio em momentos em que seu site não estava gerando e-mail ativamente são indicadores de uso indevido de credenciais.
Revise seus relatórios agregados de DMARC em busca de anomalias de volume. Mesmo quando o envio baseado em credenciais passa na autenticação DMARC, os relatórios agregados mostram o volume total de envio por fonte. Um pico no volume de envio autenticado do seu ESP que não corresponde a uma campanha conhecida ou a um evento operacional é um sinal que vale investigar, mesmo que o status de autenticação mostre 100% de aprovação.
Considere separar as credenciais de notificação do site das credenciais de marketing. Uma configuração comum coloca todos os e-mails gerados pelo site – confirmações de pedido, redefinições de senha, notificações de administração – pela mesma conta ESP que as campanhas de marketing. Separar esses em chaves de API distintas limita o raio de explosão de um comprometimento de credenciais: as credenciais roubadas do plugin não expõem automaticamente as credenciais usadas para envios de marketing de alto volume, e vice-versa.
O Problema Mais Amplo da Cadeia de Suprimento de Credenciais
O CVE-2026-4020 é uma instância de um padrão que se repete em todo o ecossistema de ferramentas que as organizações usam para gerenciar o envio de e-mail. Plugins do WordPress, integrações de CRM, plataformas de automação de marketing e ferramentas de suporte ao cliente frequentemente armazenam credenciais de ESP em tabelas de banco de dados ou arquivos de configuração acessíveis por meio de vulnerabilidades na camada de aplicação.
A aplicação do DMARC protege contra partes externas que tentam enviar e-mail alegando ser do seu domínio sem qualquer acesso à sua infraestrutura. Ela não fornece nenhuma proteção contra um atacante que obtém acesso às credenciais de aplicação que autorizam o envio por essa infraestrutura. As duas categorias de ameaças requerem defesas diferentes, e ambas estão ativas.
Para organizações que operam sites WordPress intensivos em e-mail – lojas de e-commerce, produtos SaaS, plataformas de associação – a camada de credenciais é a superfície de ataque que os registros de autenticação no DNS não conseguem proteger. Auditorias periódicas do que está armazenado na sua instalação WordPress, onde é usado e se segue princípios de mínimo privilégio são o controle que preenche a lacuna deixada pelo DMARC.
O Excello Mail oferece visibilidade contínua dos seus relatórios agregados de DMARC, fontes de envio e tendências de volume em todos os seus fluxos de e-mail. Cadastre-se gratuitamente no Excello Mail e saiba imediatamente quando algo envia a partir do seu domínio sem que deveria.