文章总结： 本文分析了ChatGPT对话泄露GitHubPAT令牌的安全事件。攻击者利用两次API调用即可无痕侦察权限，文章剖析了审计日志在用户级端点与克隆事件记录上的盲区，指出IP默认不显示的风险。建议启用源IP披露、日志流传输及扫描AI历史记录，强调快速轮换凭证以应对无痕攻击。 综合评分： 88 文章分类： 漏洞分析,安全建设,AI安全,数据泄露

从ChatGPT的疏忽到完全访问GitHub：无人察觉的攻击路径

原创

token.security token.security

安全行者老霍

2026年3月11日 09:01 北京

作者：Faina Knyazhansky

发布时间：2026年2月19日

一枚GitHub个人访问令牌（PAT）被遗忘在旧版ChatGPT对话中长达数月，却始终有效。仅需两次低风险API调用，便能获取多个组织生产仓库的管理权限。攻击者可借此权限映射访问路径，克隆受保护仓库，全程不触发任何审计日志记录–而这些日志正是多数团队依赖的安全防线。

本文将详细解析该攻击场景的演进过程，剖析GitHub审计日志在各环节的记录内容，并揭示系统漏洞所在。

1. 潜藏于聊天记录的密钥

Token Security致力于帮助客户在实际工作场景（如代码、日志、内部工具及AI聊天）中发现暴露的敏感信息。本次事件中，我们通过OpenAI合规API工具扫描某组织ChatGPT历史记录时发现了该个人访问令牌（PAT）密钥。

某次对话中，用户在聊天框粘贴代码片段时，不慎包含了其个人GitHub经典版个人访问令牌（PAT）。数月后，这条消息仍静静躺在对话历史记录中。

2. 两次API调用，完整呈现访问权限图景

我们从代码片段中获取了用户名和令牌字符串本身，但尚未解答真实事件发生初期最关键的问题：

• 该令牌是否仍有效？
• 它实际认证的是哪个GitHub用户？
• 该身份拥有访问哪些组织和仓库的权限？

我们通过两次GitHub REST API调用进行验证：

• 通过GET /user 确认令牌有效性并识别其认证的具体 GitHub 用户。
• 通过GET /user/repos 列出认证用户可访问的仓库列表，包括每个仓库的权限（读取、写入、管理）。

仅此而已。没有写入操作，没有主动操作，没有修改行为。仅进行身份确认和权限映射–这正是攻击者会优先实施的侦察手段，因为它快速且几乎不留痕迹。

3. 结果

该令牌仍处于有效状态。其所属用户拥有多个GitHub组织的行政权限，涵盖包含敏感代码和基础设施的生产仓库。

人们常低估的关键点在于：个人访问令牌（PAT）本身并不具备“独立”权限，而是继承其所有者的现有访问权限。开发人员通常在跨组织和环境中拥有广泛访问权限，因此在聊天中泄露的令牌可能迅速渗透至生产环境。

4. 可见性差距：无痕迹侦察

确认影响范围后，我们提出防御性问题：若攻击者获取相同令牌并执行相同调用，是否有人察觉？

我们在两种环境中追踪API调用痕迹：

• 标准GitHub组织，采用免费/团队方案（使用组织审计日志）
• GitHub Enterprise Cloud，配置了审计日志流传输且明确启用了API请求事件的。

背景说明：在GitHub Enterprise Cloud中，审计日志流传输可将审计事件导出至外部系统（如Splunk、Datadog、Amazon S3等）。此外还存在名为“API请求事件”的专属功能–这是需手动启用的选项，记录API活动以供调查。该功能默认处于关闭状态，必须明确开启。

令人惊讶的是：

GET /user和GET /user/repos 请求并未出现在审计日志中。这些请求既未记录在 免费/团队 组织审计日志中，也未出现在 GitHub Enterprise Cloud 审计日志流中–即使启用了 API 请求事件功能。我们发现 GitHub 仅记录针对私有仓库和内部仓库的调用，而不记录用户级别的端点调用。

