O pingback WordPress usa XML-RPC para expor seu site a varreduras e DDoS. Desative o recurso por filtro no functions.php ou por plugin, mas antes teste se o XML-RPC responde e verifique se algum app ou integração depende dele. Em vários sites, audite e aplique em lote.
A segurança WooCommerce começa pelo checkout e pelas contas de cliente, onde a fraude entra, e só depois sobe para o admin e o banco. Blinde nessa ordem: antifraude e revisão de pedidos, 2FA nos acessos, permissões enxutas e backups testados. Hardening de site institucional, como cache agressivo no carrinho, costuma quebrar a loja.
Antes de replicar um tema em vários sites, revise a origem do pacote, o escape na saída, o uso de eval e base64, as chamadas admin-ajax sem nonce e os scripts de CDN externa. O que passa no tema-base pode reabrir no child, então cada site exige rechecagem.
Um ataque força bruta WordPress aparece no log como rajadas de POST em wp-login.php e xmlrpc.php, de muitos IPs ao mesmo tempo. Trocar a senha não resolve. Bloqueie tentativas no servidor ou no plugin, desative xmlrpc sem uso e monitore a origem real.
Proteger WordPress de malware em vários sites exige camadas: bloqueie execução de PHP em uploads, padronize permissões de arquivos, ative WAF no servidor e só depois instale plugins de segurança site a site. Varreduras comparativas entre sites revelam o que já foi comprometido.
SQL injection no WordPress costuma vir de plugins e temas desatualizados. Para blindar vários sites, varra options, postmeta e usermeta em busca de payloads, atualize tudo e use prepared statements. Se a injeção já persistiu, restaurar backup costuma ser mais seguro que limpar.
Um site WordPress hackeado costuma se manifestar por redirects, links injetados ou logins estranhos. Antes de limpar, confirme o comprometimento, isole o vetor e verifique se o mesmo ataque atingiu outros sites no mesmo servidor. Só então escolha entre limpar no lugar ou restaurar backup.
Auditar logins WordPress em vários sites é listar todos os administradores via WP-CLI ou banco, cruzar cada conta com quem ainda trabalha no projeto, remover ou rebaixar o que não pertence mais e padronizar e-mail de recuperação e 2FA em lote. O trabalho é de inventário, não de senha.
Em vários sites, priorize patches com exploit ativo (aplicar em minutos), deixe os demais para a janela de manutenção e teste em um site espelho antes de espalhar. Atualização automática sem verificação é o que costuma quebrar site que ninguém está olhando.
Aplique em lote o que é reversível e não depende de tema: forçar HTTPS, limitar tentativas de login, desabilitar edição de arquivos pelo painel e revisar permissões. Regras de WAF, bloqueio de XML-RPC e troca de prefixo de tabela exigem teste site a site, porque quebram plugins e integrações.
