SQL injection no WordPress é quando dados de um formulário viram comando de banco e expõem a tabela wp_users. Segundo o OWASP Top 10 (2021), 94% das aplicações foram testadas para injeção, com 274 mil ocorrências. O risco real mora em plugins que concatenam entrada sem prepared statement. A defesa é em camadas: código, atualização e firewall.

O SQL injection é a falha em que uma entrada do usuário não tratada é interpretada como parte de uma consulta SQL, permitindo ler, alterar ou apagar dados do banco. No WordPress, o núcleo é maduro e usa proteções nativas, então o vetor quase sempre é um plugin ou tema de terceiros que monta queries de forma insegura. Este guia explica como o ataque funciona, mostra os três tipos com CVEs reais do ecossistema e fecha com as cinco defesas que a gente vê funcionar no suporte. Para o panorama completo, vale o nosso guias de segurança WordPress da FULL.

SQL injection no WordPress: Como o ataque funciona

O SQL injection no WordPress nasce em 1 ponto: quando um plugin pega um valor de $_GET e concatena direto na consulta sem sanitização. Basta um único parâmetro de busca vulnerável para um atacante anexar UNION SELECT user_login, user_pass FROM wp_users e ler as credenciais da tabela wp_users. A entrada vira comando porque o banco não distingue dado de instrução: tudo o que chega na string final é executado pelo MySQL.

A regra de ouro contra SQL injection é nunca confiar em entrada externa. Toda string que vem do navegador precisa passar por sanitização e, na query, por prepared statement. O mecanismo é antigo, mas continua na lista do OWASP porque depende de disciplina de quem escreve o código, não de uma chave que se liga. Quem entende como o MySQL interpreta a consulta percebe por que um único parâmetro mal tratado abre a porta inteira.

Legenda: o dado do formulário percorre o PHP até o MySQL; sem prepared statement, ele é executado como comando.

Os 3 tipos de SQL injection que afetam plugins WordPress

Existem 3 tipos principais de SQL injection, e a diferença entre eles está em como o atacante recebe a resposta do banco de dados. O tipo define a estratégia de detecção e o tempo do ataque, de poucos segundos a várias horas no caso da injeção cega.

A injeção blind é a mais traiçoeira em plugins abandonados: o invasor lê o banco um caractere por vez com condições booleanas e, como nenhum erro 500 é gerado, o ataque vira ruído de tráfego comum.

Cves reais de SQL injection e falhas correlatas no WordPress

Vulnerabilidades de injeção no ecossistema WordPress não são teoria: elas têm ID, CVSS e versão afetada documentados. O caso mais citado é o CVE-2020-35489 no Contact Form 7, com CVSS 10.0, um upload sem restrição que permitia escrever arquivos e encadear comandos no servidor até versões anteriores à 5.3.2.

No WPForms, o CVE-2022-3574, CVSS 9.8, atingiu versões anteriores à 1.7.7. Ambos já estão corrigidos, o que mostra manutenção ativa, mas seguem reais em sites que não atualizam.

Aqui entra um dado que poucos têm: a FULL é a única empresa brasileira credenciada como CNA (CVE Numbering Authority) sob a CISA desde mai/2022, autorizada a atribuir IDs CVE oficiais. Por isso a leitura dos números é honesta: um plugin com muitos CVEs todos corrigidos sinaliza auditoria ativa, não abandono. O risco que importa é o CVE sem patch hoje. Vale comparar com os históricos de vulnerabilidades do Contact Form 7 antes de instalar.

SQL injection e o WAF: Por que a camada de rede importa

O firewall de aplicação é a primeira barreira contra SQL injection antes do payload chegar ao PHP. Nos últimos dias, segundo o Cloudflare Radar (janela de 09/06/2026), 16,4% dos ataques de camada de aplicação mitigados no Brasil foram barrados por WAF, contra 82,4% de DDoS.

Esse recorte mostra que um WAF com assinatura de SQLi e bloqueio de payloads UNION SELECT para o ataque na borda, sem depender de o desenvolvedor ter acertado cada query do código.

Um firewall de aplicação não substitui código seguro, mas reduz a janela de exposição enquanto o patch não sai. A gente vê no suporte da FULL que sites com WAF ativo absorvem boa parte das tentativas automatizadas de SQL injection que varrem a internet atrás de plugins desatualizados. O plano da FULL inclui o All in One Security justamente para essa camada de defesa, e dá para conferir o endurecimento da REST API no mesmo movimento.

As 5 defesas contra SQL injection no WordPress

A defesa contra SQL injection no WordPress funciona em cinco camadas que se reforçam, do código ao monitoramento. Nenhuma sozinha resolve: o prepared statement protege o código novo, mas não corrige o plugin antigo que você instalou. Aplicar as cinco em ordem cobre o que você escreve e o que terceiros trouxeram.

• Camada 1: prepared statement com $wpdb->prepare() em toda query com entrada. O placeholder %s ou %d separa dado de comando, conforme o manual oficial da classe wpdb.
• Camada 2: sanitização de toda entrada com sanitize_text_field() e checagem de tipo.
• Camada 3: menor privilégio no usuário MySQL, sem DROP ou GRANT onde só leitura basta.
• Camada 4: atualização de plugins e temas, que fecha CVEs antes que sejam explorados.
• Camada 5: WAF e monitoramento com firewall e log de acesso revisado para flagrar injeção blind.

Quem combina proteção do wp-config com essas cinco camadas fecha tanto o SQL injection quanto vetores vizinhos.

Ative a defesa completa com o plano PRO da FULL

Montar firewall, atualização gerenciada e monitoramento plugin a plugin custa caro e tempo. O plano PRO da FULL sai por R$849,90 e cobre até 10 sites, o que dá cerca de R$85 por site com o bundle de 17 plugins, incluindo o All in One Security para o WAF e o controle de login. A gente vê no suporte que a maior parte dos sites comprometidos por SQL injection rodava plugin desatualizado sem firewall na frente. Centralizar essa camada em FULL.services/planos resolve o ponto cego antes do ataque. Para uma verificação imediata, o FULL Scan aponta se algum plugin do seu site está vulnerável agora.

Perguntas frequentes sobre SQL injection no WordPress

Próximos passos para blindar seu WordPress contra injeção

O SQL injection continua relevante porque depende de código disciplinado, não de uma configuração mágica. Trate toda entrada como hostil, use $wpdb->prepare(), mantenha plugins atualizados e coloque um firewall na frente. Vetores como o cross-site scripting (XSS) e o CSRF costumam aparecer no mesmo site mal mantido, então uma auditoria ampla rende mais que correções isoladas. Comece checando o que já está instalado com o guia de como verificar vulnerabilidades no WordPress e aprofunde no guia de segurança para WordPress. Para continuar aprendendo, o FULL Academy reúne tutoriais, guias e reviews em um só lugar.