Uma falha de confusão de tipo (type confusion) no PostgreSQL permite que um usuário do banco de dados com permissão para criar objetos execute código no servidor. As atualizações lançadas ontem corrigem a falha, junto com outras 51 vulnerabilidades de segurança. A proteção completa contra essa falha também exige recompilar as extensões em linguagem C instaladas no servidor.
A falha, catalogada como CVE-2026-6460 (sigla de Common Vulnerabilities and Exposures, ou Vulnerabilidades e Exposições Comuns), tem pontuação 8,8 no CVSS (sigla de Common Vulnerability Scoring System, ou Sistema de Pontuação de Vulnerabilidades Comuns). Qualquer código executado dessa forma tem os privilégios do usuário do sistema operacional que roda o PostgreSQL. Estão afetadas todas as versões anteriores às 18.7, 17.12, 16.16, 15.20 e 14.25.
O PostgreSQL Global Development Group, responsável pela publicação das versões do banco, não registrou nenhum ataque que tenha explorado a falha. A avaliação da CISA (Agência de Segurança Cibernética e de Infraestrutura dos EUA) no registro da CVE também indica que não há exploração conhecida.
A falha envolve tipos compostos, que são tipos formados por campos nomeados, cada um com seu próprio tipo de dado. O tipo de um campo pode ser alterado enquanto valores antigos desse tipo ainda estão armazenados em outras partes do servidor.
Assim, o servidor pode ler um valor antigo como se ele tivesse o novo tipo. A correção, descrita nas notas de versão do projeto, adiciona verificações de versão para que o servidor identifique um valor que não corresponde mais ao seu tipo.
O pesquisador de segurança Mehmet Ince descreveu um exploit (programa que aproveita a falha) funcional, demonstrado no PostgreSQL 18.6, em um relato técnico publicado nesta semana.
O método consiste em preparar uma consulta que contenha um valor, alterar o tipo de um dos campos desse valor e, em seguida, executar a consulta. O relato inclui o código SQL (sigla de Structured Query Language, ou Linguagem de Consulta Estruturada) que derruba um servidor não corrigido dessa forma, além de uma segunda etapa que vaza endereços de memória. Não inclui o SQL da etapa final, que faz o servidor executar um comando.
Ele escreveu que conseguiu “acionar essa falha com um perfil de login de menor privilégio”. O aviso de segurança do projeto descreve o atacante apenas como alguém que pode criar objetos, sem dizer quais privilégios isso exige.
A Red Hat, que distribui pacotes do PostgreSQL, afirma em sua avaliação da CVE que o atacante precisa de um login no banco de dados com capacidade de criar ou modificar objetos. Nenhuma dessas fontes informa se uma conta apenas com privilégios padrão consegue ir além da queda do servidor e executar código.
Ince rastreia a origem da falha até 5 de maio de 2004, quando o PostgreSQL ganhou a capacidade de alterar o tipo de uma coluna. Sua técnica para executar código depende de uma mudança posterior, feita em 14 de maio de 2015.
Ele também adaptou o exploit para serviços gerenciados de PostgreSQL e compartilhou em particular provas de conceito com as equipes de segurança desses provedores em agosto. Os provedores com os quais ele trabalhou incluem AWS (Aurora e RDS), Microsoft (Azure PostgreSQL), Google (AlloyDB), Supabase, Databricks e Ubicloud. O relato não informa o status atual de correção de cada serviço.
O projeto credita mais de uma dezena de pesquisadores pela CVE-2026-6460, incluindo o próprio Ince, e também o credita por outras cinco falhas da mesma versão.
O projeto classifica 32 das 52 falhas com nota 8,8, a mais alta da versão. Com base nas pontuações de seu índice de vulnerabilidades, apenas uma falha no servidor não exige login nem qualquer ação do usuário. Essa falha, CVE-2026-116322, permite que um cliente não autenticado acione a reinicialização de servidores PostgreSQL 18.
Outras correções estão em ferramentas cliente. Um arquivo compactado malicioso pode fazer o pg_restore executar código como o usuário que o executa. Um servidor de origem comprometido pode fazer o psql executar código por meio do script de restauração presente na saída tar do pg_dump.
O que os administradores devem fazer
- Atualize o servidor para 18.7, 17.12, 16.16, 15.20 ou 14.25, de acordo com sua versão principal.
- Recompile ou atualize todas as extensões em linguagem C ao mesmo tempo que o servidor. Extensões compiladas para versões anteriores ainda são carregadas, mas “podem não estar protegidas contra as vulnerabilidades corrigidas nesta versão”, segundo um comunicado do repositório dos mantenedores de pacotes RPM (sigla de RPM Package Manager, gerenciador de pacotes) do projeto. Algumas extensões também precisarão de alterações no código-fonte.
- Extensões recompiladas para as novas versões podem falhar ao carregar em servidores mais antigos. Os pacotes de extensão nos repositórios RPM do projeto agora exigem a nova versão secundária.
- Se o PostgreSQL rodar fora da unidade de serviço do próprio pacote, por exemplo sob o Patroni, reinicie-o logo após a atualização, afirma um mantenedor dos pacotes RPM em um post de blog sobre empacotamento.
- Atualize ferramentas cliente como pg_dump, pg_restore, reindexdb e vacuumdb em todas as máquinas que as executam.
- Não use a nova configuração composite_type_mismatch para desativar as verificações. Segundo o projeto, isso traz riscos de segurança.
- O aviso de segurança e as notas de versão do projeto não oferecem nenhuma solução alternativa para servidores que ainda não podem ser atualizados.
- O PostgreSQL 14 chegou ao fim de vida útil (end-of-life), e a versão 14.25 é a última. Versões principais mais antigas também são afetadas e não receberam atualização.
- Após a atualização, siga os passos de reindexação do anúncio da versão. Se você usa backups incrementais, faça um novo backup completo e baseie os backups incrementais seguintes nele.
