Vulnerabilidades do PostgreSQL: Tipos e como se proteger contra elas

Principais conclusões

• As vulnerabilidades do PostgreSQL se agrupam em quatro padrões: injeção de SQL, escalonamento de privilégios e execução de código, falhas no controle de acesso e uso indevido de ferramentas de backup.
• A atualização de 13 de agosto de 2026 corrigiu 28 CVEs de uma só vez, sendo que metade delas recebeu uma pontuação de 8,8.
• O pior cenário não é o vazamento de uma tabela, e sim uma cadeia de explorações que atinge o sistema operacional do host.
• Aplique patches rapidamente, reduza os privilégios, vincule seus parâmetros e não execute uma versão fora de suporte sem aplicar os patches.
• Se você achava que as funções de escape integradas ao PostgreSQL já tinham resolvido o problema da injeção de SQL, o CVE-2025-1094 diz o contrário.

O PostgreSQL possui um histórico de segurança realmente sólido e, assim como outros bancos de dados amplamente utilizados bancos de dados SQL , ele divulga alertas coordenados em uma frequência previsível; no entanto, vários dos bugs recentes têm sido graves, e alguns chegam a permitir a execução de código no host.

Os alertas de 2026 não mostram sinais de que o ritmo vá diminuir. Em fevereiro foram corrigidas cinco CVEs, em maio, onze, e em 13 de agosto foram corrigidas 28 em uma única divulgação coordenada, com falhas de alta gravidade afetando o servidor principal, os módulos contrib e as ferramentas do cliente. Aqui está um resumo dos tipos de vulnerabilidades que você realmente encontrará, o que acontece quando você as ignora e o que resolve o problema.

Tipos de vulnerabilidades do PostgreSQL

Uma observação sobre os intervalos de versões abaixo: Os alertas do PostgreSQL listam os ramos suportados que foram verificados, o que não significa que todas as versões mais antigas estejam totalmente em conformidade. Parte desse código é compartilhada entre os ramos e parte não, portanto, uma versão em fim de vida (EOL), como o PostgreSQL 13, deve ser avaliada individualmente, em vez de ser considerada vulnerável ou segura por padrão. O que é certo é que ninguém no upstream está mais fazendo essa avaliação para você. O CVE Tracker da TuxCare é a maneira mais rápida de verificar o que realmente foi avaliado para uma versão EOL e se já existe um patch por meio do Suporte de Ciclo de Vida Ilimitado.

Injeção de SQL

Ainda não está morta, por mais que muitos ORMs prometam o contrário. CVE-2025-1094, uma vulnerabilidade de injeção de SQL de alta gravidade identificada pela Rapid7 e corrigida em fevereiro de 2025, mostrou que mesmo entradas devidamente escapadas podem se transformar em uma injeção sob condições de codificação inadequadas. O problema principal era que as funções de escapamento da libpq (PQescapeLiteral, PQescapeIdentifier, PQescapeString e PQescapeStringConn) não conseguiam neutralizar a sintaxe de escapamento em textos que não passavam na validação de codificação. O mesmo tipo de bug que você encontraria em um aplicativo web mal desenvolvido, só que escondido uma camada mais a fundo. E a própria correção prejudicou essas funções de uma maneira diferente, fazendo com que elas ignorassem seus parâmetros de comprimento de string e causassem falhas em alguns chamadores, o que exigiu outro lançamento, uma semana depois, para ser resolvido.

Mais recentemente, a vulnerabilidade CVE-2026-6637 (CVSS 8,8) afetou o módulo refint contrib com um estouro de buffer de pilha que permite que um usuário sem privilégios do banco de dados execute código arbitrário na qualidade do usuário do sistema operacional que está executando o banco de dados.

Há uma segunda vulnerabilidade, mais restrita, na mesma falha: se um aplicativo declarar uma coluna controlada pelo usuário como uma chave primária refint em cascata, quem fornecer o valor de atualização para essa chave estará sujeito a uma injeção de SQL. Ambas as vulnerabilidades afetam as versões 14 a 18. O CVE-2026-6638 adiciona um vetor de injeção por meio de nomes de tabelas na instrução `ALTER SUBSCRIPTION … REFRESH PUBLICATION`, permitindo que um criador de tabela do lado do assinante execute SQL com as credenciais do lado da publicação, embora, na prática, seja muito mais restrito (CVSS 3,7, apenas versões 16 a 18).

