Drupal core - Highly critical - SQL injection - SA-CORE-2026-004
Corrija agora. Ela está sob exploração confirmada pelo CISA e tem exploit funcional público.
Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.
Resumo
Falha de SQL injection na API de abstração de banco de dados do Drupal core, explorável por usuários anônimos, mas restrita a sites que usam PostgreSQL como backend — MySQL, MariaDB e SQLite não são afetados pela injeção em si. A CISA confirmou exploração ativa e incluiu a CVE no catálogo KEV com prazo de correção de apenas 5 dias, sinal de que ataques automatizados já estão em curso.
Detalhamento técnico
A vulnerabilidade (CWE-89) está na camada de abstração de banco de dados do Drupal core, o componente responsável por sanitizar queries antes de enviá-las ao driver do banco. O advisory não detalha o ponto exato do código, mas confirma que requisições especialmente forjadas conseguem contornar essa sanitização quando o backend é PostgreSQL, injetando SQL arbitrário na query final.
Como é explorada
O vetor é uma requisição HTTP especialmente forjada contra a aplicação Drupal, sem necessidade de autenticação — a Drupal Security Team afirma explicitamente que 'this vulnerability can be exploited by anonymous users'. A pré-condição real que reduz drasticamente o alcance da falha é o backend de banco: só importa para instalações rodando PostgreSQL; sites em MySQL/MariaDB (a maioria das instalações Drupal) não sofrem a injeção, embora ainda precisem atualizar por causa das dependências de terceiros incluídas no mesmo release. Nos sites PostgreSQL vulneráveis, o impacto vai de divulgação de informação (dump de dados via injeção) a escalonamento de privilégio e, em cenários específicos, execução remota de código — a exploração bem-sucedida depende de quais campos/parâmetros da aplicação repassam entrada não confiável para a camada de abstração vulnerável. A CISA e o próprio Drupal.org confirmaram tentativas de exploração em massa a partir de 22 de maio de 2026, dois dias após a divulgação, o que elevou a pontuação de risco do advisory.
Versões
Como se proteger
A correção definitiva é atualizar para a versão fixa do branch em uso: 11.3.10 (para 11.3.x), 11.2.12 (para 11.2.x), 11.1.10 (para 11.1.x ou 11.0.x), 10.6.9 (para 10.6.x), 10.5.10 (para 10.5.x) ou 10.4.10 (para 10.4.x ou anterior). Branches já em fim de vida — 11.1.x, 11.0.x, 10.4.x e anteriores, além de Drupal 8 e 9 (ambos EOL) — não recebem cobertura de segurança oficial; o Drupal Security Team publicou patches manuais para Drupal 9.5 e Drupal 8.9 como esforço pontual dada a severidade, mas quem está nessas versões continua exposto a outras vulnerabilidades já conhecidas e não corrigidas nesses ramos. Não existe workaround de configuração publicado pelo fornecedor para neutralizar a injeção sem atualizar o código — a única mitigação real para quem não pode atualizar imediatamente é isolar ou monitorar intensivamente instâncias PostgreSQL expostas.
Como detectar
Não há indicador de comprometimento específico publicado pelo Drupal Security Team ou pela CISA além da confirmação genérica de 'tentativas de exploração detectadas in the wild' a partir de 22/05/2026. Times de SOC devem monitorar logs de acesso web por requisições anômalas com payloads típicos de SQL injection direcionadas a endpoints do Drupal em instâncias PostgreSQL, e revisar logs do próprio PostgreSQL por queries malformadas ou erros de sintaxe originados da aplicação, já que não existe assinatura oficial de exploração divulgada.