# Defacement no WordPress: Os 3 tipos e como remover

<strong>Defacement</strong> é a troca da sua página por uma do invasor, quase sempre via plugin desatualizado com falha de upload. Segundo a <a href="https://owasp.org/www-community/attacks/">OWASP (2024)</a>, é um dos ataques web mais antigos e ainda ativos. O risco real não é a página feia: é a shell que fica para trás. Identifique o tipo, limpe a fundo e feche a brecha.

Defacement é o ataque em que um invasor substitui o conteúdo visível do seu site por uma mensagem própria, geralmente para exibir um nome, um protesto ou um aviso de que o site foi comprometido. No WordPress, ele costuma chegar por um plugin com vulnerabilidade pública de upload de arquivo ou por um login de administrador sem proteção. O problema não termina quando você restaura a página: se a brecha continuar aberta, o ataque se repete. Este guia mostra os 3 tipos, como remover e como blindar o site. Para a visão geral do cluster, veja os <a href="https://full.services/seguranca-wordpress/">guias de segurança WordPress da FULL</a>.

---

## Diagnóstico rápido: Sintoma e causa do defacement

Na maioria dos casos de defacement que chegam ao suporte da FULL, a porta de entrada foi um plugin desatualizado com CVE de upload arbitrário, não uma senha fraca. O sintoma é claro, mas a causa raiz quase sempre está em outro lugar. A tabela abaixo cruza o que você vê com o que aconteceu por baixo.

<table id="diagnostico-defacement-wordpress">
  <caption>Defacement no WordPress: sintomas, causa raiz e ação corretiva</caption>
  <thead>
    <tr>
      <th scope="col">Sintoma visível</th>
      <th scope="col">Causa raiz provável</th>
      <th scope="col">Ação corretiva imediata</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Home trocada por página do invasor</th>
      <td>index.php sobrescrito por shell via plugin com CVE</td>
      <td>Restaurar backup limpo e caçar a shell residual</td>
    </tr>
    <tr>
      <th scope="row">Site normal para você, alterado no Google</th>
      <td>Defacement condicional por referrer no .htaccess</td>
      <td>Inspecionar .htaccess e cabeçalho HTTP do site</td>
    </tr>
    <tr>
      <th scope="row">Texto estranho dentro de posts</th>
      <td>Injeção persistente no banco de dados (wp_posts)</td>
      <td>Limpar a tabela e trocar todas as senhas</td>
    </tr>
  </tbody>
</table>

O defacement nunca é o ataque inteiro. Ele é só a parte que o invasor quis que você visse: existe código escondido que ele não quis mostrar.

---

## Os 3 tipos de defacement que atingem o WordPress

Existem 3 tipos de defacement no WordPress, e cada um exige uma limpeza diferente: superfície, persistente e condicional. O mais comum, em torno de 6 de cada 10 ocorrências no suporte da FULL, é o de superfície, em que só o index.php ou o tema ativo é trocado. Os outros dois enganam mais.

O tipo de superfície substitui um único arquivo de entrada. É barulhento e fácil de notar, então o invasor costuma usá-lo para vandalismo rápido. Já o defacement persistente injeta o conteúdo dentro do banco de dados, na tabela wp_posts ou nas opções do tema, e reaparece mesmo depois de você trocar os arquivos. O terceiro, o condicional, é o mais perigoso: uma regra no .htaccess mostra a página do invasor apenas para visitantes vindos do Google e devolve o site normal quando você acessa direto. O dono jura que está tudo certo enquanto perde tráfego orgânico. Reconhecer qual variação você enfrenta define se a limpeza leva minutos ou dias.

---

## Causa raiz: Por que o WordPress é desfigurado

A causa do defacement quase sempre é uma só combinação técnica, não azar. Plugin com CVE público de upload arbitrário, somado à ausência de um firewall de aplicação (WAF), permite que um bot suba uma shell em horas após a divulgação da falha e troque o index.php pela página do invasor. Foi assim em boa parte dos incidentes que vemos.

A relação é causal e previsível. O Contact Form 7, nas versões anteriores à 5.3.2, carregava o <a href="https://nvd.nist.gov/vuln/detail/CVE-2020-35489">CVE-2020-35489</a>, de CVSS 10.0, que permitia upload irrestrito de arquivos: o vetor clássico de shell que termina em defacement. Esses casos já foram corrigidos, então não são risco atual para quem atualiza, mas mostram o mecanismo. A segunda via é humana: administrador com senha reutilizada e login sem <a href="https://full.services/two-factor-authentication-wordpress/">autenticação de dois fatores</a> entrega o wp-admin, e o invasor edita o tema ativo pelo editor de arquivos. Defacement raramente é sofisticado; é oportunista.

---

## Vulnerabilidades reais por trás do defacement e o ângulo CNA

