Falha crítica no núcleo do Drupal expõe sites com PostgreSQL a injeção de SQL

A vulnerabilidade CVE-2026-9082 afeta a API de abstração de banco de dados do Drupal e pode permitir divulgação de informação, elevação de privilégio e, em alguns cenários, execução remota de código em instalações que usam PostgreSQL.

Componente	API de abstração de banco de dados usada pelo núcleo do Drupal para validar consultas e aplicar sanitização contra injeção de SQL.
Vetor	Requisições especialmente construídas enviadas por usuário anônimo contra sites Drupal configurados com banco de dados PostgreSQL.
Impacto	Injeção de SQL arbitrária, com risco confirmado de divulgação de informação e, em alguns casos, elevação de privilégio, execução remota de código ou outros ataques derivados.
Prioridade	Atualizar imediatamente os ramos suportados do Drupal e revisar exposições públicas de instalações que usam PostgreSQL.
Versões	A correção foi disponibilizada para ramos suportados 11.3, 11.2, 10.6 e 10.5; Drupal 7 não é afetado, enquanto Drupal 8, Drupal 9, 11.1.x, 11.0.x, 10.4.x e anteriores estão fora de suporte.
Mitigação	Aplicar as versões corrigidas mais recentes, incluir as atualizações de segurança incorporadas de Symfony e Twig, e tratar correções manuais para versões sem suporte apenas como medida temporária.

Resumo técnico

O núcleo do Drupal recebeu atualizações de segurança para corrigir a vulnerabilidade CVE-2026-9082, classificada como altamente crítica no comunicado do projeto e registrada com pontuação CVSS 6.5. A falha está localizada em uma API de abstração de banco de dados que participa da validação de consultas e da sanitização usada para reduzir risco de injeção de SQL. O ponto central do problema é que, em determinadas condições, essa camada não impede que uma requisição malformada resulte em injeção de SQL arbitrária quando o site usa PostgreSQL como mecanismo de banco de dados.

A condição de exploração é relevante para priorização operacional: a falha pode ser acionada por usuários anônimos e afeta somente instalações Drupal com PostgreSQL. Isso desloca o risco para sites públicos, portais autenticáveis pela internet, APIs expostas e ambientes em que rotas do Drupal recebem entrada não confiável antes da autenticação. O impacto confirmado inclui divulgação de informação e, dependendo do desenho da aplicação, dos privilégios do usuário de banco de dados, dos módulos instalados e do fluxo de execução atingido, pode evoluir para elevação de privilégio, execução remota de código ou outros ataques sobre a aplicação.

A correção foi emitida para ramos suportados, incluindo 11.3, 11.2, 10.6 e 10.5. O projeto também indicou que as versões corrigidas carregam atualizações de segurança de componentes upstream, incluindo Symfony e Twig, o que torna inadequado aplicar apenas uma alteração parcial quando há pacote oficial disponível para o ramo em uso. Drupal 7 não é afetado por essa vulnerabilidade específica. Já Drupal 8, Drupal 9, 11.1.x, 11.0.x, 10.4.x e versões anteriores estão fora de suporte, ainda que tenham sido disponibilizados patches manuais em regime de melhor esforço para alguns ramos encerrados.

Fluxo técnico

O mecanismo vulnerável fica na camada que abstrai operações de banco de dados dentro do núcleo do Drupal. Essa API existe para padronizar a criação, validação e sanitização de consultas antes que sejam enviadas ao mecanismo relacional. Em um fluxo esperado, dados recebidos por requisições HTTP são transformados por rotas, controladores, formulários, consultas de entidade, módulos contribuidos ou código customizado, e a camada de banco aplica regras para impedir que parâmetros externos alterem a semântica SQL. A falha descrita rompe essa expectativa para sites com PostgreSQL, permitindo que uma entrada especialmente preparada chegue ao banco como parte de uma consulta manipulada.

A exploração não exige conta autenticada, o que amplia a superfície inicial. Um atacante pode testar rotas expostas publicamente e campos que influenciam consultas internas, procurando diferenças de resposta, erros de banco, alterações de tempo, comportamento de paginação, filtragem ou retorno de conteúdo. Como o problema está na API de abstração, o caminho acionável pode variar conforme o site, os módulos habilitados e as rotas acessíveis. O comunicado não fornece um endpoint universal, payload público, hash, endereço de infraestrutura ou indicador de comprometimento, portanto a análise defensiva deve focar no padrão de classe da falha: entrada remota não autenticada que interfere na construção de SQL em instalações Drupal com PostgreSQL.

