O PostgreSQL liberou atualizações para corrigir uma falha de segurança que permite que uma conta com o atributo REPLICATION execute código arbitrário como o usuário do sistema operacional que está executando o servidor de banco de dados.
A vulnerabilidade, identificada como
CVE-2026-6471
e com pontuação CVSS de 7,2, existe desde a introdução da decodificação lógica no PostgreSQL 9.4, em 2014. As versões anteriores ao 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 operando com wal_level = logical. Ferramentas de backup, servidores de standby, pipelines de captura de dados modificados (CDC) e sistemas de monitoramento costumam ter esse atributo.
A correção, divulgada em 13 de agosto, adiciona um parâmetro de servidor chamado output_plugin_libraries, que define quais bibliotecas podem ser carregadas como plugins de saída da decodificação lógica. O valor padrão é 'pgoutput, test_decoding'.
Instalações que usam qualquer outro plugin de saída, entre eles wal2json e decoderbufs, 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.
“Antes, um usuário de replicação podia selecionar qualquer biblioteca carregável para a decodificação lógica, o que permitia explorações de vários tipos. Para permitir restringir isso sem quebrar configurações que funcionavam antes, introduzimos uma lista de permissões de plugins de saída autorizados”, informou o PostgreSQL Global Development Group nas notas de lançamento da versão 18.6.
O PostgreSQL atribuiu a descoberta do problema a Vladimir Tokarev e Yu Kunpeng.
Tokarev detalhou a falha em um texto publicado em 1º de setembro pela empresa de segurança de dados Cyera Research, que batizou a vulnerabilidade de PostGREShell.
Segundo a Cyera, o nome do plugin informado em um comando CREATE_REPLICATION_SLOT é passado diretamente para a função que carrega a biblioteca.
A restrição já existente do PostgreSQL sobre caminhos de plugin, que limita usuários sem privilégios de superusuário a um único diretório controlado pelo administrador, não é aplicada no caminho de replicação. O analisador do protocolo de replicação aceita quase qualquer caractere dentro de um nome de plugin entre aspas duplas, inclusive separadores de caminho e a navegação ../, de modo que um caminho completo no sistema de arquivos chega ao carregador exatamente como foi digitado.
No Windows, o servidor resolve um caminho de rede via Server Message Block (SMB) e busca a biblioteca em uma máquina controlada pelo atacante, sem gravar nada no alvo, disse a Cyera.
No Linux e no macOS, o mesmo resultado exige ativar a montagem automática de Network File System (NFS). Em qualquer outro cenário, o atacante precisa de uma forma pré-existente de gravar um arquivo no disco do servidor. O código carregado dessa maneira é executado dentro do processo de backend do banco como o usuário postgres do sistema operacional.
No teste conduzido pela Cyera, um plugin então gravou diretamente o catálogo de papéis para transformar a conta de replicação em superusuário do PostgreSQL. A empresa também criou três mecanismos de persistência capazes de sobreviver a uma reinicialização do servidor.
A Cyera descreve o atributo REPLICATION como uma credencial de baixo privilégio para backup, mas o PostgreSQL classificou a falha com o campo Privileges Required como High, avaliação replicada na análise da SUSE.
O PostgreSQL rejeitou a aplicação da restrição já existente do comando LOAD ao caminho de replicação.
“Os usuários com REPLICATION não estavam sujeitos anteriormente a restrições sobre caminhos de plugins de saída, então conseguiam contornar as proteções de carregamento no momento da decodificação lógica. Infelizmente, adicionar agora as restrições padrão do LOAD 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, na mensagem de commit.
Falhas no carregamento aparecem no log do servidor como ERROR: library "..." may not be used as an output plugin, com uma dica apontando para a configuração, segundo a documentação do parâmetro.
Os administradores são orientados a seguir estes passos:
Antes de atualizar, execute SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL; para identificar os plugins de saída em uso. Essa consulta só mostrará plugins que tenham sido usados com sucesso em algum momento.
Atualize para 18.6, 17.11, 16.15, 15.19 ou 14.24, ou para o pacote equivalente da sua distribuição.
Adicione qualquer plugin fora do padrão a output_plugin_libraries e recarregue a configuração com pg_ctl reload ou SELECT pg_reload_conf(). Não é necessário reiniciar.
Defina output_plugin_libraries no novo cluster antes de executar pg_upgrade --check ao migrar da versão 17 ou superior, já que a verificação falha se a lista não permitir os plugins de slot do cluster antigo.
Pacotes corrigidos estão disponíveis no Amazon RDS para todas as cinco linhas de versão, além de Debian, SUSE e Ubuntu.
O alerta do PostgreSQL cobre as versões suportadas de 14 a 18 e não trata das anteriores. O PostgreSQL 14 deixará de receber correções em 12 de novembro de 2026, informou o projeto no anúncio da versão.
A correção upstream “exige mudanças adicionais na configuração se algumas extensões forem usadas”, alerta o comunicado do Debian, que cita os pacotes wal2json e decoderbufs.
A USN-8653-1 do Ubuntu, publicada em 20 de agosto e que trouxe a correção para as versões LTS 22.04, 24.04 e 26.04, não menciona o parâmetro e orienta apenas os administradores a reiniciar o PostgreSQL após a atualização.
Até 4 de setembro, o projeto wal2json já havia atualizado sua documentação para orientar os usuários a adicionar o plugin a output_plugin_libraries, citando a CVE.
Ainda há uma lacuna na correção. O comando pg_createsubscriber cria slots de replicação usando pgoutput sem verificar o novo parâmetro, então o modo --dry-run funciona, mas a conversão falha depois.
“O comando pg_createsubscriber cria slots de replicação com o plugin 'pgoutput', sem verificar a GUC. Isso significa que, se o nome do plugin não estiver especificado no parâmetro, o modo --dry-run passa, mas a conversão real falha. Isso é muito inesperado para os usuários e deveria ser evitado”, disse Hayato Kuroda, da Fujitsu, em mensagem à lista de e-mails pgsql-hackers.
Um patch ainda estava em revisão e não havia sido incorporado até 4 de setembro. A
CVE-2026-6471
também continuava fora do catálogo Known Exploited Vulnerabilities (KEV) da CISA até essa data.
Até que a atualização possa ser aplicada, a Cyera afirma que a exposição pode ser reduzida removendo o atributo REPLICATION de contas que não precisem dele, restringindo as entradas de replicação no pg_hba.conf a endereços conhecidos, bloqueando o tráfego de saída SMB na porta 445 e NFS na porta 2049 a partir dos servidores de banco de dados e desativando o autofs onde ele não for necessário.
Publicidade
Vibecoding cria 10x mais sistemas, 20x mais vulneráveis. E quem ganha com isso é a galera do hacking ético e pentest. Quer ser pago para invadir sistemas? Então você tem que aprender com a Solyd que são os melhores do Brasil. Saiba mais...