PostgreSQL fechou 28 CVEs de uma vez: qual deve ser sua latência de patch

Em 13 de agosto de 2026, o PostgreSQL↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → publicou a maior release de segurança da sua história: 28 CVEs corrigidos em um único dia. O recorde anterior era 11. O número, por si só, assusta menos do que a métrica que Umair Shahid, no blog da Stormatics (Planet PostgreSQL), coloca no centro da discussão: quanto tempo sua operação leva entre um fix ser publicado e esse fix estar de fato rodando em produção. Ele chama isso de patch latency, e é essa a variável que o DBA realmente controla.

O número subiu porque a atenção subiu

A leitura em pânico é que o código piorou. A leitura correta é o oposto. Em todo o ano de 2025 foram corrigidos 7 CVEs; em 2026, já são 44, dos quais 28 nesta única release. O salto vem de mais gente e melhores ferramentas olhando para o código. Parte dos bugs foi reportada por times de segurança que usam IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI →, incluindo o da OpenAI, e a natureza deles entrega a origem: buffer overflows, integer wraparounds, type confusion. São bugs clássicos de memory-safety, exatamente o tipo que fuzzing automatizado encontra bem, e a IA está tornando o fuzzing muito mais eficiente.

Navegadores e kernels de sistema operacional passaram por esse nível de escrutínio anos atrás. O Postgres está passando por isso agora. Cada bug encontrado e corrigido é um bug a menos que um atacante pode usar depois. O código não ficou pior; ficou mais examinado, e boa parte dessas falhas estava dormindo em código estável há anos.

Por que a janela é o risco

Um CVE é um documento público. Ele nomeia o bug, lista as versões afetadas e frequentemente entrega detalhe suficiente para construir um exploit. Um dos bugs de agosto, uma falha de execução remota de código em to_char(), já tem prova de conceito funcional publicada, e um centro nacional de cibersegurança↳Segurança171 conteúdosCibersegurança no Brasil: 6 passos para sair da estagnaçãoDevSecOps · jul 2025O papel do CISO para transformar a cibersegurança em uma alavanca de reputação para as empresasDevSecOps · mar 2024Itaipu Parquetec e Exército Brasileiro realizam exercício de cibersegurança em BrasíliaDev (Back & Front) · set 2025Ver tudo em DevSecOps → emitiu aviso de "corrija imediatamente". A mesma IA que ajuda o defensor a achar a falha ajuda o atacante a transformá-la em exploit funcional, e o intervalo entre "CVE publicado" e "alguém varrendo seus servidores com ele" só encurta.

Shahid lembra o precedente de 2025: o CVE-2025-1094, uma injeção de SQL escondida nas próprias funções de escape de string do Postgres, apareceu como parte de uma cadeia de ataque real contra sistemas em produção. O bug estava em código estável havia anos. Só passou a importar quando virou público e alguém motivado o pegou. Nas palavras dele, um CVE não corrigido e já divulgado é "uma porta conhecida com as instruções de arrombamento impressas ao lado".

A boa notícia: aplicar um minor release é barato

Aqui o Postgres facilita a vida. Minor releases (18.4 para 18.6, 17.10 para 17.11) são cumulativos e binário-compatíveis. Não há dump and reload, não há pg_upgrade. Você para o servidor, troca os binários e sobe de novo. Em um nó único, isso leva segundos.

Se a troca leva segundos, por que equipes levam semanas? Porque a troca nunca foi a parte cara. Testar é. Agendar é. Fazer sem derrubar conexões vivas é. Um SLA de patch transforma tudo isso de correria em rotina.

O SLA aqui é apenas uma promessa que a equipe faz a si mesma sobre a velocidade de resposta, ordenada pela gravidade do bug. O modelo sugerido:

• Execução remota de código, ou exploit público existente: patch em dias. A release deste mês é o exemplo claro.
• Alta severidade, sem exploit conhecido ainda: patch em uma a duas semanas.
• O resto: entra na próxima janela de manutenção agendada.

Os números exatos são escolha de cada operação. O ponto é decidi-los antes de o CVE chegar. Quando uma release como a de 13 de agosto aparece, todos já sabem que é um evento de "dentro de dias" e ninguém discute isso num tópico de chat enquanto o relógio corre.

Como acertar a janela sem quebrar nada

Três hábitos tornam um SLA apertado seguro de manter:

Patch no standby primeiro. Aplique a atualização em uma réplica, observe o comportamento, faça o failover e só então corrija o antigo primary. Bem executado, o usuário vê um blip curto em vez de uma indisponibilidade. É a mesma disciplina de standby-first usada em rolling upgrades de clusters Patroni.

Teste em staging e leia a seção "Updating". A maioria das releases é troca limpa de binário, mas algumas pedem um passo adicional, e esta pediu. Quem usa índices GIN precisa checar se os valores de reltuples continuam sãos. Quem usa btree_gist em colunas float ou bit, ou ltree com caminhos muito longos, pode precisar de reindex. Dois minutos de leitura poupam uma tarde de confusão.

Mantenha um restore que você realmente testou. Patch e recuperação usam o mesmo músculo. Quando o backup restaura limpo e você conhece seu tempo real de recuperação, o patch deixa de parecer arriscado, porque sempre há um caminho de volta. Se não rodou um drill de restore recentemente, faça isso antes do próximo patch, não depois.

O que não é o binário do servidor

O binário do servidor é o alvo óbvio, mas não é o trabalho inteiro. Bibliotecas cliente e extensões também recebem CVEs. Em novembro de 2025, o libpq recebeu correção de um integer wraparound (CVE-2025-12818) que vivia na biblioteca cliente, não no servidor. O lote de agosto tocou pgcrypto, pg_stat_statements e PL/Perl. Quem fixa versões de driver, roda um connection pooler ou depende de módulos contrib precisa contar tudo isso na latência de patch. Um servidor totalmente corrigido conversando com uma libpq antiga está só na metade do caminho.

Rodar versão sem suporte também é latência de patch

Há uma forma garantida de tornar sua latência de patch infinita: rodar uma versão que não recebe mais correções. O PostgreSQL 14 recebe sua última rodada de fixes em 12 de novembro de 2026. Todos os 28 CVEs de agosto foram corrigidos na 14.24, então ainda há tempo de aplicar esta rodada e planejar a migração para uma major suportada. Depois dessa data, qualquer bug novo encontrado na 14 fica aberto permanentemente. Cadência de patch e atualidade de versão são a mesma disciplina usando dois chapéus.

O que fazer nesta semana

O resumo prático de Shahid: aplique 18.6, 17.11, 16.15, 15.19 ou 14.24 em produção; corrija o standby primeiro e faça o failover; leia as notas de "Updating" antes de começar; e escreva seus tiers de severidade para que o próximo CVE não vire debate. Para a operação brasileira que sofre com janelas curtas e SLAs apertados, a mensagem central é sóbria e correta: a segurança do dado não nasce da correria pós-incidente, mas de um critério decidido a frio, de um standby disciplinado e de um restore que você sabe que funciona.

Fonte: Planet PostgreSQL