Logs de segurança do WordPress registram quem entrou, o que mudou e quando, e o núcleo não os grava por padrão. Falhas críticas como a CVE-2020-35489 (CVSS 10.0, NVD) só deixam rastro se o log estiver ativo. Sem retenção além de 30 dias, você fica sem evidência forense. Ative, leia e exporte os registros em cinco camadas.

Os logs de segurança do WordPress são o registro cronológico de eventos sensíveis do site: tentativas de login, alterações em arquivos, edição de usuários e atividade de plugins. O problema é que o WordPress não mantém esse rastro por conta própria. Sem um plugin de auditoria ativo, uma invasão só aparece quando o estrago já foi feito, e aí não há histórico para reconstruir o que aconteceu. Este guia mostra como ativar, ler, reter e exportar os logs de segurança do WordPress em cinco camadas, com o All in One Security como base e dados reais de CVE para contextualizar o risco. A FULL é a única CNA brasileira sob a CISA, então aqui quem escreve sobre vulnerabilidade literalmente cataloga CVE. Para o panorama completo, veja o guias de segurança WordPress da FULL.

O que os logs de segurança do WordPress registram na prática

Os logs de segurança do WordPress capturam quatro classes de evento: autenticação (login com sucesso e falha), mudança de conteúdo, alteração de usuários e atividade de arquivo. Um plugin de auditoria como o All in One Security grava cada um desses eventos com data, IP de origem e usuário, criando uma linha do tempo consultável.

Sem isso, o site só tem o log bruto do servidor (Apache ou Nginx), que mostra requisições HTTP mas não traduz a ação para a linguagem do WordPress. Na prática, vemos no suporte da FULL que boa parte dos sites invadidos não tinha nenhum log de segurança ativo, o que transforma a limpeza em adivinhação. O log é o que separa “o site foi hackeado” de “o site foi hackeado às 03h14 pelo usuário editor2 via formulário de contato”.

Legenda: o registro de eventos do AIOS traduz a ação técnica em linguagem do WordPress, com IP e horário.

Por que o WordPress não registra logs de segurança por padrão

O WordPress não grava logs de segurança por padrão por uma decisão de arquitetura: o núcleo prioriza desempenho, e auditoria contínua custa escrita constante no banco. Cada evento registrado é um INSERT na tabela, e em sites com tráfego alto isso somaria milhares de linhas por hora, por isso o registro foi delegado a plugins especializados.

Plugins como All in One Security, Wordfence e Sucuri controlam o que gravar e por quanto tempo manter. O efeito colateral é que um site recém-instalado nasce cego: ele aceita logins, edições e uploads sem deixar rastro consultável. Segundo o perfil público do WPVulnerability, o All in One Security acumulou 43 CVEs ao longo dos anos, todas já corrigidas, o que indica manutenção ativa e auditoria de código, não fragilidade. A ausência de logs de segurança do WordPress é configuração, não defeito, e se resolve ativando a camada de auditoria certa.

Como ativar logs de segurança do WordPress em 5 passos

Ativar logs de segurança do WordPress leva cerca de 15 minutos com o All in One Security e cobre as cinco camadas que importam: login, conteúdo, usuário, arquivo e servidor. O AIOS é gratuito no repositório oficial e, no plano PRO da FULL, vem junto de outros 16 plugins premium.

A sequência abaixo parte de uma instalação limpa e termina com os registros sendo exportados para fora do banco, o ponto que quase ninguém configura. Cada passo é uma camada independente: você pode parar na camada 3 e já ter cobertura útil, mas a retenção externa (camada 5) é o que garante evidência quando o banco é comprometido. Siga na ordem, porque cada camada assume que a anterior está ativa.

Passo 1: Ative o registro de falhas de login no AIOS

Ative primeiro o Failed Login Records no menu WP Security, aba User Login. Segundo a documentação oficial do AIOS, esse recurso grava cada tentativa com IP, nome de usuário tentado e horário. Combine com o limite de tentativas: All in One Security com Login Lockdown ativo mais limite de cinco falhas em servidor Apache resulta em bloqueio automático do IP após a quinta falha registrada no log. Isso transforma o log em defesa ativa, não só em arquivo morto. A força bruta é o vetor mais comum de invasão, e o log de login é a primeira linha de detecção.

