GLPI 的模板注入 RCE：管理员权限为什么不该等于 root

GLPI 是套用得挺广的开源 IT 资产管理软件。CVE-2026-26026 影响 11.0.0 到 11.0.5，已在 11.0.6 修复，CVSS 9.1，评为 critical。报告日期 2026 年 4 月 6 日。

一句话描述：一个已登录的管理员，通过模板注入，在服务器上执行任意代码。

攻击链长什么样

按公开的分析，链条是：

1. 攻击者拿到 GLPI 的管理员权限（弱口令、撞库、或者本来就是个内鬼）
2. 进入允许修改模板的界面
3. 构造带注入载荷的模板并保存
4. GLPI 渲染这个模板时执行了注入的代码
5. 拿到服务器上的任意命令执行，起一个反弹 shell 做持久化
6. 以此为跳板横向移动，或者直接拖走数据

真正值得讨论的地方

漏洞的技术细节（哪个模板引擎、注入点在哪）对用这个软件的人来说没有行动价值 —— 补丁已经出了，升级就行。真正值得停下来想的是第 3 到第 4 步之间的那个假设：

为什么「能改模板」等于「能在服务器上跑命令」？

模板引擎被设计成让非程序员能改界面。它给用户的承诺是「你在这里改的东西只影响页面长什么样」。一旦模板能调用任意代码，这个承诺就作废了 —— 而 GLPI 的这个洞正是把「改界面」直接接到了「执行代码」。

更麻烦的是权限模型。管理员在 GLPI 里管的是资产、用户、工单 —— 都是应用层的东西。但这条链把应用层权限直接换算成了操作系统层权限。中间没有任何一步要求「你确实需要服务器访问权」。

这不是 GLPI 独有的问题

同类假设到处都是：

• 后台的「自定义脚本」/「代码片段」功能
• 报表模板、邮件模板里允许的表达式
• 插件市场里「安装即生效」的扩展
• 甚至 CI 的配置文件 —— 谁能改流水线，谁就能在 runner 上跑命令

它们的共同形状是：一个被当作「配置」的东西，实际上是一个图灵完备的执行入口。而权限设计是按「配置」来给的。

防守上能做什么

对用 GLPI 的人来说：

1. 升级到 11.0.6 或更高。这是唯一真正解决的动作。
2. 盘点谁有管理员。这条洞需要已认证的管理员，所以管理员数量越少、来源越可控，风险越低。
3. 把 GLPI 跑在受限环境里。容器、只读文件系统、明确的出网策略。就算模板被执行了，能做的事也有限。

第三条是这类漏洞的通用解 —— 你没法保证应用层永远没有注入，但你可以保证「即使被注入，也拿不到整台机器」。

我的判断

CVSS 9.1 里有一部分分数来自「需要高权限」这个前提被打了折。这个折扣我认为打得不对：管理员权限在很多组织里是共享账号、是外包在管、是离职没清的。把它当成强前提，等于假设一个大多数组织做不到的运维水平。

模板引擎能不能执行代码，应该是一个明确的、写在文档里的、可以关掉的选择，而不是一个默认打开的副作用。任何「后台能改的东西最终能执行代码」的产品，都该在权限界面上把这件事说清楚 —— 因为用户按下「保存模板」的时候，心里想的是「改个样式」。