PostgreSQL corrige um erro com 22 anos que permite executar código no servidor

O projeto PostgreSQL lançou a 12 de novembro as atualizações 18.7, 17.12, 16.16, 15.20 e 14.25. Segundo o projeto, corrigem 52 vulnerabilidades e mais de 140 outros erros. A mais comentada é a CVE-2026-6460, com pontuação de 8,8 em 10: um utilizador da base de dados autorizado a criar objetos pode executar o seu próprio código no servidor com as permissões do utilizador do sistema que corre o PostgreSQL. O projeto deu a mesma pontuação a outras 31 vulnerabilidades desta versão. Não há registo de ataques que explorem a CVE-2026-6460.

Porque é que o erro tem 22 anos

A falha envolve tipos compostos, ou seja, tipos formados por vários campos com nome. O tipo de um campo pode ser alterado enquanto valores antigos continuam guardados noutras partes do servidor, que depois lê um valor antigo como se já tivesse o tipo novo. No seu aviso, o projeto admite que o sistema acompanhava mal o tipo dos valores. O investigador Mehmet Ince, que demonstrou um exploit funcional na versão 18.6, situa a origem do problema a 5 de maio de 2004, quando o PostgreSQL passou a permitir mudar o tipo de uma coluna, segundo o The Hacker News.

Ince diz que conseguiu derrubar um servidor sem correção com a função de menos privilégios. Nenhuma das fontes esclarece se com essa conta é possível chegar a executar código. Em agosto adaptou o exploit às bases de dados geridas e partilhou-o com as equipas de segurança da AWS, Microsoft Azure, Google, Supabase, Databricks e Ubicloud. Não se sabe se todas já corrigiram.

Quem deve preocupar-se

Sobretudo quem deixa outras pessoas entrar na mesma base de dados: alojamentos, serviços na nuvem e qualquer projeto que dá aos clientes a sua própria conta PostgreSQL. Se só a sua aplicação fala com a base de dados, um atacante externo teria primeiro de obter permissões lá dentro. As ferramentas cliente também foram corrigidas: um arquivo manipulado pode levar o pg_restore a executar código na máquina de quem restaura a base. Só uma das 52 vulnerabilidades funciona sem iniciar sessão, e permite reiniciar um servidor PostgreSQL 18.

Não é a única atualização de servidor da semana a instalar sem demora: escrevemos há pouco sobre uma falha de HTTP/2 no Apache.

O que fazer

• Atualize o servidor para 18.7, 17.12, 16.16, 15.20 ou 14.25, conforme a sua versão principal. Não é preciso exportar e recarregar a base.
• Recompile ou atualize todas as extensões em C ao mesmo tempo. As compilações antigas continuam a carregar, mas segundo os responsáveis pelos pacotes RPM podem ficar sem proteção.
• Atualize o pg_dump, pg_restore, reindexdb e vacuumdb em todas as máquinas onde são usados.
• Se o PostgreSQL corre fora da unidade de serviço do pacote, por exemplo com Patroni, reinicie-o logo após a atualização.
• Não desative as novas verificações com a definição composite_type_mismatch: o projeto avisa que isso é um risco de segurança.
• Siga os passos da secção «Updating» do anúncio: reconstruir os índices afetados (GIN, GiST com pg_trgm, B-tree em colunas bpchar) e, se usar cópias incrementais, fazer uma nova cópia completa.
• Se usa a versão 14 ou anterior, planeie a migração: depois da 14.25 não haverá mais correções.