O mês de agosto trouxe mais uma vulnerabilidade que vale a pena conhecer. A CVE-2026-15741 (CVSS 8,8) é uma injeção de SQL na desanálise da função EXTRACT(), na qual o proprietário de um objeto executa SQL arbitrário como superusuário por meio de uma definição de objeto maliciosa; a vulnerabilidade se manifesta em qualquer lugar onde expressões desanalisadas sejam consumidas, incluindo o pg_dump, comandos do psql como \sf e ferramentas não oficiais que realizam a mesma função. O padrão é idêntico em todos os casos: uma entrada que deveria ser inerte acaba se tornando executável.

Atenção: O CVE-2025-1094 apresenta dois caminhos distintos. Para as funções de citação da libpq, o risco surge quando sua saída é utilizada como entrada no psql. Para os utilitários de linha de comando, o gatilho específico é uma codificação BIG5 no cliente combinada com EUC_TW ou MULE_INTERNAL no servidor. Se sua pilha misturar codificações ou redirecionar a saída de consultas para o psql em qualquer ponto, aplique o patch no cliente.

Escalação de privilégios e execução remota de código

As extensões de linguagem procedural são poderosas, e é exatamente isso que as torna alvos atraentes para ataques. A vulnerabilidade CVE-2024-10979 (CVSS 8,8) permitia que um usuário sem privilégios do banco de dados alterasse variáveis de ambiente sensíveis do processo por meio do PL/Perl, incluindo a variável PATH; muitas vezes, isso é o suficiente para obter a execução de código arbitrário, mesmo quando o invasor não possui nenhuma conta no sistema operacional da máquina. A vulnerabilidade afetou todas as versões da 12 à 17; portanto, estar em uma versão recente não constituía uma proteção. O PL/Perl voltou a ser alvo em agosto de 2026 com o CVE-2026-14670 (CVSS 8,8), um estouro de buffer de heap no retorno de um hash vinculado que permite ao proprietário de uma função executar código como o usuário do sistema operacional do banco de dados por meio de um corpo de função malicioso.

O lote de fevereiro de 2026 ampliou essa categoria muito além das linguagens procedurais. O CVE-2026-2006 (CVSS 8,8) decorre da falta de validação do comprimento de caracteres multibyte no processamento de texto do núcleo, onde um usuário comum do banco de dados emite consultas maliciosas, causa um estouro de buffer e acaba executando código como usuário do sistema operacional. Não é necessária nenhuma extensão para esse caso. O CVE-2026-2005 (CVSS 8,8) é um estouro de buffer de heap no pgcrypto, acessível a qualquer pessoa que possa fornecer texto cifrado a ele, o que é mais grave do que parece, pois o pgcrypto é uma extensão confiável; isso significa que um usuário sem privilégios de superusuário, mas com privilégio CREATE no banco de dados, pode instalá-la com o comando CREATE EXTENSION. A CVE-2026-2004 (CVSS 8,8) afeta o intarray devido à falta de validação de tipo na entrada do estimador de seletividade. Acrescente a CVE-2026-2007, um estouro de heap no pg_trgm na versão 8.2 que afeta o PostgreSQL 18, e temos quatro bugs de alta gravidade em uma versão com cinco CVEs, sendo três deles em módulos contrib.

Vale ressaltar que uma pontuação CVSS pode abranger mais de um resultado prático. O CVE-2026-6473, do lote de maio, recebeu uma pontuação de 8,8 por um problema de transbordamento de inteiro que permite que um usuário sem privilégios do banco de dados aloque memória com tamanho insuficiente e escreva fora dos limites. O PostgreSQL afirma que isso pode levar à execução de código arbitrário como o usuário do sistema operacional do banco de dados, enquanto aplicativos que passam entradas na escala de gigabytes para as funções afetadas podem, em vez disso, causar uma falha de segmentação no provedor de entrada. É mais importante ler o comunicado do que apenas a pontuação.

