Grafana 9.1分漏洞曝光：一个开关没关，服务器任人登录

3月31日，Grafana Labs 紧急推送了 12.4.2 版本。更新日志里藏着两个 CVE 编号，CVSS 评分 9.1 的那个足以让任何运维工程师从椅子上弹起来——攻击者能直接写文件到服务器，进而拿到 SSH 权限。这不是"理论上可能"，是已经被验证的完整利用链。

漏洞一：SQL 表达式成了后门通道

CVE-2026-27876 的根源在 Grafana 的 sqlExpressions 功能。这个特性本意是让用户在仪表盘里直接写 SQL 做数据转换，省得来回切换工具。但实现方式出了岔子：查询执行过程中，系统允许向特定路径写入文件。

Miggo Security 的研究员 Liad Eliyahu 发现了这条路径。他向 Grafana Labs 提交的漏洞报告显示，具备 Viewer 权限（ Grafana 里最低级的只读角色）的攻击者，可以覆盖 Sqlyze 驱动文件，或者篡改 AWS 数据源的配置。这两个动作任意一个完成，下一步就是远程代码执行。

更麻烦的是利用条件并不算苛刻。目标实例只需要满足两个条件：一，攻击者账号有 Viewer 或更高权限；二，sqlExpressions 功能开关处于开启状态。Grafana 12.x 系列里这个功能默认是关闭的，但不少团队为了做复杂查询会手动打开——打开之后如果没及时关，就成了定时炸弹。

Grafana Labs 在公告里确认了最坏情况：利用链跑通后，攻击者能获得"unauthorized SSH connection directly to the underlying host server"。翻译过来就是，你的监控面板被人攻破，对方直接 SSH 登录了宿主机。这时候什么防火墙、网络隔离都形同虚设。

漏洞二：零认证就能打崩服务

第二个漏洞 CVE-2026-27880 评分 7.5，属于高危拒绝服务。问题出在 OpenFeature 的验证接口——这些端点不需要任何认证，且对输入大小没有限制。攻击者发送超大请求，内存瞬间被撑爆，Grafana 实例直接崩溃。

相比 RCE，DoS 听起来没那么刺激，但对监控系统的杀伤力一点不小。Grafana 通常是整个基础设施的"眼睛"，它一挂，告警链路就断了。攻击者可以先用 DoS 打掉监控，再对其他系统下手，或者单纯为了制造业务中断。CVSS 7.5 的评分在拒绝服务类漏洞里已经算顶格了。

修复方案与临时止血

Grafana Labs 这次 backport 了五个版本：12.4.2、12.3.6、12.2.8、12.1.10，以及 11.6.14。如果你还在用 11.x 的旧版本，11.6.14 是最后的安全补丁。升级是最彻底的解决办法。

暂时无法升级的团队，有两个应急选项。针对 RCE 漏洞，彻底关闭 sqlExpressions 功能 toggle，攻击面直接归零。针对 DoS 漏洞，把 Grafana 部署在高可用架构里，确保崩溃后能自动拉起；同时在 Nginx 或 Cloudflare 这类反向代理上限制请求体大小，堵住内存耗尽的入口。

云托管用户倒是省了事。Amazon Managed Grafana 和 Azure Managed Grafana 已经在 embargo 期间完成了修复，漏洞公开时环境已经是安全的。这也是用托管服务的一个隐性收益——这种紧急补丁不用自己跟。

一个被低估的攻击向量

这次漏洞暴露了一个常见盲区：数据可视化工具往往被视为"只读"系统，安全投入优先级低于业务数据库或 API 网关。但 Grafana 的架构决定了它必须连接各种数据源，天然处于信任链的核心位置。一旦失守，攻击者拿到的不仅是监控数据，常常是通往其他系统的跳板。

sqlExpressions 这类功能开关的管理，很多团队缺乏制度化流程。开发阶段打开做调试，上线后忘记关，或者某个仪表盘依赖了这个特性，就一直开着。Grafana Labs 的默认关闭策略是对的，但"手动开启"这个操作本身，应该触发安全 review 流程——有多少团队做到了？

Liad Eliyahu 的披露方式也值得注意。负责任的漏洞报告（responsible disclosure）给了厂商缓冲期，也让云服务商有机会提前加固。但最终用户拿到信息时，漏洞已经公开，利用代码可能已经在流传。3 月 31 日的公告，31 日当天就得开始修，窗口期以小时计。

你的 Grafana 实例 sqlExpressions 开关现在是什么状态？如果答不上来，建议现在就去仪表盘右上角点一下 Administration → Feature Toggles——这个 30 秒的动作，可能省下接下来几周的救火时间。