导语：本次 Coder 越权漏洞（CVE-2026-126403）以 CVSS 8.5 的高危评级直击云开发平台最敏感的凭证边界——external agent credentials 端点仅校验 workspace read 权限便下发 agent token，使 Template Admin、Organization Admin 等非特权角色得以横向窃取工作区所有者的 Git SSH 私钥与 Git Provider OAuth 令牌，并冒充 agent 接管会话。作为长期负责研发基础设施安全的架构师，我认为这不是一次普通的参数校验疏漏，而是资源级授权模型（Resource-Level Authorization）与角色模型（RBAC）之间长期错配的典型爆发。
一、Coder 越权漏洞的攻击面全景与影响范围
Coder 是当前主流的自托管云开发环境（Cloud Development Environment）平台，其核心价值在于把开发者的 workspace 以容器化方式运行在集群中，并通过 agent 进程在 workspace 内部执行命令、转发端口、同步文件。为了让 IDE 插件、CLI 与外部工具能够与 workspace 内的 agent 通信，平台设计了一个 external agent credentials 端点，用于签发短期 agent token。问题恰恰出在这里：该端点在签发 token 前，只验证调用者是否具备目标 workspace 的 read 权限，而没有验证其是否具备 ssh 权限。
这意味着一个拥有 Template Admin 或 Organization Admin 角色的已认证用户，只要对某个 workspace 有读权限，就能拿到该 workspace 的 agent token。而 agent token 的权限边界远大于 read：它可以读取 workspace 所有者注入的 Git SSH 私钥、Git Provider OAuth 令牌，甚至以 agent 身份接收所有者的会话。攻击者由此完成从「只读观察者」到「身份冒充者」的越权跃迁。
| 受影响版本分支 | 修复版本 | 风险等级 | 处置建议 |
|---|---|---|---|
| 2.26.0 – 2.29.23 | 2.29.24 | 高危 | 立即升级 |
| 2.30.0 – 2.34.15 | 2.34.16 | 高危 | 立即升级 |
| 2.35.0 – 2.36.10 | 2.36.11 | 高危 | 立即升级 |
| 2.37.0 – 2.37.7 | 2.37.8 | 高危 | 立即升级 |
| 2.38.0 – 2.38.3 | 2.38.4 | 高危 | 立即升级 |
企业级架构规范
flowchart TD
subgraph 接入层 ["表现层与接入网关 (Client & Gateway Tier)"]
A["已认证用户 (Template Admin / Org Admin)"] --> B["调用 external agent credentials 端点"]
end
subgraph 规则层 ["授权校验层 (Authorization Tier)"]
B --> C["workspace read 权限校验通过"]
C --> D["缺失 ssh 权限校验 (缺陷点)"]
end
subgraph 领域层 ["凭证签发与泄露层 (Credential Tier)"]
D --> E["签发 workspace agent token"]
E --> F["读取所有者 Git SSH 私钥"]
E --> G["读取 Git Provider OAuth 令牌"]
E --> H["冒充 agent 接收所有者会话"]
end
subgraph 存储层 ["基础设施与数据存储 (Infrastructure Tier)"]
F --> I[("Git 仓库 / 外部代码托管平台")]
G --> I
H --> J[("所有者会话与终端通道")]
end
二、根因剖析：RBAC 角色模型与资源级授权的错配
从架构视角看，这个 Coder 越权漏洞的根因并不复杂，但非常典型。Coder 的权限体系是双层结构：一层是组织级的 RBAC 角色（Owner、Template Admin、Organization Admin、Member 等），另一层是 workspace 级的资源权限（read、update、ssh、start、stop 等）。external agent credentials 端点在设计时，把「能否看到 workspace」与「能否以 agent 身份操作 workspace」混为一谈，用 read 权限替代了 ssh 权限。
2.1 权限语义的降级：read ≠ ssh
在 Coder 的权限语义中，read 表示可以查看 workspace 的元数据、状态与日志；ssh 表示可以建立终端会话、执行命令、访问 workspace 内的敏感文件。agent token 本质上是 ssh 能力的凭证化封装，因此其签发前置条件必须是 ssh 权限，而非 read。将 read 提升为 agent token 的签发门槛，等于把「只读观察」静默升级为「完全控制」，这是权限语义的严重降级。
2.2 高权限角色的横向放大效应
更危险的是，Template Admin 与 Organization Admin 这类角色本身具备跨 workspace 的可见性。它们通常对组织内大量 workspace 拥有 read 权限，因此一旦 read 即可换 token，攻击面就从单个 workspace 放大到整个组织。攻击者无需成为 workspace 所有者，也无需被显式授予 ssh 权限，就能批量收割所有者的 Git 凭证。
agent token 一旦泄露，攻击者读取的 Git SSH 私钥与 OAuth 令牌往往具有长期有效性，且可能被复用到其他系统。即使升级修复了端点逻辑，已泄露的凭证仍需全部轮换，否则攻击窗口不会真正关闭。
三、攻击链还原：从 read 权限到会话劫持
把攻击链拆开看，Coder 越权漏洞的利用路径清晰且低门槛，一个具备基础 API 调用能力的已认证用户即可完成：
- 第一步 · 枚举目标：利用 Template Admin 或 Organization Admin 的可见性，列出组织内 workspace 及其所有者信息。
- 第二步 · 换取 token：对目标 workspace 调用 external agent credentials 端点，凭 read 权限获取 agent token。
- 第三步 · 读取凭证：以 agent 身份访问 workspace 内的 Git SSH 私钥文件与 Git Provider OAuth 令牌存储。
- 第四步 · 横向移动：使用窃取的 SSH 私钥克隆私有仓库，使用 OAuth 令牌调用代码托管平台 API。
- 第五步 · 会话劫持：冒充 agent 接入会话通道，接收所有者后续的终端会话与交互数据。
值得注意的是，第四步与第五步使该漏洞从「信息泄露」升级为「身份冒充」。在供应链攻击视角下，攻击者可以借所有者的 Git 身份向私有仓库提交恶意代码，或借会话通道窃取更多运行时密钥，形成链式放大。
资源级授权必须遵循「最小能力原则」：凭证签发端点的权限校验，应当以凭证实际具备的能力为准，而不是以调用者对资源的可见性为准。任何把 read 当作 write/ssh 前置条件的实现，都应被视为高危设计缺陷。
四、应急响应与版本升级实操
针对 Coder 越权漏洞，官方已在多个维护分支发布修复版本。生产环境应按自身所在分支选择对应升级目标，切勿跨分支跳跃升级以免引入不兼容变更。
# 1. 备份当前配置与数据库 coder server postgres-builtin-url > /backup/coder-db-url.txt docker compose -f /opt/coder/docker-compose.yaml cp coder:/home/coder/.config/coderv2 /backup/coderv2 # 2. 拉取修复版本镜像（按分支选择对应 tag） docker pull ghcr.io/coder/coder:2.38.4 # 3. 滚动更新并校验健康状态 docker compose -f /opt/coder/docker-compose.yaml up -d coder version curl -fsS http://127.0.0.1:7080/healthz || echo "health check failed" # 4. 审计近期 agent token 签发记录 coder tokens list --all 2>/dev/null || true
点击展开：临时缓解方案与凭证轮换脚本
# 临时缓解：收紧 Template Admin / Org Admin 的 workspace 可见范围 # 在升级窗口前，将非必要管理角色降级为 Member，减少 read 权限暴露面 coder organizations members edit <org-id> --user <user-id> --role member # 凭证轮换：强制所有 workspace 所有者重新生成 Git SSH 密钥 # 1) 通知所有者删除并重建 SSH key # 2) 在 Git Provider 侧吊销旧 OAuth token 并重新授权 # 3) 使所有历史 agent token 失效 coder tokens delete --all --user <owner-id>
升级只修复端点逻辑，不会自动作废已签发的 agent token，也不会轮换已泄露的 Git 凭证。务必在升级后执行一次全量 token 失效与 SSH/OAuth 凭证轮换，否则攻击者仍可凭旧凭证继续活动。
五、工程加固：把 Coder 越权漏洞挡在架构层
单点修复解决的是这一次 Coder 越权漏洞，但同类问题会在任何凭证签发系统中反复出现。作为架构师，我更关注如何把这类缺陷挡在架构层：
- 能力化授权：把权限模型从「角色 + 资源可见性」升级为「能力声明」，凭证签发端点显式声明所需能力（如 ssh:connect），由统一策略引擎裁决。
- 凭证最小化：agent token 应绑定具体操作范围与短 TTL，禁止一个 token 同时具备读取私钥与接收会话的能力。
- 敏感凭证隔离：Git SSH 私钥与 OAuth 令牌不应以明文形式暴露在 agent 可读路径，应通过密钥管理服务按需注入。
- 审计与告警：对 agent token 签发行为建立基线，检测「非所有者签发」「短时间批量签发」等异常模式。
| 加固维度 | 传统实现 | 现代加固方案 | 架构收益 |
|---|---|---|---|
| 授权校验 | read 权限即可签发 token | 能力化策略引擎显式校验 ssh 能力 | 越权面收敛 |
| 凭证生命周期 | 长期有效 agent token | 短 TTL + 操作范围绑定 | 泄露窗口缩短 |
| 敏感数据 | 私钥明文落盘 workspace | KMS 按需注入 + 内存态使用 | 凭证不可持久窃取 |
| 可观测性 | 无签发审计 | 签发基线 + 异常告警 | 攻击可发现 |
回到这次 Coder 越权漏洞本身，它的教训非常直接：授权系统的正确性不取决于角色设计得多细，而取决于每一个凭证签发点是否以「凭证实际能力」为校验基准。把 read 当成 ssh 用，本质上是在授权层做了一次静默的能力提升，而这类提升在云开发平台这种高凭证密度场景中，代价往往就是一次完整的身份沦陷。