Postgres 18.7 quebra ABI de extensões ao corrigir CVE crítica

O lançamento do Postgres↳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 → 18.7, em 12 de novembro de 2026, trouxe algo que a comunidade evita a todo custo: uma quebra de compatibilidade binária (ABI) dentro de uma versão minor. O caso foi documentado pelo DBA Jeremy Schneider, da consultoria Ardent Performance Computing, que notou o problema no próprio dia do lançamento ao ver pipelines de build de extensões quebrarem em produção.

A causa é a CVE-2026-6460, uma entre as várias correções de segurança empacotadas nessa minor. Ela não é um detalhe de rodapé: é o primeiro item das notas de lançamento oficiais da versão 18.7, o que já indica o peso que o time de core deu ao problema.

O que a correção muda por baixo do capô

A falha dizia respeito a datums compostos (valores de tipos ROW ou tipos compostos definidos pelo usuário) que podiam ser interpretados com o descritor de tupla errado. O core introduziu uma lógica de versionamento para detectar essa incompatibilidade antes que ela vire corrupção silenciosa de dados ou, pior, um vetor de exploração.

Introduzir lógica de versionamento para permitir a detecção de datums compostos que não correspondem ao descritor de tupla com o qual desejamos interpretá-los. Para proteção completa, essa mudança exige recompilar extensões em linguagem C, e algumas extensões vão precisar de mudanças no código-fonte.

Notas de lançamento do PostgreSQL 18.7Introduce versioning logic to permit detection of composite datums that don't match the tuple descriptor we wish to interpret them with. For full protection, this change requires rebuilding C-language extensions, and there are some extensions that will require source-code changes.

O problema é que essa checagem nova exige que extensões escritas em C enxerguem a estrutura interna atualizada do tuple descriptor. Sem recompilação, a extensão continua falando com o core usando a interface antiga, e é aí que a ABI quebra: o binário compilado contra o Postgres 18.6 não necessariamente roda limpo contra o 18.7.

Para quem precisa de um bypass emergencial, o core adicionou o parâmetro composite_type_mismatch, que desativa a checagem. Mas a documentação é direta: fazer isso reintroduz o risco de segurança que a CVE-2026-6460 justamente fecha. Não é uma chave para ligar em produção sem dor de cabeça depois.

Não é a primeira vez, e isso importa

Schneider lembra, no próprio post, que esse tipo de quebra já aconteceu antes: a versão 17.1 teve um episódio parecido, documentado em um explicador da EnterpriseDB sobre a ABI breakage daquela minor. A estabilidade de API e ABI do Postgres tem documentação oficial dedicada ao tema, e o post de 2024 de David Wheeler sobre o assunto, citado por Schneider, já discutia os limites dessa promessa.

Em resumo: o Postgres tenta manter um núcleo estável com uma borda de extensões rápida e inovadora, e isso é parte do motivo do ecossistema ser tão forte. Mas quando uma CVE séria exige mexer em estruturas internas, essa promessa cede, e é a segunda vez documentada que isso acontece numa minor em pouco tempo.

O problema prático: lockstep quebrado

A teoria é uma coisa; o campo é outra. Schneider relata que, nos próprios pipelines de build que mantém para extensões rodando sobre CloudNativePG em Kubernetes↳Kubernetes18 conteúdosGerenciamento de infraestrutura multicloud com Kubernetes proporciona otimização e economiaDevSecOps · set 2021Azure Kubernetes Services – AKS: referências gratuitas e dicas para solução de problemas comunsDevSecOps · abr 2019Kubernetes em produção: o que ninguém te conta e você aprende tarde demaisDev (Back & Front) · abr 2026Ver tudo em DevSecOps →, várias quebraram no mesmo dia do lançamento, porque pacotes de extensões novos chegaram antes do core atualizado.

Três exemplos citados diretamente por ele:

• AGE (extensão de grafos para Postgres) já publicou uma versão nova que não funciona na versão 18.6;
• credcheck (validação de credenciais) está na mesma situação;
• pg_cron (agendador de jobs) também lançou build incompatível com 18.6.

O padrão identificado por Schneider é consistente: as versões atualizadas das extensões usam a interface interna nova, e por isso não rodam em core antigo. Extensões antigas, por outro lado, continuam funcionando no core novo. Ou seja, o sentido do upgrade importa, e muito.

Ordem de atualização não é opcional

Para quem administra ambientes com extensões críticas, a lição operacional é clara e precisa virar rotina, não reação de bombeiro:

1. Atualize o core do Postgres para 18.7 primeiro, isolado, validando que o serviço sobe normalmente;
2. Só depois atualize os pacotes de extensões, confirmando a versão compatível com a nova minor;
3. Nunca deixe o canal de pacotes aplicar extensão nova antes do core, especialmente em pipelines automatizados de CI/CD;
4. Trate composite_type_mismatch como válvula de emergência documentada, não como configuração padrão.

Schneider menciona que Devrim Gunduz, mantenedor dos pacotes RPM do Postgres, publicou no mesmo dia um post (segundo o próprio Schneider, mais detalhado que o seu) explicando que o empacotamento RPM passou a incluir um cabeçalho de dependência que exige a minor específica do core. Isso reduz o risco de alguém instalar uma extensão nova sobre um core desatualizado via yum/dnf, mas Schneider não confirmou se o ecossistema Debian/APT já tem proteção equivalente.

Onde isso pesa mais

O cenário descrito é mais crítico em ambientes com automação agressiva de patch de segurança: quem aplica CVEs via pipeline sem revisão manual corre o risco real de atualizar o core e a extensão fora de ordem, ou de travar porque o pacote de extensão chegou primeiro no repositório. Times que operam Postgres em Kubernetes com CloudNativePG, como o próprio Schneider, sentem isso de forma mais direta, porque o ciclo de build de imagens de container tende a puxar a versão mais recente disponível de cada componente de forma independente.

A recomendação de bom senso, e que cabe a qualquer DBA que preze consistência, é tratar atualização de minor do Postgres como uma mudança de schema: planejada, testada em staging com as extensões reais do ambiente, e aplicada em lockstep, nunca componente por componente conforme a conveniência do pipeline. A segurança que a CVE-2026-6460 entrega só vale alguma coisa se as extensões em produção continuarem funcionando no dia seguinte.

Fonte: Planet PostgreSQL