Um teste de segurança do PostgreSQL gerenciado pelo Snowflake mostrou como uma função de banco de dados com privilégios limitados poderia ser transformada em controle do servidor que executa o banco.
Pesquisadores encadearam vários recursos nativos do PostgreSQL para chegar à execução de comandos no sistema operacional, mesmo com o Snowflake tendo bloqueado as formas comuns de executar comandos e acessar arquivos por meio de SQL (linguagem de consulta estruturada).
A descoberta mostra como pequenas permissões podem se combinar e gerar um risco sério em serviços de nuvem gerenciados. Os pesquisadores afirmaram que a cadeia começou com uma conta que não é superusuário, chamada snowflake_admin.
Seu principal privilégio era o CREATEROLE, que permite a uma conta criar e gerenciar funções (roles). Por si só, essa permissão não dá controle total de um banco de dados. Neste caso, porém, ela ajudou a abrir um caminho por meio de outros recursos nos quais o banco confiava.
Pesquisadores da Varonis Threat Labs identificaram a cadeia de escalonamento de privilégios e a reportaram ao Snowflake.
A Varonis afirmou que o Snowflake corrigiu o problema do lado dele antes da publicação da pesquisa, por isso clientes que usam o Snowflake Postgres não precisam tomar medidas adicionais em relação a essa descoberta. A equipe reportou a cadeia pela primeira vez em 31 de maio de 2026 e a divulgou publicamente em 17 de outubro.
Pesquisadores invadem o banco de dados Snowflake PostgreSQL
A primeira etapa dependia do CREATEROLE. Os pesquisadores usaram essa permissão para conceder à conta inicial duas funções nativas: pg_read_all_data e pg_write_all_data.
Essas funções oferecem amplo acesso às tabelas do banco de dados e aos catálogos do sistema. Esse acesso permitiu que os pesquisadores alterassem entradas do pg_cron, uma extensão do PostgreSQL que executa tarefas agendadas.
Os pesquisadores modificaram uma tarefa agendada para que ela fosse executada como a conta postgres, que tem alto nível de privilégio. Quando a tarefa rodou, criou uma função SECURITY DEFINER.
Esse tipo de função é executado com as permissões de seu proprietário, e não com as do usuário que a chama. Os pesquisadores usaram a função para obter acesso de superusuário do PostgreSQL sem recorrer à alteração direta de função que o Snowflake havia bloqueado.
Esse acesso no nível do banco de dados, porém, ainda não equivalia ao controle do servidor. O Snowflake havia bloqueado rotas conhecidas, incluindo comandos que leem arquivos do servidor, alteram configurações do sistema ou executam programas por meio de SQL.
Os pesquisadores descobriram que a linguagem interna do PostgreSQL podia vincular um novo nome de função do banco a uma função em linguagem C já presente no software do servidor. Isso permitiu restaurar o acesso às funções bloqueadas de leitura e escrita de arquivos, sob nomes diferentes.
Com o acesso a arquivos, a equipe usou o recurso de objetos grandes (large objects) do PostgreSQL para escrever em um arquivo de configuração. Alterou o archive_command, uma configuração que executa um comando de shell (interpretador de comandos) quando o PostgreSQL arquiva um segmento de WAL (write-ahead log, ou registro de escrita antecipada) já concluído.
Um WAL registra as alterações do banco antes de serem totalmente gravadas nos arquivos de dados. Quando o comando configurado foi executado, os pesquisadores alcançaram a execução de comandos do sistema operacional com a conta de sistema postgres.
A descoberta lembra que bloquear funções conhecidas de SQL para o sistema operacional pode não ser suficiente se recursos relacionados continuarem disponíveis por outras rotas.
Também é relevante porque o provedor de um banco de dados gerenciado controla o servidor e seu sistema operacional, enquanto os clientes continuam decidindo como as funções do banco são atribuídas.
Riscos semelhantes de banco de dados para servidor já apareceram em outros cenários, incluindo uma falha de execução de código no PostgreSQL e uma falha de comando de shell no pgAdmin.
Possíveis impactos e resposta
Se um agente de ameaça obtivesse acesso semelhante, poderia alterar ou destruir arquivos do banco de dados, interferir na recuperação ou modificar registros locais.
Como a atividade no nível do sistema operacional pode não passar por consultas SQL comuns, os registros de auditoria do banco podem não mostrar o quadro completo.
A Varonis afirmou que a atividade demonstrada ficou restrita ao ambiente de teste individual e de locatário único dos próprios pesquisadores. O relatório não diz que dados de clientes do Snowflake foram acessados.
O Snowflake tratou a cadeia do lado do servidor antes da publicação. O relatório diz que a empresa reconheceu a divulgação em 1º de junho e confirmou em 9 de junho que a execução local de código dentro da máquina virtual do Snowflake Postgres ultrapassou um limite de segurança.
Os pesquisadores observaram que a descoberta envolveu uma cadeia de comportamentos do PostgreSQL, e não uma amostra de malware nova. Para contexto sobre outro risco de execução relacionado ao PostgreSQL, os leitores podem consultar o relatório da GBHackers sobre execução remota de código no PostgreSQL do Appsmith.
Para equipes que mantêm seus próprios servidores PostgreSQL, os pesquisadores recomendam tratar o CREATEROLE como uma permissão de alto risco e removê-la de contas de aplicação, salvo quando for necessária.
Administradores devem revisar as concessões de funções, as tarefas agendadas do pg_cron e as funções SECURITY DEFINER em busca de alterações inesperadas.
Eles também devem restringir quem pode criar funções internas ou em linguagem C, proteger os arquivos de configuração do banco e manter os serviços de banco isolados de acessos de rede desnecessários.
Indicadores de comprometimento (IoCs)
Observação: endereços IP (Internet Protocol) e domínios foram intencionalmente desfigurados (por exemplo, [.]) para evitar resolução ou links acidentais. Restaure o formato original apenas em plataformas controladas de inteligência de ameaças, como MISP, VirusTotal ou seu SIEM (plataforma de gerenciamento de eventos de segurança).
