Scripts escondidos no código do WordPress são linhas de PHP ou JavaScript inseridas sem o seu consentimento, geralmente após uma falha de plugin ou senha vazada. Eles raramente aparecem na área visual: vivem no wp_head, no functions.php do tema ativo, em registros do banco de dados ou em arquivos .php plantados na pasta de uploads. O efeito vai de redirecionamento para sites de aposta até roubo de cartao no checkout. Este guia de segurança para WordPress mostra os 5 sinais mais comuns e o passo a passo para encontrar e remover esse código. Para o panorama geral, comece pelos guias de segurança WordPress da FULL.

Diagnóstico rápido: Onde os scripts escondidos no código do WordPress se alojam

A maioria dos scripts escondidos no código do WordPress vive em 5 lugares previsíveis, e mapear esses pontos corta o tempo de diagnóstico de horas para minutos. Nos tickets de segurança da FULL, dois locais concentram a maior parte dos casos: o functions.php do tema ativo e a tabela wp_options do banco de dados.

A tabela abaixo associa cada local ao sintoma típico e ao primeiro comando de verificação, para você ir direto ao ponto sem perder tempo. Comece sempre pelo functions.php e pela wp_options: juntos, respondem pela maior parte do que a gente vê no suporte. O malware que vive no banco é o mais ignorado, porque não aparece em nenhum scanner que só lê arquivos do servidor, e é justamente por isso que ele sobrevive a uma troca de tema ou plugin.

Legenda: código ofuscado no início do functions.php é o sinal número um de injeção.

5 sinais de que ha scripts escondidos no código do WordPress

Existem 5 sinais objetivos de scripts escondidos no código do WordPress, e bastam 2 deles juntos para tratar o site como comprometido. O primeiro é o mais barato de checar: abra o site numa aba anonima e veja se ha redirecionamento que não acontece logado. Os outros quatro exigem olhar o código-fonte e os logs, mas nenhum leva mais que alguns minutos por item.

Os sinais são: redirecionamento so para quem chega do Google; picos de uso de CPU sem tráfego real; alerta de “site enganoso” no Search Console; arquivos `.php` recem-modificados em datas que você não tocou no site; e tags “ apontando para domínios estranhos no `wp_footer`. Funções como `eval`, `gzinflate` e `str_rot13` quase nunca tem uso legitimo em tema. Se você encontrar qualquer uma delas, trate como injecao até provar o contrario e siga para o diagnóstico de scripts maliciosos em JavaScript.

## Passo a passo: Como encontrar scripts escondidos no código do WordPress

[IMAGEM: Passo a passo: Como encontrar scripts escondidos no código do WordPress: screenshot]

Encontrar scripts escondidos no código do WordPress segue 5 etapas em ordem, do ponto mais comum ao mais escondido, e a varredura completa leva cerca de 30 a 45 minutos num site médio. A regra de ouro antes de começar: faça backup do site inteiro, porque um `functions.php` editado errado derruba a página toda.

Trabalhe sempre num ambiente de teste quando possível, e nunca edite direto em produção sem cópia de segurança. As etapas abaixo cobrem, nesta ordem, o tema ativo, o header e o footer, o banco de dados, a pasta de uploads e os logs de acesso do servidor.

### Passo 1: Audite o functions.php do tema ativo

Abra o `functions.php` do tema ativo e leia as 30 primeiras linhas: é ali que cerca de metade das injecoes de tema se escondem. Procure por `eval(`, `base64_decode(`, `gzinflate(` e blocos de texto longos sem espacos, que são código ofuscado. Um `functions.php` saudavel comeca com comentários e funções nomeadas em portugues ou ingles claro, nunca com strings de centenas de caracteres aleatorios. Compare com a versão limpa do tema baixada do repositorio oficial: qualquer linha a mais é suspeita. Esse arquivo concentra tanto risco que vale linkar a explicacao do functions.php no glossario para entender o que cada bloco faz.

### Passo 2: Inspecione o header e o footer renderizados

Abra o site publicado, pressione Ctrl+U para ver o código-fonte e busque por `<script src`: leva menos de 1 minuto e revela qualquer tag injetada no `wp_head` ou `wp_footer`. Anote todos os domínios que você não reconhece. Tag manager, fontes do Google e pixel de anuncio sao legitimos; um domínio aleatorio terminado em `.ru` ou `.xyz` carregando JavaScript não é. Repita o teste numa aba anonima e a partir de um clique vindo do Google, porque muitas injecoes so disparam para visitantes novos. Se o script aparecer apenas nesse cenario, você achou a injecao. Esse padrao é classico de código que se esconde de quem esta logado no painel.

### Passo 3: Procure código malicioso no banco de dados

Acesse o phpMyAdmin e ordene a tabela `wp_options` pela coluna de tamanho: registros gigantes com `autoload` igual a `yes` sao o esconderijo favorito de quem injeta `malware` que sobrevive a troca de tema. Busque também nas tabelas `wp_posts` e `wp_postmeta` por `<script`, `eval` e `base64`. O código no banco é o motivo de o site reinfectar mesmo depois de você limpar os arquivos, porque nenhum scanner de arquivo o enxerga. Exporte um backup do banco antes de apagar qualquer linha. Em caso de duvida sobre o registro, compare com uma instalação limpa do WordPress 6.x para saber o que é padrao.

