MaxKB 为每个启用了工具的助手附加了 Shell 工具，却从未对其进行权限限制

MaxKB 是一个由 GitHub 组织 1Panel-dev 发布的开源企业助手平台，其聊天智能体构建在一个框架上：只要传入支持 shell 的后端，该框架就会静默添加一个 shell 工具——而 MaxKB 从未移除该工具，也从未要求任何人批准其使用。该漏洞为 CVE-2026-77521，以 GitHub 安全公告 GHSA-f36j-f34j-h3rx 的形式于 2026 年 9 月 2 日发布，并针对公开或嵌入式助手的情形，在 CVSS 3.1 下获评 10.0 分（满分 10 分）。Lasso Security发现并报告了该漏洞，并演示了聊天消息——或助手仅通过检索或上传文档而摄取的文字——可驱使模型执行命令：在裸金属部署中直接于主机上执行，而在官方容器中则通过一个研究人员称可用分号绕过的包装器执行。没有任何被引用的来源记录该漏洞遭到野外利用。该记录自身的严重性等级、置信度评估和来源列表位于AI 事件档案中，与同一披露批次中相邻的 MaxKB 和代理工具相关条目并列。

MaxKB 是一款自托管产品，用于构建检索增强型助手：操作员创建助手并为其附加能力——工具、Model Context Protocol 服务器、技能、子应用——连接由上传文档或抓取网站构建的知识库，然后通过经过身份验证的控制台或以公开、可嵌入的聊天组件形式对外提供该助手。这种多功能性正是其暴露面所在。该安全公告的触发条件并非特殊配置，而是常规配置：任何附加了至少一项能力的助手都会将其聊天路由到受影响的智能体路径，而未附加任何能力的聊天则不会。Lasso 的文章称该项目是其类别中采用较广泛的项目之一，并指出 MaxKB 通常作为多租户服务部署——这使得以应用用户身份运行的命令处于租户模型之下，而不是位于某个租户的切片之内。

Shell 工具是随着框架一起出现的，而不是随产品一起出现的

MaxKB 使用 LangChain 的 deepagents 库构建这些智能体，并在项目的 pyproject.toml 中将版本固定为 0.6.11，在存在漏洞的标签和当前标签中都是如此。在 apps/application/flow/tools.py 中，在 v2.10.3-lts 标签的第 467 行，项目调用 create_deep_agent，并将 backend 设置为 SandboxShellBackend，这是一个 MaxKB 子类，会在主机上运行命令。根据该公告，只要以这种方式传入 shell 后端，deepagents 就会自动注入一组工具：execute、ls、read_file、write_file、edit_file、glob 和 grep。这些工具不属于 tools=list 参数，该参数仅包含操作者自己的工具、MCP 工具和技能工具。它们无法从接口中或通过配置移除。

MaxKB 也没有传入 excluded_tools，而这个库参数本会移除它们。该公告即使将其作为补救措施，也谨慎说明了这一点为何重要：excluded_tools“只是把工具从模型被告知的内容中移除，而不是从执行器中移除”。模型不知道某个工具与某个工具无法运行之间的区别，正是整个缺陷的缩影。

一扇列出三种工具、却遗漏了第四种的门

同一调用中的人在回路控制只有一行，它列举了三个操作：interrupt_on={"write_file": False, "read_file": False, "edit_file": False}。写文件、读文件和编辑文件都被点名了。命令执行根本不是该字典中的键。按照该咨询意见的解读，这意味着对 execute 不寻求任何批准——三项文件系统操作被点名并显式设置为不中断，而 shell 工具则完全未被点名。

综合起来，路径是：不可信文本到达模型，模型调用 execute，然后命令被执行。该安全公告指出了不可信文本到达的两种方式。直接方式是聊天——一个公开或嵌入式小部件，或另一个租户的对话。间接方式是助手摄取的内容：一份 RAG 文档、一个上传的文件，或平台抓取到知识库中的网页。Lasso 的文章让第二条路径变得具体，并指出“能够把文本放到模型面前的人，比能够与它聊天的人更多”。

