A nova atualização de segurança do PostgreSQL, publicada em 12 de novembro de 2026, corrige 52 vulnerabilidades e mais de 140 outros problemas identificados no sistema de gerenciamento de bancos de dados. O destaque é a CVE-2026-6460, uma falha de confusão de tipos presente no código do PostgreSQL desde 2004, capaz de permitir a execução de código arbitrário no servidor por um usuário autenticado com determinadas permissões.
A gravidade da atualização exige atenção imediata de administradores de banco de dados, equipes DevOps e profissionais responsáveis pela infraestrutura. Entre os problemas corrigidos estão vulnerabilidades com pontuação CVSS 8,8, falhas que comprometem a segurança de ferramentas de cliente e um defeito que permite reiniciar servidores PostgreSQL 18 sem autenticação. Embora a necessidade de autenticação reduza as possibilidades de exploração de algumas dessas falhas, isso não elimina o risco em ambientes com múltiplos usuários e aplicações.
Neste artigo, você conhecerá o funcionamento da vulnerabilidade de 22 anos, as versões afetadas e corrigidas e os procedimentos necessários para atualizar servidores com segurança. Também é importante observar que a atualização encerra oficialmente o ciclo de suporte do PostgreSQL 14, tornando o planejamento de migração ainda mais urgente. diginews.johandenoyer.fr+2
Como funciona a CVE-2026-6460, a falha de 22 anos no PostgreSQL
A CVE-2026-6460 é uma vulnerabilidade de confusão de tipos (type confusion) no mecanismo interno do PostgreSQL. O problema está relacionado à maneira como o banco de dados acompanha os tipos de dados associados a valores armazenados na memória, especialmente quando estruturas compostas passam por alterações de definição.
Em determinadas operações, um administrador ou usuário com permissões para criar e modificar objetos pode alterar o tipo de um campo de uma estrutura composta. Entretanto, valores antigos associados à definição anterior podem continuar presentes em áreas da memória. Quando o PostgreSQL interpreta esses valores utilizando informações de tipo desatualizadas, pode ocorrer uma incompatibilidade entre a representação real dos dados e a interpretação feita pelo sistema.
Essa inconsistência abre caminho para operações perigosas sobre a memória do processo. Um invasor que consiga explorar a condição pode transformar a falha em execução de código arbitrário com os privilégios do usuário do sistema operacional responsável pelo processo do PostgreSQL.
Na prática, isso significa que o comprometimento não fica necessariamente limitado ao conteúdo de uma tabela. Dependendo das permissões concedidas à conta que executa o banco, o impacto pode alcançar outros recursos acessíveis pelo processo.
O detalhe histórico chama atenção: a origem do problema remonta a 5 de maio de 2004, quando uma questão relacionada ao acompanhamento dos tipos de valores já estava presente no desenvolvimento do projeto. A pesquisa divulgada por Mehmet Ince demonstra como uma inconsistência aparentemente antiga pode permanecer relevante durante décadas, especialmente quando envolve mecanismos internos complexos.
A investigação também explora técnicas de exploração desenvolvidas a partir de mudanças introduzidas em maio de 2015. Os testes consideraram diferentes ambientes de hospedagem e serviços gerenciados, incluindo AWS Aurora e RDS, Azure Database for PostgreSQL, Google AlloyDB, Supabase, Databricks e Ubicloud.
O ponto mais importante para administradores é que a vulnerabilidade não deve ser tratada como um problema exclusivo de instalações locais. Serviços gerenciados também precisam receber as correções disponibilizadas por seus respectivos provedores. A classificação CVSS 8,8 reforça a gravidade do problema, especialmente porque a exploração exige privilégios prévios, mas não depende de interação adicional da vítima.
Outras falhas da atualização de segurança do PostgreSQL: reinicialização sem login e ferramentas de cliente
A CVE-2026-6460 não é o único problema que merece atenção. Outra vulnerabilidade importante é a CVE-2026-116322, relacionada ao processamento de solicitações de cancelamento durante a inicialização do servidor.
Diferentemente da falha de confusão de tipos, essa vulnerabilidade não exige autenticação. Um cliente remoto pode explorar uma condição envolvendo o parâmetro authentication_timeout e o mecanismo interno de bloqueio (spinlock) para provocar a reinicialização de servidores PostgreSQL 18.
O impacto principal é a disponibilidade do serviço, com possibilidade de interrupção das aplicações que dependem do banco de dados. A vulnerabilidade recebeu pontuação CVSS 5,3 e afeta exclusivamente a versão 18 antes da atualização 18.7. As versões anteriores à linha 18 não são afetadas por esse problema específico.
Outro aspecto relevante envolve os utilitários utilizados fora do servidor. A rodada de segurança também corrige problemas em ferramentas como pg_dump, pg_restore, psql, reindexdb e vacuumdb.
Entre os riscos identificados estão a execução de código por meio de arquivos de restauração maliciosos processados pelo pg_restore e a possibilidade de scripts comprometidos produzidos pelo pg_dump serem interpretados pelo psql.
Isso amplia o alcance da atualização. Não basta corrigir o servidor de produção e deixar ferramentas antigas instaladas nas estações de trabalho dos desenvolvedores, servidores de automação ou máquinas utilizadas para restauração de backups.
Um arquivo de backup não deve ser considerado automaticamente confiável apenas porque utiliza um formato reconhecido pelo PostgreSQL. A procedência dos arquivos e a versão dos utilitários empregados no processamento precisam fazer parte da estratégia de segurança.
Versões corrigidas e o fim do suporte ao PostgreSQL 14
A atualização de segurança contempla todas as cinco principais versões mantidas pelo projeto. Os pacotes disponibilizados em 12 de novembro de 2026 são:
| Versão anterior | Versão corrigida |
|---|---|
| PostgreSQL 18.x | 18.7 |
| PostgreSQL 17.x | 17.12 |
| PostgreSQL 16.x | 16.16 |
| PostgreSQL 15.x | 15.20 |
| PostgreSQL 14.x | 14.25 |
Todas as versões anteriores às respectivas correções estão sujeitas às vulnerabilidades abrangidas pelo comunicado, embora algumas falhas tenham alcance restrito a determinadas versões principais.
Um detalhe merece atenção especial: o PostgreSQL 14.25 é a última atualização da série 14. O projeto declarou oficialmente o fim de vida (End of Life, EOL) dessa versão. Isso significa que não haverá novos patches de segurança ou correções de bugs para o PostgreSQL 14 depois dessa publicação.
Portanto, instalar a versão 14.25 resolve as vulnerabilidades desta rodada, mas não representa uma solução de segurança de longo prazo. Organizações que ainda utilizam essa série precisam planejar a migração para o PostgreSQL 15 ou uma versão posterior ainda suportada.
A escolha da versão de destino deve considerar compatibilidade com aplicações, extensões, procedimentos de replicação, ferramentas de monitoramento e integrações existentes. Uma migração de versão principal exige planejamento diferente de uma atualização menor, podendo envolver testes adicionais e utilização de ferramentas como pg_upgrade.
Como aplicar a atualização de segurança do PostgreSQL sem comprometer a infraestrutura
A correção não deve ser tratada como uma atualização convencional de manutenção. A quantidade de vulnerabilidades e, principalmente, as mudanças internas relacionadas aos tipos compostos exigem cuidados adicionais.
O próprio projeto PostgreSQL informa que não é necessário realizar um despejo e restauração (dump/restore) nem utilizar pg_upgrade para atualizar entre versões menores da mesma série. O procedimento normal consiste em interromper o serviço, atualizar os binários e iniciar novamente o servidor.
Entretanto, existem particularidades importantes.
1. Atualize imediatamente os servidores PostgreSQL
Identifique todas as instâncias em execução e confirme suas versões:
psql -c "SELECT version();"Planeje uma janela de manutenção, verifique a disponibilidade de backups e atualize os pacotes para a versão corrigida correspondente.
Em distribuições Linux, utilize os repositórios oficiais ou os canais de atualização mantidos pelo fornecedor da distribuição. Evite misturar pacotes de diferentes fontes, principalmente em ambientes empresariais.
2. Recompile e atualize todas as extensões escritas em C
Este é um dos cuidados mais importantes desta atualização.
A correção da CVE-2026-6460 introduz um mecanismo de versionamento para identificar valores compostos incompatíveis com a estrutura de dados esperada. Essa mudança afeta a interface binária utilizada pelas extensões desenvolvidas em C.
Consequentemente, extensões compiladas contra versões anteriores podem apresentar incompatibilidades, falhar ao carregar ou não oferecer a proteção esperada.
O PostgreSQL recomenda reconstruir essas extensões para garantir compatibilidade com os novos mecanismos internos. Algumas também precisarão de alterações no código-fonte.
Para quem utiliza os repositórios PGDG RPM, a orientação é atualizar o servidor e todas as extensões na mesma transação, sem deixar os componentes para uma manutenção posterior. Os mantenedores reconstruíram os pacotes de extensões para acompanhar as novas versões menores.
Não atualize apenas o servidor deixando as extensões antigas em produção. Essa sincronização é uma exigência particularmente importante para ambientes baseados em RHEL, Rocky Linux, AlmaLinux, Fedora e distribuições compatíveis.
3. Verifique ambientes com Patroni e gerenciamento externo
Infraestruturas que utilizam Patroni ou outros mecanismos externos de gerenciamento precisam de atenção adicional.
Quando a atualização dos binários acontece fora do controle direto da unidade de serviço padrão, o processo pode não reiniciar automaticamente todos os componentes necessários.
Isso significa que atualizar os pacotes não garante, por si só, que todos os processos estejam utilizando os novos arquivos executáveis e bibliotecas.
Após a instalação, verifique o estado de cada membro do cluster, confirme a versão efetivamente carregada e execute as reinicializações necessárias conforme a arquitetura de gerenciamento. Não considere a manutenção concluída enquanto existirem instâncias executando componentes antigos.
4. Atualize também os utilitários de cliente
Verifique todas as máquinas que executam ferramentas do ecossistema PostgreSQL, incluindo:
pg_dump, utilizado para gerar backups lógicos.pg_restore, responsável pela restauração de arquivos de backup.reindexdb, utilizado para reconstruir índices.vacuumdb, empregado na manutenção e atualização de estatísticas.
Também é importante atualizar o psql, especialmente em estações que processam scripts e arquivos de restauração recebidos de terceiros.
Esses programas podem estar instalados em servidores auxiliares, máquinas de desenvolvimento, pipelines de integração contínua e sistemas de automação. Atualizar somente o servidor principal deixa outros pontos vulneráveis.
5. Não desative a proteção composite_type_mismatch
A nova configuração composite_type_mismatch merece atenção especial.
Ela permite desativar as verificações introduzidas para identificar incompatibilidades entre valores compostos e suas definições de tipos. Embora possa ser necessária em situações específicas de compatibilidade com extensões, desabilitá-la representa um risco de segurança.
O procedimento recomendado é corrigir ou recompilar as extensões incompatíveis, em vez de enfraquecer as proteções implementadas pelo PostgreSQL.
6. Execute as verificações pós-atualização e revise os backups
A atualização também corrige problemas que poderiam provocar corrupção de índices.
Administradores devem revisar os registros de alterações e identificar índices potencialmente afetados. Entre os casos que merecem atenção estão índices GIN, índices GiST que utilizam gist_trgm_ops e determinados índices B-tree associados a colunas bpchar sem comprimento definido.
Quando houver suspeita de corrupção ou indicação nas notas de versão, execute a reindexação apropriada. Por exemplo:
REINDEX INDEX nome_do_indice;Para reconstruir os índices de uma tabela:
REINDEX TABLE nome_da_tabela;Outro alerta envolve os backups incrementais. O projeto recomenda não confiar nos arquivos incrementais anteriores à atualização, devido à descoberta de diferentes situações capazes de produzir cópias corrompidas.
Depois de atualizar, gere um novo backup completo e utilize essa cópia como base para os próximos incrementais. Essa medida é fundamental para evitar que uma estratégia de recuperação aparentemente funcional preserve arquivos inconsistentes.
Por fim, valide a inicialização dos serviços, a disponibilidade das aplicações, a replicação, os registros de erros e a integridade dos dados antes de encerrar a janela de manutenção.
Atualização de segurança do PostgreSQL exige planejamento, mas não pode esperar
A correção de 52 vulnerabilidades demonstra a importância de manter o PostgreSQL atualizado, especialmente em ambientes que concentram informações empresariais, aplicações financeiras e serviços essenciais.
A CVE-2026-6460 chama atenção pela idade do problema e pela possibilidade de execução de código com os privilégios do processo do banco. Entretanto, o risco não termina nessa vulnerabilidade: os problemas em ferramentas de cliente, a possibilidade de reinicialização remota e as demais falhas corrigidas ampliam a superfície de exposição.
Para administradores, o maior desafio operacional está na necessidade de atualizar servidor e extensões em conjunto, validar ambientes gerenciados externamente e revisar os procedimentos de backup. O encerramento do suporte ao PostgreSQL 14 acrescenta outra responsabilidade: planejar a migração para uma série mais recente.
Adiar a manutenção significa prolongar a exposição a vulnerabilidades que já possuem correções disponíveis. Por isso, a recomendação é priorizar os sistemas expostos à rede, os ambientes com múltiplos usuários e as instalações que executam extensões de terceiros.
Sua infraestrutura já recebeu a nova atualização de segurança do PostgreSQL? Compartilhe nos comentários como está sendo o processo de atualização dos bancos de dados em produção e se sua equipe já iniciou a migração do PostgreSQL 14.
Até o momento da divulgação, não havia confirmação pública de exploração ativa dessas vulnerabilidades. Ainda assim, a ausência de ataques conhecidos não deve ser interpretada como garantia de segurança, principalmente diante da gravidade das falhas e da disponibilidade das correções.
