# Zero-day no WordPress: Os 3 sinais e como se proteger

Um <strong>zero-day</strong> é uma falha sem patch disponível, explorada antes do autor do plugin publicar a correção. Segundo o <a href="https://nvd.nist.gov/vuln/detail/CVE-2020-35489">NVD/NIST (2020)</a>, o CVE-2020-35489 no Contact Form 7 (CVSS 10.0) foi explorado antes do patch. A maioria dos ataques, porém, é n-day: o patch existe e o site não atualizou. Saber distinguir os dois muda a defesa.

Um zero-day é uma vulnerabilidade que está sendo explorada enquanto ainda não existe correção oficial, o pior cenário de exposição. O nome vem do tempo que o desenvolvedor teve para reagir: zero dias. No WordPress, o núcleo raramente sofre esse tipo de falha, porque a equipe central audita o código com rigor. O risco real mora nos plugins e temas de terceiros, onde uma brecha pode virar ataque em massa antes do autor reagir. Este guia de conceito faz parte do hub de <a href="https://full.services/vulnerabilidades-wordpress/">vulnerabilidades WordPress da FULL</a> e mostra como reconhecer e mitigar um zero-day.

---

## O que é um zero-day no WordPress: Definição e os 3 sinais

Um zero-day no WordPress é uma falha de segurança em uso ativo por atacantes antes de o autor do plugin ou tema lançar o patch. O número que define o conceito é zero: zero dias de aviso prévio para quem mantém o site. Nos tickets de invasão da FULL, três sinais separam o caso real do alarme falso, e o mais comum é confundir um n-day com uma falha sem patch verdadeira.

A causa raiz quase sempre é código de terceiros com uma brecha que o atacante descobriu primeiro, como um upload sem validação ou uma rota REST exposta. A tabela abaixo resume os três sinais que indicam um zero-day genuíno, cada um com o critério técnico e a ação imediata. O que os une é a ausência de patch: enquanto a correção não existe, atualizar não resolve.

<table id="sinais-zero-day-wordpress">
  <caption>Zero-day no WordPress: 3 sinais e ação imediata para cada um</caption>
  <thead>
    <tr>
      <th scope="col">Sinal</th>
      <th scope="col">Critério técnico</th>
      <th scope="col">Ação imediata</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Sem patch publicado</th>
      <td>Falha confirmada, mas nenhuma versão corrige até agora.</td>
      <td>Aplicar patching virtual via WAF na borda.</td>
    </tr>
    <tr>
      <th scope="row">Exploração em massa</th>
      <td>Mesmo vetor visto em vários sites na mesma janela.</td>
      <td>Desativar o plugin afetado até a correção.</td>
    </tr>
    <tr>
      <th scope="row">Aviso sem CVE ainda</th>
      <td>Alerta de pesquisador antes do ID CVE ser emitido.</td>
      <td>Monitorar logs e isolar o componente.</td>
    </tr>
  </tbody>
</table>

<p class="wp-caption-text">Legenda: a falha vive na janela entre ser explorada e o patch existir, quando atualizar ainda não é opção.</p>

## Por que o WordPress Core resiste, mas os plugins sofrem zero-day

O núcleo do WordPress raramente sofre um zero-day porque passa por revisão pública e auditoria contínua, enquanto os mais de 60 mil plugins do diretório têm qualidade desigual. Em cerca de 9 de cada 10 invasões que chegam ao suporte da FULL, o vetor é um plugin ou tema de terceiros, nunca o core em si. A superfície de ataque está na extensão, não na base.

O motivo é estrutural: o core tem uma equipe dedicada e milhares de olhos sobre cada commit, enquanto um plugin pode ser mantido por uma pessoa só. Uma falha de upload sem validação, combinada com um visitante não autenticado, vira um web shell antes de o autor publicar a correção. Por isso a regra prática é tratar todo plugin com upload, formulário ou editor de arquivos como o primeiro alvo de um zero-day. Reduzir o número de plugins ativos encolhe essa superfície, como detalha o guia de <a href="https://full.services/como-fazer-hardening-de-seguranca-no-wordpress/">hardening de segurança</a>.

