CVE-2016-10033

Falha de injeção de argumentos (CWE-88) na função mailSend() do transporte isMail() do PHPMailer, presente em todas as versões antes da 5.2.18. Permite que um atacante não autenticado, ao controlar o campo 'From' de um formulário (contato, cadastro, reset de senha), injete parâmetros no comando sendmail invocado pela função mail() do PHP e escreva um arquivo com conteúdo parcialmente controlado em local arbitrário do servidor — na prática, um webshell na raiz web. O CVSS 9.8 é justificado quando as pré-condições de uso (transporte isMail, From vindo de input do usuário, Sender não definido explicitamente, servidor sendmail/exim e não postfix) estão presentes, o que é comum em formulários de contato mal escritos, mas não é universal.

Quando a propriedade Sender do PHPMailer não é definida explicitamente, a biblioteca a copia automaticamente do endereço 'From'. Esse valor é então incorporado a uma string prefixada com '-f' e passada ao parâmetro $additional_parameters da função mail() do PHP, que por sua vez invoca o binário sendmail (ou compatível) via shell. O PHPMailer validava o endereço de e-mail antes de aceitá-lo, mas a validação de RFC para endereços de e-mail é permissiva o suficiente para admitir um endereço que, embora tecnicamente válido, também constitui um argumento de linha de comando executável quando interpretado pelo shell — a descrição oficial cita especificamente o uso de um backslash seguido de aspas duplas (\") dentro do Sender para escapar do contexto de endereço e injetar conteúdo adicional na chamada ao sendmail.

O problema raiz é a mistura de dois contextos incompatíveis: uma string que precisa ser simultaneamente um e-mail RFC-válido e segura para uso como argumento de shell. Não há como sanitizar isso de forma completamente segura só validando formato de e-mail.

A correção inicial na 5.2.18 usou escapeshellarg() sobre o endereço antes de passá-lo ao mail(). Isso, porém, gerou um segundo problema (CVE-2016-10045, 'Act II'): a documentação do PHP afirma que mail() aplica escapeshellcmd() internamente ao comando gerado, e o encadeamento escapeshellcmd(escapeshellarg($address)) pode, com um endereço malicioso específico, quebrar o escaping e permitir novamente a execução de comando. Essa segunda falha foi corrigida na 5.2.20, com limpeza adicional na 5.2.21, restringindo mais severamente os caracteres aceitos no endereço do remetente — abandonando parte da conformidade estrita com RFC em favor de segurança.

O vetor típico é qualquer formulário público (contato, feedback, cadastro, recuperação de senha) que instancia o PHPMailer com o transporte padrão isMail() e faz algo como $mail->setFrom($_POST['email']) — ou seja, usa entrada do usuário diretamente como endereço de remetente sem validação adicional além da do próprio PHPMailer. Não é necessária autenticação: o atacante só precisa enviar uma requisição HTTP ao endpoint que dispara o e-mail.

Com um valor malicioso no campo de e-mail (usando o backslash+aspas para escapar do contexto), o atacante injeta argumentos extras no comando sendmail — o PoC público e o módulo Metasploit exploram isso para forçar a escrita de um arquivo com conteúdo parcialmente controlado (o corpo/payload do e-mail) em um caminho arbitrário dentro do web root. Requer que o processo PHP tenha permissão de escrita no diretório alvo, e o módulo Metasploit documenta que a exploração completa pode levar alguns minutos, já que depende do agendamento e envio real do e-mail pelo servidor. Uma vez escrito o arquivo (ex.: um script PHP) no web root, uma segunda requisição HTTP o executa, resultando em execução de código arbitrário no contexto do usuário do servidor web.

A falha está no catálogo KEV da CISA (exploração confirmada em ambiente real) e possui módulo Metasploit e template Nuclei públicos, o que reduz drasticamente a barreira técnica — a existência de PoC completo praticamente elimina a necessidade de conhecimento avançado para explorar instalações vulneráveis expostas.

Atualizar para PHPMailer 5.2.18 ou superior é o mínimo. Como a correção de 5.2.18 introduziu a falha relacionada CVE-2016-10045, a recomendação efetiva é atualizar para 5.2.20 ou 5.2.21 (ou versões mais recentes da linha 5.x/6.x), que corrigem ambas. Verificar a versão embutida em CMSs e plugins (WordPress, Drupal, Joomla, SugarCRM, Yii e outros empacotam PHPMailer internamente) — atualizar o CMS não necessariamente atualiza a biblioteca vendorizada, é preciso checar a versão do PHPMailer especificamente.

Se não for possível atualizar imediatamente, o paliativo real é eliminar a pré-condição: nunca definir o 'From' a partir de entrada não confiável do usuário. A prática correta, segundo os próprios mantenedores, é usar um endereço 'From' fixo do domínio da aplicação e colocar o endereço fornecido pelo usuário em addReplyTo() — esse valor passa pela mesma validação, mas não é usado na construção do parâmetro -f do mail(). Trocar o transporte de isMail() para isSMTP() também elimina o vetor, já que o transporte SMTP não invoca shell/sendmail. Usar postfix como MTA reduz o risco porque ele não suporta a flag -X do sendmail necessária para a escrita de arquivo controlado, mas os próprios mantenedores alertam que isso não deve ser tratado como mitigação confiável, pois outras variantes de exploração podem contornar essa limitação.

Não funciona como mitigação: apenas trocar de CMS ou confiar em WAF genérico para filtrar caracteres de e-mail — a superfície de validação é do lado do endereço, não do payload HTTP, e regras de WAF tendem a gerar falsos positivos ou serem contornáveis por variações de encoding do endereço.

Em logs de aplicação/formulário, procurar submissões com caracteres incomuns no campo de e-mail — em especial sequências de backslash seguido de aspas duplas (\") ou outros metacaracteres de shell fora do padrão normal de endereço de e-mail. Em logs do servidor web, verificar criação inesperada de arquivos no document root (novos arquivos .php ou similares) próximos no tempo a submissões de formulário de contato/cadastro. Em nível de sistema, monitorar invocações do binário sendmail/exim com argumentos anômalos ou flags como -X originadas do processo do servidor web (Apache, PHP-FPM etc.), e alertas de EDR/AV para escrita de shell PHP no web root.

Não há assinatura de rede confiável e única, já que o payload varia por PoC e o tráfego é uma submissão HTTP POST comum a um formulário legítimo — o sinal mais forte é comportamental (arquivo novo executável aparecendo no web root após submissão de formulário), não uma string fixa em requisição.