在裸机安装中，该命令只是一个命令。

无论 MaxKB 在隔离方面做了什么，都发生在 apps/application/flow/backend/sandbox_shell.py 中，而在 v2.10.3-lts 中，这一切从一个默认值开始。第 9 行写着 _enable_sandbox = bool(int(CONFIG.get("SANDBOX", 0)))，并且 SANDBOX 并未出现在 apps/maxkb/conf.py 的 Config.defaults 中。如果没有显式的 MAXKB_SANDBOX 设置，该值就是零，第 65 行的包装器分支会被跳过，execute 会直接在主机上以 shell=True 到达 subprocess.run，并以运行该服务的用户身份执行——用公告中的话说，如果服务以 root 运行，那就是 root。

这就是研究人员用于其主机概念验证的配置。他们在未设置 MAXKB_SANDBOX 的情况下从源码运行了 MaxKB 的真实代码，创建了一个附带单个工具的助手，并在单条聊天消息中要求它执行系统信息命令。execute 工具被触发，写入了一个文件，其内容是主机自身的 uname、id 和 sw_vers 输出——通告指出，这些输出已确认在任何容器内均不存在。Lasso 还记录了阻止它的限制所在：一个名称露骨的验证文件被模型拒绝，而使用温和的运维措辞则未被拒绝。用他们的话说，模型对齐是“一个部分性的减速带，而不是一种控制手段”。

在官方镜像上，沙箱运行了，但仍然发生了泄漏。

官方容器在基础镜像的 installer/Dockerfile-base 第 48 行设置了 MAXKB_SANDBOX=1，因此包装脚本在那里处于激活状态——而该包装脚本正是第二个缺陷。它拼接成了一个字符串：env -i LD_PRELOAD=/opt/maxkb-app/sandbox/lib/sandbox.so，后面跟着 gosu sandbox，然后是模型提供的命令，并交给一个以 root 身份运行的 shell。由于命令是作为文本插入的，其中只有第一个 token 位于 gosu 之下。模型输出中的任何分号、管道、重定向或命令替换，都会在沙箱看到它之前先由外层 root shell 求值。

Lasso 的分析文章给出了其可行形态：一个 payload 为 env -i LD_PRELOAD=... PATH="$PATH" gosu sandbox ls; whoami; id，其中 ls 被限制，whoami 不受限制，而它之后的所有内容都可自由运行。在测试中，研究人员通过重定向写入了一个 root 拥有的文件，而受沙箱限制的内部命令被阻止。雪上加霜的是，installer/Dockerfile 和 installer/Dockerfile-base 都不包含 USER 指令，因此应用镜像以 UID 0 运行——公告报告确认运行时为 root。因此容器无论如何都会执行命令，而沙箱只决定哪些命令在表面上被归因于低权限用户。

Lasso 描述的完整攻击流程完全不需要访问目标。攻击者将命令放置在一个网页上，等待受害者的代理将其抓取到知识库中，随后受害者提出一个普通问题。返回的答案正确且合法；而注入的 curl 早已在攻击者的服务器上触发。该公告指出，研究人员仅测试了他们自己的部署，并未测试任何第三方或托管的 MaxKB 实例。

来源能够确立什么，以及什么根本没有被测量

该机制、两种部署模式、致谢以及修复版本在四份文档中相互一致：GitHub 安全公告、2026 年 9 月 21 日发布的 NVD 记录、Lasso 于 2026 年 9 月 10 日发布的技术说明，以及 GBHackers 于 2026 年 9 月 22 日的报道——后者是本次 CVE 所找到的唯一独立媒体报道。没有任何来源对该发现的任何部分提出异议，档案将该条目记录为无争议，并标注为其最高置信等级。