## Zero-day ou n-day: A distinção que muda toda a defesa

A diferença entre zero-day e n-day decide qual defesa funciona, e a maioria dos casos é n-day. Um zero-day não tem patch; um n-day tem patch há dias ou semanas e o site simplesmente não atualizou. Nos tickets da FULL, a esmagadora maioria dos sites comprometidos rodava um plugin com CVE publicado e correção disponível, só com a atualização desligada.

A consequência é direta: contra n-day, atualizar resolve, então a defesa é manter as atualizações automáticas ligadas e revisar a fila de updates pendentes toda semana. Contra zero-day real, atualizar não existe como opção, e a defesa precisa vir do WAF com patching virtual na borda. Um exemplo concreto é o CVE-2023-6449 no <a href="https://nvd.nist.gov/vuln/detail/CVE-2023-6449">Contact Form 7 (CVSS 7.2)</a>, na versão < 5.8.4: depois do patch, ele virou n-day, e quem não atualizou ficou exposto por pura escolha de configuração. Para fechar essa janela, o guia de <a href="https://full.services/como-atualizar-corretamente-os-plugins-do-wordpress/">como atualizar corretamente os plugins</a> mostra o fluxo seguro de aplicação.

## Como o patching virtual protege na janela do zero-day

O patching virtual protege o site na janela em que o patch oficial ainda não existe, bloqueando o vetor de ataque na borda em vez de no código. Um WAF gerenciado, como o do Wordfence ou o da camada da FULL, recebe uma regra que reconhece a requisição maliciosa e a barra antes de ela chegar ao plugin, em geral em minutos após a falha ser publicada.

A mecânica é a seguinte: o WAF não corrige o plugin, ele intercepta a requisição que explora a falha. Isso cobre o intervalo crítico entre o zero-day aparecer e o autor lançar o patch. Quando o CVE-2023-3124 no <a href="https://nvd.nist.gov/vuln/detail/CVE-2023-3124">Elementor Pro (CVSS 8.8)</a> foi divulgado, ambientes com WAF ativo bloquearam o vetor enquanto o patch 3.11.7 era preparado. Ferramentas para <a href="https://full.services/ferramentas-verificar-wordpress-vulnerabilidades/">verificar vulnerabilidades no WordPress</a> ajudam a saber se algum plugin já tem alerta aberto.

## A FULL inclui WAF gerenciado e patching virtual no bundle

A segurança gerenciada da FULL parte de um princípio: cobrir a janela de um zero-day na borda custa menos que limpar um site invadido toda semana. O plano PRO sai por R$849 e cobre 10 sites, o que dá R$85 por site, com o WAF gerenciado, patching virtual e o <a href="https://full.services/all-in-one-security/">All in One Security</a> já no bundle.

Em vez de pagar uma limpeza emergencial por incidente, você fica com a regra de WAF rodando na borda assim que uma falha é publicada. Conheça os <a href="https://full.services/planos">planos da FULL</a> e compare com o custo de uma única invasão por zero-day.

Vale o contexto de autoridade aqui: 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. Para um diagnóstico rápido, o <a href="https://security.full.services">FULL Scan</a> verifica seu site sem instalação, e o <a href="https://security.full.services/vulnerabilidades-no-wordpress">repositório de vulnerabilidades</a> lista os CVEs por plugin.

<h2 id="faq">Perguntas frequentes sobre zero-day no WordPress</h2>

<details>
<summary>O que é um zero-day no WordPress e como ele difere de um CVE comum?</summary>
<p>Um zero-day é uma falha sem patch disponível, explorada antes da correção existir. A diferença prática para um CVE comum é o tempo: o CVE comum já tem patch publicado e o ID atribuído, enquanto a falha sem patch muitas vezes nem recebeu CVE ainda. O CVE-2020-35489 no Contact Form 7 (CVSS 10.0) começou como zero-day antes de virar CVE corrigido.</p>
</details>

