O update de segurança do Postgres pode desligar o seu CDC

Imagem de capa

Ilustração de capa, sem texto legível. Um fluxo contínuo de traços atravessa uma abertura estreita e para diante dela. Ao lado da abertura, uma pequena lista com duas marcas preenchidas e espaço vazio abaixo, sugerindo uma relação de nomes autorizados com vagas por preencher.

É terça-feira e o painel de vendas mostra os números de sexta.

A pipeline não está com erro vermelho, e o banco de origem está no ar. No fim de semana houve janela de manutenção e o servidor subiu de versão. O problema é que a leitura do log de transação parou de ser aceita, e ninguém ligou uma coisa na outra.

Neste artigo, explicamos o que a correção de segurança de agosto mudou no PostgreSQL, por que ela derruba parte das replicações e qual pergunta fazer antes da próxima janela.

O que a correção de 13 de agosto mudou

A decodificação lógica é o mecanismo que deixa uma ferramenta externa ler as alterações do banco a partir do log de transação. Ela existe desde a versão 9.4, de 2014, e é a base de quase todo CDC (change data capture) em PostgreSQL.

A escolha do plugin de saída não era verificada. Uma conta com privilégio de replicação podia apontar para qualquer biblioteca visível ao usuário do sistema que roda o servidor, e o banco carregava. Carregar biblioteca arbitrária significa executar código arbitrário com aquele usuário.

Isso virou o CVE-2026-6471, com nota 7.2 na escala CVSS 3.0. As versões anteriores a 18.6, 17.11, 16.15, 15.19 e 14.24 são afetadas, e a correção saiu em 13 de agosto de 2026, na mesma leva que fechou 28 vulnerabilidades.

A porta ficou doze anos aberta.

O parâmetro output_plugin_libraries e seu padrão

A correção não desliga a decodificação lógica. Ela passa a exigir que a biblioteca do plugin esteja numa lista declarada no servidor, pelo parâmetro output_plugin_libraries.

O padrão traz só o que vem de fábrica. A lista começa com pgoutput e test_decoding, os dois plugins que acompanham o PostgreSQL. Qualquer outro passa a ser recusado até que alguém acrescente o nome ao parâmetro e a configuração do servidor seja aplicada.

A documentação é explícita quanto ao alcance: a restrição vale para todos os usuários, e pedido de decodificação lógica para biblioteca fora da lista é recusado. Não é um privilégio que se contorna trocando de conta.

É aqui que a conta muda de lado. Ferramenta que usa pgoutput continua lendo como antes. Ferramenta que depende de wal2json, de decoderbufs ou de qualquer plugin instalado à parte encontra a porta fechada logo depois do update.

Como saber se você vai ser afetado

Não é preciso esperar a janela de manutenção para descobrir. Três consultas respondem, e todas rodam com permissão de leitura no banco de origem.

-- 1. em que versão o servidor está
SELECT version();

-- 2. quais slots de replicação existem e qual plugin cada um usa
SELECT slot_name, plugin, slot_type, active
  FROM pg_replication_slots;

-- 3. se o servidor já foi atualizado, o parâmetro existe e mostra a lista
SHOW output_plugin_libraries;

A coluna plugin é a que responde. Se ela mostrar pgoutput em todos os slots, o update não muda nada para você. Se aparecer qualquer outro nome, esse nome precisa entrar na lista do servidor antes da atualização, e não depois.

A terceira consulta tem um efeito colateral útil. Enquanto ela devolver erro dizendo que o parâmetro não existe, o servidor ainda não foi corrigido — e você está do lado errado da vulnerabilidade, não do lado errado da lista.

Rode as três em toda origem que você replica, não só na que vem à cabeça. Um time de uma ou duas pessoas costuma ter mais slots abertos do que consegue nomear de memória, e o slot esquecido é o que quebra.

Pergunte antes de o domingo chegar.

O que pedir a quem administra o banco

A correção é curta e não é sua para aplicar, a não ser que o banco seja seu. O que muda é acrescentar o plugin à lista e aplicar a configuração do servidor.

