skrkcb2/cve-2025-0924-differentAnálise técnica da CVE-2025-0924, uma vulnerabilidade de XSS Armazenado no plugin WP Activity Log para WordPress. Inclui análise da causa raiz, demonstração de exploração e orientações de remediação.
Stored XSS é uma vulnerabilidade em que um script malicioso é armazenado no servidor e executado automaticamente quando outros usuários abrem a página posteriormente; é um tipo de ataque classificado como CWE-79 (Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')).
O WordPress é o sistema de gerenciamento de conteúdo (CMS) de código aberto mais popular do mundo, permitindo criar e gerenciar facilmente sites e blogs. Os usuários podem expandir e personalizar o site por meio de vários plugins e temas, mesmo sem conhecimento de código.
O WP Activity Log é um plugin que rastreia e registra as atividades administrativas de sites WordPress. Ele é útil para administradores monitorarem em tempo real diversos eventos que ocorrem no site e fornece logs para auditoria de segurança e solução de problemas.
O CVE-2025-0924 ocorre no plugin WP Activity Log (versões iguais ou anteriores à 5.2.2) devido à falta de validação de entrada e à ausência de escape de saída no parâmetro 'message'. Pretendemos examinar como essa vulnerabilidade ocorre e buscar medidas de mitigação correspondentes.
No WordPress, quando um usuário copia e cola um script malicioso no título do site e essa alteração é registrada no log pelo WP Activity Log 5.2.2, ocorre um ataque de Stored XSS. Vamos examinar um exemplo para entender como o Stored XSS é desencadeado usando o WP Activity Log.
[Figura 1] Criação de post no WordPress, inserção de script no DB
Como visto na [Figura 1], inicialmente é criado um post para gerar o log. Nesse processo, dois posts são escritos: um é digitado diretamente e o outro é inserido por meio de copiar e colar.Ao verificar o banco de dados após a criação do post, no caso do post copiado e colado, é possível observar que o valor do campo post_title é armazenado sem ser adequadamente sanitizado (limpeza e filtragem dos valores de entrada).
Isso sugere a possibilidade de os dados serem tratados de forma diferente dependendo do método de entrada, o que pode ser uma causa para o surgimento da vulnerabilidade de XSS (cross-site scripting).
[Figura 2] Geração de log do WP Activity Log e verificação do ataque
O histórico do post criado na [Figura 1] permanece no log do WP Activity Log; ao buscar as informações no banco de dados e solicitar More details..., é possível ver a execução do script da [Figura 2]. 
[Figura 3] class-list-events.php - retorno de More details...
Como pode ser visto na [Figura 3], More details... recebe AjaxInspector (ajax callback function / get metadata), occurrence e produz a saída do resultado. 
[Figura 4] AuditLog.php -> AjaxInspector() - sem sanitização
[Figura 4] metadata sample
O AjaxInspector da [Figura 4], visto na [Figura 3], gera o resultado por meio do metadata da [Figura 5] e finaliza retornando as variáveis sem sanitizá-las, o que causa a vulnerabilidade.Até agora, analisamos o Stored XSS por meio do WP Activity Log, um plugin de log de segurança do WordPress. Esse caso ocorre sempre que o usuário consegue inserir conteúdo de script na criação de páginas e nos logs. Como medida de mitigação, sugerimos atualizar o WP Activity Log da versão 5.2.2 ou superior para a 5.3.0.
[Figura 5] Alterações no AjaxInspector / adição de esc_html()
Neste caso, o problema parece ter ocorrido porque esc_html() não foi usado para sanitizar adequadamente o HTML retornado. No entanto, ainda não estou certo se esta análise corresponde exatamente à vulnerabilidade descrita no CVE-2025-0924.
Atualmente, realizei testes após atualizar para a versão 5.3.0 e confirmei que a correção foi aplicada. No entanto, a vulnerabilidade descrita no CVE-2025-0924 ocorre por meio de Stored Cross-Site Scripting via o parâmetro ##message## e especifica class-alert.php e class-alert-manager.php como caminhos. Já na minha análise atual, o problema está no metadata, e não no parâmetro message, e os arquivos PHP problemáticos no processo são class-list-events.php e AuditLog.php. Portanto, tudo exceto Stored Cross-Site Scripting difere da descrição do NIST. Assim, é necessário verificar adicionalmente se há correspondência exata.