这意味着攻击者可利用泄露的PAT凭证确认仓库所有者身份，进而跨仓库和组织映射有效访问权限。整个过程不会触发任何审计信号–而这正是许多团队依赖的早期检测手段。

5. 更糟的是：克隆操作也能悄然发生

侦察完成后，克隆仓库是显而易见的下一步行动。人们通常认为这类操作会留下明显痕迹，但实际情况往往并非如此。

GitHub明确声明：git.clone事件不会显示在审计日志网页界面中。用户只能通过REST API、审计日志流或特定导出功能获取这些事件。

5.1 为何这很重要：

1. 若仅通过审计日志网页界面进行检查，您将完全错过克隆活动记录。
2. Git事件的保留周期通常短于其他审计事件（GitHub文档中注明Git事件保留期为七天）。
3. 若未导出或实时传输审计日志，待您最终追查时可能已无可用数据。

即便捕获到git.clone事件，其表面也可能看似正常。由于PAT认证时会以令牌所有者身份验证，GitHub会将合法用户记录为操作主体。该事件包含仓库、传输协议、国家代码及用户代理等有用上下文信息。

但这些信息均无法证明键盘背后的真实操作者。狡猾的攻击者还能通过匹配常见开发者用户代理、经预期区域的VPN中转、在正常工作时间操作等方式消除明显异常，使事件完全融入环境。

6. 改变局面的关键设置

有一个切实可行的步骤能显著提升检测效果：在GitHub审计日志设置中启用源IP披露功能。

GitHub默认不会在审计日志中显示源IP地址。必须在审计日志设置中手动开启该功能。

启用IP显示后，高风险模式将清晰呈现：来自未知企业/VPN范围IP的git.clone操作，配合异常地理位置或用户代理、非工作时间访问、或短时间内克隆大量仓库等异常流量。

若无源IP数据，您只能依赖行为特征进行判断–而稍具心机的攻击者可轻易伪造这些特征。启用后则能获得更难伪造的识别依据。

7. 立即检查您的风险暴露

若需评估自身风险暴露与检测覆盖率，请从以下问题开始：

• 您是否将审计日志导出或流传输至可后续检索的位置？
• 导出/流传输内容是否包含Git事件？
• 是否启用了源IP披露功能？（设置 → 审计日志 → 设置选项卡 → 启用源IP披露）
• 是否对内部AI工具和聊天平台进行机密凭证信息扫描？

若上述任一问题回答“否”或“不确定”，则您存在与前述事件相同的盲区。

8. 速度是唯一关键的控制手段

泄露的个人访问令牌（PAT）不仅是字符串，更是一种能力。

由于侦察行动可能快速且隐蔽，防御优势取决于核心要素：在凭证被利用前，您能多快发现泄露并完成凭证轮换。

理论上响应流程很简单：检测泄露→确认所有者→验证令牌有效性→了解其授予的权限→立即轮换。但现实中每个步骤都比听起来更难，尤其当机密凭证散落在数月前的AI对话、跨工具系统和分散的身份账户中时。

9. 凭证安全如何应对

凭证安全帮助客户捕捉潜入日常工具的机密信息，包括易被遗忘的内部ChatGPT对话。

发现问题后，我们专注于实现切实可行的补救措施：

• 所有权：将机密凭证与背后身份绑定，明确责任主体。
• 有效性：验证凭证是否仍具使用价值（而非仅存在）。
• 访问权限：展示凭证实际可触达的范围，包括跨组织跨职能的暴露风险。

这些上下文信息使凭证轮换可操作化–确保正确人员快速轮换正确凭证，团队能理解真正的影响范围，而非仅关注凭证偶然出现的具体位置。

https://www.token.security/blog/from-a-chatgpt-slip-to-full-github-access-the-attack-path-no-one-detects

（完）

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全行者老霍 token.security token.security《从ChatGPT的疏忽到完全访问GitHub：无人察觉的攻击路径》