一句注入怎么走到主机命令
九月二十一日，MaxKB 的一个严重漏洞被正式披露，编号 CVE-2026-77521，同步 advisory 为 GHSA-f36j-f34j-h3rx，CVSS 3.1 直接给到 10.0 满分。MaxKB 是 1Panel 生态下的企业级开源 AI 知识库助手。问题在于：在 2.10.5-lts 之前的版本里，只要一个助手接了工具、MCP 工具、技能或子应用，它就会走 deepagents 那条带 SandboxShellBackend 的 agent 链路，而这个后端默认把「执行 shell」工具暴露出来，却没把它放进人工确认的中断清单。于是，来自聊天的提示注入，或者更隐蔽地，RAG 检索吃进来的文档里的间接注入，都能让模型直接调用 shell 命令。在没开沙箱的自建部署里，命令以应用账户身份直接执行；即便在官方 root 容器里，那层字符串拼出来的 gosu 包装也让 shell 元字符逃出本意中的沙箱。一句话的注入，沿助手后端一路走到了主机命令执行。
沙箱为什么没挡住
这漏洞最该被咀嚼的地方，不是「没有沙箱」，而是「沙箱被自己的实现绕开」。官方镜像确实设了 MAXKB_SANDBOX=1，意图是把命令降到低权限沙箱用户去跑。但 SandboxShellBackend 在底层用 subprocess.run 配 shell=True，把整条命令当字符串交给外层 shell 解释。外层是 root，于是重定向、管道、命令分隔符、命令替换这些元字符，在外层 shell 真正把命令交给低权限进程之前就被先解释了。研究者用一个简单的重定向就造出了 root 拥有的文件，哪怕真正在沙箱用户下跑的那段命令本身被拦了。换句话说，危险不在沙箱「有没有」，而在「命令字符串在被下沉前被谁先读」。CWE 把它归到 78（OS 命令注入）、250（不必要的特权执行）和 749（暴露危险方法），三条加一起，正好描述了「能注入、以高权限、走危险通道」的完整链路。
谁最危险
风险面分成三块。其一，公开可访问、无需鉴权的助手，攻击者可以直接对话投毒；其二，多租户部署，一个租户的助手出问题可能波及其他租户；其三，也是最容易被人忽略的，间接提示注入——你不必直接跟助手说话，只要控制它被检索的文档或上传内容，注入就跟着 RAG 进了上下文。研究方 Lasso Security 提到，这类触发不总需要越狱，几个普通的运维命令就足以让助手去执行系统信息命令并把结果写进文件。对把 MaxKB 当企业知识库、又开了工具能力的团队来说，这台机器上往往躺着凭证、配置文件和内网入口，一旦被远程代码执行，横向移动和持久化的空间都不小。当然，公开助手是否真被大规模利用，目前尚无在野利用的公开证据，厂商与多家漏洞库也将其列为已修复状态。
修法不是升级那么简单
官方修复落在 2.10.5-lts：把 execute 工具纳入人工确认、堵上 shell 拼接的口子。但对企业来说，光升级不够。其一，逐一审一遍接了工具、MCP、技能或子应用的助手，确认它们不再无声拥有 shell 能力；其二，自建或裸金属部署要显式开启安全的沙箱，且遵循「拿不到就失败关闭」的默认；其三，容器别以 UID 0 跑，别用 shell=True 拼命令串，把 RAG 文档、上传物和外部内容一律当不可信输入。更底层的教训是：别把模型对齐当成安全边界——提示注入面前，靠「模型应该不会那么做」来防命令执行，本身就是一道会被跨过的篱笆。人类审批必须发生在 execute 动作之前，而不是事后。
给 Agent 开发者的硬规矩
MaxKB 这课对所有做智能体平台的人都是一面镜子。凡是给助手接「能执行」类工具的，默认就该要求人工确认；凡是把命令交给 shell 的，宁可多写几行参数化调用，也别拼字符串；凡是吃外部内容的，先假设它带毒。漏洞的 CVSS 10.0 不是吓得人不敢用 Agent，而是提醒一件事：智能体的能力边界每往外扩一寸，攻击面就跟着扩一圈，防护必须同步长出来。目前各漏洞库对该 CVE 的利用概率评分仍偏低、尚无 CISA KEV 列入，后续是否出现公开利用官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
一句收尾
CVE-2026-77521 给行业留下一句朴素结论：当一个能浏览、能读文件、能代操作的智能体，和「默认高权限、默认无确认、默认拼字符串」碰在一起，满分漏洞几乎是可预期的。Agent 安全的下一课，是把「最小特权 + 执行前确认 + 内容不可信」写进框架默认值，而不是等出事再补丁。