A injeção de SQL arbitrária pode produzir efeitos diferentes conforme a configuração. Em um caso mais direto, o atacante pode obter informação que a aplicação não deveria retornar, como registros de usuários, metadados de conteúdo, dados de sessão, permissões, filas, configuração ou outros objetos armazenados no banco. Em cenários mais graves, se a consulta vulnerável interagir com tabelas sensíveis ou se o usuário de banco possuir privilégios além do mínimo necessário, a exploração pode alterar dados, influenciar credenciais, modificar papéis, preparar cadeia de elevação de privilégio ou atingir caminhos que terminem em execução de código pela aplicação. A menção a execução remota de código deve ser tratada como impacto condicionado, não como garantia universal para qualquer instalação vulnerável.

Superfície afetada

A superfície afetada é limitada a sites Drupal que usam PostgreSQL. Ambientes com outros mecanismos de banco de dados não entram na condição descrita para está vulnerabilidade, e Drupal 7 foi indicado como não afetado. A prioridade deve recair sobre instalações públicas nos ramos suportados 11.3, 11.2, 10.6 e 10.5, porque são os ramos com cobertura de segurança e atualizações oficiais. Sites em ramos encerrados exigem decisão de risco mais severa: ainda que haja patches manuais para versões sem suporte, essas versões continuam acumulando vulnerabilidades previamente divulgadas e não devem permanecer como base operacional de longo prazo.

Em ambientes corporativos, a exposição pode estar distribuída entre produção, homologação, portais internos acessíveis por VPN, instâncias de desenvolvimento publicadas temporariamente, imagens antigas em clusters, serviços atrás de balanceadores e cópias usadas para testes de conteúdo. O inventário precisa confirmar a versão real do núcleo do Drupal, o mecanismo de banco configurado, a origem do pacote instalado, os módulos contribuidos ativos, customizações que constroem consultas e o nível de privilégio do usuário de banco. Uma instalação aparentemente interna ainda pode ser explorável se estiver acessível por usuários não confiáveis, parceiros, redes planas ou credenciais de baixo privilégio.

A presença de atualizações de Symfony e Twig nas versões corrigidas também deve entrar no escopo de validação. Esses componentes são dependências relevantes no processamento de requisições, renderização e execução de fluxos de aplicação, e a aplicação das versões mais recentes do Drupal reduz múltiplos riscos acumulados. Operações que mantêm somente patches locais, sem elevar o ramo para uma versão coberta, devem registrar exceção formal e planejar migração, porque a correção de CVE-2026-9082 não elimina outras falhas já conhecidas em ramos fora de ciclo.

• Instalações do núcleo do Drupal em ramos suportados 11.3, 11.2, 10.6 e 10.5 com banco PostgreSQL.
• Sites acessíveis por usuários anônimos, incluindo portais públicos, APIs, formulários, catálogos, áreas de busca e rotas de conteúdo dinâmico.
• Ambientes legados em Drupal 8, Drupal 9, 11.1.x, 11.0.x, 10.4.x e anteriores, que estão fora de suporte e devem ser tratados como dívida crítica.
• Instâncias clonadas, containers antigos, servidores de homologação e ambientes temporários que reutilizam base de dados PostgreSQL e permanecem acessíveis.

Hunting e telemetria

A ausência de indicadores específicos exige hunting baseado em comportamento. Equipes devem correlacionar logs HTTP, logs da aplicação Drupal, eventos do servidor web e registros do PostgreSQL para identificar requisições anônimas que produzam erros de sintaxe SQL, exceções de consulta, respostas anômalas, aumento incomum de 500, variações de latência ou enumeração intensa de parâmetros. Campos de busca, filtros, ordenação, paginação, endpoints com parâmetros complexos e rotas que retornam listas de conteúdo merecem atenção porque frequentemente influenciam consultas ao banco.

