Uma vulnerabilidade recém-divulgada no Kirki, um framework de personalização para WordPress instalado em mais de 500 mil sites, permite que um atacante não autenticado envie e-mails de phishing pelo próprio servidor de correio do site. Sem credenciais roubadas, sem remetente falsificado, sem nenhum serviço de envio de terceiros para abusar. A mensagem é gerada e enviada pelo próprio site legítimo, o que significa que ela herda o alinhamento SPF real desse site, sua assinatura DKIM real e um DMARC aprovado, porque nada na camada de autenticação está sendo enganado. O e-mail realmente veio de onde diz que veio.
O Que o CVE-2026-12472 Faz Exatamente
O Kirki fornece a experiência de “Customizer” que muitos temas do WordPress usam para controles de design com pré-visualização ao vivo, e inclui um recurso de notificações que envia e-mails aos usuários do site por meio de elementos de interface que o plugin chama de “chips”. A falha, registrada como CVE-2026-12472, é um bypass de autorização: o plugin não verifica se a requisição que dispara um desses e-mails vem de alguém autorizado a enviá-lo. Em todas as versões até a 6.0.11 inclusive, um atacante não autenticado pode chamar diretamente o endpoint subjacente e controlar tanto o assunto quanto o corpo da mensagem resultante.
A linha de assunto passa por sanitize_text_field(), um filtro fraco que remove parte da formatação, mas não faz nada para impedir um texto de engenharia social convincente. O corpo é pior: os itens “text” dentro de emailBody são concatenados diretamente no HTML do e-mail sem nenhum escape, dando ao atacante injeção de HTML sem filtro dentro de uma mensagem que o próprio site do destinatário está prestes a enviar a ele. Mais grave ainda, os itens “chip” nesse mesmo corpo podem incluir um link de redefinição de senha do WordPress genuíno e válido para a conta específica que o atacante escolher como alvo. O resultado é um e-mail de phishing que se parece, se autentica e funciona exatamente como uma notificação real de redefinição de senha de um site em que o destinatário já confia, porque de fato é.
Um Tipo de Falha Diferente do Roubo de Credenciais
Quem acompanha este blog deve se lembrar da nossa cobertura do CVE-2026-4020 no plugin Gravity SMTP no mês passado, em que atacantes extraíam as chaves de API do provedor de e-mail armazenadas em um site e enviavam correio pela própria conta de ESP da vítima. Aquele era um problema de roubo de credenciais: o atacante obtinha chaves reais e usava infraestrutura real que não era dele.
O CVE-2026-12472 é um animal diferente. Não há nenhuma credencial para roubar, porque o atacante nunca precisa de uma. O caminho de código vulnerável faz parte da própria lógica de aplicação do site, rodando no próprio servidor do site, chamando a própria função wp_mail() do site exatamente como faria para uma solicitação legítima de redefinição de senha. A única coisa que falha é a verificação de autorização que deveria ter confirmado que a solicitação era permitida em primeiro lugar. Tudo o que acontece depois dessa verificação ausente, o transporte de correio, a assinatura DKIM, o IP de envio alinhado ao SPF, é completamente legítimo. É exatamente isso que torna a falha perigosa.
Onde o DMARC Não Tem Nada a Acrescentar
Este caso traça o limite do escopo do DMARC com mais clareza do que a maioria. DMARC, SPF e DKIM existem para responder a uma única pergunta: esta mensagem passou por uma infraestrutura que o dono do domínio autorizou a enviar em seu nome? Para uma mensagem gerada pelo CVE-2026-12472, a resposta honesta é sim. O servidor de correio real do domínio a enviou. A chave DKIM real do domínio a assinou. O registro SPF real do domínio cobre o IP de envio. Um provedor de caixa de entrada que avaliar essa mensagem contra a política DMARC do domínio vai registrar aprovação, porque, por todas as métricas que o DMARC verifica, a mensagem se qualifica como legítima.
Os relatórios agregados do DMARC também não vão sinalizar isso. Os relatórios agregados resumem as taxas de aprovação e falha de autenticação por fonte de envio; eles não dizem nada sobre se o conteúdo de uma mensagem aprovada foi autorizado pelo dono do site ou injetado por um atacante anônimo explorando uma verificação de permissão quebrada. Um domínio pode estar em p=reject com um histórico de autenticação perfeito e ainda assim entregar um e-mail de phishing a um cliente real, porque a vulnerabilidade está na lógica da aplicação, algo que o DMARC nunca foi projetado para inspecionar.
O Que os Donos de Sites Precisam Fazer
Atualize o Kirki agora. O bypass de autorização está corrigido na versão atual; qualquer site rodando a 6.0.11 ou anterior está exposto. Como o Kirki também teve uma falha crítica de tomada de conta sem autenticação (CVE-2026-8206, CVSS 9,8, corrigida na 6.0.7) e um problema separado de SSRF sem autenticação corrigido na 6.0.12, sites que não foram atualizados recentemente provavelmente carregam mais de uma exposição ativa ao mesmo tempo.
Verifique seu histórico de atualizações, não apenas a versão atual. Cerca de 150 mil das mais de 500 mil instalações do Kirki ainda rodavam código vulnerável quando a falha de tomada de conta foi divulgada em junho. Um plugin tão amplamente implantado, com uma cadência de patches críticos sucessivos, é um forte candidato a atualizações automáticas em vez de ciclos de revisão manual que acabam atrasando.
Audite os registros de e-mail de saída em busca de tráfego anômalo de redefinição de senha. Como esse abuso passa em todas as verificações de autenticação, a detecção baseada em registros precisa olhar para o comportamento em vez disso: e-mails de redefinição disparados sem uma solicitação correspondente do dono da conta, rajadas incomuns de e-mail de saída de um único site em uma janela curta, ou links de redefinição gerados para contas que nunca pediram isso.
Trate o código de plugins que envia e-mail como parte da sua superfície de ataque. Qualquer plugin do WordPress que chame wp_mail() em nome de um usuário, seja para notificações, redefinições de senha ou gatilhos de marketing, é um canal potencial para exatamente esse padrão. Revisar quais plugins podem gerar e-mail de saída, e confirmar que cada um verifica corretamente a autorização antes de fazer isso, fecha uma categoria de vulnerabilidade que a aplicação do DMARC sozinha não consegue alcançar.
A Conclusão
A aplicação total do DMARC continua sendo a base correta para todo domínio, e ela ainda impede o caso muito mais comum de um estranho falsificando seu cabeçalho From sem nenhum acesso aos seus sistemas. Mas o CVE-2026-12472 é um lembrete de que passar na autenticação não é o mesmo que uma mensagem ser confiável. Quando a vulnerabilidade está dentro da própria aplicação autorizada a enviar, o DMARC vai deixar o phishing resultante passar direto, e quem defende precisa olhar para o que disparou o envio, não apenas de onde ele veio.
A Excello Mail oferece visibilidade contínua sobre seus relatórios agregados de DMARC e suas fontes de envio, para que você veja exatamente o que está se autenticando como seu domínio e aja rápido quando algo parecer errado. Cadastre-se gratuitamente na Excello Mail para manter essa visibilidade enquanto sua equipe fecha brechas como essa.