OAuth 登录已经成功，令牌为何发给了攻击者？DocsGPT CVE-2026-91201 深度解析

导语：OAuth 最后一跳也会决定全局安全

许多团队审计 OAuth 时，会重点检查 redirect_uri、state、PKCE、客户端密钥和授权码交换，却很少追问：

回调完成后，前端如何知道授权成功？连接器会话令牌又如何从弹窗交回主窗口？

常见实现是主页面打开 OAuth 弹窗，回调页执行：

复制代码

window.opener.postMessage(result, targetOrigin)

如果 targetOrigin 是 '*'，浏览器会把消息发给当前 opener，无论它来自哪个站点。若任意页面都可以成为 opener，敏感数据便可能跨源发送。

DocsGPT 的公开代码和问题记录显示，连接器 OAuth 流程正是踩中了这个坑。

一、时效时间线

2026 年 6 月 15 日：研究者称通过私下渠道报告问题。
2026 年 9 月 12 日：DocsGPT 0.20.0 发布；公开漏洞记录将该版本列入受影响范围。
2026 年 9 月 13 日 ：项目公开 Issue #2766，披露跨源 postMessage、接收端缺少来源校验和无认证断开连接等问题。
2026 年 9 月 14 日：NVD 发布 CVE-2026-91201；项目出现修复 PR #2780。
2026 年 9 月 15 日：GitHub Advisory Database 收录该 CVE；截至本文核验，记录仍为 Unreviewed，PR #2780 仍处于 Open 状态。

因此，本文解读的是刚进入公共漏洞数据流、仍在修复中的事件。不能把开放 PR 当成已上线补丁，也不能声称 0.20.0 之后存在某个尚未发布的安全版本。

二、先把已知与未知分开

已确认事实

CVE-2026-91201 影响 DocsGPT 至 0.20.0 的版本。
GitHub 数据库记录为 Moderate，CVSS 4.0 为 5.3，CWE 为 CWE-346"来源验证错误"。
回调状态页面把 session_token 和用户邮箱发送给 window.opener，目标源使用 '*'。
前端消息处理器没有检查 event.origin。
公开 Issue 指出 /api/connectors/disconnect 接受 session_token，没有 JWT 身份验证和所有权校验。
当前公开发布版本为 0.20.0；修复 PR 尚未合并，也没有正式修复版本可供核验。

需要谨慎表述的内容

CVE 公共记录明确支持的影响，是连接器会话令牌与提供方邮箱泄露，以及利用令牌断开受害者连接器。
开放修复 PR 的作者进一步描述：在多用户部署中，攻击者可能利用自己创建的会话行承载受害者完成授权后的云盘凭据，并访问文件列表或原始提供方 Token。这一结论来自项目 PR 的代码路径分析与测试说明，但尚不是合并后的厂商发布公告。
session_token 不应直接等同于 Google、Microsoft 或 Atlassian 的原始 OAuth Access Token；它是指向服务器端连接器会话的标识。能否进一步取得原始凭据，取决于后端接口、身份与所有权校验。

尚无证据

截至 2026 年 9 月 15 日，核验的一手来源没有确认在野利用。
没有公开证据支持特定攻击者、受害规模或数据泄露数量。

三、漏洞链的第一环：`postMessage(..., '*')`

公开 Issue 展示的回调逻辑等价于：

复制代码

if (status === "success" && window.opener) {
  window.opener.postMessage({
    type: providerType + "_auth_success",
    session_token: sessionToken,
    user_email: userEmail
  }, "*");
}

window.postMessage() 本身是安全的跨窗口通信能力。风险来自第二个参数。

指定精确 targetOrigin 时，浏览器只在接收窗口的源匹配时投递消息：

复制代码

popup.postMessage(data, "https://app.example.com")

使用 '*' 时，投递条件退化为"只要它是 opener 就发送"。如果攻击者页面打开 OAuth 弹窗，它就可能成为接收者。

这不是传统 CORS 问题。CORS 控制网页能否读取网络响应；postMessage 是浏览器提供的跨窗口消息机制，安全性依赖发送端指定目标源、接收端验证消息源。

