PostgreSQL corrige 52 falhas de segurança, incluindo vulnerabilidade descoberta após 22 anos

O PostgreSQL lançou atualizações de segurança para corrigir 52 vulnerabilidades, incluindo uma falha de alta gravidade presente no banco de dados há mais de duas décadas. Identificada como CVE-2026-6460, a vulnerabilidade permite que usuários autenticados, com permissões para criar objetos no banco, executem código no servidor.

A falha recebeu pontuação CVSS 8.8 e afeta todas as versões anteriores às atualizações 18.7, 17.12, 16.16, 15.20 e 14.25. A exploração bem-sucedida permite executar comandos com os privilégios da conta do sistema operacional responsável pelo processo do PostgreSQL.

O PostgreSQL Global Development Group não relatou ataques explorando a vulnerabilidade. O registro da CVE também não apresenta evidências de exploração ativa, segundo a avaliação da CISA.

Falha permite confusão de tipos e execução de código

A vulnerabilidade está relacionada ao processamento de tipos compostos (composite types), estruturas que agrupam campos identificados por nomes e tipos de dados específicos.

O problema ocorre quando o tipo de um campo é alterado enquanto valores antigos continuam armazenados em outras partes do servidor.

Nessas condições, o PostgreSQL pode interpretar um valor antigo como se pertencesse ao novo tipo, provocando uma condição de confusão de tipos (type confusion).

A correção introduz verificações de versão para identificar valores que não correspondem mais à definição atual de seus tipos.

O pesquisador de segurança Mehmet Ince publicou uma análise técnica demonstrando a exploração da vulnerabilidade no PostgreSQL 18.6.

A técnica envolve preparar uma consulta que mantém determinado valor em memória, modificar o tipo de um de seus campos e executar posteriormente a consulta.

O pesquisador apresentou comandos SQL capazes de provocar a interrupção de um servidor vulnerável e uma segunda etapa que permite obter endereços de memória. Entretanto, não divulgou o código SQL utilizado na etapa final de execução de comandos.

Ince afirmou que conseguiu provocar a falha utilizando uma conta autenticada com privilégios mínimos.

Apesar disso, o comunicado oficial do PostgreSQL descreve o cenário de exploração como dependente de permissões para criar objetos no banco de dados. A Red Hat também considera necessário que o invasor tenha uma conta capaz de criar ou modificar objetos.

Não foi confirmado se usuários com apenas as permissões padrão conseguem avançar da interrupção do serviço até a execução de código.

Vulnerabilidade existe desde 2004

Segundo Mehmet Ince, a origem da CVE-2026-6460 remonta a 5 de maio de 2004, quando o PostgreSQL passou a permitir alterações no tipo de dados de colunas.

Entretanto, a técnica utilizada para alcançar a execução de código depende também de uma modificação introduzida posteriormente, em 14 de maio de 2015.

O pesquisador adaptou a exploração para serviços gerenciados de PostgreSQL e compartilhou provas de conceito de maneira privada com equipes de segurança em agosto.

Entre os provedores envolvidos estão AWS, com Aurora e RDS; Microsoft, com Azure PostgreSQL; Google, com AlloyDB; além de Supabase, Databricks e Ubicloud.

A publicação não informa a situação atual das correções em cada um desses serviços.

O projeto PostgreSQL atribuiu a descoberta da CVE-2026-6460 a mais de uma dezena de colaboradores, incluindo Ince, que também recebeu créditos por outras cinco vulnerabilidades corrigidas na mesma atualização.

Outras 51 vulnerabilidades também foram corrigidas

Das 52 falhas corrigidas, 32 receberam pontuação CVSS 8.8, a maior classificação de gravidade registrada nessa atualização.

Entre os problemas identificados está a CVE-2026-116322, que permite que um cliente não autenticado provoque a reinicialização de servidores PostgreSQL 18.

De acordo com as classificações disponíveis no índice de vulnerabilidades do projeto, essa é a única falha do servidor que não exige autenticação nem interação do usuário.

Outras vulnerabilidades afetam ferramentas utilizadas para administração e recuperação de bancos de dados.

No utilitário pg_restore, um arquivo especialmente preparado pode provocar a execução de código com os privilégios do usuário que realiza a restauração.

Já no psql, um servidor de origem comprometido pode explorar scripts de restauração presentes na saída TAR do pg_dump para executar comandos.

Esses problemas ampliam o escopo das atualizações, que devem contemplar não apenas os servidores PostgreSQL, mas também os sistemas que executam ferramentas cliente.

Correção exige atualização de extensões desenvolvidas em C

O PostgreSQL Global Development Group recomenda que os administradores atualizem os servidores para as versões corrigidas correspondentes às suas instalações.

Entretanto, a atualização do banco de dados não é suficiente para garantir proteção completa contra a CVE-2026-6460.

Extensões desenvolvidas em linguagem C também precisam ser recompiladas ou atualizadas para utilizar as novas verificações de segurança.

Segundo os mantenedores dos pacotes RPM do PostgreSQL, extensões compiladas para versões anteriores podem continuar funcionando, mas não necessariamente estarão protegidas contra as vulnerabilidades corrigidas.

Algumas extensões também podem exigir alterações no código-fonte.

Por outro lado, extensões recompiladas para as versões atualizadas podem deixar de funcionar em servidores antigos. Por isso, os pacotes de extensões dos repositórios RPM oficiais passaram a exigir as novas versões menores do PostgreSQL.

Administradores que executam o banco fora da unidade de serviço padrão, como em ambientes gerenciados pelo Patroni, também devem garantir a reinicialização do PostgreSQL imediatamente após a atualização.

As ferramentas pg_dump, pg_restore, reindexdb e vacuumdb precisam ser atualizadas em todas as máquinas que as utilizam.

O projeto também recomenda não desabilitar as novas verificações por meio da configuração composite_type_mismatch, pois essa alteração pode reintroduzir riscos de segurança.

PostgreSQL 14 chega ao fim do suporte

A versão 14.25 representa a última atualização da linha PostgreSQL 14, que chegou ao fim de seu ciclo de suporte.

Versões principais ainda mais antigas também são afetadas pelas vulnerabilidades, mas não receberam correções.

Após a instalação das atualizações, os administradores devem seguir os procedimentos de reindexação descritos no comunicado oficial.

Ambientes que utilizam backups incrementais também precisam realizar um novo backup completo e utilizá-lo como base para as próximas cópias incrementais.

O projeto não apresentou soluções alternativas para servidores que não possam receber as atualizações imediatamente.