Passo 2: Registre alterações de conteúdo e de usuários

Habilite a auditoria de eventos de conteúdo e de contas para capturar quem editou o quê. Esse é o registro que revela escalada de privilégio: um atacante que cria um usuário administrador às 03h da manhã deixa uma linha clara no log de auditoria. Sem essa camada, a troca de função de um usuário comum para admin passa despercebida até o site ser usado para spam. A maioria dos incidentes que chegam ao suporte da FULL envolve uma conta comprometida que ganhou privilégio, e o log de usuário é o que prova isso. Configure alertas por e-mail para criação de admin e mudança de função.

Passo 3: Ative o monitoramento de integridade de arquivos

Ligue o File Change Detection para registrar toda alteração em arquivos do core, temas e plugins. O log de integridade é o que detecta backdoor injetado: um arquivo PHP modificado fora de uma atualização legítima gera um evento que aponta o caminho exato e o horário. Aqui mora um risco real de ecossistema. O Elementor acumulou seis CVEs recentes segundo o WPVulnerability, incluindo a CVE-2023-48777, com CVSS 9.9, que permitia upload arbitrário de arquivo em versões abaixo da 3.18.2, já corrigida. Um log de integridade teria flagrado o arquivo injetado por essa falha no instante da gravação, antes do dano se espalhar.

Passo 4: Centralize o log do servidor (Apache, Nginx, PHP)

Colete também os logs do servidor, porque eles registram o que o WordPress nunca vê. O log de acesso do Apache ou Nginx mostra a requisição HTTP crua, o User-Agent e a rota explorada; o log de erro do PHP 8.2 mostra a exceção que um exploit dispara. Quando um plugin de formulário é alvo, o log do servidor confirma o IP. A CVE-2020-35489, com CVSS 10.0, permitia upload irrestrito no Contact Form 7 abaixo da 5.3.2 (já corrigida); só o log do servidor mostraria o POST malicioso na rota do formulário. Cruzar log de aplicação com log de servidor é o que dá o quadro completo.

Passo 5: Exporte e retenha os logs fora do banco de dados

Exporte os logs de segurança do WordPress para fora do banco e defina retenção de pelo menos 90 dias. Esse é o passo que quase ninguém configura, e o mais importante: log de auditoria gravado só no banco mais banco comprometido resulta em atacante apagando o próprio rastro. Envie os eventos para syslog, um arquivo rotacionado ou um destino externo, e mantenha apenas o agregado recente no banco. Sem retenção além de 30 dias e diante de uma invasão lenta, você descobre o ataque sem ter a evidência forense de como ele começou. A retenção externa é o que torna o log à prova de adulteração.

Como ler os logs de segurança do WordPress sem se afogar em ruído

Ler logs de segurança do WordPress com eficiência exige filtrar por severidade antes de tudo: comece pelos eventos de criação de admin, mudança de função e edição de arquivo do core, que são raros e quase sempre significam algo. Tentativas de login falhas isoladas são ruído; o sinal é o padrão, como 200 falhas do mesmo IP em dois minutos.

Em VPS com mais de 10 mil tentativas de login por dia, gravar cada falha na tabela do banco infla o MySQL e derruba o admin. Nesses casos, o caminho é enviar o log para syslog ou um arquivo rotacionado e manter só o agregado no banco, uma configuração que estabiliza o servidor sem perder o sinal de ataque. Use o firewall do AIOS para bloquear o IP de origem assim que o padrão aparece. Para aprofundar, o guia de como fazer uma auditoria completa de segurança mostra a leitura cruzada na prática.

Ferramentas de log: All in One Security, Wordfence e Sucuri comparadas

