Bug de 22 anos no PostgreSQL vira falha de execução remota de código

Um defeito de 22 anos, uma CVE recente

Em 9 de novembro de 2026, o pesquisador de segurança Mehmet Ince publicou a terceira parte de uma série de seis posts chamada "Systemic Risks in the Managed 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 → Industry". Nela, ele narra como chegou à CVE-2026-6460: uma vulnerabilidade de type confusion (confusão de tipos) que, segundo ele, existe no núcleo do PostgreSQL há 22 anos.

O achado nasceu de um trabalho anterior. Entre junho e julho de 2026, Ince explorava vulnerabilidades de corrupção de memória em extensões do PostgreSQL, entre elas a pg_clickhouse, que traduz valores do ClickHouse para o formato nativo do Postgres. Ele reportou a falha da pg_clickhouse ao fornecedor, que corrigiu o problema em 23 de junho de 2026. Mas o processo de explorar essa extensão deixou uma pergunta em aberto: como o PostgreSQL decide, internamente, o que é cada valor?

Do Datum ao type confusion, com um agente de IA como professor

Para responder essa pergunta, Ince foi direto ao código interno do banco. Ele conta que usou um agente de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI →, batizado por ele de pg_expert (rodando sobre o modelo Opus 5), como tutor para entender conceitos como Datum e OID (Object Identifier).

A lógica que ele descreve é simples de resumir: todo valor dentro do PostgreSQL trafega como um Datum, um contêiner genérico de 8 bytes que não carrega, sozinho, nenhuma informação sobre seu próprio tipo. Quem diz o que aquele Datum representa é um OID separado, que aponta para uma linha no catálogo pg_type - e é essa linha que define qual função de entrada (typinput) e saída (typoutput) o Postgres vai chamar para interpretar os bytes.

Isso levou Ince a uma pergunta central, que ele registra nestes termos:

E se eu conseguisse de alguma forma trocar o tipo entre o momento em que o PostgreSQL constrói um valor e o momento em que ele usa esse valor?

Mehmet Ince, pesquisador de segurançaWhat if I could somehow change the type between the moment PostgreSQL constructed a value and the moment it used that value?

O truque: alterar o tipo depois que a query já foi entendida

A resposta técnica envolve três recursos do PostgreSQL combinados de um jeito que, segundo o próprio Ince, surpreende até quem conhece bem os internos do banco: tipos compostos, PREPARE/EXECUTE e ALTER TYPE ... ALTER ATTRIBUTE.

O passo a passo que ele demonstra é este:

CREATE TYPE pg_temp.poc AS (key uuid);

PREPARE pc_crash AS
SELECT '(01020000-0000-0000-0000-000000000000)'::pg_temp.poc;

ALTER TYPE pg_temp.poc
  ALTER ATTRIBUTE key TYPE bytea CASCADE;

EXECUTE pc_crash;

O PREPARE faz o PostgreSQL analisar e planejar a query uma vez, tratando o atributo key como uuid. Antes do EXECUTE, porém, Ince altera a definição do tipo composto para que o mesmo atributo passe a ser bytea. Quando o EXECUTE roda, o banco interpreta os bytes que eram um UUID válido como se fossem a representação interna de um bytea - e trava com segmentation fault.

A diferença em relação a uma técnica anterior do próprio Ince (abusar da LANGUAGE internal para forçar funções nativas a lerem um Datum como se fosse de outro tipo) é o nível de privilégio exigido. Aquela exigia superusuário; esta, segundo ele, pode ser disparada por qualquer role de login com o menor privilégio possível.

Por que isso é mais grave que um crash

Um segmentation fault já é sério em produção, mas o ângulo que dá nome ao CVE é a execução remota de código. A peça que explica isso é o formato bytea.

Internamente, o bytea usa uma representação chamada varlena, com um cabeçalho de 4 bytes antes do conteúdo. Ince descreve dois formatos possíveis para esse cabeçalho:

• Representação inline: os bytes iniciais só descrevem o tamanho do valor que vem em seguida.
• Representação externa expandida: quando o cabeçalho começa com 01, o PostgreSQL entende que o que vem depois não é o dado em si, mas um ponteiro para um objeto em memória.

No exemplo do UUID usado como prova de conceito, os 16 bytes controlados pelo atacante começam justamente com 01 02 - exatamente o padrão que, se o campo fosse de fato um bytea, faria o Postgres tratar o restante dos bytes como um endereço de memória. Ince afirma que esse é "o primitivo de exploração mais confiável" que já viu em vulnerabilidades do PostgreSQL, porque dá a um atacante a chance de controlar um ponteiro interno a partir de dados que, nominalmente, eram só um UUID.

Esta terceira parte da série termina na descoberta do crash e na análise do porquê ele acontece; o caminho completo até a execução de código, segundo a numeração do próprio post (3 de 6), deve ser detalhado nas partes seguintes da série.

O que isso muda para quem roda PostgreSQL no Brasil

O ponto mais prático do relato é o nível de privilégio necessário. Criar um tipo composto temporário, usar PREPARE/EXECUTE e rodar ALTER TYPE sobre um tipo que você mesmo criou não exige acesso de superusuário - só uma conexão autenticada comum.

Isso importa especialmente para três cenários comuns em times brasileiros:

• Bancos gerenciados: a série de Ince se chama "Systemic Risks in the Managed PostgreSQL Industry", e ele afirma acreditar que o problema afeta "provavelmente todas as ofertas compatíveis com Postgres" - categoria que inclui serviços como RDS, Cloud SQL, Supabase, Neon e Crunchy Data, muito usados por startups e empresas no Brasil.
• Ambientes multi-tenant, onde cada cliente ou equipe roda com uma role de baixo privilégio dentro da mesma instância: o relato sugere que isolamento de privilégio sozinho não bloqueia o ataque.
• Aplicações que expõem SQL de alguma forma (painéis de BI, notebooks internos, ferramentas de dados, endpoints que aceitam queries customizadas): qualquer superfície que permita rodar CREATE TYPE, PREPARE e ALTER TYPE em sequência vira caminho potencial.

Até a publicação deste relato, o material disponível não traz um advisory oficial do PostgreSQL com versões afetadas e status de correção para a CVE-2026-6460 - essa confirmação, se já existir, deve vir do canal oficial de segurança do projeto PostgreSQL ou das próximas partes da série de Ince. Vale acompanhar o blog do pesquisador e o changelog de segurança do seu provedor de banco gerenciado nos próximos dias.

Fonte: Hacker News