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.

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

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.