PostgreSQL recebe correção fora de ciclo para 28 vulnerabilidades críticas, incluindo execução remota de código

A Postgres↳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 → Professional, empresa por trás de um dos forks corporativos do PostgreSQL, publicou atualizações de segurança fora do ciclo que fecham 28 vulnerabilidades críticas e mais de 110 bugs encontrados no PostgreSQL. Segundo reportagem do CNews, parte dessas falhas permite que um atacante remoto assuma o controle do servidor de banco de dados, o que na prática coloca em risco toda a infraestrutura onde o SGBD roda.

O ponto que interessa para quem opera PostgreSQL em produção no Brasil é que essas correções nascem no projeto upstream: o fork russo apenas as portou primeiro para sua edição Enterprise. Ou seja, as CVEs citadas afetam o ecossistema PostgreSQL como um todo, não um produto de nicho. Se você mantém instâncias em produção, é caso de acompanhar o anúncio oficial de segurança do projeto e o boletim da sua distribuição ou provedor de nuvem.

Três grupos de risco

O release organiza as falhas por tipo de impacto no negócio. Vale entender a diferença, porque cada categoria muda o cálculo de urgência.

1. Execução de código arbitrário (RCE). É o grupo mais grave, com falhas de CVSS 8.8, que permitem executar código remotamente no servidor. Estão aqui vulnerabilidades de estouro de buffer e de confusão de tipos (type confusion):

Chama atenção que componentes de uso cotidiano estejam na lista: pg_dump e pg_stat_statements fazem parte da rotina de qualquer time que faz backup lógico ou observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps → de consultas.

2. Acesso não autorizado a dados. Inclui injeções de SQL que permitem contornar o controle de acesso e ler dados sem permissão. O destaque é a CVE-2026-15741, que possibilita injeção de SQL pelo argumento de EXTRACT() durante o deparsing de expressões.

3. Execução de comandos do sistema operacional. Falhas que escapam do SGBD e chegam ao shell do servidor:

• CVE-2026-18408: execução de comandos de shell via psql \unrestrict na restauração de dump.
• CVE-2026-6471: carregamento de bibliotecas arbitrárias na decodificação lógica. A correção restringe os módulos permitidos ao parâmetro output_plugin_libraries.
• CVE-2026-6464: em falha precoce de COPY FROM STDIN, linhas de dados podem ser interpretadas como comandos do psql, abrindo caminho para execução no nível do shell.

Por que "fora de ciclo" importa

A empresa separou deliberadamente correções de segurança das atualizações funcionais. A justificativa, dada pela CTO Yulia Rydenkova, é reduzir o risco de mexer numa aplicação que já funciona só para fechar uma brecha:

Para sistemas de negócio, é importante não só fechar rápido as ameaças de segurança, mas também manter a previsibilidade da operação. Por isso lançamos as atualizações de segurança separadas das funcionais. O cliente pode instalar as correções necessárias de imediato, sem esperar a próxima atualização planejada e sem introduzir novos recursos ao mesmo tempo.

Yulia Rydenkova, CTO da Postgres Professional

Essa lógica é familiar para quem administra banco: aplicar patch de segurança não deveria arrastar mudança de comportamento do planejador ou de recursos. É o mesmo princípio de backport de correções que distribuições Linux e o próprio PostgreSQL upstream seguem nas releases de manutenção (as que mudam só o último número da versão).

O que muda na hora de atualizar

Um alívio operacional: segundo o material, a instalação não exige pg_upgrade nem export/import das bases. Basta:

# parar o servidor
# substituir os binários
# reiniciar o servidor

O tempo de parada tende a ser mínimo e não depende de negociação demorada com os donos dos dados, algo que na rotina de um DBA reduz bastante o atrito para agendar a janela.

A parte que não pode ser ignorada são as verificações recomendadas após o update, porque algumas correções tocam a representação interna de dados de índices:

• Índices GIN: revisar tabelas com esses índices e, se necessário, rodar ANALYZE para atualizar estatísticas, o que mantém o planejador de consultas correto.
• Índices btree_gist: reindexar índices em colunas dos tipos float4, float8, bit e bit varying. A mudança pode afetar o formato interno, e a reindexação garante consistência.
• Índices b-tree sobre ltree: reindexar quando os valores tiverem mais de 14.653 labels; acima desse limite os índices podem operar incorretamente.
• Decodificação lógica: revisar a configuração e adicionar plugins confiáveis ao parâmetro output_plugin_libraries. Isso é especialmente relevante para quem usa replicação ou soluções de CDC baseadas em decodificação lógica, cenário cada vez mais comum em arquiteturas de dados brasileiras que alimentam data lakes e streaming.

O que fica em aberto

A fonte é o anúncio de um fork comercial específico, com foco na sua edição Enterprise. O que o time de infraestrutura brasileiro precisa confirmar por conta própria: em quais versões upstream do PostgreSQL cada CVE foi corrigida, se a sua distribuição (Debian, RHEL, Ubuntu) ou seu provedor gerenciado (RDS, Cloud SQL, Azure Database) já disponibilizou os pacotes, e se instâncias expostas ou com extensões como pg_stat_statements e PL/Perl habilitadas exigem prioridade. Diante de falhas com potencial de RCE e injeção de SQL, o caminho seguro é tratar o patch como urgente e cruzar a lista de CVEs acima com o inventário do seu parque.

Fonte: CNews (Rússia)