四、第二环：接收端没有验证 `event.origin`

公开记录显示，DocsGPT 前端监听 message 事件后，会检查消息中的 type，却没有验证：

event.origin 是否为预期 API / 回调源；
event.source 是否为当前前端亲自打开的那一个弹窗；
消息结构和 Token 是否绑定当前授权事务。

仅检查：

复制代码

event.data.type === `${provider}_auth_success`

只能证明消息长得像预期格式，不能证明消息来自预期窗口。

发送端通配目标与接收端无来源校验是两项不同问题：

前者可能把真实令牌发给错误页面；
后者可能让错误页面把伪造令牌送入真实前端。

安全设计必须同时约束两个方向。

五、第三环：会话令牌没有始终绑定所有者

浏览器把 Token 交给谁，只是第一道边界。后端还必须把会话令牌绑定到：

复制代码

当前登录用户 + 当前提供方 + 当前连接器会话

Issue #2766 指出，断开连接接口没有 JWT 验证，也没有确认会话属于调用者。开放修复 PR 还为同步、远程上传和会话删除增加用户所有权与提供方匹配约束。

这说明 session_token 在部分路径中被当成了 Bearer Capability：谁拿到它，谁就能发起相应操作。

随机 UUID 能降低猜测概率，却不能替代身份验证。高熵 Token 只能防止"猜到"，不能防止"被错误发送、写入 URL、记录到日志或跨源泄露"。

六、完整信任链如何被串起来

下面是公开资料支持的概念流程，不是可直接攻击真实实例的步骤：

复制代码

非预期页面成为 OAuth 弹窗的 opener
                │
                ▼
用户在合法提供方完成授权
                │
                ▼
DocsGPT 回调创建或更新连接器会话
                │
                ▼
回调页向 window.opener 发送 session_token
targetOrigin = "*"
                │
                ▼
非预期页面收到连接器会话标识
                │
                ▼
后端操作若缺少身份、所有权或提供方校验
会话破坏或数据访问风险被放大

重点是：攻击者不是伪造 Google 或 Microsoft 的 OAuth 页面，也不必破解授权码。用户可能在真正的提供方页面完成真正的授权，风险却发生在授权结果返回应用之后。

七、为何 AI 知识库连接器风险更敏感

DocsGPT 等 AI 知识库会连接企业云盘、协作文档和知识源。连接器通常具有：

列举文件和目录的权限；
读取用于索引的文档内容；
定期同步或重新抓取能力；
将内容进入向量库、搜索索引或 Agent 上下文的通道。

事实：公共 CVE 明确描述了会话令牌泄露与断开连接风险。

工程推断：如果同一会话还能调用文件列举、同步或原始凭据返回接口，影响可能扩展到云盘数据访问与知识库污染。是否成立需要结合实际部署、用户身份和后端接口校验确认。

不能直接下结论 ：这不等于所有 DocsGPT 部署的云盘文件已经泄露，也不等于获得 session_token 就必然得到提供方 Access Token。

八、开放修复 PR 做了什么

PR #2780 截至核验时仍未合并，但它展示了维护者正在评审的修复方向。

1. 精确限制发送目标源

回调页不再向 '*' 广播，而是基于回调自身源、配置的前端地址和新的允许源列表确定目标。

2. Token 不再进入 URL

候选补丁让成功回调直接渲染结果页，不再把 session_token 和邮箱放入回调状态 URL；同时建议设置 Cache-Control: no-store 与 Referrer-Policy: no-referrer。

这样可以减少浏览器历史、代理日志、访问日志和 Referer 泄露。

3. 接收端双重校验

前端要求：

复制代码

event.source == 当前打开的 popup
event.origin == 服务端返回的 callback_origin

源正确但窗口不正确，或窗口正确但源不正确，都不能接受。

4. 后端验证身份与所有权

候选补丁要求断开、同步和远程操作验证当前用户是否拥有该连接器会话，并校验提供方匹配。

5. 增加负向测试

