PostgreSQL corrige 52 CVEs em uma única atualização menor e eleva a régua de urgência em produção

O pacote que saiu em 12 de novembro

No dia 12 de novembro, o PostgreSQL↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → Global Development Group publicou atualizações menores para todas as branches suportadas: 18.7, 17.12, 16.16, 15.20 e 14.25, esta última a derradeira versão antes de o PostgreSQL 14 entrar oficialmente em fim de vida. No mesmo dia saiu também o PostgreSQL 19 RC2, com disponibilidade geral da versão 19 prevista para 19 de novembro.

O calendário de 2026 já vinha fora do padrão. Releases majores costumam sair em setembro ou outubro; o PostgreSQL 19 só chegou ao RC2 em meados de novembro, depois de um Beta 4 que reverteu um lote de funcionalidades anunciadas e de um RC1 que saiu só em outubro. Segundo relato do especialista Ruohang Feng, criador do Pigsty e colaborador da comunidade PostgreSQL, em artigo publicado no Planet PostgreSQL, a equipe de gerenciamento de releases explicou em post na lista de discussão em 10 de outubro que havia um backlog grande de correções acumuladas nas branches de manutenção, e todas precisavam entrar no RC2 antes de a 19.0 ser cortada.

O resultado desse represamento apareceu agora: 52 CVEs e mais de 140 correções de bugs numa única release menor. Para efeito de comparação, uma atualização trimestral típica do PostgreSQL corrige entre três e cinco CVEs; em agosto, o lote já havia soado pesado com 28 CVEs e mais de 110 bugs. Mesmo olhando trinta anos de histórico do projeto, uma atualização de ponto desse tamanho é incomum.

Por trás do volume: auditoria contínua por IA

Feng não trata o número como mistério. Modelos de linguagem↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI → de ponta estão auditando continuamente códigos-base de infraestrutura aberta, e o PostgreSQL é um dos alvos. Nas notas de agradecimento da versão 18.7 aparecem, em sequência, OpenAI Security Research Team, OpenAI Codex Security, Anthropic OSS program, Claude e a empresa Ada Logics.

O perfil técnico das falhas confirma a origem automatizada. Trinta e dois dos 52 CVEs carregam pontuação CVSS v3.1 de 8,8, boa parte deles permitindo execução arbitrária de código. A maioria se encaixa em categorias clássicas de bug de memória e tipagem em C: confusão de tipo, use-after-free, estouro de buffer em heap e wraparound de inteiro. Elas atravessam quase toda a árvore de código, de tipos compostos, plperl, pltcl e dblink até as funções de importação de estatísticas e utilitários de linha de comando que todo DBA roda por hábito, como pg_dump, pg_restore, reindexdb e vacuumdb.

O perigo real está em projetos abandonados, repositórios semimortos e forks órfãos. As ferramentas automatizadas de IA encontram tantas vulnerabilidades nesses códigos quanto em qualquer outro, só que não há ninguém para corrigi-las, deixando backdoors prontos sentados em produção.

Ruohang Feng, criador do Pigsty e fundador da PGSTYThe real danger sits in abandoned projects, half-dead repositories, and orphaned forks. Automated AI tools find just as many vulnerabilities in those codebases, except nobody is around to fix them, leaving ready-made backdoors sitting in production.

Os bugs que corrompem dado, não só os que viram CVE

Nem todo problema sério do pacote recebeu um CVE. Entre as mais de 140 correções comuns estão falhas de integridade de dados que qualquer time de dados precisa levar a sério:

• rodar pg_dump em paralelo contra uma réplica standby podia corromper tanto o arquivo de dump quanto os próprios dados da standby;
• backups incrementais podiam gerar conjuntos de backup corrompidos;
• índices GIN e índices GiST com gist_trgm_ops podiam corromper ou deixar de retornar linhas que deveriam casar com a busca;
• deduplicação de índice B-tree sobre colunas bpchar sem limite de tamanho podia fazer index-only scans devolverem resultado errado (colunas char(n) de tamanho fixo não são afetadas).

O planejador de consultas também teve a lógica de remoção de junções (join removal) reescrita nesta release menor, algo que as próprias notas de lançamento reconhecem como incomum fora de uma versão major: correções incrementais no código antigo tinham chegado a um limite e continuariam vazando bugs se não fossem substituídas.

O checklist pós-upgrade que vai além de trocar o binário

Atualizar dentro da mesma branch major do PostgreSQL normalmente não exige pg_upgrade nem dump e reload lógico, mas desta vez trocar apenas os binários do servidor não fecha o ciclo. As notas oficiais da 18.7 listam tarefas de pós-upgrade que costumam ficar de fora do runbook:

1. Recompilar extensões em C. Fechar completamente o CVE-2026-6460 exige recompilar extensões contra os headers atualizados; algumas também precisam de ajuste de código-fonte. Quem instala por repositório de distribuição deve confirmar que os pacotes de extensão já foram reconstruídos; quem compila a partir do código-fonte deve recompilar e testar compatibilidade de verdade, em vez de desligar a checagem composite_type_mismatch como atalho.
2. Checar e reconstruir índices afetados. Inspecionar índices GIN potencialmente corrompidos, reconstruir índices GiST que usam gist_trgm_ops, reconstruir índices B-tree sobre colunas bpchar sem limite e, se aparecer erro de "missing chunk number", reindexar as tabelas indicadas nas notas de lançamento.
3. Resetar a baseline de backup incremental. Quem usa backup incremental precisa tirar um backup completo novo depois do upgrade para resetar a baseline, e aproveitar para checar tabelas particionadas quanto a constraints NOT NULL NO INHERIT não intencionais.
4. Planejar a saída do PostgreSQL 14. A versão 14.25 é a última da branch; quem ainda roda PG 14 em produção precisa colocar um upgrade de versão major no calendário.

Quando correr e quando esperar

Feng mantém a mesma régua que vem repetindo em releases anteriores: se o banco está atrás de firewall interno, com apenas aplicações e engenheiros de confiança rodando SQL, dá para agendar a atualização numa janela de manutenção normal, sem pânico a cada boletim de segurança.

Não se apressar, porém, não é o mesmo que arrastar os pés num pacote deste peso. Isolamento de rede barra scanner de internet pública, mas não impede escalonamento de privilégio a partir de uma role de baixo privilégio depois que um servidor de aplicação é comprometido. Boa parte das falhas deste lote exige só privilégio básico de criação de objeto para ser disparada, caso do CVE-2026-6460, e até pg_dump e pg_restore podem ser explorados por um banco de origem malicioso ou por um arquivo de backup não confiável. Nenhum firewall ajuda contra backup incremental corrompido ou resultado errado de consulta por índice quebrado.

O que fica para o calendário

Com o PostgreSQL 14 encerrando o suporte justamente nesta release, a atualização entra na lista de prioridades de quem ainda mantém essa branch em produção, com um upgrade de versão major a planejar a partir daqui. Para quem já está em branches mais novas, o pacote de 12 de novembro é o tipo de patch que vale testar em ambiente de homologação antes de ir para produção, dada a reescrita de parte do planejador de consultas.

O PostgreSQL 19, com GA prevista para 19 de novembro, carrega o mesmo backlog de correções que represou o calendário deste ano. Times que planejam adotar a versão nova assim que sair ganham, ao menos, a tranquilidade de que boa parte dessas 52 falhas já chega corrigida de fábrica, em vez de esperar o primeiro minor release da série 19.x para ser fechada.

Fonte: Planet PostgreSQL