PostGREShell: uma vulnerabilidade de 12 anos no PostgreSQL transforma acesso REPLICATION em RCE

O pesquisador Vladimir Tokarev, da Cyera Research, divulgou detalhes do CVE-2026-6471 (PostGREShell), uma vulnerabilidade do PostgreSQL que existe desde a versão 9.4 (2014). Ela permite que uma conta com o privilégio REPLICATION carregue uma biblioteca arbitrária e execute código no processo do PostgreSQL.

O problema está no mecanismo de decodificação lógica. Ao criar um slot de replicação lógica, o cliente especifica um plugin de saída — uma biblioteca compilada (.so, .dll, .dylib) que o PostgreSQL carrega em seu processo. Para o comando SQL LOAD, o PostgreSQL restringe o carregamento de bibliotecas por meio de check_restricted_library_name(). No entanto, essa verificação não era realizada no caminho de replicação: o nome do plugin de saída era passado diretamente ao carregador, enquanto o parser do protocolo de replicação aceitava componentes de caminho incluindo /, \, ../ e até caminhos UNC do Windows. Como resultado, um atacante pode especificar um caminho para sua própria biblioteca e fazê-la ser carregada via dlopen() ou LoadLibrary().

No Windows, o ataque pode ser totalmente remoto se as seguintes condições forem atendidas: • Uma conta PostgreSQL com REPLICATION; • wal_level = logical; • Conectividade SMB/445 de saída do servidor para o atacante. Um caminho UNC como \\atacante\compartilhamento\evil.dll pode ser especificado como plugin. Quando o PostgreSQL chama LoadLibrary(), o Windows se conecta ao servidor SMB do atacante e carrega a DLL diretamente no processo do PostgreSQL — nada precisa ser colocado no sistema de arquivos de destino antecipadamente.

No Linux/macOS, um cenário semelhante é possível via NFS quando o automount /net está ativo. Em ambientes típicos Linux/Docker/Kubernetes, o atacante também precisa de uma forma de escrever um arquivo .so em um sistema de arquivos acessível ao PostgreSQL.

O código carregado executa com os privilégios do usuário de sistema postgres. Em sua prova de conceito, os pesquisadores usam uma função interna do PostgreSQL para se tornar o superusuário bootstrap da sessão atual e, em seguida, modificam diretamente pg_authid para tornar persistentes os privilégios de superusuário do PostgreSQL.

O caminho vulnerável foi introduzido com a decodificação lógica no PostgreSQL 9.4 e permaneceu exposto por aproximadamente 12 anos. A Cyera também encontrou 114 plugins maliciosos do PostgreSQL no VirusTotal, incluindo trojans, mineradores de criptomoedas e shells reversos. No entanto, isso não prova que o CVE-2026-6471 foi explorado em ataques no mundo real.

Para mitigar a vulnerabilidade, instale a atualização de segurança do PostgreSQL, audite contas com REPLICATION, remova o privilégio onde não for estritamente necessário, restrinja as contas restantes a IPs confiáveis conhecidos via pg_hba.conf e bloqueie tráfego SMB/445 e NFS/2049 de saída desnecessário dos servidores PostgreSQL.

Artigo: https://www.cyera.com/research/postgreshell-the-database-powering-much-of-the-internet-had-an-open-door-for-12-years