这些来源不包含任何暴露程度的衡量。没有 MaxKB 部署数量的统计，没有面向互联网或嵌入式助手的数量统计，没有扫描结果，没有遥测数据，也没有具名受害者。记录中没有任何内容显示该漏洞被用于攻击任何人，CISA 自己的利用评估也持相同看法：2026 年 9 月 22 日附加到 NVD 记录上的 SSVC 区块将利用情况评为“poc”，可自动化评为“yes”，技术影响评为“total”。FIRST 的 EPSS 模型在 2026 年 10 月 27 日给出的未来 30 天内被利用概率为 1.05%，处于第 64 百分位，并且该 CVE 未出现在日期为 2026 年 10 月 27 日的 CISA 已知被利用漏洞目录中。该档案自身的评级反映了同样的证据：严重性为高，实际危害为否。

10.0 这个分数值得说清楚它的适用范围，因为它是最容易被断章取义引用的数字。这是公开或嵌入式助手情形下的评分，其 CVSS 向量为 AV:N/AC:L/PR:N/UI:N/S:C —— 网络可达、无需权限、无需用户交互，并且存在范围变更，因为助手内部的一条命令会跨越进入宿主操作系统。该分数由 CNA 给出，此处的 CNA 是 GitHub 的公告项目，CVE 记录的来源标识符也指向这里。NVD 以次要指标的形式收录了相同的向量，并且截至 2026 年 10 月 28 日，该条目被列为"Deferred"（已推迟）状态，这意味着 NVD 发布的是分配方的分析，而非其自身的分析。

补丁比安全公告早一个月发布。

时间顺序从发布时点往回倒推，这是记录中最不直观的部分。Lasso 于 2026 年 7 月 8 日通过 GitHub 的公告渠道私下报告了该漏洞。MaxKB 次日回复，将报告范围限定为官方镜像，并要求提供容器概念验证；研究人员于 7 月 10 日提供了该验证以及沙箱绕过方法。一个修复提交 594f50f2 于 7 月 9 日落地——即报告后一天——它重写了 sandbox_shell.py，使模型命令字符串先被解析，并将 gosu 前缀应用于每个简单命令，而不是仅应用于第一个命令，同时重新引用每个参数列表，使替换无法逃逸到父 shell 中。Lasso 的撰文将该变更描述为将 gosu 前缀应用于“每个简单命令，而不仅是第一个”。

包含该修复的版本 v2.10.5-lts 于 2026 年 8 月 6 日发布。GitHub 安全公告于 9 月 2 日上线，NVD 于 9 月 21 日发布该 CVE，CISA 的 SSVC 条目随后被补充、GBHackers 于 9 月 22 日进行了报道，而 Lasso 自己的文章则出现在 9 月 10 日——处于这一序列的中段，而非起点。相比之下，只跟踪发布标签、而不关注安全公告源的操作者，在警告出现前大约四周就已经拿到了补丁。

版本边界比公告所给予的关注更值得重视，因为两个主要来源说法不一致，而代码仓库能对这个问题给出定论。公告的表单字段将受影响版本记录为“<= 2.10.3-lts”，并注明这一点已在 2.10.3-lts 上验证，且该漏洞路径“很可能”影响所有以这种方式构建 agent 的版本。Lasso 自己的说明则将受影响范围写为“<= 2.10.4-lts”。标签证实了更宽的范围：2026 年 7 月 16 日发布的 v2.10.4-lts 带有与 v2.10.3-lts 相同的 75 行 sandbox_shell.py，而重写后的 311 行文件首次出现在 v2.10.5-lts 中。运行 2.10.4-lts 的运维人员如果只读了公告中的范围，就会认为自己不在该范围内。事实并非如此。

该修复未做的事

