CVE-2026-72898: nota 10.0 no painel que guarda a senha de todos os seus bancos

Nota 10.0 é rara. Na escala CVSS 3.1 ela só aparece quando a falha é explorável pela rede, sem autenticação, sem interação do usuário, e ainda por cima escapa do componente comprometido para atingir outros sistemas. A CVE-2026-72898 marca 10.0 nas duas escalas, 3.1 e 4.0, e o motivo fica claro quando você lembra o que um servidor de Metabase costuma guardar: a credencial de conexão de todos os bancos de dados que a empresa quis colocar em um relatório.

A falha em uma frase

A CVE-2026-72898 é uma injeção de SQL (CWE-89) no endpoint de recuperação de senha do Metabase. Um atacante remoto e não autenticado injeta SQL arbitrário na consulta que o fluxo de reset faz contra o banco de aplicação do próprio Metabase, e com isso obtém acesso de administrador da instância. A NVD atribui CVSS 3.1 de 10,0 com o vetor CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, e CVSS 4.0 de 10,0 com CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H.

• Endpoint vulnerável: POST /api/session/reset_password, sem autenticação
• Afetadas: instalações self-hosted a partir da linha 0.58 / 1.58; versões anteriores à 58 não são afetadas
• Corrigidas em: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 e 0.63.5, e nas versões Enterprise equivalentes (1.58.24 e seguintes)
• Divulgada pela Metabase em 6 de agosto de 2026, com exploração em produção já confirmada antes disso
• Publicada na NVD em 10 de agosto de 2026 e adicionada ao catálogo CISA KEV em 11 de agosto de 2026, com prazo de correção em 14 de agosto de 2026 para as agências federais americanas
• Mitigação temporária de quem não podia atualizar na hora: bloquear o endpoint /api/session/reset_password na borda

Por que 10.0 e não 9.8

A diferença entre 9,8 e 10,0 no CVSS 3.1 está em um único campo do vetor: o escopo. Quase toda falha crítica de execução remota fica em S:U, escopo inalterado, porque o estrago acontece dentro do componente vulnerável. Aqui o escopo é S:C, alterado, e essa escolha da própria pontuação já conta a história do bug.

O que o atacante compromete não é só o Metabase. É o banco de aplicação do Metabase, e dentro dele estão as credenciais que a ferramenta usa para consultar os bancos de negócio. Comprometer o painel dá acesso ao data warehouse, ao banco transacional, ao réplica de leitura, a tudo que alguém um dia conectou para montar um dashboard. Os sistemas atingidos são outros, sob outra administração, e a nota reflete isso.

O mecanismo: um campo que não deveria existir no corpo da requisição

O fluxo de recuperação de senha é dos poucos que precisam ser não autenticados por natureza: quem esqueceu a senha não tem como provar quem é antes de trocá-la. O corpo esperado da requisição é pequeno, um token e a nova senha, e o servidor usa esse token para localizar o usuário no banco de aplicação.

POST /api/session/reset_password HTTP/1.1
Host: metabase.exemplo.interno
Content-Type: application/json

{"token": "<token-do-e-mail-de-reset>", "password": "<nova-senha>"}

# Esse e o corpo esperado. A falha nao esta em nenhum desses dois campos.
# O endpoint aceitava campos NAO DECLARADOS no corpo e os repassava para a
# camada de montagem de consulta, que interpretava o valor como estrutura de
# consulta em vez de tratar como identificador ja validado. Resultado: um
# campo extra vira expressao SQL dentro da consulta do fluxo de reset.
#
# Nao publicamos o payload de injecao. O ponto aqui e a classe do bug, nao a
# receita: entrada aceita sem lista de campos permitidos chegando viva ate o
# construtor de SQL.

A correção da Metabase segue exatamente essa leitura: o fluxo de reset passou a aceitar estritamente os campos esperados, de modo que nenhum campo não declarado no corpo influencie a consulta ao banco de aplicação. É a diferença entre validar o que você recebe e listar o que você aceita. A primeira abordagem tenta adivinhar o que é perigoso; a segunda descarta tudo que não estava previsto, e por isso não depende de o desenvolvedor ter imaginado o ataque de antemão.

Vale notar que isso não é a injeção de SQL de manual, aquela concatenação de string em um formulário de login. O Metabase usa uma camada de montagem de consulta que, em condições normais, parametriza os valores corretamente. A brecha apareceu na fronteira entre desserializar o JSON de entrada e alimentar essa camada: um mapa vindo do usuário e tratado como fragmento de consulta em vez de valor. É um padrão que estamos vendo com frequência em stacks modernas, e que passa despercebido em revisão justamente porque não existe concatenação nenhuma no código.

O raio de alcance: o BI é o mapa do dado da empresa

Em muitos inventários de superfície de ataque, a ferramenta de BI entra classificada como interna e de baixo risco. É um erro de leitura fácil de cometer, porque o produto parece passivo: ele só mostra gráfico. Só que para mostrar gráfico ele precisa de conexão persistente, credencial armazenada e, quase sempre, permissão de leitura ampla nos bancos de produção. Nenhuma outra aplicação da empresa costuma ter esse alcance concentrado.

• Acesso administrativo à instância, o que inclui criar contas, alterar permissões e desligar controles
• As credenciais de conexão de todos os bancos configurados, e portanto acesso direto a eles com os privilégios que a ferramenta tem
• Consulta e exportação de qualquer dado alcançável por essas conexões, sem precisar tocar no banco pela rede
• Os segredos disponíveis ao processo em execução, incluindo integrações configuradas na instância
• O histórico de perguntas e dashboards, que funciona como um mapa comentado de onde estão os dados sensíveis