PR 描述的测试包含：拒绝通配符、null 与非 HTTP 源；不把 Token 放进 URL；拒绝外来会话；验证弹窗身份和消息来源。

需要强调：这些是开放 PR 中的候选修复，不代表 0.20.0 已具备这些保护，也不能作为"已修复版本"对外宣称。

九、一个不联网的无害模型

下面只模拟投递决策，不打开窗口、不连接 DocsGPT，也不处理真实令牌。

复制代码

function vulnerableDelivery(openerOrigin) {
  // '*' 意味着无论 opener 是哪个源，都允许投递
  return { targetOrigin: "*", deliveredTo: openerOrigin };
}

function fixedDelivery(openerOrigin, callbackOrigin, allowedOrigins) {
  const allowed = new Set(allowedOrigins);

  if (!allowed.has(openerOrigin)) {
    return { delivered: false, reason: "origin not allowed" };
  }

  if (openerOrigin !== callbackOrigin) {
    return { delivered: false, reason: "callback mismatch" };
  }

  return { delivered: true, targetOrigin: callbackOrigin };
}

console.log(vulnerableDelivery("https://unexpected.example"));
// 仍然投递

console.log(fixedDelivery(
  "https://unexpected.example",
  "https://docs.example",
  ["https://docs.example"]
));
// 拒绝

后端还需要独立执行所有权校验：

复制代码

def authorize_connector_action(session, current_user, provider):
    if session.user_id != current_user.id:
        raise PermissionError("foreign connector session")
    if session.provider != provider:
        raise PermissionError("provider mismatch")

两个模型分别保护浏览器投递与服务端资源访问，不能互相替代。

十、当前部署应该如何处置

由于截至核验时没有正式修复版本，不能简单给出"升级到某版本"的答案。

P0：立即降低暴露

确认是否启用 Google Drive、SharePoint、Confluence 等连接器，以及是否为多用户部署。
若业务允许，临时停用外部 OAuth 连接器，直到官方修复合并并发布。
限制 DocsGPT 前端和 API 的可访问源，避免不受信站点参与 OAuth 弹窗流程。
在反向代理或临时补丁层阻止未认证的连接器断开、同步和远程操作。
不要把开放 PR 分支直接当成正式安全版本部署到生产；若必须自建修复，应完成代码评审和回归验证。

P1：回溯排查

重点检查：

OAuth 回调、callback-status URL 是否在日志中包含会话 Token；
异常连接器创建、断开、同步或远程文件操作；
同一会话 Token 是否由不同用户、IP 或 User-Agent 使用；
连接器会话的所有者与提供方授权账户是否异常不一致；
OAuth 完成后是否出现来自非预期 Origin 的前端活动；
代理、浏览器诊断、错误上报中是否收集过完整回调 URL。

若确认连接器会话可能泄露，应撤销 DocsGPT 会话，并在对应云服务侧撤销 OAuth Grant 或刷新令牌，而不是只删除本地连接器记录。

P2：等待并验证正式补丁

正式版本发布后，验证以下行为：

不再出现 postMessage(..., '*')；
前端同时检查 event.origin 和 event.source；
Token 不进入查询参数、日志和 Referer；
所有连接器操作都验证登录身份、会话所有权与提供方；
未配置允许源时关闭失败，而不是回退到通配符；
跨域前后端部署完成明确的允许源配置。

十一、开发团队的安全编码建议

建议一：敏感消息永远指定精确目标源

复制代码

targetWindow.postMessage(payload, expectedOrigin)

expectedOrigin 必须来自服务端配置或当前可信事务，不能来自未验证的 URL 参数。

建议二：接收端验证源、窗口和事务

复制代码

if (event.origin !== expectedOrigin) return;
if (event.source !== oauthPopup) return;
if (event.data.state !== pendingState) return;

然后再校验消息 Schema，最后才读取 Token。

建议三：不要把凭据放进 URL

URL 可能进入历史记录、网关日志、监控、Referer 和截图。OAuth 结果应通过短生命周期、一次性通道传递，并在使用后失效。

