PostgreSQL corrige 11 CVEs em release de maio 2026

O PostgreSQL Global Development Group lançou em 14 de maio de 2026 atualizações simultâneas para cinco branches ativas — 18.4, 17.10, 16.14, 15.18 e 14.23. A release, segundo os mantenedores, "fixes 11 security vulnerabilities and over 60 bugs reported in the last several months". Quem roda Postgres em produção — seja via Supabase, AWS RDS, Neon ou servidor próprio — tem janela curta antes de exploits públicos aparecerem.

O que foi corrigido e por que importa

Entre as 11 vulnerabilidades, os vetores de maior risco documentados na release são um timing attack via MD5 em autenticação e um DoS por recursão em conexões SSL/GSS. O timing attack afeta configurações onde pg_hba.conf ainda usa autenticação md5 — cenário comum em projetos migrados de versões antigas sem revisar o método de auth. O DoS via SSL atinge qualquer instância com SSL habilitado e conexão aberta ao exterior.

Os mais de 60 bugs corrigidos cobrem correções em planejador de queries, índices GIN, particionamento e lógica de replicação. A maioria não causa crash em condições normais, mas alguns afetam consistência em cargas de escrita concorrente — exatamente o padrão de SaaS com múltiplos usuários simultâneos.

• Timing attack MD5: afeta instâncias com auth-method md5 no pg_hba.conf — migrar para scram-sha-256 resolve independentemente do patch.
• DoS SSL/GSS: afeta qualquer instância com porta 5432 exposta com SSL ativo.
• Bugs de planejador e GIN: impactam queries complexas com filtros sobre JSONB ou tsvector.
• Replicação: correcciones em edge cases de logical replication que causavam lag inesperado.

Impacto por tipo de setup

Supabase — a plataforma aplica patches de segurança automaticamente em projetos hospedados; verifique no dashboard a versão reportada em Settings → Database. Projetos self-hosted (Supabase Docker) precisam atualizar a imagem manualmente.

AWS RDS / Aurora PostgreSQL — patches chegam via maintenance window. Para os CVEs de timing e DoS, vale antecipar o maintenance window ou habilitar auto minor version upgrade se ainda não estiver ativo. A AWS costuma disponibilizar o patch dentro de 7–14 dias após a release upstream.

Self-hosted (VPS, Hetzner, DigitalOcean) — update direto via gerenciador de pacotes. Em Debian/Ubuntu: apt update && apt install postgresql-17 (ou a branch correspondente). Reinicialização do serviço é necessária; planeje janela de manutenção de 2–5 minutos para a maioria dos setups pequenos.

O que fazer nos próximos dias

1. Confirmar qual branch está rodando em produção (SELECT version();).
2. Checar se pg_hba.conf usa md5 — se sim, migrar para scram-sha-256 antes ou junto ao patch.
3. Em self-hosted, agendar janela de manutenção para apt upgrade ou equivalente até o fim de semana.
4. Em RDS/Aurora, verificar se Auto Minor Version Upgrade está ativo ou antecipar o maintenance window.
5. Em Supabase hospedado, confirmar versão no dashboard — se ainda mostrar versão anterior, abrir suporte.

Quem ainda está no PG 14 e quer entender o escopo completo do upgrade para 17 — incluindo mudanças de comportamento, extensões afetadas e checklist de rollback — pode consultar o guia PostgreSQL 14 perde suporte em novembro: upgrade agora.