Auditando o WordPress? Comece pelos seus plugins

Summary

A maioria das auditorias de segurança do WordPress está ao contrário: elas enfatizam atualizações do núcleo e relatórios de scanners, enquanto as vulnerabilidades que realmente afetam vivem nos plugins. Um whitepaper da SANS descobriu que mais de 96% das vulnerabilidades do ecossistema se originam em plugins de terceiros, e cerca de 43% não exigem autenticação. Este artigo apresenta uma auditoria com foco em plugins para uma pequena equipe de marketing interna, usando a história de um site que foi hackeado porque todos estavam escaneando a camada errada. Você aprenderá a inventariar e classificar cada plugin, testar superfícies de ataque não autenticadas, revisar manualmente usuários e logs e traduzir descobertas em uma linguagem de risco que um chefe não técnico entenda. O resultado é um ritual trimestral de triagem em vez de um exercício de caixa de seleção.

A maioria das auditorias de segurança do WordPress é teatro. Você passa uma tarde atualizando o núcleo, alterando a senha do administrador e executando um scanner de plugins que relata orgulhosamente: "Nenhum problema crítico." Enquanto isso, o plugin que aceitava uploads de arquivos e foi atualizado pela última vez há três anos fica quieto no seu diretório de uploads, esperando por alguém que não está na lista de convidados.

Os números confirmam isso. Um whitepaper da SANS sobre a verificação de plugins do WordPress descobriu que mais de 96% das vulnerabilidades no ecossistema do WordPress se originam em plugins de terceiros, com temas em 4% e o núcleo em menos de 1%. Aproximadamente 43% dessas falhas podem ser exploradas sem qualquer autenticação. Então, quando sua auditoria gasta a maior parte da energia no núcleo, você está examinando as árvores enquanto um incêndio florestal começa no diretório de plugins ao lado.

Este não é um chamado para entrar em pânico com o núcleo. Vulnerabilidades do núcleo, como as falhas de RCE do wp2shell que ganharam exploits públicos recentemente, devem ser corrigidas no dia em que são anunciadas. Mas elas são raras o suficiente para não merecerem a maior parte das suas horas de auditoria. A maior parte pertence aos plugins, e é aí que o fluxo de trabalho real começa.

Imagine o cenário anterior: numa manhã de domingo, seu site redireciona para uma página de cassino, e seu chefe envia um e-mail: "Eu pensei que tínhamos segurança." Vocês tinham segurança — vocês tinham uma auditoria de caixa de seleção. O cenário posterior é um sistema de triagem que trata os plugins como a superfície de ataque que eles realmente são, testa-os de fora e verifica o que os scanners não conseguem ver.

Você está em uma pequena equipe de marketing com um site WordPress que está no ar desde 2017. Ele tem um plugin personalizado de registro de eventos que um freelancer construiu em 2019, um plugin de formulário de contato com um campo de upload de arquivo e um plugin de slider que foi vendido e não tem mais uma página pública de atualizações. Essa não é uma combinação incomum. É daqui que sua auditoria começa.

---

O inventário de plugins é sua política de segurança

Faça um inventário de cada plugin e tema. Anote a versão, a data da última atualização, se o fornecedor ainda está ativo e se alguém realmente usa. Em seguida, classifique cada um em uma categoria: mantido e usado, mantido e não usado, abandonado mas usado, abandonado e não usado. Remova os não usados imediatamente. Ignore a defesa "é só US$ 50/mês" — um plugin não usado é um passivo, não um recurso. Para os abandonados, mas usados, decida: substitua-o ou aceite o risco e anote em um registro de riscos que seu chefe já viu.

O plugin de registro de eventos se enquadra na categoria abandonado, mas usado. Ele processa pagamentos e envia e-mails de confirmação, e substituí-lo é um projeto, então você o mantém por enquanto. Mas você escreve uma nota que diz: "esta é a fonte mais provável de uma futura violação" e o adiciona ao topo da lista de testes.

Superfície de ataque	Participação nas vulnerabilidades conhecidas do WordPress	Prioridade de auditoria
Plugins de terceiros	Mais de 96%	Mais alta — inventariar, verificar, testar, substituir
Temas	Cerca de 4%	Média — apenas se personalizados ou desatualizados
Núcleo do WordPress	Menos de 1%	Baixa — mantenha corrigido, siga em frente

Quando a SecurityWeek contabilizou mais de 8.000 novas vulnerabilidades do WordPress em 2024, a grande maioria era desse tipo: problemas de plugins, não correções do núcleo. Um scanner informará sobre aquelas que foram divulgadas e receberam um CVE. Ele não informará sobre o código personalizado de freelancer sem CVE, porque ninguém nunca o examinou cuidadosamente. Essa análise manual é seu trabalho. Para um passo a passo mais aprofundado sobre verificações específicas de plugins, consulte este guia sobre auditoria de plugins do WordPress para vulnerabilidades.

---

Teste como um estranho: os 43% que não precisam de senha

Seu scanner já informou que não há nada errado. Agora faça o que ele não pode: sonda o site de fora, sem login. Comece com cada campo de upload de arquivo, cada formulário que processa um POST, cada endpoint admin-ajax. O upload realmente verifica o conteúdo do arquivo ou apenas a extensão? Onde os arquivos enviados são armazenados e o servidor web pode executar PHP nesse diretório? Os 43% das falhas de plugins que não exigem autenticação geralmente estão exatamente nesses lugares: XSS armazenado não autenticado, upload arbitrário de arquivo e injeção de objeto PHP.