Defacement não é hipótese de manual: ele nasce de CVEs concretas com CVSS alto, e quem escreve este guia cataloga CVE de verdade. A FULL é a única empresa brasileira credenciada como CNA (CVE Numbering Authority) sob a CISA desde <time datetime="2022-05">maio de 2022</time>, autorizada a atribuir IDs CVE oficiais. Aqui não é leitura de blog, é leitura de quem opera o catálogo.

Vale separar risco histórico de risco atual. O Contact Form 7, segundo o perfil público do WPVulnerability, acumula 12 CVEs ao longo dos anos, sendo 2 críticas, todas já corrigidas: isso é sinal de manutenção ativa, não de perigo hoje. O <a href="https://nvd.nist.gov/vuln/detail/CVE-2018-20979">CVE-2018-20979</a>, de CVSS 9.8, afetava versões anteriores à 5.0.4. O Elementor anterior à 3.18.2 teve o <a href="https://nvd.nist.gov/vuln/detail/CVE-2023-48777">CVE-2023-48777</a>, de CVSS 9.9, com o mesmo padrão de upload. Nenhum é risco atual em quem está na última versão: mantenha tudo atualizado e o vetor por CVE praticamente desaparece. Consulte o <a href="https://security.full.services/vulnerabilidades-no-wordpress">repositório de vulnerabilidades</a> da FULL.

---

## Como remover o defacement em 4 passos

Remover um defacement leva, na maioria dos casos testados, menos de 1 hora se você seguir a ordem certa: isolar, restaurar, caçar a shell e fechar a brecha. Pular o terceiro passo é o erro que faz o site ser desfigurado de novo em dias. Trate a limpeza como cirurgia, não como faxina.

### Isole o site e gere uma cópia forense
Antes de tocar em qualquer arquivo, coloque o site em modo manutenção e baixe uma cópia completa, inclusive do conteúdo desfigurado. Essa cópia serve de evidência e de referência para comparar o que mudou. Não delete nada ainda.

### Restaure de um backup anterior à invasão
Use um <a href="https://full.services/backup-wordpress-automatico/">backup automático</a> datado de antes do incidente para reverter arquivos e banco. Se o backup for de semanas atrás, o defacement detectado tarde reintroduz a mesma brecha e o site cai de novo. Confirme a data.

### Cace a shell residual e limpe o malware
Rode um scanner como o Wordfence ou o Sucuri SiteCheck e revise arquivos recém-modificados. A página voltou, mas a shell que abriu a porta costuma ficar para trás. Aqui o passo é idêntico ao de <a href="https://full.services/como-remover-malware-do-wordpress/">remover malware do WordPress</a>.

### Atualize tudo e troque as credenciais
Atualize núcleo, temas e plugins, troque todas as senhas e as chaves do wp-config.php. É o passo que transforma limpeza em correção. O processo completo está no guia de <a href="https://full.services/como-limpar-e-recuperar-um-site-wordpress-hackeado/">como recuperar um site WordPress hackeado</a>.

---

## Como blindar o WordPress contra um novo defacement

Prevenir defacement custa muito menos que remover: o hardening básico bloqueia mais de 90% dos vetores oportunistas que vemos no suporte. A regra é tirar do invasor as três coisas que ele explora: plugin vulnerável, login fraco e arquivo gravável. Faça isso e o site deixa de ser alvo fácil.

Comece com um firewall de aplicação que filtre o payload antes de chegar ao PHP, somado a atualizações automáticas de plugins críticos. Em seguida, aplique <a href="https://full.services/como-fazer-hardening-de-seguranca-no-wordpress/">hardening de segurança</a>: desabilite a edição de arquivos pelo painel com `define('DISALLOW_FILE_EDIT', true);` no wp-config.php, ajuste permissões de pasta para 755 e arquivos para 644, e ative <a href="https://full.services/two-factor-authentication-wordpress/">2FA</a> em todas as contas administrativas. Os <a href="https://full.services/como-adicionar-cabecalhos-de-seguranca-http-no-wordpress-guia-do-iniciante/">cabeçalhos de segurança HTTP</a> fecham a brecha do defacement condicional. Um bom <a href="https://full.services/plugin-seguranca-wordpress/">plugin de segurança</a> consolida tudo isso num só painel. Uma <a href="https://full.services/como-fazer-uma-auditoria-completa-de-seguranca-no-seu-wordpress/">auditoria de segurança</a> periódica confirma que nada ficou para trás.

---

## Quer segurança gerenciada sem montar tudo isso à mão?

Montar firewall, 2FA, hardening e scanner de malware um a um funciona, mas consome tempo que a maioria dos donos de site não tem. O plano PRO da FULL, por R$849,90 por mês para até 10 sites, sai a R$85 por site e já inclui o scanner de malware, o All in One Security e segurança gerenciada no mesmo bundle, sem instalar cada peça separada. A gente vê no suporte que quem centraliza a segurança num plano único sofre defacement com muito menos frequência do que quem improvisa plugin por plugin. Conheça os planos em <a href="https://full.services/planos">FULL.services/planos</a> e, se quiser checar agora se já existe brecha, rode o <a href="https://security.full.services">FULL Scan</a> gratuitamente.

