Uma vulnerabilidade zero-day de injeção SQL (SQLi) no Metabase Cloud está sendo explorada ativamente por atacantes e já começa a revelar um problema maior do que o comprometimento de uma plataforma de analytics: o potencial de atingir os bancos de dados e, consequentemente, organizações conectadas ao ambiente. A falha foi classificada pelo próprio Metabase com CVSS 10,0, pontuação máxima de criticidade, e ainda não possuía identificador CVE no momento desta publicação.
O ponto tecnicamente mais sensível está no fato de que a exploração pode ocorrer remotamente por meio do endpoint de redefinição de senha. A injeção de comandos SQL no banco de dados da própria aplicação pode permitir que um atacante obtenha privilégios administrativos no Metabase. A partir daí, o risco deixa de ser apenas o comprometimento da ferramenta de Business Intelligence: credenciais armazenadas para conexão com bancos externos podem ser acessadas, permitindo leitura e exportação dos dados disponíveis por essas conexões.
Esse mecanismo explica o chamado “blast radius” da vulnerabilidade. O Metabase atua como uma camada de análise sobre diferentes fontes de dados corporativas. Portanto, comprometer a plataforma pode fornecer uma ponte para informações que estão fora dela. Em ambientes empresariais, isso pode significar exposição de dados de clientes, fornecedores, operações, indicadores financeiros, engenharia, produção ou outros ativos que alimentam dashboards e aplicações analíticas.
O caso já apresenta evidências concretas desse efeito em cadeia – a empresa n8n informou em 8 de agosto que um atacante obteve 136 registros de clientes, incluindo nomes e endereços de e-mail; cinco registros continham senhas protegidas por bcrypt e outros 25 estavam armazenados em texto claro em razão de uma vulnerabilidade anterior; a empresa afirmou que considerava improvável que essas contas tivessem sido acessadas. A startup Kilo Code também informou que seus registros de clientes foram acessados durante um comprometimento do Metabase Cloud ocorrido em 2 de agosto.
Cloud protegido automaticamente; self-hosted exige ação
Há uma diferença importante entre os ambientes. Segundo o Metabase, clientes do Metabase Cloud não precisam executar uma atualização manual, pois as instâncias foram atualizadas automaticamente para versões corrigidas. Já organizações que operam versões self-hosted precisam verificar imediatamente sua exposição. A própria documentação de segurança do fornecedor informa que ambientes Cloud são automaticamente corrigidos quando vulnerabilidades são identificadas e resolvidas, enquanto instalações próprias dependem da gestão do cliente.
O alerta é particularmente importante para instalações self-hosted cujo endpoint /api/session/reset_password esteja acessível pela Internet.
Segundo Dr. Johannes Ullrich, do SANS Internet Storm Center, a possibilidade de exploração depende da exposição desse endpoint; instalações Metabase podem operar como contêiner Docker ou aplicação Java independente, normalmente disponibilizando a API pela porta 3000, cuja exposição efetiva depende da arquitetura de firewall e proxy utilizada.
O problema não é apenas “mais uma SQL injection”
Do ponto de vista de arquitetura de segurança, o episódio chama atenção para uma questão recorrente: uma ferramenta de análise de dados pode se transformar em um ponto privilegiado de acesso a múltiplas fontes corporativas.
A SQL injection continua sendo um dos tipos clássicos de vulnerabilidades de aplicações web. Neste caso, porém, a gravidade decorre da combinação entre três fatores: acesso remoto, possibilidade de obtenção de privilégios administrativos e conectividade do Metabase com bancos de dados externos. A exploração bem-sucedida pode alterar configurações, acessar credenciais armazenadas e consultar dados disponíveis por essas conexões.
O caso também evidencia uma tensão de engenharia. O Metabase precisa trabalhar com uma ampla variedade de bancos de dados e drivers, o que torna a implementação de mecanismos de parametrização e prepared statements mais complexa. Isso, entretanto, não reduz a responsabilidade de segurança: justamente por ocupar uma posição intermediária entre usuários e diferentes bases de dados, a plataforma precisa ser tratada como componente de alta criticidade na arquitetura de dados.
Impacto para OT, indústria e infraestrutura crítica
Para ambientes industriais, o episódio merece atenção mesmo quando o Metabase não está diretamente conectado a sistemas de controle. A preocupação não é afirmar que a vulnerabilidade permita, por si só, controlar uma planta industrial, mas reconhecer que plataformas de analytics podem estar conectadas a historians, bancos de dados corporativos, sistemas MES, ERP, plataformas de manutenção e outras fontes que integram IT e OT.
Quanto maior o número de fontes conectadas, maior pode ser o impacto de uma conta ou credencial comprometida. Por isso, o princípio de least privilege deve ser aplicado também às conexões utilizadas por plataformas de Business Intelligence: o usuário de banco empregado pelo Metabase deve possuir apenas as permissões necessárias para suas funções, e credenciais de escrita ou administração devem ser evitadas quando não forem indispensáveis.
O incidente reforça ainda a necessidade de segmentação de rede, restrição de interfaces administrativas, monitoramento de logs, rotação de credenciais após suspeita de comprometimento e inventário permanente das conexões entre plataformas analíticas e bases corporativas.
O que as empresas devem verificar
Para organizações que utilizam Metabase self-hosted, a prioridade é identificar a versão instalada, verificar o advisory do fornecedor e aplicar imediatamente a versão corrigida correspondente. Também é recomendável verificar se a API está diretamente exposta à Internet e revisar as regras de firewall, reverse proxy e WAF.
Em caso de exposição potencial, a investigação não deve terminar com a atualização do software. É necessário avaliar logs de autenticação e requisições, atividades administrativas inesperadas, alterações de configuração, consultas anômalas e acessos aos bancos conectados. Como a vulnerabilidade pode ter sido utilizada para obter credenciais armazenadas na aplicação, uma eventual suspeita de exploração deve levar à avaliação da necessidade de rotacionar credenciais das bases de dados conectadas.
O Metabase mantém um Security Center para instalações self-hosted, no qual administradores podem acompanhar os advisories de segurança; a documentação recomenda também a configuração de notificações para novos alertas.
A lição estratégica
O caso Metabase reforça uma mudança importante na segurança de ambientes orientados a dados: o perímetro de segurança não termina no servidor que hospeda uma aplicação. Ele se estende às conexões, credenciais, APIs e bases de dados às quais essa aplicação tem acesso.
Em arquiteturas modernas, especialmente aquelas que aproximam BI, IA, analytics, automação e dados operacionais, uma ferramenta aparentemente situada na camada de visualização pode possuir privilégios capazes de alcançar ativos muito mais críticos. O “blast radius”, portanto, é determinado menos pelo tamanho da aplicação vulnerável e mais pela quantidade e criticidade dos sistemas aos quais ela está conectada.
O zero-day do Metabase é, nesse sentido, mais um alerta sobre a necessidade de tratar plataformas de dados como componentes de infraestrutura crítica: cada conexão adicional representa também uma nova superfície potencial de ataque.
