Você replicou o mesmo tema em cinco clientes e, semanas depois, um deles aparece com redirecionamento estranho. O tema é o mesmo em todos. Antes de culpar o plugin, olhe para o pacote que você instalou: a segurança do tema WordPress é a camada que quase ninguém audita, porque o tema “é só o visual”. Não é. O tema roda código PHP com os mesmos privilégios do core, e um único functions.php mal escrito abre porta para injeção, upload indevido e execução remota.
Aqui a ordem de verificação é do tema, não do site. Origem do pacote, funções de escape na saída, uso de eval e base64, chamadas de admin-ajax sem nonce e scripts carregados de CDN externa. Depois, o recorte de quem replica: o que se checa uma vez no tema-base e o que precisa ser rechecado em cada site.
Por que a segurança do tema WordPress é o elo esquecido
Plugins têm tela de atualização, aviso de vulnerabilidade e changelog. Tema costuma ser instalado uma vez e esquecido. Por isso, um tema WordPress vulnerável pode ficar anos no ar sem ninguém notar. Além disso, tema pago comprado em site de terceiros, o famoso nulled, é o vetor mais comum de backdoor em sites pequenos. O pacote vem com o código original mais uma linha a mais, geralmente ofuscada.
Quando você replica o mesmo tema em vários clientes, o problema se multiplica. Uma falha no tema-base vira cinco sites comprometidos na mesma semana. Por isso a revisão de segurança do tema WordPress precisa acontecer antes da replicação, não depois do incidente.
Ordem de verificação do próprio tema
Siga esta sequência. Ela vai do mais fácil de checar ao mais profundo, e cada etapa elimina um tipo de risco.
1. Origem do pacote
Antes de qualquer análise de código, confirme de onde veio o arquivo. Baixe direto do repositório oficial ou do site do desenvolvedor, com licença e nota fiscal. Se o tema é pago e você recebeu por grupo de Telegram, pasta compartilhada ou site de “download grátis”, trate como comprometido até prova em contrário.
Um teste rápido: compare o style.css do pacote com o do repositório oficial. Diferença de versão, autor ou Theme URI é sinal de pacote alterado. Na prática, tema nulled costuma vir com uma versão levemente acima da oficial, para parecer atualizado.
2. Escape na saída
Abra o tema e procure por echo e print que imprimem variável direto, sem função de escape. O correto é usar esc_html(), esc_attr(), esc_url() ou wp_kses_post() na saída. Sem isso, qualquer campo que o usuário controla (comentário, título de post, parâmetro de URL) pode injetar HTML e script.
O padrão que denuncia problema é este:
echo $_GET['msg'];
O correto seria echo esc_html( $_GET['msg'] );. A documentação oficial do WordPress explica cada função de escape e quando usar: developer.wordpress.org/apis/security/. Vale ler antes de revisar, porque a lista é longa e o contexto importa.
3. eval, base64 e ofuscação
Procure por eval(, base64_decode(, gzinflate(, str_rot13( e create_function(. Tema legítimo quase nunca usa isso. Quando usa, geralmente é para esconder código malicioso. Um bloco de string longa em base64 dentro do functions.php é o padrão clássico de backdoor.
Se encontrar, não apague na hora. Copie o arquivo, decodifique em ambiente isolado e veja o que o código faz. Só depois remova. Apagar sem entender pode deixar um gancho ativo em outro arquivo.
4. admin-ajax sem nonce
Funções registradas em wp_ajax_ e wp_ajax_nopriv_ são acessíveis por qualquer visitante. Se o tema registra uma ação que grava opção, cria usuário ou envia e-mail sem verificar nonce, você tem um vetor de abuso direto. O padrão correto é check_ajax_referer() ou wp_verify_nonce() no início do callback.
Procure por add_action( 'wp_ajax_nopriv_ no tema. Cada ocorrência merece leitura do callback. Se não houver verificação de nonce e a ação altera dados, é falha grave.
5. Scripts de CDN externa
Tema que carrega jQuery, Font Awesome ou qualquer biblioteca de CDN sem versão fixa e sem integrity aceita o que o CDN entregar. Se o CDN for comprometido ou o domínio expirar, o script que roda no seu site é outro. Prefira os scripts já empacotados no core do WordPress ou hospede localmente.
Verifique também se o tema enfileira scripts com wp_enqueue_script() ou se injeta <script> direto no header.php. O segundo caso dificulta controle e cache.
O que checar uma vez e o que rechecar em cada site
Quem replica tema em vários clientes precisa separar o que é auditoria de tema-base do que é auditoria de site. Misturar os dois faz você refazer trabalho ou, pior, deixar passar algo específico.
| Item | Frequência | Por quê |
|---|---|---|
| Origem do pacote | Uma vez, no tema-base | O arquivo é o mesmo em todos os sites |
| eval, base64, ofuscação | Uma vez, no tema-base | Código malicioso no pacote afeta todos |
| Escape na saída | Uma vez, no tema-base | Falha estrutural do tema, não do site |
| admin-ajax sem nonce | Uma vez, no tema-base | Registro é do tema, não do site |
| CDN externa | Uma vez, no tema-base | Dependência declarada no tema |
| functions.php do child | A cada site | Cada cliente tem customização própria |
| Plugins que estendem o tema | A cada site | Combinação varia por projeto |
| Usuários com permissão de editar tema | A cada site | Quem pode editar código muda por cliente |
O ponto crítico é o functions.php do child. Ele roda depois do tema pai e pode reabrir um buraco que o pai já tinha fechado. Por exemplo: o tema-base usa esc_html() em um campo, e o child sobrescreve o template com echo direto. A auditoria do tema-base passou, mas o site continua exposto. Por isso, revisar tema antes de instalar não termina no pacote: termina no child de cada cliente.
Como diagnosticar na prática
Você não precisa de ferramenta paga para a primeira passada. Acesso ao arquivo do tema já resolve a maior parte.
- Baixe o tema e descompacte em ambiente local. Nunca analise direto no servidor de produção.
- Rode uma busca por
eval,base64_decode,gzinflate,str_rot13ecreate_functionem todos os arquivos.php. - Busque por
echo $_eprint $_para achar saída sem escape. - Busque por
wp_ajax_nopriv_e leia cada callback. - Busque por
http://ehttps://emwp_enqueue_scriptpara mapear CDNs. - Compare o resultado com o changelog oficial do tema. O que não está documentado merece atenção.
Se você tem SSH, o mesmo trabalho sai com grep -rn "eval(" wp-content/themes/ direto no servidor. Se só tem painel de hospedagem, baixe o tema por FTP ou pelo gerenciador de arquivos e analise local. Não edite o tema em produção durante a revisão: um erro de sintaxe tira o site do ar.
Quando NÃO usar essa abordagem
Auditar tema próprio faz sentido quando você controla o código. Se o cliente usa um tema premium fechado, com atualização automática e suporte do desenvolvedor, sua revisão serve para confirmar origem e versão, não para reescrever o tema. Alterar tema de terceiro sem contrato de manutenção costuma quebrar atualização futura.
Também não vale a pena auditar tema que você vai substituir em duas semanas. Nesse caso, priorize o tema novo e mantenha o antigo isolado até a troca. E se o site já está comprometido, a auditoria de tema não substitui a limpeza. Nesse cenário, siga o processo de diagnosticar e limpar site WordPress hackeado em vários sites antes de voltar a replicar.
Erros comuns na revisão
- Revisar só o tema pai e esquecer o child. O buraco costuma estar no child.
- Confiar no nome do arquivo. Backdoor não se chama
backdoor.php. - Apagar código suspeito sem copiar antes. Você perde a evidência e pode não remover o gancho.
- Rodar a análise em produção. Um erro de sintaxe derruba o site.
- Replicar o tema em cinco clientes antes de terminar a auditoria. Uma falha vira cinco incidentes.
- Não registrar a versão auditada. Seis meses depois ninguém sabe o que foi checado.
Prevenção para quem replica em vários sites
Monte um tema-base auditado, versione no Git e trate como produto interno. Cada cliente recebe esse tema-base mais um child próprio. O child é o único lugar onde entra customização, e ele passa por revisão antes de ir para produção.
Restrinja quem pode editar tema no painel. Em wp-config.php, a constante DISALLOW_FILE_EDIT desliga o editor de temas e plugins. Isso reduz muito o risco de alguém com acesso administrativo inserir código sem passar pela revisão.
Mantenha um inventário de versões por site. Quando o tema-base recebe correção, você sabe exatamente quais clientes precisam atualizar. Esse controle é o que separa uma replicação organizada de um parque de sites desatualizados. Vale combinar com o que já foi discutido em atualização de segurança WordPress em vários sites, porque tema e plugin seguem a mesma lógica de propagação.
Se você administra muitos clientes, o trabalho de rechecar child, plugin e versão site por site é o que mais consome tempo. O 100% WP existe justamente para isso: centraliza atualização, backup e monitoramento dos sites em um painel só, o que ajuda a manter o tema-base sincronizado sem abrir site por site. Ainda assim, a auditoria de código continua sendo trabalho seu, porque nenhum painel lê functions.php por você.
Quando chamar alguém
Se você encontrou eval ou base64_decode no tema e não sabe o que o código faz, não mexa sozinho. O mesmo vale se o site já apresenta sintoma de comprometimento: redirecionamento, link injetado, usuário administrador desconhecido. Nesses casos, o tema pode ser só a ponta. Um serviço de segurança e remoção de malware faz a limpeza com rastreio da origem, o que evita que o problema volte na próxima replicação.
Por fim, antes de assumir um site novo com tema já instalado, vale conferir o que mais precisa ser avaliado além do tema. O artigo sobre o que avaliar antes de assumir um site WordPress cobre o restante da stack.