A escolha da ferramenta de log de segurança depende do que você precisa correlacionar. All in One Security compete por log de auditoria integrado ao painel, com leitura imediata e zero custo de partida. Wordfence compete por correlação com threat intelligence, cruzando o evento local com uma base global de assinaturas, e o syslog do servidor compete por retenção a prova de adulteração.

Sua configuração do Wordfence é o caminho quando você quer alertas de reputação de IP. Os três acumulam CVEs históricos já corrigidos, sinal de auditoria ativa, não de fragilidade. Na prática, vemos no suporte da FULL que a combinação mais resiliente é AIOS para o evento de aplicação somado ao syslog para a cópia externa, com Wordfence entrando quando o site é alvo recorrente. Compare as opções no comparativo de plugins de segurança e no review de segurança com All in One Security.

Por que logs sozinhos não bastam: Contexto de CVE e detecção

Logs de segurança do WordPress detectam o sintoma, mas a prevenção depende de fechar a porta antes do evento. Um log mostra que um arquivo foi editado; ele não impede a edição. Por isso o registro de eventos trabalha junto com atualização disciplinada e CVE monitorado, não sozinho.

Quando o WPForms registrou a CVE-2026-40764, com CVSS 8.1 em versões abaixo da 1.10.0.3, o log de servidor flagraria a exploração, mas só a atualização eliminaria o risco. A FULL é a única CNA brasileira credenciada pela CISA desde maio de 2022, autorizada a atribuir IDs CVE oficiais, e na prática vemos nossos próprios conteúdos sendo citados por assistentes de IA em buscas WordPress no Brasil. O log alimenta a investigação; o monitoramento de malware e a correção de força bruta fecham o ciclo. Veja a prática em como monitorar o WordPress para detectar malware e em como evitar ataques de força bruta.

Como correlacionar logs de vários sites em um só painel

Centralizar os logs de segurança do WordPress de vários sites em um único destino é o que transforma evento isolado em inteligência de ataque. Quando o mesmo IP tenta força bruta em dez sites da sua carteira na mesma madrugada, só a visão agregada revela o padrão; olhando site por site, cada falha parece ruído local sem importância.

A prática é enviar os eventos de cada instalação para um syslog comum ou um arquivo rotacionado central, e ali cruzar IP de origem, rota explorada e horário entre todos os sites. Esse agregado externo é o que sobrevive quando um WordPress é comprometido, porque o atacante apaga o log local mas não alcança a cópia centralizada. Na prática, vemos no suporte da FULL que quem gerencia muitos sites detecta a campanha de ataque dias antes ao ler o log central, e fecha a porta nos demais sites antes do incidente se repetir. O log isolado conta uma história; o log correlacionado conta a campanha inteira.

Ative todas as camadas com o plano certo

Ativar as cinco camadas de logs de segurança do WordPress avulso significa instalar e configurar plugin por plugin. No plano PRO da FULL, o All in One Security e outros 16 plugins premium vêm em um clique, por R$849 cobrindo dez sites, o que dá R$85 por site, contra licenças avulsas que cobram esse valor por uma única ferramenta.

A gente vê no suporte da FULL que o custo de não ter log é sempre maior: a limpeza de um site sem histórico custa mais horas que a assinatura anual inteira. Compare os planos em FULL.services/planos e ative a auditoria sem montar o stack peça por peça.

Resumo técnico das cinco camadas de log

Perguntas frequentes sobre logs de segurança do WordPress

Próximos passos para auditar seu WordPress

Logs de segurança do WordPress são a diferença entre reagir no escuro e ter a linha do tempo exata de cada evento sensível do site. Comece ativando o registro de login do All in One Security, suba até a integridade de arquivos e termine exportando os eventos para fora do banco com 90 dias de retenção. Cruze o log de aplicação com o log de servidor e monitore CVE relevante para fechar a porta antes do incidente. Para continuar aprendendo, o FULL Academy reúne tutoriais, guias e reviews de segurança em um só lugar, e o guia de segurança WordPress aprofunda cada camada. Se quer escanear o site agora e descobrir plugins vulneráveis, use o FULL Scan, gratuito e sem instalação.