O padrão observado nos casos mais graves é que o acesso no nível do banco de dados está, discretamente, se transformando em acesso no nível do host. A postura defensiva consiste na aplicação adequada do princípio do privilégio mínimo, o que significa restringir quem pode criar funções e objetos, remover extensões que seus aplicativos nunca utilizam e manter a superfície de exposição reduzida. Só não confunda nada disso com um substituto para a aplicação de patches, pois nada disso impede um bug de segurança de memória no processamento de texto do núcleo.

Falhas no controle de acesso e na segurança de linhas

Nem todo bug se revela. O CVE-2024-10976 surgiu devido a um rastreamento incompleto de tabelas que utilizavam segurança no nível da linha, de modo que um plano de consulta reutilizado poderia acabar retornando ou modificando linhas que não deveria ter acessado. Ele afeta apenas bancos de dados que realmente utilizam o comando CREATE POLICY, o que faz com que seja fácil ignorar o problema até você se lembrar quais dos seus aplicativos dependem desse recurso. O CVE-2026-14666 é a versão de agosto de 2026 da mesma ideia, em que políticas de segurança no nível da linha armazenadas em cache permanecem válidas após alterações na associação a funções, nos atributos das funções e na propriedade do banco de dados; assim, um usuário continua realizando leituras e gravações que eram permitidas há pouco tempo, mas que agora não são mais.

A vulnerabilidade CVE-2024-10978 também se enquadra nessa categoria. Um aplicativo que utilize SET ROLE ou SET SESSION AUTHORIZATION pode aplicar o ID de usuário errado a uma consulta, permitindo que um usuário com menos privilégios visualize ou altere linhas destinadas a outra pessoa. Não se trata de execução de código, mas exatamente do tipo de coisa que, discretamente, compromete um modelo multilocatário. Essas são as vulnerabilidades silenciosas, específicas do aplicativo e fáceis de passar despercebidas, pois nada trava. Os dados simplesmente vazam pela porta dos fundos.

O CVE-2026-6478 (CVSS 6,5) é mais um caso diferente. Um canal de temporização oculto na comparação de senhas com hash MD5 permite que um invasor recupere credenciais com qualidade suficiente para se autenticar. Isso não afeta o scram-sha-256, que já é o padrão em todas as versões suportadas há algum tempo, mas muitos bancos de dados em produção ainda contêm hashes MD5 herdados de uma atualização do PostgreSQL 13 ou versões anteriores. Essa é a população que está realmente em risco. Afeta as versões 14 a 18, corrigidas no lote de maio de 2026.

Ferramentas de backup e restauração

Essa vulnerabilidade não se encaixa no modelo mental habitual de vulnerabilidades de bancos de dados, e é exatamente por isso que merece uma categoria própria.

As vulnerabilidades CVE-2025-8714 e CVE-2025-8715 (ambas com CVSS 8,8) foram identificadas no pg_dump em agosto de 2025. A CVE-2025-8714 permite que um superusuário mal-intencionado no servidor de origem insira metacomandos do psql no dump, os quais são executados como a conta do sistema operacional do cliente durante uma restauração. O CVE-2025-8715 faz algo semelhante por meio de uma quebra de linha em um nome de objeto criado propositalmente, e pode-se argumentar que é o pior dos dois: ele requer apenas um usuário do servidor de origem, em vez de um superusuário, e o mesmo ataque também pode resultar em injeção de SQL como superusuário no destino da restauração. O pg_dumpall, o pg_restore e o pg_upgrade estão todos incluídos no escopo. O CVE-2012-0868 já havia corrigido essa classe de bug uma vez, e a versão 11.20 a reintroduziu discretamente.

Então, a correção precisou ser corrigida. O CVE-2026-18408 (CVSS 8,8, agosto de 2026) identificou outro caminho por meio da expansão de entrada contornando a proteção \restrict que havia sido introduzida para o CVE-2025-8714, sendo que o comando \unrestrict, por si só, já era suficiente para fazer com que o ataque original durante a restauração voltasse a funcionar. O lote de maio já havia adicionado o CVE-2026-6477 (CVSS 8,8), no qual um superusuário do servidor sobrescreve a memória da pilha no psql ou no pg_dump por meio da função lo_read() da biblioteca libpq.

