Ops! Um bug de SQL injection acabou de forçar um patch de emergência no core do WordPress na semana passada.
Em 17 de julho, o WordPress lançou uma versão de emergência para corrigir uma falha de execução remota de código não autenticada no core, acessível via SQL injection que um atacante anônimo pode explorar em uma instalação padrão. O WordPress.org chegou a ativar atualizações automáticas forçadas devido à gravidade. A Searchlight Cyber, que a reportou, estima que mais de 500 milhões de sites rodam WordPress. Se você for afetado, atualize para a Versão 7.0.2 e 6.9.5 para a ramificação mais antiga.
SQL injection, também estilizado como SQLi, é uma vulnerabilidade antiga com uma correção fácil, então as pessoas presumem que está morta. Mas, como acabamos de ser lembrados, não está.
SQL injection: Das origens humildes aos dias atuais
SQL injection e suas soluções fazem parte das aulas de Introdução à Ciência da Computação. Lembro-me de aprender sobre prompt injection na universidade há mais de uma década, e, honestamente, é a única vulnerabilidade baseada em aplicação que me lembro de terem ensinado (acho que eles passaram para outros tópicos depois de cobri-la, ou talvez eu não tenha prestado atenção depois disso).
SQL injection foi documentada publicamente em 1998 pelo pesquisador conhecido como rainforest puppy. A correção que resolve a maioria dos problemas de SQLi, as prepared statements, foi descoberta cerca de um ano depois. A correção é mais antiga do que muitos engenheiros da empresa. Use consultas parametrizadas e mantenha a entrada do usuário como dados. Mas mesmo com uma correção disponível, SQL injections ainda acontecem.
Com base nos dados do GitHub Advisory Database, filtrando os avisos por CWE e contando por ano:
O número de alertas de SQL injection aumentou a cada ano completo de 2023 a 2025, de 2.096 para 2.850. As três classes de injeção mais antigas juntas, SQL injection, injeção de comando e path traversal, ainda representam mais de um em cada dez de tudo o que foi relatado.
A OWASP moveu a injeção da terceira para a quinta posição em seu Top 10 de 2025, mas não porque os problemas foram resolvidos. A categoria geral de injeção ainda apresenta mais CVEs relatados do que qualquer outra, com mais de 60.000 registros. Desses, o SQL injection sozinho totalizou mais de 14.000. Nas varreduras de Mackenzie em repositórios de código fechado, 20% dos projetos apresentaram pelo menos uma vulnerabilidade de SQL injection em sua primeira varredura.
Por que o SQL injection se recusa a morrer
Primeiro, para deixar claro, as pessoas cometem erros ao escrever código. Acontece. Então, de vez em quando, um SQLi vai escapar. Mas os sistemas modernos que deveriam nos ajudar não o fazem cem por cento do tempo, e podem até nos levar a cometer erros diferentes.
Por exemplo, frameworks mais recentes possuem métodos para ajudar a prevenir SQL injection. ORMs como Django, Hibernate e ActiveRecord parametrizam por padrão, o que convence muitas equipes de que o problema está resolvido. Mas se alguém recorrer a uma consulta SQL bruta ou usar um método inseguro, a proteção desaparece.
O CVE-2024-42005 do Django é um exemplo. Dois dos próprios métodos de consulta do Django, usados para ler campos de uma coluna JSON, inseriam os nomes dos campos passados diretamente no SQL sem sanitizá-los. Assim, um atacante que controlasse um nome poderia controlar parte da consulta, através de um método que as equipes presumiam ser seguro.
Por outro lado, códigos muito antigos também são um problema, com o código legado carregando essas falhas por décadas. As equipes confiam em um WAF e assumem (rezam) que ele captura tudo. Embora a correção exista há mais de 25 anos, aplicá-la em cada consulta, cada endpoint e cada canto legado, todas as vezes, é um trabalho tedioso que nunca foi totalmente concluído em todas as bases de código existentes. A forma como Mackenzie Jackson, nosso CTO de campo, coloca a questão, é que isso deixou de ser um problema técnico e se tornou um problema de cultura, processo e educação.
E, claro, IA.
A IA também escreve SQLi
A esperança óbvia é que assistentes de codificação de IA, treinados com décadas de exemplos, parassem de reproduzir um bug de 1998. Mas, como sabemos, a IA não escreve código perfeito.
Podemos analisar isso quantitativamente. O estudo de 2021 Asleep at the Keyboard da NYU e Cornell gerou 1.689 programas do GitHub Copilot em cenários de fraquezas comuns e descobriu que cerca de 40% eram vulneráveis, com injeção de SQL e injeção de comando entre as mais frequentes. O próprio teste de Mackenzie se enquadra na mesma faixa. Executando um prompt no ChatGPT algumas centenas de vezes, cerca de 12% dos resultados eram injetáveis, próximo à taxa em código aberto.
Mas por quê? Os modelos aprendem com código público que contém essas falhas, então eles as reproduzem com uma frequência semelhante. A IA lida com injeção de SQL melhor do que com bugs que dependem muito de contexto, como cross-site scripting, onde o mesmo relatório encontrou a maioria das saídas inseguras. A IA continua a melhorar, então esses números estarão desatualizados em seis meses, mas podemos esperar que a IA ainda escreva isso acidentalmente, assim como nós.
E agora, mais "vibe-coders" e pessoas menos treinadas tecnicamente estão escrevendo código. Eles são menos propensos a reconhecer injeções de SQL (se é que sabem procurá-las), então mais código pode entrar na base de código da empresa sem olhos treinados para garantir que esse problema seja considerado.
É por isso que é preciso ter um backstop
Mesmo que você faça tudo certo, como consultas parametrizadas em todos os lugares, allowlists em cada entrada, e o que mais... Você ainda vai querer proteção em tempo de execução. A sanitização perfeita em todos os endpoints, para sempre, não é algo real. SQLi pode até acontecer em uma dependência vulnerável que você não controla (ou, digamos, no site padrão de um provedor de hospedagem), o que está além de qualquer coisa que você possa gerenciar razoavelmente.
Aikido Zen é um firewall incorporado no aplicativo que roda dentro da sua aplicação e monitora a entrada do usuário enquanto ela se move em direção a um coletor de dados, como uma consulta de banco de dados ou leitura de arquivo.
Quando um payload de ataque está prestes a alcançar um desses locais, Zen o bloqueia no momento, com contexto de aplicativo suficiente para distinguir um ataque de uma string de busca que por acaso se parece com um.
Ele também cobre falhas que chegam através de dependências, onde seus próprios padrões de codificação não alcançam. Considere-o como um backstop de tempo de execução para quando a codificação segura falha, o que na prática sempre acontece. Zen é RASP, que entende entradas perigosas em nível de código. Isso é diferente de um WAF que bloqueia entradas suspeitas no nível da rede, o que é menos preciso, então tem uma tendência a bloquear demais. Eu entro em muito mais detalhes sobre isso em nossa postagem sobre WAF vs RASP vs ADR.
Um firewall incorporado no aplicativo como o Zen fica entre wp2shell e um site WordPress sem patch. Zen é construído para bloquear a injeção de SQL na qual essa falha se baseia, então um site aguardando a atualização ainda tinha uma defesa enquanto o patch era lançado.
Detecte injeções de SQL na sua branch de desenvolvimento
O tempo de execução é a rede de segurança, mas a prevenção é, claro, o padrão ouro. Idealmente, encontramos e removemos todas as injeções de SQL no código.
Análise estática como SAST detecta muitas injeções de SQL, o tipo simples onde a entrada é executada em uma consulta sem uma declaração parametrizada. Não teria detectado esta. O core do WordPress é tão escaneado quanto um software pode ser, e este bug não foi detectado. Neste caso, a injeção só se torna explorável quando uma requisição em lote malformada desalinha a contabilidade interna do WordPress, de modo que o valor atinge o banco de dados por um caminho que ignora a limpeza. Essa é uma interação entre requisições que um scanner estático não consegue percorrer. Encontrar esta vulnerabilidade levou um modelo de fronteira executando quatro agentes por seis horas.
A injeção comum é trabalho do seu scanner. O tipo oculto e dependente de lógica exige cada vez mais uma IA para encontrá-lo antes que outra pessoa o faça, o que é o caso para pentest de IA do Aikido e apontá-lo para o seu próprio código da mesma forma que este pesquisador apontou um para o WordPress. Aikido tem pentest contínuo com Aikido Infinite, o que pode ajudar você a verificar regularmente qualquer novo SQLi que possa tentar passar pela revisão de código.
Little Bobby Tables ainda está vivo e saudável. Leve-o a sério, e proteja seu código, mesmo as coisas chatas.