No banco de dados, a análise deve procurar padrões incompatíveis com o uso normal da aplicação, como consultas com estruturas inesperadas, erros repetidos de parser, uso anormal de operadores, tentativa de acessar tabelas administrativas, enumeração de metadados e sequências de falha seguidas por consultas bem-sucedidas. A investigação deve considerar o fuso horário dos logs, camadas de cache e proxies reversos, porque a exploração pode aparecer no servidor web como uma sequência de requisições comuns enquanto o sinal mais claro surge no PostgreSQL ou no log de exceções do Drupal.

Em endpoint e infraestrutura, o foco é confirmar se a injeção levou a impacto posterior. Revisar alterações recentes em contas administrativas, papéis, permissões, conteúdo executável, configuração do site, módulos habilitados, arquivos modificados, tarefas agendadas e artefatos gerados pela aplicação. Caso existam pipelines de implantação, comparar o estado em produção com o repositório e com o artefato assinado de entrega. Para ambientes com WAF ou proxy, exportar as requisições bloqueadas e permitidas durante a janela anterior à atualização, buscando tentativas de manipular parâmetros de consulta antes que a correção tenha sido aplicada.

• Requisições anônimas com parâmetros incomuns seguidas por erros de banco, exceções do Drupal ou respostas 500 em rotas públicas.
• Mensagens do PostgreSQL indicando falhas de sintaxe, consultas inesperadas ou acesso anormal a tabelas sensíveis da aplicação.
• Alterações não planejadas em usuários, papéis, permissões, conteúdo, configuração, módulos, temas ou arquivos após tráfego suspeito.
• Picos de requisições a buscas, filtros, listagens, paginação e endpoints que aceitam entrada textual ou parâmetros estruturados.

Mitigação

A resposta principal é atualizar o núcleo do Drupal para a versão corrigida correspondente ao ramo suportado em uso. A atualização deve ser tratada como mudança de segurança prioritária para qualquer site com PostgreSQL, especialmente quando há acesso anônimo pela internet. O processo precisa incluir backup verificável, aplicação em homologação, execução de testes funcionais nos fluxos que consultam conteúdo, usuários e formulários, atualização de dependências incorporadas e implantação controlada em produção. Após a atualização, confirmar no inventário que a versão efetiva em execução corresponde ao pacote corrigido e que não há instâncias paralelas ainda vulneráveis.

Para ramos fora de suporte, patches manuais não devem ser confundidos com cobertura de segurança completa. Eles podem reduzir o risco específico de CVE-2026-9082, mas não corrigem automaticamente vulnerabilidades acumuladas em Drupal 8, Drupal 9, 11.1.x, 11.0.x, 10.4.x e versões anteriores. A ação defensiva adequada é migrar para um ramo suportado, remover exposição pública quando a migração não for imediata, restringir acesso por camada de rede e revisar exceções de negócio. Se um patch manual for inevitável, ele deve ser aplicado com controle de integridade, revisão de código, teste de regressão e prazo explícito de substituição.

A contenção deve acompanhar a correção. Reduzir privilégios do usuário de banco para o mínimo necessário, bloquear acesso administrativo não indispensável, revisar módulos contribuidos e customizações que constroem consultas, e elevar a sensibilidade de alertas para erros SQL e mudanças administrativas. Depois da implantação, executar varredura autenticada e não autenticada, comparar logs antes e depois da correção e validar que o WAF ou proxy não está mascarando falhas persistentes. Em caso de evidência de exploração, preservar logs, congelar artefatos relevantes, revisar tabelas críticas, rotacionar credenciais administrativas e investigar se houve alteração de permissões ou implantação de código não autorizado.

• Atualizar os ramos suportados do Drupal afetados e validar que as atualizações de segurança de Symfony e Twig foram incluídas.
• Confirmar quais instâncias usam PostgreSQL, inclusive homologação, containers antigos, clones e sites internos acessíveis por usuários não confiáveis.
• Migrar versões sem suporte para ramo coberto; usar patches manuais apenas como contenção temporária e documentada.
• Revisar privilégios do usuário de banco, logs de requisições anônimas, exceções de SQL, contas administrativas e alterações de configuração.
• Se houver sinal de exploração, preservar evidências, rotacionar credenciais relevantes e verificar integridade de arquivos, módulos, temas e registros sensíveis.