A vulnerabilidade CVE-2026-6475 (CVSS 8,8) estende o problema aos comandos `pg_basebackup` e `pg_rewind`, nos quais o seguimento de um link simbólico permite que um superusuário de origem sobrescreva arquivos locais não relacionados, como, por exemplo, `/var/lib/postgres/.bashrc`, e assuma o controle da conta do sistema operacional. O PostgreSQL delimita cuidadosamente o escopo dessa vulnerabilidade, e você também deve fazer o mesmo: iniciar o servidor após a execução desses comandos já implica confiança implícita no superusuário de origem por meio de mecanismos como o `shared_preload_libraries`; portanto, a exposição prática reside em fluxos de trabalho que movem, criam instantâneos ou realizam outras ações nos arquivos resultantes antes que o servidor seja inicializado.

O fio condutor de toda esta seção é que a superfície de ataque não é o seu aplicativo nem o seu pool de conexões, e sim a sua tarefa de backup — algo que frequentemente é executado com privilégios elevados e raramente recebe o mesmo nível de análise que a configuração principal do banco de dados. Isso também serve como um lembrete de que boa parte dessas vulnerabilidades (CVEs) está no lado do cliente. O PostgreSQL as classifica sob o componente cliente, e aplicar patches no servidor não resolve nada para elas. As máquinas que executam o psql, o pg_dump, o pg_basebackup e o pg_createsubscriber precisam receber patches por conta própria.

Riscos decorrentes da falta de correção de vulnerabilidades do PostgreSQL

Essa não é uma decisão do tipo “vamos resolver isso no próximo sprint”. As consequências negativas vão desde um vazamento de dados incômodo até a perda total do controle sobre o servidor.

Uma violação que custa dinheiro de verdade

O Relatório da IBM de 2026 sobre o Custo de uma Violação de Dados estimou a média global em US$ 4,99 milhões, um recorde e um aumento de 12% em relação ao ano anterior, sendo que a detecção, a escalada e a perda de negócios foram os principais fatores responsáveis por esse aumento. O dado que deve preocupar qualquer pessoa que mantenha um ciclo de atualizações lento é o tempo. O tempo médio para identificar e conter uma violação subiu para 247 dias, revertendo cinco anos consecutivos de melhorias, e as violações que ultrapassaram a marca de 200 dias custaram cerca de um terço a mais do que aquelas resolvidas mais rapidamente.

As organizações que utilizam IA e automação nas etapas de prevenção, detecção, investigação e resposta resolveram as brechas cerca de dois meses mais rápido e gastaram US$ 1,93 milhão a menos do que aquelas que não utilizam essas tecnologias. Tudo isso reforça a importância de direcionar essa automação para o gerenciamento de vulnerabilidades — o trabalho de identificar e corrigir falhas antes que alguém as explore.

Comprometimento total do servidor, não apenas perda de dados

A vulnerabilidade CVE-2025-1094 está diretamente relacionada à vulnerabilidade CVE-2024-12356 da BeyondTrust, que foi explorada como uma vulnerabilidade zero-day no ataque de grande repercussão ao Departamento do Tesouro dos EUA. Em todos os cenários testados pela Rapid7, a exploração bem-sucedida da falha da BeyondTrust exigiu a exploração da vulnerabilidade CVE-2025-1094 para conseguir a execução remota de código. Assim que alguém estiver executando comandos de shell no host do banco de dados, o próprio banco de dados passa a ser a menor das suas preocupações – torna-se possível o movimento lateral pelo restante da sua frota de sistemas Linux.

As equipes que utilizam o PostgreSQL integrado a outros produtos muitas vezes nem percebem que estão expostas a riscos. O PostgreSQL é fornecido como uma dependência em muitos softwares de terceiros e, quando surge um CVE, você pode acabar aplicando uma correção em um banco de dados que nem lembrava que tinha.

Executando uma versão em fim de vida útil (EOL) sem patches

