Como corrigir vulnerabilidade SQL Injection no WordPress
Perguntas frequentes
O que o invasor consegue fazer com um SQL Injection?
Ele pode ler dados sensíveis (hashes de senha na wp_users, dados de clientes), criar um administrador oculto, alterar conteúdo e até apagar tabelas. Como o SQLi dá acesso direto ao banco, é uma das falhas mais graves de um site WordPress.
O $wpdb->prepare() sozinho resolve o SQL Injection?
Resolve a maioria dos casos, porque separa o comando SQL dos dados via placeholders. Mas nomes de coluna e cláusulas de ordenação não vão em placeholder; para esses, use uma allowlist. Prepare nos valores mais allowlist na estrutura cobre a falha por completo.
Como descubro qual plugin tem a vulnerabilidade SQLi?
Rode o WPScan ou um scanner que cruza seus plugins com bancos de vulnerabilidades conhecidas. Ele aponta o componente, a versão afetada e a versão que corrige. Com isso, basta atualizar o plugin ou substituí-lo se estiver abandonado.
Um plugin de segurança bloqueia o SQL Injection?
O WAF detecta e barra muitos payloads conhecidos, o que ajuda como camada de defesa. Mas ele não corrige o código vulnerável. A solução de raiz é atualizar o plugin com a falha ou reescrever a consulta com $wpdb->prepare().
Vi o erro "error in your SQL syntax" na tela. É SQL Injection?
Pode ser um sinal de que uma entrada não tratada chegou à consulta, o que indica exposição a SQLi. Independente da causa, vaze de erro de SQL na tela é perigoso: desative o WP_DEBUG em produção e investigue a consulta que recebe o parâmetro manipulado.
Corrigi a falha mas apareceu um admin que não criei. O que faço?
O invasor provavelmente já explorou o SQLi antes da correção. Remova os usuários admin desconhecidos, regenere as SALT keys do wp-config.php, troque todas as senhas e audite o banco. Fechar a brecha não desfaz os acessos já criados; é preciso limpá-los à mão.