O plugin de formulário de contato permite que os visitantes anexem um currículo. Ele renomeia o arquivo usando o nome original do visitante, então você envia "resume.php" e ele o salva em uma pasta /uploads/contact/ que é gravável por padrão. Se o servidor também permitir executar PHP nesse diretório, o invasor acaba de obter um webshell. A Fastly documentou exploração ativa de XSS armazenado não autenticado em plugins do WordPress — isso não é um risco de apresentação de slides. Seu teste é simples: crie um arquivo com conteúdo conhecido, envie-o e veja se ele retorna com o nome e o tipo originais. Depois, tente enviar um arquivo .php. Se ele retornar como .php, você acabou de encontrar uma brecha explorável.

É também aqui que o argumento "mas nosso plugin de segurança tem um WAF" não se sustenta. Um WAF pode bloquear um payload conhecido, mas as regras de normalização de caminho em que ele se baseia muitas vezes divergem do que o servidor realmente faz. O Guia de Testes de Segurança Web da OWASP é uma referência melhor do que qualquer painel: ele descreve como testar falhas de upload de arquivo e XSS armazenado de maneira metódica. E se você descobrir que o plugin está abandonado, é hora de aplicar o protocolo de limpeza: o perigo oculto de plugins do WordPress abandonados explica por que deixar uma extensão morta no lugar é pior do que removê-la e ajustar seu fluxo de trabalho.

---

O que o scanner não vê: usuários, logs e código antigo

Os testes dinâmicos captam o que está exposto agora. A revisão manual capta o que já está dentro. Comece pelas contas de usuário: abra a lista de administradores e procure por contas que você não criou. Um administrador chamado "support" com um endereço de e-mail gratuito e nenhum humano por trás é uma backdoor, não um colega. Verifique os timestamps dos arquivos em wp-content/uploads para qualquer coisa modificada recentemente que não seja seu conteúdo. Verifique o log de acesso do servidor para solicitações que parecem um comando curl de bot, em vez do navegador de uma pessoa.

O plugin de eventos tem um upload de "foto do palestrante" que salva em uploads/event-headshots/. Durante o teste, você encontra um arquivo que não é seu — um pequeno arquivo PHP com um nome de aparência aleatória. Esse é o seu webshell. Ele chegou lá pela mesma falha de upload que você testou duas semanas atrás e, a essa altura, um scanner ainda não o "veria", porque não é uma vulnerabilidade de plugin; é uma evidência de uma. A revisão manual o encontra, exclui e verifica o log para o endereço de IP que o colocou lá. A Invicti observou que a injeção de objeto PHP em plugins está aumentando e é quase invisível para varreduras de caixa-preta, pois o objeto malicioso só se materializa durante a execução. A única maneira de detectá-lo é ler o código em busca de padrões perigosos, como chamar unserialize() em entrada fornecida pelo usuário. Ler algumas centenas de linhas do plugin personalizado é mais barato do que pagar uma assessoria de resposta a incidentes.

É também aqui que o conselho padrão de "apenas instale mais plugins de segurança" chega ao seu limite. Empilhar três plugins de segurança gera regras de WAF sobrepostas que se bloqueiam umas às outras, uma enxurrada de e-mails de log duplicados e o ocasional erro "você foi banido" no seu próprio login de administrador. Um único plugin de segurança ativo, bem configurado, é suficiente. Leia sobre por que plugins de segurança demais saem pela culatra antes de adicionar qualquer coisa à pilha.

---

Dizendo a verdade ao seu chefe sem causar pânico

Seu chefe não se importa com pontuações CVSS ou injeção de objeto PHP. Ele se importa com o site fora do ar, a loja não recebendo pedidos e o orçamento de TI. A tradução é simples: "Este plugin tem uma falha conhecida de execução remota de código não autenticada. Um estranho pode excluir o conteúdo do nosso site ou instalar uma backdoor. Precisamos substituí-lo neste trimestre." Em seguida, mostre a lista de prioridades: substituir o plugin de eventos, desativar o upload de arquivos do formulário de contato até que ele valide corretamente os tipos de arquivo, trocar todas as credenciais de administrador e agendar a próxima revisão trimestral.

Você também tem uma vantagem de linguagem: a CISA mantém o catálogo Known Exploited Vulnerabilities, que informa exatamente quais falhas publicadas estão sendo ativamente exploradas na natureza. Se algum dos seus plugins aparecer lá, o argumento deixa de ser teórico — existe um exploit conhecido e você está contra o relógio. Se não aparecerem, use-o mesmo assim como padrão para o que "urgente" significa. O rastreamento da CISA facilita convencer um chefe não técnico de que isso não é um e-mail de phishing; é um banco de dados público do que os invasores estão fazendo agora. Quando o trimestre terminar, você terá um fluxo de trabalho de correção, não um exercício único de caixa de seleção. Um fluxo de trabalho para transformar vulnerabilidades em um ciclo de correção mantém o hábito vivo.

---

O antes era um site quebrado, um e-mail frenético e um relatório limpo do scanner que dizia que nada estava errado. O depois é um ritual trimestral: inventariar, classificar, testar de fora, revisar usuários e logs e anotar as decisões que você tomou e os riscos que aceitou. O scanner se torna um mapa de onde olhar, não um certificado de saúde. Os plugins se tornam uma lista que você conhece pelo nome. E na próxima vez que seu chefe perguntar sobre a auditoria, você terá uma resposta que não envolve cruzar os dedos.