导语：没有一处检查能替代另外两处
安全团队习惯问"OAuth 回调验证了吗"。对 DocsGPT CVE-2026-91201，更有用的问题是：成功结果给了谁，前端信了谁，后端允许谁使用这个结果？浏览器跨窗口通信、前端消息处理、连接器 API 的所有权校验是三道不同的边界。如果设计时只审查一处，很容易把会话结果沿着整条链传给错误对象。
【事实】GitHub Advisory Database在 2026 年 9 月 15 日发布 CVE-2026-91201：DocsGPT 至 0.20.0 的 OAuth 回调将连接器 session_token 和提供方账户邮箱发给目标 Origin 未受限的 opener；漏洞记录指出可据此断开受害者云盘连接器，标记为 Moderate/CVSS 4.0 5.3。该记录仍是 Unreviewed，结构化修复版本为 Unknown。
背景：AI 知识库的 OAuth 不是"一次登录"
连接云盘的系统通常同时处理三种东西：用户在提供方的授权结果、应用内部表示连接器会话的标识、供后续文件列表/同步等 API 使用的服务端会话记录。这些对象虽有关联，权限却不等价。云盘 Access Token 不应由 session_token 字样自动推导；应用会话标识也不能因为不是 Access Token 就被当作公开数据。
【推断】知识库导入、后台同步和多租户连接器使这类会话标识跨越浏览器与后端多个模块，信任边界比普通"登录弹窗成功"更长。实际暴露程度须结合实例配置与服务器所有权检查判断。
技术原理：三道边界对应三类安全不变量
| 边界 | 输入与输出 | 最小不变量 | DocsGPT 公开材料对应问题 |
|---|---|---|---|
| ① OAuth 回调 → opener | 授权结果变成浏览器消息 | 只交给被允许的前端 Origin，秘密不进入 URL | postMessage(..., '*') |
| ② opener/其他窗口 → 前端 | 消息变成 UI 状态 | 来源 Origin、弹窗引用和当前授权流程必须一致 | ConnectorAuth.tsx 未查 event.origin |
| ③ 前端/其他调用者 → 后端 | 会话标识变成连接器动作 | 身份、会话归属与 provider 对齐 | 研究者指出 disconnect 缺少身份/归属验证 |
【事实】Issue #2766在 2026 年 9 月 13 日提供回调、前端及断连代码路径。其引用的回调快照、前端快照和断连快照给出了可审计的固定代码状态。Issue 中"其他接口导致更多文件/令牌访问"的描述属于报告方分析，不能自动推广到所有版本或每一部署。
【事实】修复 PR #2780由贡献者于 2026 年 9 月 14 日提出组合修复：发送端 Origin 白名单；接收端 event.origin + event.source；成功回调不在 URL 中携带令牌；断连、同步和远程导入校验归属。PR 作者在说明中提出多用户场景下更广的攻击链，并列出自动化与真实浏览器测试；其完整提供方 OAuth 往返未测试。核验时 PR 仍 Open，不是正式修复版本。
风险影响：链条中哪一步已经证明，哪一步尚待验证
【事实】漏洞公告明确支持"错误窗口接收连接器会话标识、邮箱，并可能断开云盘连接"的描述。研究者对未经认证断连的观察记载于 Issue，但不是厂商事后调查。
【推断】若后端进一步把泄露的会话标识当作授权证明，而没有检查账户归属，文件元数据访问、跨账户关联等风险可能放大。不能把"会话标识暴露"直接等同"原始云盘 Access Token 必然泄露"，也不能把研究者拟定的组合链当作在野利用。2026 年 9 月 15 日可核验的一手来源未确认现实攻击活动。
无害验证：设计安全不变量测试矩阵
这不是对真实实例发请求的 PoC。测试开发可在内存中固定 flow_id=F1、user_id=U1、provider=drive、origin=app.example.invalid，并只写虚拟会话编号：
| 测试条件 | 预期安全结果 |
|---|---|
| 预期 Origin + 预期 popup + U1 自有会话 | 成功通知与业务动作允许 |
| 非预期 Origin + 预期 popup | 不投递/不接收成功消息 |
| 预期 Origin + 非本流程 popup | 前端拒绝消息 |
| 正确消息 + U2 使用 U1 会话 | 后端拒绝业务操作 |
| U1 会话 + 错误 provider | 后端拒绝业务操作 |
| 成功回调 URL 含会话字段 | 测试失败，避免日志/历史扩散 |
负向用例比"正常登录能成功"更能证明边界建立。还要验证不同前端/API Origin 的部署、并发流程、消息被重复发送与会话撤销后的旧消息；所有测试都可使用虚拟提供方，不需真实云盘凭据。
行动建议：把修复做成一个闭环
【建议·P0】盘点实例版本、连接器配置、授权回调与公网暴露情况；正式修复未发布/核验前，评估暂停高敏云盘连接器授权，审计异常断连与导入事件，并保持最小必要数据留存。核对最近是否把会话标识写入 URL 或日志；日志排查需保护敏感值。
【建议·P1】审查 PR/补丁时按表中的三道边界逐项验收，特别是在后端每个接受会话标识的接口校验身份、会话所有权及提供方匹配。准确部署允许 Origin 列表，不用 '*'、宽泛子域通配或把开发 Origin 放入生产；测试前后端分源环境的正常 OAuth 流程。
【建议·P2】为仓库制定三个可检查的指标：携带敏感字段的 wildcard postMessage 数量为零；消息处理器缺失 Origin/source 校验数量为零；消费会话标识但缺少所有权测试的 API 数量为零。将 URL/Referer/日志中会话字段泄露纳入评审，并搜索支付、SSO、MCP 连接器的同类代码变体。
总结
OAuth 回调负责签收授权结果，浏览器消息负责送达，服务端 API 负责最终执行。只有把接收人、发件人和会话所有人分别验证，才能把"登录成功"变成"正确用户的正确连接器获得正确操作"。DocsGPT 案例最值得借鉴的是这个可测试的三层不变量，而不是某个字符串 '*' 的孤立修补。