PostgreSQL lança patches para 52 vulnerabilidades, incluindo bug de 22 anos que permite RCE autenticado

A comunidade PostgreSQL divulgou, em 13 de novembro de 2026, um conjunto de correções que abrange 52 falhas de segurança, entre elas um bug de 22 anos de idade (CVE‑2026‑6460) que permite execução remota de código (RCE) por um usuário autenticado que possua permissão para criar objetos.

Entendendo a vulnerabilidade CVE‑2026‑6460

Trata‑se de uma falha de "type confusion" em tipos compostos – estruturas que agrupam campos de diferentes tipos de dados. O mecanismo permite que o tipo de um campo seja alterado enquanto valores antigos ainda permanecem armazenados em outras partes do servidor. Quando o servidor lê um desses valores antigos como se pertencessem ao novo tipo, ocorre a confusão que pode ser explorada para executar código arbitrário.

A exploração ocorre com os mesmos privilégios do usuário do sistema operacional que executa o processo PostgreSQL, o que, em ambientes típicos, corresponde ao usuário "postgres" ou a um usuário de serviço dedicado. O CVSS base da vulnerabilidade foi avaliado em 8,8, indicando risco alto.

Escopo de versões afetadas

Todos os lançamentos anteriores a 18.7, 17.12, 16.16, 15.20 e 14.25 são vulneráveis. Isso inclui as versões de suporte de longo prazo (LTS) ainda em uso por muitas organizações.

Exploração demonstrada

O pesquisador de segurança Mehmet Ince publicou, nesta semana, um write‑up detalhando um exploit funcional contra o PostgreSQL 18.6. O método consiste em inserir um valor em uma tabela, alterar o tipo de um dos campos desse valor e, em seguida, executar a consulta que força o servidor a interpretar o valor antigo como pertencente ao novo tipo. O primeiro passo gera uma falha que pode ser usada para vazar endereços de memória; a etapa final, que executa código, não foi divulgada publicamente.

Ince afirma que o crash pode ser disparado por um login com o menor privilégio que ainda possua a capacidade de criar objetos. O advisory oficial do projeto descreve o atacante apenas como alguém que pode criar ou modificar objetos, sem especificar se privilégios padrão são suficientes para avançar da falha de crash para a execução de código.

Ilustração: Diagrama simplificado mostrando o fluxo de exploração da vulnerabilidade de type confusion em tipos compostos do PostgreSQL.

Posicionamento de fornecedores e autoridades

O PostgreSQL Global Development Group ainda não registrou incidentes de exploração em produção. O registro CVE no NVD indica que a exploração observada é "none", conforme avaliação da CISA. A Red Hat, responsável pelos pacotes PostgreSQL em várias distribuições Linux, confirma que o atacante precisa de credenciais de banco de dados com permissão para criar ou modificar objetos.

Outras correções incluídas no release

Além do CVE‑2026‑6460, a atualização corrige 51 falhas adicionais, das quais 32 recebem pontuação CVSS 8,8 – a mais alta do lote. Uma vulnerabilidade (CVE‑2026‑116322) permite que um cliente não autenticado provoque a reinicialização de servidores PostgreSQL 18, embora não ofereça execução de código.

Vários problemas também afetam ferramentas cliente: um arquivo de archive mal‑formado pode fazer o pg_restore executar código como o usuário que o invoca, e um servidor de origem comprometido pode induzir o psql a executar código ao processar scripts de restauração gerados por pg_dump.

Recomendações para administradores

• Atualizar imediatamente o servidor para 18.7, 17.12, 16.16, 15.20 ou 14.25, conforme a versão principal em uso.

• Recompilar ou atualizar todas as extensões escritas em C simultaneamente à atualização do servidor. Extensões compiladas contra versões anteriores podem permanecer vulneráveis.

• Verificar a compatibilidade das extensões recompiladas; pacotes RPM já exigem a nova versão menor.

• Se o PostgreSQL for gerenciado por ferramentas como Patroni, reiniciar o serviço logo após a atualização.

• Atualizar também as ferramentas cliente (pg_dump, pg_restore, reindexdb, vacuumdb) em todas as máquinas que as utilizam.

• Não desativar a nova configuração composite_type_mismatch; a documentação alerta que isso reduz a segurança.

• Não há solução alternativa oficial para servidores que não podem ser atualizados imediatamente.

• Observe que o PostgreSQL 14 chegou ao fim de vida; a versão 14.25 é a última lançada para essa série.

• Após a atualização, executar os procedimentos de reindexação descritos no anúncio e gerar um backup completo antes de retomar backups incrementais.

Impacto prático para organizações brasileiras

Empresas que operam bancos de dados PostgreSQL – seja on‑premise ou em serviços gerenciados como Amazon Aurora, Azure Database for PostgreSQL, Google AlloyDB ou Supabase – devem validar o status de patch desses provedores. Muitos deles já receberam os patches, mas a confirmação varia. A falta de atualização pode expor ambientes a execução de código com privilégios de serviço, comprometendo dados sensíveis e permitindo escalonamento lateral.

Além disso, a necessidade de recompilar extensões C pode gerar interrupções temporárias, exigindo planejamento de janela de manutenção. Organizações que ainda utilizam a série 14 devem considerar a migração para versões suportadas, já que não haverá mais correções de segurança para essa linha.

Próximos passos

Em resumo, a prioridade imediata é aplicar os patches oficiais, validar a integridade das extensões e atualizar as ferramentas cliente. Monitorar os boletins de segurança dos provedores de nuvem e manter backups recentes são medidas complementares essenciais para reduzir o risco de exploração.

Perguntas frequentes