建议四：Token 必须绑定资源所有者

每一个使用连接器会话的接口都应同时校验：

复制代码

authenticated_user_id
session.user_id
requested_provider
session.provider
tenant_id

不要把"持有随机 Token"视为充分授权。

建议五：把跨源攻击者放进威胁模型

测试时至少准备三个 Origin：合法前端、合法 API 回调、恶意 opener。验证恶意页面既收不到真实消息，也不能向真实前端注入伪消息。

十二、DevSecOps 应增加哪些门禁

静态检测

搜索：

复制代码

postMessage(..., '*')
window.addEventListener('message', ...)
event.data without event.origin
token in query parameters
session lookup without user_id

单元与浏览器测试

非允许 Origin 收不到消息；
不是当前 popup 的窗口不能注入消息；
null、通配符和非 HTTP(S) 源被拒绝；
Token 不出现在地址栏和服务端访问日志；
A 用户不能操作 B 用户的连接器会话；
提供方不匹配时拒绝；
Token 被使用或撤销后不能重放。

发布检查

OAuth 回调变更需要前后端共同安全评审；
新增连接器必须提交数据流图和 Token 生命周期；
安全补丁只有在合并、发布、镜像构建和部署完成后，才能标记为已修复；
SCA 需要识别实际容器镜像与后端版本，不能只查看前端包版本。

十三、事实、推断和建议总结

事实：0.20.0 及之前版本存在通配目标源与消息来源验证问题；公共记录确认会话令牌可能泄露，并可被用于断开连接器。

项目 PR 中的进一步分析：多用户部署的会话所有权问题可能让影响扩展至文件列表或提供方 Token。该 PR 仍开放，结论需要以后续合并代码和正式公告继续核验。

工程建议：在正式修复发布前，优先停用或隔离连接器；长期同时修复跨窗口通信、Token 传递和服务端所有权校验。

未知：尚无一手来源确认在野利用，也没有官方发布的修复版本。

总结

CVE-2026-91201 没有破解 OAuth 提供方，也没有伪造合法回调。它利用的是授权成功后的交付链：回调页把敏感会话发给"任何 opener"，前端对消息来源缺少验证，后端部分接口又把会话 Token 当成足够的权限证明。

对 AI 知识库和 Agent 平台而言，外部连接器就是数据供应链入口。安全边界必须从 OAuth 发起、回调、弹窗消息一直延伸到后端每一次文件访问与同步操作。

真正安全的完成条件不是"用户已经点了允许"，而是：

授权结果只交给正确窗口，连接器会话只属于正确用户，每次数据访问都重新验证这两个事实。

OAuth 登录已经成功，令牌为何发给了攻击者？DocsGPT CVE-2026-91201 深度解析

导语：OAuth 最后一跳也会决定全局安全

一、时效时间线

二、先把已知与未知分开

已确认事实

需要谨慎表述的内容

尚无证据

三、漏洞链的第一环：postMessage(..., '*')

四、第二环：接收端没有验证 event.origin

五、第三环：会话令牌没有始终绑定所有者

六、完整信任链如何被串起来

七、为何 AI 知识库连接器风险更敏感

八、开放修复 PR 做了什么

1. 精确限制发送目标源

2. Token 不再进入 URL

3. 接收端双重校验

4. 后端验证身份与所有权

5. 增加负向测试

九、一个不联网的无害模型

十、当前部署应该如何处置

P0：立即降低暴露

P1：回溯排查

P2：等待并验证正式补丁

十一、开发团队的安全编码建议

建议一：敏感消息永远指定精确目标源

建议二：接收端验证源、窗口和事务

建议三：不要把凭据放进 URL

建议四：Token 必须绑定资源所有者

建议五：把跨源攻击者放进威胁模型

十二、DevSecOps 应增加哪些门禁

静态检测

单元与浏览器测试

发布检查

十三、事实、推断和建议总结

总结

三、漏洞链的第一环：`postMessage(..., '*')`

四、第二环：接收端没有验证 `event.origin`