PostgreSQL corrige 52 falhas, incluindo bug de 22 anos que permite RCE autenticado

O PostgreSQL Global Development Group liberou em 12 de novembro de 2026 um conjunto de atualizações que fecha 52 falhas de segurança. A mais grave, catalogada como CVE-2026-6460, tem CVSS 8.8 e permite que um usuário do banco com permissão para criar objetos execute código com os privilégios do processo do PostgreSQL no sistema operacional.

A raiz do problema remonta a 5 de maio de 2004, quando o projeto ganhou a capacidade de alterar o tipo de uma coluna. O pesquisador Mehmet Ince, que publicou um writeup técnico sobre a falha nesta semana, também aponta uma mudança de 14 de maio de 2015 como a peça que viabiliza a execução de código, não só a falha original.

O bug: tipo composto que engana o servidor

A falha está em tipos compostos, estruturas formadas por campos nomeados, cada um com seu próprio tipo de dado. O problema: o tipo de um campo pode ser alterado enquanto valores antigos desse tipo ainda estão retidos em outras partes do servidor. O resultado é que o servidor pode ler um valor antigo como se ele já tivesse o novo tipo, uma confusão de tipos clássica que abre espaço para corrupção de memória.

O fix, descrito nas release notes do projeto, adiciona verificações de versão para que o servidor detecte quando um valor não corresponde mais ao tipo esperado. As versões afetadas são todas anteriores a 18.7, 17.12, 16.16, 15.20 e 14.25. Vale notar que a versão 14 agora está em fim de vida: 14.25 é o último release dessa série, e versões major mais antigas não recebem mais atualização nenhuma.

O exploit que não chega ao fim (de propósito)

Ince demonstrou a exploração funcional na versão 18.6, mas deixou de fora deliberadamente a etapa final: o SQL que efetivamente faz o servidor rodar um comando. O método publicado prepara uma query que retém um valor, altera o tipo de um dos campos desse valor e executa a query. Isso já derruba um servidor não corrigido; um segundo passo vaza endereços de memória.

Há uma divergência relevante sobre quem consegue chegar até o fim do ataque. Ince descreveu o primeiro passo (o crash) como possível para qualquer conta de baixo privilégio:

Eu consigo disparar essa falha como uma role de login com o privilégio mais baixo possível.

I can trigger this crash as a lowest-privileged login role.Mehmet Ince, pesquisador de segurança

Já o advisory oficial do projeto descreve o atacante apenas como alguém que pode criar objetos, sem detalhar qual privilégio isso exige. A avaliação de CVE da Red Hat é mais específica: exige um login de banco com capacidade de criar ou modificar objetos. Nenhuma das três fontes confirma se uma conta com privilégios padrão consegue ir além do crash e chegar à execução de código. Para quem administra banco de produção, isso muda pouco na prática: trate a falha como RCE completo até prova em contrário.

RDS, Aurora e as outras nuvens: o que ainda não se sabe

Ince adaptou o exploit para serviços gerenciados e compartilhou provas de conceito de forma privada com os times de segurança em agosto de 2026. A lista inclui a AWS (Aurora e RDS), Microsoft (Azure PostgreSQL), Google (AlloyDB), Supabase, Databricks e Ubicloud. O writeup não informa o status de patch atual de cada provedor.

Isso é o ponto que mais importa para quem opera infraestrutura na AWS: não há confirmação pública de que Aurora PostgreSQL e RDS for PostgreSQL já aplicaram o patch equivalente nas versões gerenciadas. A recomendação prática é checar diretamente no console ou via CLI quais engine versions estão disponíveis na sua região:

aws rds describe-db-engine-versions \
 --engine postgres \
 --region sa-east-1 \
 --query "DBEngineVersions[?EngineVersion>='18.7' || EngineVersion>='17.12' || EngineVersion>='16.16' || EngineVersion>='15.20' || EngineVersion>='14.25'].EngineVersion"

Se a versão corrigida da sua major ainda não aparecer disponível em sa-east-1, trate isso como uma lacuna de patch gerenciado e acompanhe o AWS Security Bulletin para RDS/Aurora, não apenas o anúncio do projeto PostgreSQL.

O parâmetro que não deve ser mexido

O patch introduz um parâmetro novo, composite_type_mismatch, pensado para permitir desligar a verificação em casos de incompatibilidade legítima. O projeto é explícito: não use esse parâmetro para desativar a checagem, porque isso reintroduz o risco de segurança que o patch corrige. Em RDS, isso significa não tocar nesse parâmetro no DB parameter group depois de aplicar a atualização, mesmo que algum log de aplicação reclame de incompatibilidade.

Checklist para quem opera PostgreSQL fora de RDS

Quem roda PostgreSQL em EC2, em Kubernetes ou sob Patroni (comum em arquiteturas self-managed de alta disponibilidade) tem uma lista mais longa de tarefas que o RDS abstrai:

• Atualizar o servidor para 18.7, 17.12, 16.16, 15.20 ou 14.25, de acordo com a major em uso.
• Reconstruir ou atualizar toda extensão em linguagem C instalada no servidor; extensões antigas ainda carregam, mas não ficam protegidas pela correção.
• Se o PostgreSQL roda fora da própria service unit do pacote (caso típico de Patroni), reiniciar o processo logo após a atualização, conforme orienta um mantenedor dos pacotes RPM do projeto.
• Atualizar as ferramentas cliente em toda máquina que as executa: pg_dump, pg_restore, reindexdb e vacuumdb.
• Seguir os passos de reindexação descritos no anúncio de release antes de considerar o ambiente saneado.

O advisory e as release notes do projeto não oferecem nenhum workaround para quem não pode atualizar agora. Não existe mitigação de configuração: é patch ou exposição.

Dois bugs extras que merecem atenção

Além da falha principal, duas outras correções no mesmo release pesam para quem desenha pipeline em produção. A CVE-2026-116322 permite que um cliente não autenticado dispare o reinício de servidores PostgreSQL 18, sem exigir login nem ação de usuário; é o único bug do lote, pelos critérios do índice de vulnerabilidades do projeto, que dispensa autenticação. Reforça o argumento de manter o endpoint do banco fora de rede pública: no RDS, isso significa PubliclyAccessible=false e security group restrito à VPC da aplicação.

A segunda frente afeta ferramentas de backup e restore. Um arquivo malicioso pode fazer o pg_restore executar código como o usuário que o roda, e um servidor de origem comprometido pode fazer o psql executar código através do script de restore embutido no tar gerado pelo pg_dump. Isso é relevante para pipelines de migração e disaster recovery que automatizam dump e restore entre contas ou ambientes: trate todo artefato de backup como não confiável até validar a origem, e rode operações de restore em ambiente isolado quando o dump vier de fora da sua conta.

O que fica em aberto

Permanecem sem resposta pública: o status exato do patch em Aurora e RDS, se uma conta com privilégios padrão de aplicação consegue ir do crash à execução de código, e se algum dos provedores gerenciados mencionados por Ince já fechou a janela. Até essas respostas aparecerem em bulletin oficial da AWS, a postura prudente é assumir vulnerabilidade e revisar com urgência quais roles de aplicação têm permissão de CREATE em schemas de produção:

REVOKE CREATE ON SCHEMA public FROM app_role;

Reduzir quem pode criar objetos no banco não elimina a falha, mas reduz a superfície de contas capazes de disparar o primeiro passo do exploit enquanto o patch gerenciado não se confirma.

Fonte: The Hacker News