O bug

duplicate_meta_entries() em classes/clone-handler.php copia as linhas de metadados do post para um post clonado usando um INSERT em massa feito à mão. Ela busca as linhas com segurança usando $wpdb->prepare(), mas depois insere $entry->meta_key diretamente na string SQL sem escape:

Como meta_key vem do banco de dados, o código o trata como confiável. Mas usuários com a função Contributor podem definir nomes de campos arbitrários pelo painel de Campos Personalizados — então eles controlam o que está nessa coluna.

O ataque tem duas etapas:

1. Gravar: armazenar uma string maliciosa como nome de campo personalizado. add_post_meta() lida com isso com segurança — o payload chega ao banco de dados sem executar nada.
2. Acionar: clicar em Happy Clone. duplicate_meta_entries() lê a chave novamente e a concatena no INSERT bruto. O MySQL executa a subconsulta injetada.

A análise estática não detecta isso porque a fonte dos dados perigosos é uma leitura do banco de dados ($wpdb->get_results()), que os mecanismos de taint marcam como saneada. A fronteira de armazenamento quebra a cadeia de taint.

Impacto

Qualquer Contributor pode extrair:

• Hashes de senha de todos os usuários (quebráveis offline — modo 400 do hashcat)
• Chaves secretas / sais do WordPress (forjar cookies de autenticação persistentes)
• Qualquer linha de wp_options (chaves de API, credenciais de pagamento)
• Conteúdo de posts privados

Mais de 400 mil instalações ativas foram afetadas no momento da divulgação.

Uso

O script autentica via HTTP, armazena o payload de injeção como um nome de campo personalizado, aciona a ação Happy Clone e lê o hash vazado dos campos de metadados do post clonado. A saída é salva em hash.txt.

Writeup completo

https://folks-iwd.github.io/writeups/cve-2025-68999.html

Linha do tempo da divulgação

A correção

A weDevs substituiu todo o INSERT feito à mão por:

update_post_meta() internamente chama $wpdb->update() com prepared statements tanto para a chave quanto para o valor.