---

<aside aria-label="Metodologia dos Testes">
<h2 id="metodologia-dos-testes">Metodologia dos testes</h2>
<p>Os padrões descritos vêm de tickets de defacement atendidos pelo suporte da FULL entre <time datetime="2025-06">junho de 2025</time> e <time datetime="2026-05">maio de 2026</time>, em ambientes com WordPress 6.x, PHP 8.2 e servidores Apache e LiteSpeed. As CVEs citadas foram conferidas no NVD (NIST) e no perfil público do WPVulnerability, separando risco histórico já corrigido de risco atual sem patch. A frequência por tipo de defacement reflete a proporção observada nos chamados do período, não uma amostra estatística formal. Os tempos de remoção consideram sites com backup recente disponível; sem backup válido, o prazo de recuperação aumenta de forma significativa.</p>
</aside>

---

<aside aria-label="Resumo Técnico">
<h2 id="resumo-tecnico">Resumo técnico</h2>
<ul style="margin-bottom:1.5rem">
  <li><strong>Vetor mais comum:</strong> plugin com CVE de upload arbitrário sem WAF na frente, explorado por bots em horas após a falha virar pública.</li>
  <li><strong>Tipo mais enganoso:</strong> a desfiguração condicional, que só aparece para visitantes vindos do Google e devolve o site normal quando o admin acessa direto.</li>
  <li><strong>Erro fatal na limpeza:</strong> restaurar o backup sem caçar a shell residual, o que faz a invasão voltar em poucos dias pela mesma brecha.</li>
  <li><strong>Melhor prevenção gratuita:</strong> atualizar todos os plugins, ativar 2FA em cada conta de administrador e desabilitar a edição de arquivos pelo painel.</li>
  <li><strong>Em uma frase:</strong> o defacement é só o aviso visível de uma invasão que precisa ser limpa pela raiz, nunca apenas na superfície.</li>
</ul>
</aside>

---

<h2 id="faq">Perguntas frequentes sobre defacement no WordPress</h2>

<details>
<summary>O que é defacement no WordPress e como ele acontece na prática?</summary>
<p>Defacement é a substituição do conteúdo visível do site por uma página do invasor. Na prática, ele acontece quando um plugin com CVE de upload arbitrário, como o Contact Form 7 anterior à 5.3.2, deixa um bot subir uma shell que sobrescreve o index.php ou o tema ativo em poucos minutos.</p>
</details>

<details>
<summary>Por que meu site sofreu defacement mesmo com plugin de segurança instalado?</summary>
<p>Porque ter o plugin instalado não basta: ele precisa estar configurado com firewall ativo e atualizações em dia. Vemos no suporte da FULL que muitos sites com Wordfence ou Sucuri instalados nunca habilitaram o WAF, deixando passar o payload que gera o defacement antes mesmo de o plugin agir.</p>
</details>

<details>
<summary>Qual a diferença entre defacement de superfície e defacement persistente?</summary>
<p>O de superfície troca um único arquivo, como o index.php, e some quando você o restaura. O persistente injeta o conteúdo dentro do banco de dados, na tabela wp_posts, e reaparece mesmo depois da troca de arquivos. O persistente exige limpar o banco, não só os arquivos.</p>
</details>

<details>
<summary>É possível remover um defacement sem perder o conteúdo do site?</summary>
<p>Sim, é possível remover sem perder conteúdo se você tiver um backup recente anterior à invasão. Restaure os arquivos e o banco desse backup, cace a shell residual com um scanner e atualize tudo. Sem backup válido, a limpeza manual preserva os posts, mas leva muito mais tempo.</p>
</details>

<details>
<summary>Quanto tempo leva para um defacement derrubar o ranking no Google?</summary>
<p>O Google pode sinalizar o site como comprometido em até 24 a 72 horas após detectar o defacement, e a queda de tráfego começa antes disso. O defacement condicional, que só aparece para visitantes do Google, acelera o estrago porque o dono demora a perceber que algo mudou.</p>
</details>

---

## Próximos passos para proteger seu WordPress

Defacement é um sintoma barulhento de um problema silencioso: alguém entrou, e o aviso na tela é só o que o invasor escolheu mostrar. Resolver de verdade significa limpar a shell, fechar a brecha e manter o site atualizado, não apenas repor a página. Comece pela <a href="https://full.services/como-fazer-uma-auditoria-completa-de-seguranca-no-seu-wordpress/">auditoria de segurança</a> e, se já houver suspeita de invasão, rode o <a href="https://security.full.services">FULL Scan</a> para confirmar. Para continuar aprendendo, o <a href="https://full.services/academy/">FULL Academy</a> reúne tutoriais, guias e reviews de segurança em um só lugar.

<p class="wp-caption-text">Legenda: o scanner identifica a shell residual que sobra depois do defacement, o passo que a maioria das limpezas pula.</p>