2.10.5-lts 修复的是包装器：它不再在 root 权限下构建单个 shell 字符串。它没有做的是针对该工具的任何处理。直接阅读 2026 年 10 月 22 日发布的标签 v2.10.8-lts 处的仓库可知，agent 仍使用 backend=SandboxShellBackend 构造，interrupt_on 仍恰好包含三个键——write_file、read_file 和 edit_file——且没有 execute。该公告的前两条修复建议——默认基于非执行后端构建，以及在审批映射中添加 "execute": True——在该版本中并不存在。

失败关闭（fail-closed）建议后来才落地，是在 v2.10.7-lts 中，而它对处境最差的部署模式尤为重要。该版本发布于 2026 年 10 月 15 日，它将 sandbox_shell.py 中的那一行从 CONFIG.get("SANDBOX", 0) 改为 CONFIG.get("SANDBOX", 1)。对于从未设置该变量的源码安装或裸机安装，包装器现在默认开启而非关闭，这正是狭义上的“在非容器部署中失败关闭”建议。该公告在同一标题下提出的要求不止于此——即当沙箱运行时不可用时，具备执行能力的流程应拒绝启动——并且另行要求包装器绝不为 root shell 构建命令字符串。在容器方面，这是一个事实而非建议：在 v2.10.8-lts 标签中，installer/Dockerfile 和 installer/Dockerfile-base 都没有 USER 指令，因此应用镜像仍以 root 身份启动。

综合来看，截至 2026 年 10 月 28 日，记录所反映的情况如下。该漏洞的后半部分——即分号得以逃逸出的沙箱——已被封堵，主机部署上的失效开放默认设置也已被封堵。前半部分，即一个随后端对象一同出现、且不属于批准映射中某个键的执行工具，仍然是 MaxKB 构建启用了工具的助手的方式。研究人员自己给出的修复建议是较窄的那一条：升级到 2.10.5-lts 或更高版本，并运行启用了沙箱的 Docker 版本。GBHackers 转述了同样的指示，并为管理员补充了一份更广泛的清单——除非明确需要代码执行，否则禁用具备 shell 能力的代理后端；在任何执行操作前要求人工批准；以非 root 用户运行容器；并将爬取的页面、RAG 文档和上传内容视为不可信输入。

同一批九月记录中的另一条 MaxKB 记录

档案中本批次的第二个 MaxKB 条目是一个不同的漏洞，结局更糟。CVE-2026-77516 同样于 2026 年 9 月 21 日发布到 NVD，它是一个权限绕过而非命令注入：从 2.0.0 到 2.9.2 版本，处于最低角色的工作区成员虽已通过 WorkspaceUserResourcePermission 被明确拒绝访问某个工具，仍可通过 tool_ids、skill_tool_ids 或 mcp_tool_ids 绑定该工具的标识符，并通过智能体或工作流调度路径执行它。调度路径不会重新应用专用工具路由所强制执行的逐工具授权，而工具执行会解密服务端的 init_params，因此调用方会收到其被拒绝访问的工具所携带的凭据。其评分为 5.4，NVD 的描述以一句 CVE-2026-77521 不必包含的话作结：“截至本次审查，尚无已修复版本。”

对比对任何要处置这两个漏洞的人来说才是有用的部分。评分为 10.0 的漏洞在一天内提交了修复，并在其公布前一个月发布。评分为 5.4 的漏洞在其 CVE 发布时没有已发布的修复版本。

真正仍未解决的部分，比评分所暗示的要小，但比补丁说明所暗示的要大。该发现并无争议，其机制已由发现团队在两种部署模式下端到端验证。暴露面则完全未被量化——没有人公布过有多少 MaxKB 助手带有工具、其中有多少可被不受信任方触达，或有多少运行在没有沙箱的主机上——因此该缺陷的现实影响取决于部署习惯，而没有任何被引用的来源统计过这些习惯。而将评分推至最高分的那部分设计，在当前版本中依然存在：一项可执行命令的能力，默认被附加，却未出现在那张要求人类先做确认的图景中。