CVE-2025-1094 no PostgreSQL: quando uma função de escape pode permitir SQL injection

Publicado em 2026-10-27 por frfrand

Explicamos o caso de injeção SQL em funções de escape do PostgreSQL, alcance preciso, versões corrigidas e mitigações.

O problema que ninguém esperava de uma função de segurança

Em um banco de dados, costumamos confiar nas funções que preparam caracteres especiais para uma consulta. Mas CVE-2025-1094, corrigida em fevereiro de 2025, demonstrou que até mesmo essas defesas precisam de contexto. O problema afetou determinadas funções de escape da biblioteca cliente libpq e ferramentas de linha de comando do PostgreSQL. Sob combinações específicas de entradas e codificações, um texto supostamente preparado poderia acabar alterando uma instrução SQL.

O que é SQL injection e por que preocupa?

A injeção SQL ocorre quando dados externos são interpretados como parte de um comando enviado ao banco de dados. Dependendo dos privilégios, pode modificar registros, ler informações ou alterar o comportamento de uma tarefa. Nem toda injeção SQL concede controle total: os resultados dependem de qual consulta é construída e com qual usuário ela é executada.

O que essa CVE corrigia exatamente?

O aviso oficial menciona PQescapeLiteral(), PQescapeIdentifier(), PQescapeString() e PQescapeStringConn() em certas situações em que a entrada não passa pela validação de codificação. Para as funções do libpq, o cenário relevante inclui usar o resultado ao construir entradas para psql, o cliente interativo. Também foi descrito um caso em utilitários de linha de comando com combinações de codificação BIG5 e EUC_TW ou MULE_INTERNAL. Não é um defeito que afete toda consulta parametrizada do PostgreSQL.

Quem descobriu e como se estuda uma falha assim?

O caso foi documentado e corrigido por meio do processo de segurança do PostgreSQL. Para investigar vulnerabilidades desse tipo, compara-se como uma mesma string é interpretada no cliente, no parser e no banco de dados, especialmente com caracteres inválidos ou codificações incomuns. Não se deve atribuir uma técnica ou um pesquisador específico sem consultar o crédito oficial do registro.

Como alguém pode aproveitá-lo?

Um atacante precisa que o aplicativo ou um script permita a inserção de dados que resultem em uma construção SQL vulnerável. No cenário descrito, o texto mal codificado pode escapar das regras de aspas esperadas ao atravessar as ferramentas envolvidas. O dado-chave é a forma de construir as ordens, não apenas a versão do servidor. Sem esse padrão de uso, a presença de uma versão histórica não demonstra exploração.

Quais versões foram afetadas?

O fornecedor identifica os ramos anteriores a 17.3, 16.7, 15.11, 14.16 e 13.19 como afetados no aviso de fevereiro de 2025. Hoje, convém manter um ramo respaldado pelo projeto ou por um distribuidor que documente patches; não instale versões históricas apenas porque foram o primeiro fix.

Como saber se meu aplicativo está em risco?

1. Inventarie versões do PostgreSQL, libpq, ferramentas como psql e bibliotecas cliente do backend. 2. Identifique scripts que concatenem instruções SQL ou que gerem arquivos para psql. 3. Verifique se são admitidos dados de usuários nesses fluxos e como as codificações são validadas. 4. Revise as permissões da função do banco de dados; nunca use uma conta de superusuário para tarefas normais. 5. Confirme com os boletins de pacotes se você possui patches retroportados.

Como se corrige?

Aplique a atualização pertinente em clientes e servidor quando for o caso. Prefira consultas parametrizadas em vez de concatenar SQL manualmente; evite construir comandos de psql com entradas não confiáveis; e teste os processos de importação e migração após o patch. Um WAF web não necessariamente vê as tarefas internas de dados que originam a exposição.

Perguntas rápidas

Afecta o Django? O Django costuma usar parâmetros SQL, mas scripts auxiliares ou integrações personalizadas podem utilizar outros caminhos. Investigue o uso real.

A base está comprometida? Não se pode deduzir apenas por uma versão antiga.

O PostgreSQL 17.x é sempre seguro? Não: é necessário conhecer a subversão e os patches.

Fontes: Boletim oficial PostgreSQL CVE-2025-1094 · Registro CVE.

Onde seguir alertas CVE e receber orientação?

Em ArduMaker CVE e suporte publicamos atualizações e centralizamos consultas sobre vulnerabilidades, começando pelo WordPress e suas tecnologias relacionadas. Se o seu caso envolver outro runtime ou um banco de dados, especifique componente, versão, sistema operacional e exposição do serviço para contextualizá-lo. O aviso de uma CVE não prova que seu servidor esteja comprometido: a avaliação requer inventário, configuração e evidência.

Nota editorial — outubro de 2026: estas versões corrigidas são os marcos do aviso original. Ao atualizar hoje, escolha um ramo com suporte vigente e verifique o comunicado atual do fabricante.

Exemplo prático: parâmetros em vez de construir SQL com texto

Situação: uma API em Python consulta o PostgreSQL por e-mail. Um desenvolvedor escreve uma consulta concatenando o que chega do formulário. Isso é um antipadrão perigoso, embora CVE-2025-1094 se refira especificamente a funções de escape/libpq e certos fluxos com psql.

Padrão seguro com o driver psycopg:

email = request_data["email"]
cursor.execute(
    "SELECT id, nombre FROM clientes WHERE email = %s",
    (email,)
)
cliente = cursor.fetchone()

O driver trata o e-mail como valor, não como SQL. Para avaliar o CVE real, revise também a versão de libpq e psql, não apenas SELECT version() no servidor.

Antes: scripts que interpolam strings para passá-las ao psql. Depois: parâmetros sempre que possível, revisão de codificações, atualização de pacotes cliente e permissões mínimas do papel SQL.

Por que o exemplo ajuda? Ensina a eliminar a classe habitual de erros por concatenação, embora não substitua o patch específico da falha de escape registrada pelo PostgreSQL.