<details>
<summary>Por que o WordPress core raramente sofre um zero-day, mas os plugins sofrem?</summary>
<p>Porque o core passa por revisão pública e auditoria contínua, enquanto plugins de terceiros têm qualidade desigual. Em 9 de cada 10 invasões que vemos no suporte da FULL, o vetor é um plugin ou tema, não o núcleo. Um plugin mantido por uma pessoa só tem menos olhos sobre o código do que o core, que conta com uma equipe dedicada.</p>
</details>

<details>
<summary>Qual a diferença entre um zero-day e um n-day no WordPress?</summary>
<p>O zero-day não tem patch; o n-day tem patch há dias ou semanas e o site não atualizou. Essa distinção decide a defesa: contra n-day, atualizar resolve, então mantenha as atualizações automáticas ligadas. Contra zero-day, só o WAF com patching virtual cobre a janela. O CVE-2023-6449 no Contact Form 7 virou n-day depois do patch 5.8.4.</p>
</details>

<details>
<summary>É possível proteger o WordPress de um zero-day sem esperar o patch oficial?</summary>
<p>Sim, é possível na maioria dos casos com patching virtual via WAF. O firewall recebe uma regra que bloqueia a requisição maliciosa na borda, sem tocar no código do plugin, geralmente minutos após a falha ser publicada. Foi assim que ambientes com WAF ativo barraram o vetor do CVE-2023-3124 no Elementor Pro enquanto o patch 3.11.7 era preparado.</p>
</details>

<details>
<summary>Quanto tempo um plugin WordPress fica exposto entre a falha zero-day e o patch?</summary>
<p>A janela varia de horas a semanas, dependendo de quão rápido o autor reage. Plugins populares costumam corrigir em até alguns dias após a divulgação responsável, mas exploração em massa pode começar em horas. Sem WAF, o site fica exposto por toda essa janela; com patching virtual, a janela cai para o tempo de o firewall receber a regra.</p>
</details>

---

<aside aria-label="Metodologia dos Testes">
<h2 id="metodologia-dos-testes">Metodologia dos testes</h2>
<p>As observações de campo deste guia vêm dos tickets de invasão tratados pelo suporte da FULL entre <time datetime="2024-01">janeiro de 2024</time> e <time datetime="2026-05">maio de 2026</time>, em ambientes com WordPress 6.x e PHP 8.2. Os CVEs citados, como o CVE-2020-35489 no Contact Form 7 e o CVE-2023-3124 no Elementor Pro, foram conferidos um a um contra o NVD/NIST e cruzados com o perfil público do WPVulnerability, distinguindo sempre zero-day real de n-day já corrigido para não alarmar com falha que já tem patch. A proporção de invasões por plugin de terceiros descrita reflete o padrão recorrente nesses chamados, não um número de telemetria fechado: é a leitura qualitativa de quem cataloga vulnerabilidade como a única CNA brasileira sob a CISA, autorizada pela agência norte-americana a emitir identificadores CVE oficiais.</p>
</aside>

## Próximos passos para reduzir a exposição a zero-day

Entender o zero-day muda a prioridade da defesa: cobrir a janela na borda com WAF e, ao mesmo tempo, eliminar o n-day mantendo tudo atualizado. Um plano em camadas combina patching virtual, um bom <a href="https://full.services/plugin-de-seguranca-wordpress-os-5-melhores-em-2026/">plugin de segurança</a> e atualização automática, de modo que tanto a falha sem patch quanto a falha já corrigida encontrem pouca margem. Se o site já foi atingido, o passo a passo de <a href="https://full.services/site-wordpress-invadido-o-que-fazer-imediatamente/">o que fazer imediatamente após uma invasão</a> organiza a resposta, e falhas como o <a href="https://full.services/cross-site-scripting-xss-o-que-e-e-como-corrigi-lo/">cross-site scripting (XSS)</a> mostram como um vetor comum vira porta de entrada. Para continuar aprendendo, o <a href="https://full.services/guias/guia-de-seguranca-para-wordpress">guia de segurança para WordPress</a> reúne os próximos passos em sequência.