Quando uma versão principal chega ao fim de sua vida útil, o projeto original deixa de produzir correções de segurança para ela. Novas vulnerabilidades (CVEs) continuam sendo descobertas — elas simplesmente deixam de ser corrigidas nesse ramo. Vários dos 2.026 bugs mencionados acima afetam todos os ramos com suporte, do 14 ao 18, e o problema é que o PostgreSQL 14 deixa de receber correções em 12 de novembro de 2026; portanto, a versão com suporte hoje já será um problema no próximo trimestre. Se você estiver usando o PostgreSQL 13, não verá sua versão no comunicado e, de qualquer forma, não receberá uma correção do desenvolvedor original.

É exatamente isso que o Suporte de Ciclo de Vida Ilimitado da TuxCare foi criado. Ele faz o backport de correções CVE para o PostgreSQL 13 e as aplica por meio do seu gerenciador de pacotes habitual, com cobertura para o PostgreSQL 14 anunciada antes mesmo da data de fim de vida útil (EOL), para que você possa manter o sistema atualizado agora e migrar para uma versão suportada quando for mais conveniente para o seu plano de desenvolvimento.

Como se proteger contra vulnerabilidades do PostgreSQL

A segurança do PostgreSQL depende principalmente de disciplina, e não de atos heróicos. Três hábitos são suficientes para lidar com grande parte dos riscos práticos.

Aplique as correções imediatamente e acompanhe os CVEs

O PostgreSQL lança atualizações de segurança coordenadas em todos os ramos suportados ao mesmo tempo. O lote de novembro de 2024 corrigiu a vulnerabilidade CVE-2024-10979 e suas variantes nas versões 17.1, 16.5, 15.9, 14.14, 13.17 e 12.21 no mesmo dia. O lote de maio de 2026 trouxe onze correções nas versões 18.4, 17.10, 16.14, 15.18 e 14.23 simultaneamente, e o de 13 de agosto lançou vinte e oito correções nas versões 18.6, 17.11, 16.15, 15.19 e 14.24. Inscreva-se para receber os boletins e trate as atualizações de versão secundária como manutenção de rotina, em vez de um projeto que exija uma justificativa de negócios.

Dica profissional: Após uma atualização de versão secundária, execute SELECT version(); no psql para confirmar se o servidor está realmente na versão que você imagina. Um pacote que foi atualizado corretamente, mas cujo serviço nunca foi reiniciado, continuará indicando a versão antiga. Em seguida, verifique o lado do cliente separadamente, pois SELECT version() não fornece nenhuma informação sobre o psql, o pg_dump, o pg_basebackup ou a libpq nas máquinas que os executam. Uma armadilha específica do PostgreSQL 18: a versão 18.5 nunca foi lançada após a detecção de uma regressão após a conclusão do processo de compilação, portanto, o lançamento de agosto salta diretamente da versão 18.4 para a 18.6.

Restringir privilégios e a criação de extensões

Muitas vias de ataque ao PostgreSQL ainda passam por privilégios no nível do banco de dados, direitos de criação de objetos ou acesso a uma extensão específica; é por isso que o princípio do privilégio mínimo continua sendo tão importante. Limite quem pode criar funções em PL/Perl e PL/Python, remova as extensões que ninguém está usando e mantenha as funções de segurança bem restritas de maneira geral.

Os bugs recentes no refint, pgcrypto, intarray e pg_trgm são um bom argumento para auditar essa lista de extensões nesta semana, em vez de no próximo trimestre. Essas restrições teriam bloqueado a vulnerabilidade CVE-2024-10979 e reduzido várias outras, mas não impedirão um bug de segurança de memória no processamento de texto do núcleo; portanto, elas complementam a aplicação de patches, em vez de substituí-la.

Validar entradas e usar consultas parametrizadas

A fuga é um recurso de segurança, não uma estratégia por si só. Utilize consultas parametrizadas sempre que os valores vierem de entradas não confiáveis, de modo que essas entradas nunca tenham a chance de se tornar SQL executável. Para as partes de uma instrução que não podem ser definidas como parâmetros — ou seja, identificadores, nomes de tabelas, direção de classificação e qualquer outro elemento estrutural —, utilize uma lista de permissões rigorosa. Combine ambas as medidas com validação na fonte.