Esse último item é o que costuma ser subestimado. O histórico de consultas de um Metabase corporativo é documentação pronta: ele diz qual tabela guarda cliente, qual guarda transação, qual coluna tem documento fiscal e qual junção produz a base completa. Um atacante que precisaria de dias explorando esquema de banco recebe isso mastigado, escrito por quem conhece o negócio.

O que já aconteceu

A falha foi explorada antes de existir. A Metabase divulgou o problema em 6 de agosto de 2026 depois de detectar ataque real contra a própria infraestrutura de nuvem no começo do mês, bloquear o endpoint e publicar as versões corrigidas. O identificador CVE só saiu em 10 de agosto, e a CISA incluiu a falha no catálogo KEV em 11 de agosto, com prazo de três dias para as agências federais americanas sob a diretiva BOD 26-04. Três dias é o prazo reservado a falhas que reúnem os quatro critérios de maior risco: ativo exposto à internet, presença no KEV, exploração automatizável e controle total do sistema depois de explorada.

Do lado das instâncias self-hosted, o levantamento da Dataminr em 8 de agosto identificou cerca de 11 mil instalações prováveis de Metabase alcançáveis pela internet, das quais 4.309 aparentavam rodar versão vulnerável. Mais de 97% dos hosts identificados nas linhas afetadas ainda estavam sem correção naquela varredura, dois dias depois da divulgação. A distribuição inclui governo, saúde, energia, finanças, telecom e aviação.

Pelo menos três empresas que usavam a versão em nuvem confirmaram publicamente acesso indevido a dado de cliente na janela anterior ao patch: Framework, Anaconda e n8n. No caso da Anaconda, o Kilo Code confirmou exposição de tokens de acesso ao Slack de usuários do recurso de bot. Apareceu também uma menção ao Metabase em blog de extorsão atribuído ao ShinyHunters, mas a autoria segue não confirmada e nós não a tratamos como fato.

Como checar se a sua instância foi usada

Atualizar não responde a pergunta que importa depois de uma falha com exploração ativa e endpoint público: alguém já passou por aqui? Nesse caso existe um padrão de log bastante específico, indicado pela própria Metabase, que serve de ponto de partida para a caça no histórico do proxy reverso ou do balanceador.

# Padrao a procurar nos logs de acesso, na mesma sessao/IP e em sequencia:

POST /api/session/reset_password   -> 400
GET  /api/user/current             -> 200

# A leitura: a tentativa de reset falhou (400), mas logo depois a requisicao
# que so responde 200 para sessao valida respondeu 200. Ou seja, a sessao foi
# obtida sem um fluxo de autenticacao valido no meio.
#
# Exemplo de recorte rapido em log combinado de proxy reverso:
grep -E 'reset_password|api/user/current' access.log \
  | awk '{print $1, $4, $7, $9}' \
  | sort -k1,1 -k2,2

Se o endpoint esteve acessível pela internet em qualquer momento durante a janela, a recomendação oficial vai além de atualizar. Sessões emitidas antes do patch continuam válidas depois dele, e chave de API criada por um administrador falso continua funcionando mesmo com a falha corrigida. Persistência não desaparece com o upgrade.

-- Executar no banco de APLICACAO do Metabase, depois de atualizar.
-- Invalida todas as sessoes ativas, inclusive as criadas pelo atacante.
DELETE FROM core_session;

-- Em seguida, no proprio painel e fora dele:
--   1. revisar e apagar chaves de API que voce nao reconhece
--   2. auditar a lista de administradores e mudancas recentes de permissao
--   3. rotacionar a credencial de TODOS os bancos conectados a instancia
--   4. revisar os logs do data warehouse por consulta ou export fora do padrao
--   5. revisar o historico de atividade e de perguntas dentro do Metabase

O item 3 é o mais caro e o mais pulado. Rotacionar credencial de banco de produção exige janela, coordenação e alguém disposto a assumir o risco de derrubar um relatório. É exatamente por isso que ele fica para depois, e é exatamente por isso que ele importa: a credencial roubada é o que sobrevive ao incidente.

O que muda no escopo do pentest

Nos escopos que chegam até nós, ferramenta de BI raramente aparece. Quando aparece, entra como aplicação de apoio, no fim da lista, com prioridade baixa. A CVE-2026-72898 é o argumento pronto para inverter essa ordem, e a inversão não depende dessa falha específica continuar existindo: o raio de alcance da ferramenta é estrutural, não é consequência de um bug.

• Atualize para 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 ou 0.63.5, conforme a linha em que você está, e confirme a versão em execução em vez de confiar no que está no repositório de deploy
• Tire o Metabase da internet aberta: acesso por VPN ou por proxy autenticado, e o endpoint de reset nunca exposto publicamente
• Revise a permissão de cada conexão configurada; um painel de BI raramente precisa de usuário com escrita, e quase nunca precisa de superusuário
• Trate a instância como sistema que processa dado pessoal para efeito de LGPD, porque é o que ela faz, e inclua na avaliação de impacto
• Faça a caça retroativa no log de acesso pelo padrão 400 seguido de 200 antes de considerar o caso encerrado, mesmo que a instância já esteja atualizada
• Inclua BI, orquestrador de dados e ferramenta de ETL no escopo do próximo pentest, com peso de sistema crítico, e não como aplicação interna de baixo risco

Este post é educativo e voltado à defesa. Não publicamos exploit funcional nem o payload de injeção: os trechos acima reproduzem o formato documentado da API do produto, o indicador de comprometimento divulgado pelo próprio fornecedor e os passos de remediação do advisory oficial. O que queremos deixar registrado é a leitura de risco. Se a sua ferramenta de BI cair, não é um dashboard que cai junto, é o conteúdo de todos os bancos que ela consegue enxergar.