### Passo 4: Varra a pasta de uploads e os plugins

Liste por FTP todos os arquivos `.php` dentro de `wp-content/uploads`: essa pasta deveria conter so imagens e documentos, entao qualquer `.php` ali é quase sempre um shell de invasor. Faca o mesmo em `wp-content/mu-plugins`, onde plugins falsos rodam sem aparecer na lista de plugins do painel. Ferramentas como Wordfence e Sucuri SiteCheck comparam seus arquivos com os originais e apontam o que foi modificado nas ultimas semanas. Um arquivo do core com data de modificacao recente, sem que você tenha atualizado o WordPress, é um sinal forte. Remova o que for confirmado como injecao e guarde a evidencia.

### Passo 5: Cruze os achados com os logs de acesso

Abra os logs de acesso do servidor e filtre por requisicoes `POST` para `.php` em horarios fora do seu padrao: e assim que você liga o código injetado a porta de entrada que o colocou ali. Procure o IP que acessou o arquivo suspeito e o user-agent usado. Esse cruzamento responde a pergunta mais importante depois da limpeza: por onde entraram. Sem fechar essa porta, o código volta em dias. A FULL mantem cabeçalhos de segurança como camada extra; vale ver o guia de cabeçalhos de segurança HTTP no WordPress para reduzir a superficie de ataque.

## Como remover os scripts escondidos no código do WordPress sem quebrar o site

[IMAGEM: Como remover os scripts escondidos no código do WordPress sem quebrar o site: screenshot]

Remover scripts escondidos no código do WordPress sem derrubar a página depende de uma ordem fixa: banco primeiro, arquivos depois, e troca de senhas por último, num processo que costuma levar de 1 a 2 horas. Apagar apenas os arquivos é o erro mais comum, porque o registro deixado no banco recria o código no próximo carregamento da página.

Comece restaurando o `functions.php` e os arquivos do core a partir de cópias oficiais, depois limpe os registros confirmados na `wp_options`. Em seguida, troque todas as senhas, incluindo a do banco no `wp-config.php`, e revogue chaves de API antigas. Se o site já foi marcado pelo Google, peça a reanálise no Search Console só depois de tudo limpo. Para casos de reinfecção persistente, o caminho seguro é seguir um processo de remoção de malware do WordPress completo, e nunca remendos pontuais que ignoram o banco.

## Como impedir que os scripts escondidos no código do WordPress voltem

[IMAGEM: Como impedir que os scripts escondidos no código do WordPress voltem: screenshot]

Impedir que scripts escondidos no código do WordPress voltem exige fechar a porta de entrada, e não apenas limpar o sintoma: cerca de 35% das falhas de 2024 seguiam sem correção em 2025, segundo a Wordfence. A causa mais comum de reinfecção é um plugin desatualizado ou anulado (nulled), que reabre o mesmo buraco já explorado.

Mantenha core, tema e plugins atualizados, remova o que não usa e instale apenas de fontes oficiais. Um firewall de aplicação (WAF) bloqueia a maior parte das tentativas automatizadas antes que cheguem ao PHP. Ative também a verificação de integridade de arquivos, que avisa quando um `.php` muda sem a sua ação. Para escolher a camada de proteção, compare as opções nos 12 melhores plugins de segurança do WordPress e priorize os que monitoram o banco, e não só os arquivos do servidor.

## Plano PRO da FULL: Segurança gerenciada por r$85 por site

[IMAGEM: Plano PRO da FULL: Segurança gerenciada por r$85 por site: screenshot]

A gente vê no suporte da FULL que limpar um site infectado custa caro em tempo, e que prevenir sai muito mais barato do que remediar uma invasão. O plano PRO da FULL custa R$849 e reúne os principais plugins de segurança, performance e otimização num único pacote gerenciado e atualizado.

Diluído entre os sites de uma agência ou de quem mantém vários projetos, o plano PRO dá cerca de R$85 por site, com atualização automática e camada de WAF já configurada de fábrica. Em vez de pagar licença avulsa de cada plugin de segurança, o bundle entrega o conjunto testado e ativado em um clique. Conheça os planos da FULL e compare com o custo de uma única limpeza emergencial de site hackeado.

Perguntas frequentes sobre scripts escondidos no código do WordPress

—

## Próximos passos para blindar seu WordPress

[IMAGEM: Próximos passos para blindar seu WordPress: screenshot]

Achar scripts escondidos no código do WordPress é so a metade do trabalho: fechar a porta de entrada é o que evita a reinfeccao. Audite os 5 locais deste guia, limpe banco antes dos arquivos, troque as senhas e suba uma camada de WAF para barrar o tráfego automatizado. Para um diagnóstico imediato e sem instalação, rode o FULL Scan e veja se algum plugin do seu site esta vulneravel. Se quiser aprofundar a rotina de proteção, o guia de segurança para WordPress reune os passos de auditoria, limpeza e prevencao em sequencia. Tratar segurança como manutenção continua, e não como emergencia, é o que mantem o código do site sob seu controle.