Melhores práticas para prevenir vulnerabilidades no PostgreSQL

Esses controles bloqueiam vias de ataque específicas. O próximo passo é tornar a detecção e a correção sistemáticas, para que os problemas sejam identificados e resolvidos antes que alguém consiga explorá-los.

Executar varredura contínua de vulnerabilidades

Não dá para corrigir o que não se vê, e as instâncias do PostgreSQL incluídas em pacotes ficam bem escondidas, às vezes até mesmo das pessoas que as administram. Faça varreduras continuamente, em vez de trimestralmente, para que um novo CVE apareça no seu radar em questão de horas, e não só na próxima auditoria. Quando um scanner sinalizar algo, confirme se é real antes de entrar em pânico, pois investigar um falso positivo desperdiça tempo que você não vai recuperar.

Automatize a aplicação de patches e abranja toda a pilha

A parte demorada da aplicação de patches geralmente não é encontrar a correção, e sim a janela de manutenção. A aplicação automatizada de patches reduz o intervalo entre a divulgação e a implantação, que é o período em que uma vulnerabilidade conhecida permanece explorável, mesmo que uma correção já esteja disponível. É também nesse ponto que a cobertura de fim de vida útil (EOL) mostra seu valor, já que a TuxCare retroporta correções de segurança para versões do PostgreSQL em fim de vida útil (EOL) que são suportadas, juntamente com as dependências diretas e transitivas cobertas; assim, uma versão sem suporte continua recebendo correções de qualquer maneira.

Dica de especialista: Defina o SLA da sua correção com base na data de divulgação do CVE, e não na data em que alguém por acaso percebeu a vulnerabilidade. Vulnerabilidades expostas à Internet tendem a começar a atrair tentativas de varredura e exploração logo após um aviso público; portanto, seu prazo deve começar a contar a partir do momento em que o aviso for divulgado.

Configurar o Harden e monitorar os registros

As configurações padrão são um ponto de partida, não uma configuração finalizada. Implemente o TLS para conexões de clientes e crie regras no arquivo pg_hba.conf que especifiquem os bancos de dados, funções, redes e métodos de autenticação que realmente precisam de acesso, em vez de deixar entradas genéricas sem ajuste. Remova ou ignore a instalação de extensões do contrib que você não estiver usando e fique atento aos logs para detectar erros SQL incomuns ou falhas repetidas do tipo injeção. Considerando quantos dos bugs recentes surgiram especificamente no contrib, vale a pena reduzir essa lista agora, em vez de esperar pela próxima revisão programada.

Proteja o PostgreSQL contra explorações de vulnerabilidades com a TuxCare

As vulnerabilidades do PostgreSQL são controláveis, mas somente se você aplicar as correções em tempo hábil e não deixar uma versão fora de suporte em produção sem proteção de segurança. O PostgreSQL 13 atingiu o fim de vida útil definido pela comunidade em 13 de novembro de 2025 e não recebe mais correções oficiais para CVEs, e o PostgreSQL 14 seguirá o mesmo caminho em 12 de novembro de 2026.

Se algum deles ainda estiver na sua pilha, o Suporte de Ciclo de Vida Ilimitado da TuxCare faz o backport dessas correções para você, aplicando-as por meio das atualizações normais do gerenciador de pacotes, em vez de um fluxo de trabalho separado de aplicação de patches, para que você não fique na dúvida entre permanecer vulnerável ou migrar de acordo com o prazo de outra empresa. Verifique primeiro em que situação suas implantações do PostgreSQL realmente se encontram e, em seguida, preencha as lacunas na cobertura de patches.

Resumo

Nome do artigo

Vulnerabilidades do PostgreSQL: Tipos e como se proteger contra elas

Descrição

Saiba mais sobre as vulnerabilidades do PostgreSQL, os métodos comuns de ataque e as melhores práticas para proteger seu banco de dados contra possíveis ameaças à segurança.

Autor

Rohan Timalsina

Nome da editora

TuxCare

Logotipo da editora