IA acelera caça a vulnerabilidades e atrasa o PostgreSQL 19

O cronograma da versão 19 do PostgreSQL sofreu atraso nas últimas semanas, e o motivo não é um recurso incompleto: é uma avalanche de relatos de vulnerabilidade. Em post publicado em 6 de novembro no Planet PostgreSQL, Ruohang Feng, mantenedor do projeto Pigsty, descreve o fenômeno como um "teste de estresse de segurança movido por 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 →" que atinge toda a indústria de software, e o ecossistema PostgreSQL não ficou de fora.

A causa é direta: ferramentas de varredura automatizada de vulnerabilidades, hoje potencializadas por modelos de IA, rodam continuamente contra bases de código open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) →. O resultado é um volume diário de disclosures que nenhuma comunidade de manutenção, por mais disciplinada que seja, consegue simplesmente ignorar. Segundo Feng, mesmo o núcleo do PostgreSQL, historicamente um dos projetos open source mais estáveis em matéria de segurança, sentiu o impacto: o code freeze e o empacotamento da versão 19, previstos para 9 de novembro, com lançamento geral uma semana depois, foram reagendados em função da onda de correções necessárias.

O que isso significa pra quem mantém banco em produção

Para times de engenharia que operam PostgreSQL, o recado é duplo. Primeiro, o volume de patches de segurança tende a crescer, não a diminuir: se scanners automatizados encontram falhas mais rápido do que humanos revisam, a cadência de releases corretivos vira a nova normalidade. Segundo, atraso de release maior (como o da versão 19) não é sinal de descuido, é sinal de que o processo de triagem está absorvendo mais entradas do que o habitual.

Em resumo: antes de tratar um patch de segurança como rotina de atualização automática, vale entender o que exatamente mudou no plano de execução e nas permissões afetadas, porque a origem do patch (scanner automatizado vs. relato humano revisado) não muda o rigor que a aplicação em produção exige.

PostGIS corta superfície de ataque, não só bugs

O exemplo mais claro dessa pressão veio do PostGIS. Segundo Feng, vulnerabilidades anteriores em duas extensões companheiras, address_standardizer e postgis_tiger_geocoder, afetaram praticamente todos os principais provedores de PostgreSQL gerenciado. A resposta do time de manutenção, na versão 3.7.0, foi radical: remover as duas do pacote central do PostGIS e separá-las para build e empacotamento independentes.

Isso não é um patch pontual, é uma mudança estrutural de superfície de ataque. Quando ferramentas automatizadas testam cada caminho de código em busca de falhas, manter componentes não essenciais acoplados ao core vira passivo. Para quem administra bancos com PostGIS instalado, a consequência prática é concreta: instalações que dependem de address_standardizer ou postgis_tiger_geocoder precisam instalar os pacotes separadamente após a atualização para 3.7.0, sob risco de quebra silenciosa em funções de geocodificação.

O mesmo padrão de hardening apareceu em outras extensões no mesmo período, segundo o levantamento de Feng:

• emaj 5.0.1 corrigiu uma falha de escalonamento de privilégio;
• pg_anon 3.3.2 lançou uma atualização de segurança;
• dezenas de outras extensões emitiram point releases em ritmo acelerado.

Um lote de releases por semana

Feng relata que, nos últimos dois meses, o ritmo de acompanhamento de atualizações de core e extensões no repositório do Pigsty tem sido de aproximadamente um lote de releases por semana. Para quem mantém um pipeline de empacotamento próprio, ou depende de imagens de container atualizadas, isso significa que o processo de patch não pode mais ser tratado como evento trimestral: a janela entre disclosure e correção exige monitoramento ativo de changelogs, não apenas de CVEs publicados em bases centralizadas.

Dessa esteira saíram também marcos que não são puramente reativos. O OrioleDB, engine de armazenamento alternativo que ataca o bloat de tabela e a amplificação de escrita da MVCC nativa do PostgreSQL por meio de undo logs e controle de concorrência em nível de página, finalmente deixou a fase beta. A versão 1.10.1 chegou com suporte a três ramos principais: PG 16.15, 17.11 e 18.6. É um marco de maturidade, mas vale lembrar que trocar o engine de armazenamento de uma tabela crítica é decisão que exige teste de carga equivalente ao de produção antes de qualquer migração, independentemente do rótulo GA.

Até fornecedores grandes tropeçam em testes básicos

Um detalhe da própria rotina de empacotamento de Feng ilustra bem o valor de pipelines de QA amplos. Ao compilar e testar extensões contra uma matriz ampla de distribuições Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps → e arquiteturas de CPU, ele encontrou bugs de build e runtime em pgactive e pgcollection, duas das poucas extensões PostgreSQL publicadas diretamente pela AWS. Em vez de abrir issue e esperar, ele mesmo escreveu e enviou os patches.

Uma matriz ampla de empacotamento multi-distro acaba sendo um dos testes de integração mais eficazes que um ecossistema open source pode ter.

Ruohang Feng, mantenedor do PigstyA broad multi-distro packaging matrix turns out to be one of the most effective integration tests an open-source ecosystem can get.

O episódio é um lembrete direto para times de engenharia: o fato de uma extensão vir de um fornecedor com reputação de nuvem não dispensa teste próprio em ambiente representativo antes do deploy. Bug de build básico em código publicado pela AWS mostra que a origem institucional não substitui a validação local.

O que fica em aberto

O cronograma da versão 19 ainda não tem data definitiva de lançamento geral; Feng escreve que espera que nenhum "showstopper" de última hora force novo adiamento nos dias seguintes à publicação do post, em 6 de novembro. Para quem planeja migração assim que a versão sair, o conselho prático é adiar o teste de regressão até o release final estabilizar, e não a partir de builds de release candidate que ainda podem receber correções de segurança de última hora.

A lição estrutural, porém, já está posta: times que operam PostgreSQL em escala devem tratar monitoramento de changelog de extensões como parte do processo de patch de segurança, não como item opcional. Separar componentes de ataque amplo (como fez o PostGIS), revisar dependências transitivas antes de cada upgrade e manter ambiente de staging representativo da produção deixaram de ser boas práticas de manual e passaram a ser condição de sobrevivência operacional nesta fase do ecossistema.

Fonte: Planet PostgreSQL