Postgres 18.7 corrige 52 CVEs, incluindo falha grave de confusão de tipos

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 hoje as versões 18.7, 17.12, 16.16, 15.20 e 14.25, um release de segurança que fecha 52 CVEs. O volume chamou a atenção de Lukas Fittl, criador do podcast "5mins of Postgres", que dedicou o episódio 123 da série a organizar o anúncio por tipo de explorador em vez de seguir a ordem bruta da lista oficial.

Em resumo: se a aplicação permite que algum usuário execute SQL arbitrário, ou se há risco de SQL injection, a atualização deixa de ser opcional. Fittl resume o risco prático: um usuário comum que consiga rodar SQL pode, encadeando algumas dessas falhas, chegar a usuário do sistema operacional ou a superusuário do Postgres.

Seis classes de risco, não 52 problemas soltos

Fittl, cuja análise combinou os commits do Postgres, o texto do anúncio oficial, as release notes e assistência de modelos de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → (Claude Fable e Opus, segundo o próprio post), agrupou as CVEs pelo que o atacante precisa ter em mãos para explorá-las.

A linha que mais preocupa Fittl é a segunda: qualquer usuário autenticado, mesmo sem privilégio nenhum além de conectar, pode acionar funções como ts_delete() ou ts_rank_cd() com um tsvector malformado e provocar um heap buffer overflow. Para provedores gerenciados como o Amazon RDS, onde o cliente nunca tem acesso root, esse tipo de falha é justamente o que normalmente ficaria contido.

CVE-2026-6460: trocar o tipo de uma coluna engana o Postgres

A vulnerabilidade mais discutida do pacote é a CVE-2026-6460, relatada por cerca de 20 pessoas, entre elas os programas de segurança da OpenAI e da Anthropic. O problema: operações como ALTER TYPE ... ALTER ATTRIBUTE ... TYPE, ALTER TABLE ... SET DATA TYPE ou um ADD COLUMN seguido de rollback mudam a definição de um tipo depois que uma consulta já capturou valores daquele tipo, por exemplo num prepared statement. O Postgres não percebe a mudança e interpreta os bytes antigos com a definição nova, uma confusão de tipos (type confusion) clássica.

O pesquisador Mehmet Ince publicou nesta semana uma análise mostrando como transformar essa confusão de tipos em execução remota de código, com prova de conceito disponível. O ponto que Fittl destaca é que o ataque não depende de condição de corrida: funciona dentro de uma única sessão, de forma determinística.

O problema era que você escrevia uma tupla, uma versão de linha, com uma definição de tipo, depois mudava a definição do tipo, e o Postgres não sabia que o tipo tinha mudado.

Lukas Fittl, criador do "5mins of Postgres"The problem was that you would write a tuple, a row version, with one definition of the type, then you would change the type definition, and Postgres wouldn't know that the type changed.

Um remendo incomumente invasivo para release menor

Para fechar a CVE-2026-6460, o time de segurança do Postgres introduziu uma camada inteira de versionamento para o armazenamento interno de tuplas. Agora, quando o Postgres detecta que a definição de um tipo mudou desde que a tupla foi lida, ele aborta com erro em vez de reinterpretar os bytes antigos com a definição nova. É uma mudança de comportamento incomum para uma minor release, que normalmente se limita a bugfix pontual sem tocar em estrutura interna.

Esse tipo de correção tem efeito colateral direto sobre extensões compiladas contra a ABI do Postgres. Duas consequências práticas, segundo Fittl:

• O pgrx, framework usado para escrever extensões em Rust↳Rust7 conteúdosDesmistificando Rust: a linguagem segura e rápida que você precisa conhecerDev (Back & Front) · out 2024Como criar seu primeiro Programa em Rust com Solana PlaygroundDev (Back & Front) · mai 2026Rust no ranking: a segurança de memória perdeu a guerra corporativa?Marketing Tech · abr 2026Ver tudo em Dev (Back & Front) →, já lançou uma versão atualizada para a nova API exigida pela mudança.
• O PostGIS também precisa de tratamento especial, sobretudo em cenários de pg_upgrade, onde casos de borda passaram a exigir atenção.

Quem mantém extensões compiladas localmente, e não via pacote empacotado pela distribuição, deve verificar se o build está alinhado com o novo layout interno antes de reiniciar o servidor em produção.

Reinicie o servidor, não só os pacotes

A mudança de ABI cria uma armadilha operacional específica: se o binário do servidor for atualizado, mas os processos em execução não forem reiniciados, ou se as extensões forem atualizadas antes do binário do servidor, o Postgres pode falhar ao carregar uma biblioteca compartilhada, como a do PL/pgSQL, com um erro do tipo:

ERROR: could not load library "/usr/lib/postgresql/18/lib/plpgsql.so": /usr/lib/postgresql/18/lib/plpgsql.so: undefined symbol: heap_datum_update_type

O motivo é simples: há descompasso entre a versão menor rodando em memória e a versão menor das bibliotecas compartilhadas no disco. Quem gerencia o próprio Postgres (fora de serviço gerenciado) precisa planejar o reinício do servidor como parte obrigatória da atualização de pacotes, não como etapa opcional.

Outras frentes que merecem checagem pontual

Além da corrupção de memória, o pacote cobre pontos que passam longe da modelagem clássica mas afetam diretamente quem usa padrões de upsert ou RLS:

• CVE-2026-16237 e CVE-2026-120154: um INSERT ... ON CONFLICT DO UPDATE sobre uma view auto-atualizável ou sobre uma tabela com row-level security pode ler e modificar linhas que a cláusula WHERE da view, ou a política de RLS, deveriam esconder.
• CVE-2026-116311: DROP OWNED permite que um papel se remova de políticas restritivas de RLS em tabelas que não possui.
• CVE-2026-116314 e CVE-2026-116330: arquivos de pg_restore ou saídas tar de pg_dump não confiáveis podem executar código arbitrário na máquina que roda a restauração, indo além do que já era esperado (rodar SQL no destino).
• CVE-2026-116322: um cancel request enviado antes do login, cronometrado para coincidir com o disparo de authentication_timeout, derruba o servidor inteiro sem exigir autenticação. Afeta só a versão 18.

Equipes que usam upsert como padrão de escrita, ou que dependem de RLS para isolar dados multi-tenant, devem revisar essas duas CVEs específicas antes de assumir que a atualização de versão sozinha resolve o problema de modelagem subjacente: políticas de RLS mal desenhadas continuam sendo políticas mal desenhadas depois do patch.

O que fica como lição operacional

O episódio de Fittl reforça um ponto que vale para qualquer operação de banco: a superfície de risco de 52 CVEs não é uniforme, e tratar todas como "aplicar e torcer" é pior do que entender qual classe de exploração se aplica ao seu ambiente. Quem roda SQL de terceiros, mesmo filtrado, está na faixa de maior exposição. Quem opera um Postgres isolado, sem replicação lógica de origem desconhecida e sem extensões PL/Perl ou PL/Tcl abertas ao público, tem uma janela um pouco mais confortável, mas não motivo para adiar.

A recomendação prática que se extrai do material: agendar o reinício completo do servidor junto com a atualização dos pacotes, revalidar extensões compiladas localmente contra a nova ABI, e conferir se alguma rotina de aplicação depende de INSERT ... ON CONFLICT DO UPDATE sobre view ou tabela com RLS antes de considerar o trabalho encerrado.

Fonte: Planet PostgreSQL