O PostgreSQL lançou atualizações para corrigir uma falha de segurança que permite a uma conta com o atributo REPLICATION (replicação) executar código arbitrário como o usuário do sistema operacional que executa o servidor de banco de dados.
A falha, registrada como CVE-2026-6471 (nota CVSS — Sistema Comum de Pontuação de Vulnerabilidades: 7,2), está presente desde que a decodificação lógica foi introduzida no PostgreSQL 9.4, em 2014. Versões anteriores a PostgreSQL 18.6, 17.11, 16.15, 15.19 e 14.24 são afetadas.
A exploração exige uma conta com o atributo REPLICATION e um servidor rodando com wal_level = logical. Ferramentas de backup, servidores em espera, pipelines de captura de dados de alterações (CDC) e sistemas de monitoramento normalmente possuem esse atributo.
A correção, disponibilizada em 13 de agosto, adiciona um parâmetro de servidor chamado output_plugin_libraries que lista quais bibliotecas podem ser carregadas como plugins de saída de decodificação lógica, com padrão 'pgoutput, test_decoding'.
Instalações que utilizem qualquer outro plugin de saída, wal2json e decoderbufs entre eles, terão a decodificação lógica recusada após a atualização até que um administrador adicione a biblioteca à lista e recarregue a configuração do servidor.
"Anteriormente, um usuário de replicação podia selecionar qualquer biblioteca carregável para decodificação lógica, permitindo exploits de vários tipos. Para permitir bloquear isso sem quebrar configurações que funcionavam antes, introduzimos uma lista branca de plugins de saída permitidos", disse o PostgreSQL Global Development Group nas notas de lançamento da 18.6.
O Projeto PostgreSQL creditou Vladimir Tokarev e Yu Kunpeng pelo relato do problema.
Tokarev detalhou em um artigo de 1º de setembro para a empresa de segurança de dados Cyera Research, que batizou a falha como PostGREShell.
O nome do plugin fornecido em um comando CREATE_REPLICATION_SLOT é passado diretamente para a função que carrega a biblioteca, segundo a Cyera.
A restrição existente no PostgreSQL sobre caminhos de plugins, que limita usuários sem privilégios de superusuário a um único diretório controlado pelo administrador, nunca é acionada no caminho de replicação. O analisador do protocolo de replicação aceita quase qualquer caractere dentro do nome do plugin entre aspas duplas, incluindo separadores de caminho e traversal via ../, de modo que um caminho completo do sistema de arquivos chega ao carregador exatamente como digitado.
No Windows, o servidor resolve um caminho de rede via SMB (Bloco de Mensagens do Servidor) e busca a biblioteca em uma máquina controlada pelo atacante, sem escrever nada no alvo, segundo a Cyera.
No Linux e no macOS, o mesmo resultado exige habilitar a montagem automática via NFS (Sistema de Arquivos em Rede). Em qualquer outro ambiente, o atacante precisa de uma forma pré-existente de gravar um arquivo no disco do servidor. O código carregado dessa forma é executado dentro do processo backend do banco de dados como o usuário postgres do sistema operacional.
O plugin de teste da Cyera então gravou o catálogo de papéis diretamente para tornar a conta de replicação um superusuário do PostgreSQL. Também configurou três mecanismos de persistência que sobrevivem a uma reinicialização do servidor.
A Cyera descreve o atributo REPLICATION como uma credencial de backup de baixo privilégio, mas o PostgreSQL pontuou a falha com Privileges Required (Privilégios Necessários) definido como High (Alto), avaliação reproduzida na própria análise da SUSE.
O PostgreSQL recusou aplicar sua restrição existente de LOAD (carregamento de biblioteca) ao caminho de replicação.
"Usuários REPLICATION não estavam sujeitos anteriormente a restrições sobre caminhos de plugins de saída, então conseguiam contornar proteções de tempo de carregamento (LOAD) durante a decodificação lógica. Infelizmente, adicionar as restrições padrão de LOAD agora exigiria retroativamente que todos os plugins de saída de terceiros fossem instalados no diretório $libdir/plugins", disse Jacob Champion, autor da correção,
