SQL Injection no WordPress: como corrigir a falha

Tipo Seguranca

Nome do erro Vulnerabilidade SQL Injection EN: SQL Injection vulnerability

Severidade Crítico

Descrição Uma vulnerabilidade de SQL Injection no WordPress permite que um invasor injete comandos SQL através de uma entrada mal tratada e leia ou altere o banco de dados. Corrigir significa achar a consulta vulnerável, usar consultas preparadas com $wpdb->prepare() e atualizar o plugin ou tema que abriu a falha.

O que é a vulnerabilidade SQL Injection?

SQL Injection (SQLi) é uma falha em que dados controlados pelo atacante entram numa consulta ao banco sem tratamento, permitindo que ele altere o comando SQL executado. No WordPress, costuma surgir quando um plugin ou tema monta consultas concatenando entrada do usuário direto na string, em vez de usar consultas preparadas. Pela brecha, o invasor pode ler senhas e hashes da tabela wp_users, criar um admin oculto, exfiltrar dados de clientes ou apagar tabelas. É uma das falhas mais graves justamente porque dá acesso direto ao banco, o coração do site. A correção real é parametrizar a consulta, não filtrar o sintoma.

Como identificar

O scanner de segurança ou o WPScan reporta “SQL Injection” em um plugin ou tema instalado.
No log do servidor aparecem requisições com payloads como “‘ OR 1=1 –” ou “UNION SELECT” em parâmetros.
Erros do banco vazam na tela, como “You have an error in your SQL syntax”, ao manipular uma URL.
Surgem usuários administradores que você não criou ou posts/registros alterados sem explicação.

Antes de começar: Faça backup do banco antes de auditar e remover registros suspeitos. Se a injeção já criou ou alterou dados, apagar às cegas pode quebrar o site; salve uma cópia para reverter caso remova algo legítimo.

Como prevenir

Use sempre $wpdb->prepare() com placeholders em qualquer consulta que receba entrada do usuário
Mantenha plugins e temas atualizados e remova os abandonados sem correção de segurança
Use um WAF que bloqueie payloads de SQL Injection e limite as permissões do usuário do banco

Causa

Plugin ou tema que monta consultas SQL concatenando entrada do usuário direto na string da query.
Uso de $wpdb->query() com variável de $_GET ou $_POST sem passar por $wpdb->prepare().
Plugin desatualizado com uma vulnerabilidade SQLi conhecida e já catalogada (CVE/WPScan) sem correção aplicada.
Parâmetro numérico (id de post, página) usado na consulta sem validação nem cast para inteiro.
Código antigo que confia em escape manual frágil em vez de placeholders preparados pelo wpdb.

Como resolver

Identifique a origem da falha: rode o WPScan ou um scanner de segurança para descobrir qual plugin/tema tem a vulnerabilidade SQLi reportada e em qual versão ela foi corrigida.
Atualize o componente vulnerável: na maioria dos casos a brecha já tem correção. Atualize para a versão que fecha o SQL Injection; se o plugin foi abandonado, troque por uma alternativa mantida.
Use consultas preparadas no seu código: se a falha está em código próprio, reescreva toda consulta que recebe entrada do usuário usando $wpdb->prepare() com placeholders, nunca concatenação.
Valide e tipe os parâmetros: force inteiro em ids com absint() e use allowlist para nomes de coluna/ordenação, que não podem ir em placeholder. Rejeite qualquer valor fora do esperado.
Audite o banco e troque as credenciais: verifique usuários admin desconhecidos, revise wp_options, regenere as SALT keys do wp-config.php e troque as senhas de admin e do banco para invalidar acessos do invasor.

PHP

// Errado: concatena a entrada na query, abrindo SQL Injection
global $wpdb;
$id = $_GET['id'];
$wpdb->query( "SELECT * FROM {$wpdb->posts} WHERE ID = $id" );

// Certo: consulta preparada com placeholder (%d para inteiro, %s para string)
$id = absint( $_GET['id'] );
$resultado = $wpdb->get_results(
    $wpdb->prepare( "SELECT * FROM {$wpdb->posts} WHERE ID = %d", $id )
);

// String tambem vai em placeholder, nunca concatenada
$autor = $_GET['autor'];
$wpdb->get_results(
    $wpdb->prepare( "SELECT * FROM {$wpdb->posts} WHERE post_author = %s", $autor )
);

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.

Crítico

Como corrigir o checkout bloqueado pelo firewall do All in One Security no WooCommerce

O checkout bloqueado pelo firewall do All in One Security acontece quando uma regra avancada do AIOS inspeciona o POST da finalizacao de compra e devolve 403 Forbidden, impedindo o cliente de concluir o pedido. A causa quase sempre e o filtro de string avancado ou as regras 6G barrando a rota admin-ajax.php ou a Store API do WooCommerce.

Atenção

Como corrigir os cabeçalhos de segurança que não aplicam no WordPress com All in One Security

Os security headers no WordPress não aplicam quando você os adiciona via .htaccess no All in One Security, mas o servidor roda Nginx ou um proxy que ignora o .htaccess, quando outro componente já envia o mesmo cabeçalho, ou quando a regra foi colada no bloco errado do arquivo.

Grave

Como corrigir a enumeracao de usuários no WordPress com All in One Security

User enumeration no WordPress e quando um atacante descobre os nomes de login validos do site pela REST API, pela query de autor ou pelo XML-RPC, e o All in One Security bloqueia esses três vetores em poucos cliques antes que vire forca bruta.

Crítico

Como corrigir vulnerabilidade de plugin no WordPress atualizando com segurança

Uma vulnerabilidade de plugin no WordPress é uma falha de segurança conhecida (catalogada como CVE) numa versão específica do plugin. A correção real é atualizar para a versão que aplica o patch, depois de fazer backup e validar em ambiente de teste para não quebrar o site.

Crítico

Como corrigir o wp-config.php exposto no WordPress

O wp-config exposto é uma falha grave em que o arquivo de configuração do WordPress fica legível pela web, revelando a senha do banco e as chaves de autenticação. Ocorre quando o servidor entrega o conteúdo em texto, em vez de processá-lo como PHP, ou quando um backup do arquivo fica acessível por URL.

Grave

Como corrigir o bloqueio do sitemap entre All in One Security e Rank Math

O bloqueio do sitemap AIOS Rank Math acontece quando uma regra de firewall do All in One Security devolve 403 Forbidden ao acessar o sitemap_index.xml gerado pelo Rank Math. As regras avancadas de filtro de query string e de métodos do AIOS interpretam a URL do sitemap como tráfego suspeito e o Google passa a receber 'Couldn't fetch'.

Setores

Extensões

Integrações

Como corrigir vulnerabilidade SQL Injection no WordPress

O que é a vulnerabilidade SQL Injection?

Como identificar

Como prevenir

Causa

Como resolver

Perguntas frequentes

Itens relacionados

Como corrigir o checkout bloqueado pelo firewall do All in One Security no WooCommerce

Como corrigir os cabeçalhos de segurança que não aplicam no WordPress com All in One Security

Como corrigir a enumeracao de usuários no WordPress com All in One Security

Como corrigir vulnerabilidade de plugin no WordPress atualizando com segurança

Como corrigir o wp-config.php exposto no WordPress

Como corrigir o bloqueio do sitemap entre All in One Security e Rank Math

Setores

Extensões

Integrações

Extensões

Hero Sections

Seções de CTA

Login

Blog

Cabeçalhos

Seções de FAQ

Cadastro

Blog individual

Rodapés

Seções de contato

Seções de preços

Faixas

Portfólio

Seções de equipe

Números

Logotipos