# SQL injection no WordPress: Os 3 tipos e 5 defesas 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.

SQL injection no WordPress: os 3 tipos e como detectar
Tipo	Como o dado retorna	Sinal de detecção
In-band (clássica)	Dados aparecem direto na resposta da página, via UNION ou erro.	Mensagens de erro SQL visíveis ou conteúdo estranho na tela.
Blind (cega)	Nenhum dado na tela; o atacante infere por verdadeiro ou falso.	Picos de requisições GET sequenciais no log de acesso.
Out-of-band	Resposta sai por outro canal, como uma requisição DNS externa.	Conexões de saída inesperadas do servidor para domínios externos.

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

O que é SQL injection no WordPress e como o ataque acontece?

SQL injection é a falha em que uma entrada do usuário, como um campo de busca, é interpretada como comando SQL pelo banco. No WordPress, acontece quando um plugin concatena dados de `$_GET` direto na query sem `$wpdb->prepare()`. O atacante anexa algo como `UNION SELECT` e lê a tabela wp_users. O núcleo do WordPress é protegido; o vetor quase sempre é código de terceiros.

Por que o $wpdb->prepare protege contra SQL injection e a concatenação não?

Porque o `$wpdb->prepare()` usa placeholders (`%s`, `%d`) que separam o dado da instrução: o MySQL trata o valor como texto puro, nunca como comando. A concatenação simples gruda a entrada na string final, então qualquer aspas ou `UNION` digitado vira parte da query. A diferença é estrutural, não cosmética, conforme o manual oficial da classe wpdb.

É possível sofrer SQL injection sem nenhum plugin instalado no WordPress?

Não, o núcleo sozinho é suficiente para barrar o ataque: o WordPress usa `wpdb` e prepared statements de forma consistente desde versões antigas. Quando o site sofre SQL injection, o vetor quase sempre é um plugin ou tema de terceiros que monta queries inseguras, ou código customizado mal escrito. Por isso, evite plugins abandonados e mantenha tudo atualizado, como mostram os CVEs já corrigidos no ecossistema.

Qual a diferença entre SQL injection in-band, blind e out-of-band?

A diferença está em como o dado volta, e a blind é a mais perigosa por ser silenciosa. Na in-band, o resultado aparece na própria página, via UNION ou erro. Na blind, nada aparece na tela: o atacante infere por respostas verdadeiro ou falso, um caractere por vez. Na out-of-band, a resposta sai por outro canal, como uma requisição DNS. Para detectar a blind, monitore picos de requisições GET sequenciais no log.

Como detectar se meu WordPress já sofreu um ataque de SQL injection?

Revise o log de acesso atrás de requisições GET com `UNION`, `SELECT` ou aspas codificadas, além de picos de requisições sequenciais que indicam injeção blind. Verifique usuários administradores não reconhecidos na tabela wp_users e rode um scanner como o FULL Scan. Em servidor, conexões de saída inesperadas sugerem variante out-of-band. Atualizar tudo é o primeiro passo após a suspeita.

--- ## 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.