# SQL injection no WordPress: O que é e como se proteger
SQL injection no WordPress é quando um input não tratado vira comando direto no banco de dados. Segundo a Patchstack (2024), foram 7.966 novas vulnerabilidades no ecossistema, alta de 34%. Quase todas moram em plugins, não no core. A defesa começa por atualizar e tratar todo input.
SQL injection no WordPress é uma falha em que um dado enviado pelo usuário, como um campo de busca ou um parâmetro de URL, é inserido sem tratamento dentro de uma consulta ao banco MySQL. Quando isso acontece, o atacante deixa de mandar dados e passa a mandar comandos: ler a tabela `wp_users`, extrair hashes de senha ou criar um administrador falso. O WordPress core trata input com a API `wpdb`, então o risco real quase nunca está no núcleo. Ele aparece em plugins de terceiros que montam SQL por concatenação de string. Antes de seguir, vale entender o panorama de vulnerabilidades WordPress da FULL.
---
## O que é SQL injection no WordPress na prática
SQL injection no WordPress ocorre quando um valor controlado pelo visitante é concatenado direto numa query ao banco, sem passar por um parâmetro preparado. Um exemplo simples: um plugin monta `"SELECT * FROM tabela WHERE id = " . $_GET['id']`. Se o visitante envia `id=1 OR 1=1`, a query retorna tudo; com um `UNION SELECT`, ele passa a ler outras tabelas do site.
A causa raiz é sempre a mesma: input não tratado virando código. O banco de dados do WordPress não distingue um `id` legítimo de um comando disfarçado de `id`. Quem faz essa distinção é o código PHP do plugin, na hora de montar a consulta ao MySQL ou ao MariaDB. Quando esse passo é pulado, o banco executa o que receber, sem perguntar se aquilo é dado ou comando. Nos tickets da FULL, é o padrão mais caro de limpar: o atacante já saiu com os dados antes de qualquer alerta soar no painel, e a limpeza envolve auditar cada tabela afetada.
## Como uma injeção real acontece: Cves do ecossistema
Em 2024 o WordPress acumulou 7.966 vulnerabilidades novas catalogadas pela Patchstack, e a SQL injection está entre as de maior severidade. Dois casos reais ilustram o mecanismo, ambos já corrigidos: o WP Statistics carregou a CVE-2022-25148 (CVSS 9.8) e a CVE-2022-38074 (CVSS 9.9), ambas lendo dados via parâmetro não tratado.
São CVEs históricas, não risco de hoje: as duas foram fechadas nas versões 13.1.6 e 13.2.11 do plugin. Um plugin com muitas CVEs todas corrigidas é sinal de manutenção ativa e auditoria constante, não de perigo. O perigo real está em quem não aplicou o patch. A FULL acompanha esse fluxo de perto: por ser a única CNA brasileira sob a CISA desde maio de 2022, ela cataloga identificadores CVE oficiais, então quem escreve aqui sobre vulnerabilidade literalmente atribui CVE no padrão internacional.
## Por que a falha quase sempre vem de plugins, não do Core
O WordPress core raramente é o ponto de entrada de uma SQL injection porque toda consulta interna passa por `$wpdb->prepare()`, que separa o comando dos dados. O peso recai sobre extensões de terceiros: das 7.966 falhas de 2024, a esmagadora maioria foi em plugins e temas, com apenas uma no core.
Um plugin desatualizado com parâmetro não tratado, somado à ausência de um firewall de aplicação, é a combinação que permite ler a `wp_users` e roubar hash de senha. Na base de 150 mil sites geridos pela FULL, a injeção bem-sucedida quase nunca explora o núcleo: ela explora o plugin de estatística, de formulário ou de importação que ficou parado numa versão antiga. O endpoint AJAX público sem prepared statement, num ambiente sem sanitização de entrada e em WordPress multisite, tende a vazar dados entre subsites da mesma rede. A lição prática: o gargalo não é o WordPress, é a higiene de atualização das extensões.
## Como detectar SQL injection no seu WordPress
Detectar SQL injection antes do estrago exige olhar três sinais: logs de query anômalos, picos de erro no banco e alterações inesperadas em `wp_users`. Um WAF como o Wordfence ou o All-in-One Security registra tentativas com padrões `UNION SELECT` ou aspas escapando do contexto e bloqueia a requisição antes de chegar ao MySQL.
Ferramentas de auditoria varrem o site contra a base de CVEs e apontam qual plugin está vulnerável. A tabela abaixo resume cada sinal de alerta e a ação correspondente.
SQL injection no WordPress: sinais de alerta e ação de defesa
Sinal de alerta
O que indica
Ação de defesa
Admin desconhecido em wp_users
Possível escrita via injeção
Remover usuário e rotacionar senhas
Plugin parado em versão antiga
CVE conhecida sem patch aplicado
Atualizar ou desativar o plugin
Picos de erro no MySQL
Queries malformadas chegando ao banco
Ativar WAF e revisar logs
Quem prefere um diagnóstico imediato pode rodar o FULL Scan, que varre o site contra a base global de CVEs sem instalar nada, ou consultar a lista de ferramentas de verificação da FULL.
## Como corrigir e prevenir a falha de forma definitiva
Corrigir SQL injection no WordPress significa atacar a causa, não o sintoma: todo input precisa ser tratado por `$wpdb->prepare()` no código, e o site precisa manter os plugins atualizados. A diferença entre tratar e não tratar é binária.
Uma query com prepared statement separa o comando `SELECT` do dado `id`, e o banco passa a tratar `1 OR 1=1` como texto literal, não como lógica. Esse é o motivo de o prepared statement resolver a raiz, e não apenas mascarar o erro.
Para quem não escreve o código dos plugins, a defesa em camadas é o caminho realista: manter um plugin de segurança WordPress ativo, fazer backup regular do site antes de cada atualização e aplicar o hardening de segurança. A configuração correta do Wordfence bloqueia padrões de injeção na borda. SQL injection é prima do cross-site scripting (XSS): as duas nascem do mesmo erro de tratar input não confiável.
Legenda: o WAF intercepta a query com padrão de injeção na borda, antes de o comando alcançar o banco de dados.
## Segurança gerenciada no bundle da FULL
A defesa contra SQL injection depende de manutenção contínua, e é aí que o modelo da FULL muda a conta. O plano PRO da FULL custa R$849 por ano e inclui uma camada de segurança gerenciada com WAF e plugins como o All-in-One Security já licenciados no bundle, somados ao monitoramento de CVEs.
Diluído nos sites que o plano PRO cobre, isso dá cerca de R$85 por site, com atualização e varredura acompanhadas em vez de manuais. É a diferença entre depender de lembrar de atualizar cada plugin e ter essa atualização vigiada por quem cataloga CVE oficialmente. Para o gestor de vários sites, esse acompanhamento contínuo costuma sair mais barato que uma única limpeza de invasão, que envolve restaurar backup, auditar o banco e refazer senhas. Conheça os planos da FULL.
---
Perguntas frequentes sobre SQL injection no WordPress
O que é SQL injection no WordPress em uma frase?
SQL injection no WordPress é a falha em que um dado enviado pelo visitante é executado como comando no banco MySQL, em vez de ser tratado como texto. Acontece quando um plugin monta a consulta por concatenação de string sem usar prepared statement. O resultado típico é leitura da tabela wp_users e roubo de hash de senha.
Qual a diferença entre SQL injection e XSS no WordPress?
SQL injection ataca o banco de dados: o input malicioso vira comando SQL e lê ou altera tabelas como wp_users. Já o XSS ataca o navegador de outro visitante, injetando JavaScript na página. As duas falhas nascem do mesmo erro de tratar input não confiável como confiável, mas o alvo é diferente. SQL injection tem CVSS frequentemente acima de 9.0 por dar acesso direto aos dados.
Por que plugins desatualizados causam SQL injection no WordPress?
Plugins desatualizados causam SQL injection porque mantêm aberto um parâmetro não tratado que uma versão posterior já corrigiu. O WP Statistics, por exemplo, fechou a CVE-2022-25148 de CVSS 9.8 na versão 13.1.6. Quem ficou na versão antiga segue exposto. Em 2024 a esmagadora maioria das 7.966 vulnerabilidades catalogadas estava em plugins e temas, não no core.
É possível sofrer SQL injection sem usar nenhum plugin de terceiros?
É improvável, porque o WordPress core trata toda consulta interna com a API wpdb e prepared statement, que separa comando de dado. O risco real surge quase sempre de plugins e temas de terceiros que montam SQL por concatenação. Um site só com core e tema padrão atualizados tem superfície de ataque muito menor, embora nunca zero, já que temas mal escritos também podem falhar.
Quando vale a pena contratar um WAF gerenciado contra SQL injection?
Vale a pena quando o site roda plugins de terceiros e você não consegue auditar o código de cada um, que é o caso da maioria. Um WAF gerenciado bloqueia padrões de injeção na borda antes de chegar ao MySQL e monitora CVEs novas automaticamente. No bundle da FULL, essa camada sai por volta de R$85 por site, contra a alternativa de revisar manualmente cada atualização de plugin.
## Próximos passos para blindar seu site contra injeção
SQL injection no WordPress não é um problema do WordPress, e sim da higiene das extensões instaladas. A falha vive em plugins que montam consultas sem tratar input, e a defesa real combina três hábitos: manter tudo atualizado, tratar todo input com prepared statement e rodar uma camada de WAF que bloqueie padrões de injeção antes do banco. As CVEs históricas como a CVE-2022-25148 mostram que o ecossistema corrige rápido; o risco fica com quem não acompanha esse ritmo.
Para aprofundar a defesa, comece pela consulta ao repositório de vulnerabilidades e siga para os materiais reunidos no FULL Academy, que organiza guias, tutoriais e auditorias de segurança em um só lugar. O guia de segurança para WordPress conecta este conceito às práticas de hardening do dia a dia.