• Antes da janela. Entregue a quem administra o servidor a lista de plugins que aparece em pg_replication_slots. É uma linha de configuração, não um projeto.
• Se a origem é gerenciada por um provedor. A lista costuma virar um parâmetro do grupo de configuração da instância, e a alteração pode pedir reinício. Isso entra na janela, não depois dela.
• Se o update já passou. A leitura volta assim que o nome do plugin entra na lista. As alterações do período continuam no log enquanto o slot existir e houver espaço em disco para segurá-las.

O terceiro item tem prazo. Slot parado segura log, log parado ocupa disco, e disco cheio derruba o banco de produção inteiro. Corrigir a lista é urgente por esse motivo, não pelo relatório atrasado.

O projeto do plugin costuma dizer o que fazer. O README do wal2json, por exemplo, documenta a mudança citando o CVE e entrega a linha pronta, com o nome do plugin somado aos dois que vêm de fábrica. Vale abrir a documentação do plugin que você usa antes de escrever o pedido.

O que essa correção custa a você

A correção fecha uma falha real, e ainda assim cobra. Vale saber o que ela cobra antes de tratar o assunto como item de lista do DBA.

Trocar de plugin não é trocar de configuração. O plugin de saída define o formato em que a alteração sai do banco, e a ferramenta do outro lado precisa entender esse formato. Migrar para pgoutput só para escapar da lista é trocar o mecanismo de leitura, não uma linha do arquivo.

A decisão pode não ser sua. Em instância gerenciada, o parâmetro só muda se o provedor o expuser no grupo de configuração. Quando ele não expõe, sobra abrir chamado e esperar, com o pipeline parado enquanto isso.

Voltar atrás também não é saída. Segurar a versão antiga para manter a replicação de pé mantém a vulnerabilidade aberta, e ela se explora justamente pela credencial que o pipeline carrega. Quem adiou no 14 ainda tem o fim de suporte em 12 de novembro de 2026 encurtando a janela.

O custo é de coordenação, não de código.

O que o anúncio da versão não avisa

O anúncio de 13 de agosto destaca três situações que pedem passo extra depois de atualizar: build paralelo de índice GIN, o btree_gist e o ltree. A mudança no carregamento do plugin de decodificação não está nessa lista.

Não é omissão, é escopo. A lista do anúncio é de coisas que corrompem dado ou índice. Um slot recusado não corrompe nada: ele simplesmente para de entregar, e quem descobre é a pessoa que abre o relatório na segunda-feira.

Vale também dimensionar a vulnerabilidade sem inflá-la. O vetor oficial exige privilégio alto: quem explora já precisa de uma conta com o atributo de replicação no banco. Não é uma porta aberta na internet, é uma escalada a partir de uma credencial que ferramenta de backup e pipeline de CDC costumam ter.

O que faz o risco valer atenção é justamente isso. A conta que o seu pipeline usa todo dia é a conta que serve para a escalada, e ela costuma estar guardada em mais lugares do que a senha do superusuário.

Duas urgências, uma janela só.

Onde o Januss entra

Qual plugin de saída a conexão pede é uma pergunta para o fornecedor de cada ferramenta, e o Januss não é exceção: essa resposta vem de quem opera o produto, não deste artigo. O que dá para mostrar aqui é o que acontece no dia em que o banco recusa a leitura.

O Januss confere os pré-requisitos antes de salvar a origem. Ele verifica coisas como wal_level, binlog_format e a habilitação de CDC no SQL Server, e diz na tela o comando que resolve o que falta, inclusive o caminho diferente do Amazon RDS.

O aviso não espera você olhar. A falha dispara e-mail com o erro e link direto para a execução, e depois de três falhas seguidas a pipeline se desliga sozinha, em vez de seguir queimando franquia. Quando o log do banco rotaciona antes da leitura, a recarga é automática, porque perder posição no log é um problema de dado, não de agenda.

Quer ver esse comportamento com a sua origem? O trial de 14 dias não pede cartão, e a checagem de pré-requisitos roda antes de qualquer linha ser lida. Criar seu ambiente no Januss.

Fontes

A descrição da falha, as versões afetadas e a data da correção estão na página oficial do projeto; a linha de configuração pronta, na documentação do plugin mais usado:

• PostgreSQL — CVE-2026-6471: logical decoding can dlopen arbitrary file
• PostgreSQL 18.6, 17.11, 16.15, 15.19, 14.24 and 19 Beta 3 Released!
• wal2json — plugin de saída para decodificação lógica do PostgreSQL