Frameworks de abstração de banco de dados prometem que SQL injection é um problema resolvido. O CVE-2026-9082 prova que essa promessa descansa na premissa de que a abstração está correta para todos os drivers, todos os padrões de input, todos os caminhos de código. Quando a abstração falha, a queda é mais dura porque ninguém espera por ela.
O bug que não deveria existir
A Database Abstraction API do Drupal existe para impedir SQL injection. É a camada que separa o desenvolvedor do SQL raw, que sanitiza placeholders, que garante que input do usuário nunca vira código executável. Exceto quando vira.
O PostgreSQL EntityQuery condition handler processa filtros via JSON:API. Quando um atacante envia filter[name][condition][value][]=v, o PHP parseia isso em arrays associativos onde as chaves são controladas pelo atacante. O código em Condition.php faz foreach(condition['value'] as key => value) e concatena key no nome do placeholder SQL: LOWER(:db_placeholder_key).
Chaves controladas pelo atacante no nome do placeholder. Isso escapa da gramática preparada e injeta SQL raw na cláusula WHERE. A abstração que deveria impedir SQL injection é exatamente o vetor de SQL injection.
O fix: array_values(). Uma função. Strip das chaves, força índices numéricos. O patch inteiro é uma linha. O que é mais revelador: a simplicidade da correção ou a fragilidade que ela expõe? "Quase correta" é "totalmente vulnerável".
O caminho de ataque: anônimo, rápido, escalável
JSON:API é habilitado por default desde Drupal 8.8. Os endpoints /user/login?_format=json e os filtros JSON:API são os dois caminhos anônimos confirmados que alcançam o code path vulnerável. Sem autenticação. Sem sessão. Sem privilégio. Apenas um HTTP request craftado.
O PoC público gera HTTP 500 com SQLSTATE[HY093] — prova de que o payload foi concatenado no SQL. A distância entre esse erro e a extração de dados é curta. A distância para RCE é ainda menor.
No PostgreSQL, pg_execute_server_program permite COPY (SELECT ...) TO PROGRAM 'sh -c "cmd"'. O usuário de banco do Drupal tem privilégios elevados para schema migrations. A cadeia completa: SQL injection → dump da tabela users → escrita de backdoor PHP no webroot → login como admin → RCE. Em automação, segundos. Um script que percorre essa cadeia não precisa de intervenção humana.
Os números que importam
Imperva registrou 15.000+ tentativas contra aproximadamente 6.000 sites em 65 países nas primeiras 48h. 50% dos ataques concentrados em gaming e financial services — setores onde dados de usuários e transações financeiras são o alvo principal.
Drupal estimou que menos de 5% das instalações usam PostgreSQL. Mas Drupal roda em centenas de milhares de sites — governo, universidades, enterprise. 5% ainda são milhares de alvos. E esses alvos tendem a ser os maiores: governos e grandes organizações frequentemente escolhem PostgreSQL por requisitos de compliance e licenciamento.
CISA adicionou o CVE ao KEV (Known Exploited Vulnerabilities). Prazo federal para correção: 27 de maio. Quando o governo dos EUA dá um prazo, é porque o risco é real e a exploração está acontecendo.
A discrepância que engana
Drupal classificou 23/25 — "Highly Critical". A descrição: "all non-public data accessible, all data modifiable or deletable". NVD atribuiu CVSS 6.5 — impacto "Low".
Quando o vendor diz "todos os dados não-públicos acessíveis" e o NVD diz "impacto baixo", confie no vendor. O NVD não modela RCE via COPY TO PROGRAM. O scoring do CVSS não captura cadeias de exploração que cruzam camadas — do banco de dados ao sistema operacional. Essa discrepância não é acadêmica: equipes de segurança que priorizam por CVSS vão subestimar o risco. Equipes que priorizam pela classificação do vendor vão agir corretamente.
Nós vemos isso repetidamente na nossa operação: scores do NVD que não refletem a realidade de exploração. O CVSS é um input, não um veredito. A classificação do vendor, o contexto da infraestrutura e a existência de cadeias de exploração públicas são indicadores mais confiáveis.
A história se repete
O Drupalgeddon de 2014 (CVE-2014-3704) estava na mesma camada de abstração. Mesmo resultado: SQL injection através da API que deveria impedir SQL injection. A mesma premissa quebrada. A mesma confiança mal colocada.
Doze anos depois, a história se repete. Não porque os desenvolvedores do Drupal são negligentes — são excelentes. Repete porque a premissa de que uma camada de abstração cobre todos os casos é estruturalmente frágil. Cada novo driver, cada novo formato de input, cada novo code path é uma superfície de ataque que a abstração não testou. O fato de funcionar para 95% dos casos não protege os 5% restantes — e os 5% restantes podem ser os mais críticos.
A lição não é "não use abstrações". A lição é: abstrações reduzem risco, não eliminam. E quando o risco residual se materializa, você precisa de uma camada independente que funcione quando a abstração falha.
Defesa em profundidade, não confiança em camada única
O patch é necessário e urgente. Mas patch é reativo — você aplica depois que a vulnerabilidade é descoberta, depois que os ataques começam, depois que o CISA adiciona ao KEV. A janela entre a divulgação e a correção é onde os danos acontecem.
Um WAF com regras de SQL injection bloqueia os payloads antes que cheguem à aplicação. Não substitui o patch, mas protege durante a janela crítica. E mais importante: protege contra a próxima vulnerabilidade na mesma camada. Porque se a história se repete a cada 12 anos na mesma API, a próxima falha de abstração não é uma questão de "se", é uma questão de "quando".
Na Tech86, operamos com o princípio de que nenhuma camada de proteção é suficiente por si só. A abstração do framework é a primeira linha. O WAF é a segunda. O monitoramento de anomalias é a terceira. Quando uma falha, as outras continuam de pé. É isso que chamamos de Blindagem Perímetro — e é exatamente o tipo de proteção que o CVE-2026-9082 torna evidente.