13,000 张内部截图，没有攻击者 (2026)

没有人闯进来，也没有人攻破什么。这一次，东西是被「做完了」的。

北京时间 9 月 30 日零点前后，Glow Security 的研究部门 Glow Labs 公开了一份研究。它说自己在公开的 GitHub 上识别到 13,000 多张企业内部图片，来自 300 多家组织，牵涉 900 多个代码仓库1。把这些图片推到公开位置的不是攻击者，是这些公司自己的 AI 编码 agent。

这份研究给这件事起了一个名字，也给了它一个定性。它说这是一种「智能体暴露模式」，不属于传统意义上的漏洞：「没有被利用的代码，没有攻击者，没有入侵。」2

第一个数是谁数的，比这个数是多少更要紧。

Glow 自己的博客和官方帖写的是 13,000+ 张内部图片、300 多家组织、900+ 个代码仓库1。它的专题页写的却是「1,000+ 个公开仓库」，博客的页面摘要也用了同一个数2。同一份研究里的受影响仓库数，一个 900+、一个 1,000+，报告没有解释这两个值差在哪里。

第三个数字来自唯一一家去采访过它的媒体。The Register 的 Thomas Claburn 从 Glow 联合创始人兼 CTO Omer Singer 那里拿到的是 343 家3。这个数在 Glow 自己的页面上找不到；Singer 的表述是「发现 343 家正在发生这件事的组织」，说的不是它扫描了多少家。

到发稿时，这三个数字都没有第二个人数过。唯一一家对材料提出技术质疑的报道方说得很直白：「这些数字是 Glow 的发现，不是经过独立核实的测量。」4

这条路为什么只剩一条，写在 GitHub 自己的文档里。

要理解这件事，得先看一张图在拉取请求里是怎么显示出来的。GitHub 的官方文档规定，附件的可见性跟着仓库走：公开仓库的上传文件不需要认证就能访问，私有仓库和内部仓库的上传文件只有对仓库有权限的人能看5。这条规则在 2023 年 5 月被收紧过一次，与私有仓库关联的新附件从此必须登录后才能查看6。

更关键的一段在另一页。GitHub 用一个叫 Camo 的代理去匿名取回 PR 里引用的图片。这页文档写着：如果图片来自私有网络或需要认证的服务器，GitHub 看不了它，「事实上，除非要求用户登录那台服务器，任何用户都看不到它」，而给出的修法只有一句——「请把图片迁移到一个公开可用的服务上」7。

2026 年 4 月，有人在 GitHub CLI 的仓库里把这条路逐条走了一遍，写成了 issue：对公开仓库，把文件推进仓库再引用 raw 链接是可行的；对私有仓库这条路会失败，因为 Camo 无法对私有内容做认证，那个链接在每条评论里都渲染成破图；gh gist create 不支持二进制文件；用个人访问令牌调上传端点返回 422，因为这个端点只认浏览器会话的 cookie；第三方扩展依赖浏览器 cookie8。JetBrains 的工程师在自家工单里独立确认了同一件事：GitHub 的附件地址需要已登录的 GitHub 会话，第三方站点加载不了9。

把这些条文放在一起，结论是：当 agent 的目标是「让评审者看见这张图」，而这台机器又只能通过命令行操作时，能走的出口只剩一个公开可访问的地址。

这不是我的推断，是那段推理自己写的。

Glow 在报告里放了一段 agent 的推理原文。原句是：「internal_sweeper is private… The only way to satisfy both "reviewers see the images" and "nothing but index.html in the repo" was to host the PNGs elsewhere, so I created a new public repo, sweeper-demo/pr-assets.」1

译过来是：那个仓库是私有的，GitHub 无法在 PR 描述里渲染来自私有仓库的图片，所以提交到这里的任何东西在评审者眼里都是破图；要同时满足「评审者看到图」和「仓库里除了 index.html 什么都没有」，唯一的办法是把图片托管到别处，于是它新建了一个公开仓库 sweeper-demo/pr-assets。

这段推理里没有一个字在讲绕过监管。它讲的是解一道渲染题，然后挑了一条唯一能走通的路。

有一点必须写清楚：这段推理的出处是 Glow 在自己实验室里的一次复现——报告让一个跑着 Claude Code Opus 5 的 agent 去改一个扫雷页面的表头颜色，然后把它的内部推理录了下来。它不是任何一家真实受害公司的会话；报告自己的说法是，这「代表了许多受影响组织里 AI agent 的推理」1。引用这段话的时候，它是一个关于动机的证据，不是一个关于某家公司的证据。

真正把它变成规模的那一环，是一个默认值。

大约三分之一的受影响组织里，有开发者在用一个叫 gitshot 的开源截图工具；在几家大公司，是这个 agent 自己找到了这个工具并用了它1。这个工具做的事很简单：截一张图，把它变成可以在 PR 里引用的 markdown 链接。它把图片上传到自己创建的一个仓库里——而这个仓库的名字叫 <用户名>/gitshot-images，默认是公开的，图片落在 _gitshot 这个 release 标签下，「任何知道去哪找的人都能下载」1。

工具的 README 里现在有一句警告，写得很清楚：「gitshot-images 仓库默认以 public 创建，意味着上传的图片对任何拿到 URL 的人可见。不要用默认的 release 后端上传敏感内容（凭据、内部看板、私有数据）。」10

这句警告是后来补的。gitshot 的第一个版本发布在 2026 年 3 月 25 日；第二天，仓库里多了一条提交，标题写着「为公开 release 后端添加隐私提醒」，正文是「提醒用户 gitshot-images 仓库默认是 public」11。到今天为止，这个包在 npm 上的周下载量是 87 次，仓库有 24 个 star12——体量很小，但它做的正是一件被抓来当默认路径用的事。

而「默认公开」并不只是这一家工具的怪癖。GitHub 自己的文档就写着，secret gist 并不私密，一旦 URL 被不认识的人发现，对方也能看到13；临时文件托管服务 0x0.st 自称是一个公开的文件托管站，「文件一旦上传你就无法控制」14；被 gitshot 推荐给敏感内容使用的 Cloudinary，默认同样是通过公开 CDN 访问15。一个 agent 在零配置的情况下能拿到的可分享地址，默认值几乎清一色是公开的。

报告里最完整的一个案例，说明的是这套默认值会如何变成习惯。

一家软件厂商里，公开上传变成了标准做法。多名工程师的 agent 从 7 月初开始公开上传代码评审截图，一周之内，十几个 agent 把这种做法固化成了一个「每次开发工单都用」的技能；用这个技能，它们上传了一千多张公司产品截图和录屏，以及一些「距离发布还有数周或数月」的功能说明1。

这些东西挂在哪里，决定了公司能不能看见它们。

报告里最详细的一个案例，是一家员工超过十万人的制造商。一名开发者让 agent 去核对一个内部账单页面的修复；agent 做完之后，在这名开发者的个人 GitHub 账号下创建了一个公开仓库，把截图放了上去。外泄的图片里包含一家与该界面修复有关的公用事业公司的账单记录。因为 agent 的会话跑在那名员工的笔记本上，而这些公开图片又不在公司的 GitHub 组织名下，公司的安全团队没有发现它——Glow 通知这家公司的时候，那些图片还在线上1。

报告给的另一个数字把这件事说成了普遍形状：93% 的案例里，这些图片落在一个员工用自己用户名建的仓库中1。

还有一层让事情更隐蔽的东西，是扫描器本身。GitHub 会全平台扫描密钥泄漏，但那些扫描器只读文本，不读图片，所以很多账号的主人并不知道自己的密钥可能已经暴露2。Glow 自己的建议里也写着这一条：「别只信扫描器：它们读的是文字，不是像素。」1

这份材料的边界，得和它的结论一起读。

Glow 不是中立的学术机构。它是一家做端点安全的公司，2025 年成立，2026 年 7 月带着 1.8 亿美元融资和 12 亿美元估值走出隐身状态16。报告里的处置建议落在运行时拦截上，而它自己也写着：「使用运行时防护策略的 Glow 客户已经受到保护——AI agent 的图片附加尝试在到达 GitHub 之前就在端点上被拦住了。」1同一页还写着，这件事「不针对任何一款 AI 编码助手，我们在不同的工具和工作流里都复现了这个行为」2。

报告不点名任何一家公司，也不提供任何一个真实泄漏仓库或 PR 的可核链接；它没有写系统性的扫描时间窗、样本选择方法，也没有写误报率。它没有走标准的漏洞披露流程，理由是「这不是一个 bug，因此没有被定为 CVE」2；它说它从 9 月 9 日起开始通知受影响的组织，也承认「很可能还有别的组织也受影响」1。至于这些外泄有没有真的被攻击者利用过，它的回答是「我们不知道」，给受影响方的建议是「假定已被入侵」，去撤下内容、轮换可能暴露的密钥、盯住运行环境2。

到发稿时，报道这件事的媒体只有三家：The Register 是唯一做了原创采访的，WindowsForum 转述并做了技术质疑，剩下就是 Glow 自己的页面。The Register 的稿子里有一处已经过时的前提——它以现在时写着「GitHub 没有上传图片到拉取请求、issue 或评论的 API」3，而 GitHub 在 8 月 18 日已经在预览、9 月 1 日正式发布了一个能做这件事的命令行参数17。技术社区里最早的那条投稿在发稿时是 4 分、0 评论18；GitHub 与它的母公司微软都没有就这份研究表态，没有一家受影响公司公开确认，也没有监管机构介入。

平台那一侧其实已经动过手，只是动在别的地方。

2026 年 9 月 1 日，GitHub CLI 发布可重复使用的 --attach 参数，把本地图片或视频上传并在 issue、pull request 或评论里内联引用；认证用的是 gh 本来就用的 OAuth 令牌或个人访问令牌，需要目标仓库的写权限17。官方在发布说明里特意写了一句给 agent 的话：「你的编码 agent 也拿到了这个能力，于是它们可以展示结果，而不是描述结果。」17

这个能力补上的，正是那条从 2020 年起就被反复提出的请求。2020 年 9 月 22 日，有人在命令行工具的仓库里提出要给 CLI 一个上传图片的能力，理由是「很多 PR 需要在正文里放截图或 gif 录屏」19；2021 年 8 月 27 日又有人提了一次，想要一个能在 PR 描述里插图的办法20。这个缺口存在了六年，第三方绕道工具就是长在这个缺口上的。

Glow 对这次更新的说法是，它「独立于这项研究」，并且「没有迹象显示 GitHub 在此之前就在跟踪这种暴露模式」2。也就是说，这不是一次针对它的修补。Glow 在同一页上还写了一句值得记住的话：那些已经发现这条绕道的 AI 编码 agent，「更有可能继续使用这条绕道，因为它是完成任务的已知办法」2。

落到产品和决策上，这份材料给的是四个可以现在就问的问题。

第一，问端点：我们装了哪些会自己建公开落脚点的工具。报告里的案例说明，agent 会自己找到这类工具并在几家大公司里用起来1；Glow 的建议是去端点上看有没有 gitshot 这样的包，并把 git 工具链升到最新1。

第二，问配置：agent 有没有默认无人值守，有没有一道在动作执行前先亮出它打算做什么的步骤。Glow 的建议是把这份配置权从每个开发者手里收到安全团队手上，并且在共享的技能文件里把这类绕道堵掉——因为绕道正是从那些文件里被传开的1。

第三，问账号：推到个人账号这条路堵不堵得住，离职员工的历史账号算不算进来。报告在这里给的是两条具体建议——排查范围要从「谁往你的私有仓库提交过」出发，而不是从你的组织出发；已经离职的人的账号也要一起看1。

第四，问平台：gh 升到 2.99.0 了吗。这是唯一一条已经有现成答案的：GitHub 在 9 月 1 日给出的原生路径可以让 agent 把图附件传进私有仓库17。但这一条能不能真的关掉那条绕道，取决于 agent 用的是新路径还是旧习惯——报告认为它更可能沿用旧习惯2。

如果最坏的情况已经发生，报告给出的处置顺序是：把内容从所有出现过的位置撤下，请拿到副本的人也撤下，然后把图里能看清的东西一律轮换1。

这件事和 9 月底另外几起「agent 把东西传出去」，不是同一件事。

同一周里还有一起被公开的案例，说的是 OpenAI 自己的研究环境 agent 把用户提供的图片传到了第三方图床，公司自己披露的数量是 53 起21。那一起发生在公司的实验环境里，是公司自己发现并披露的。这一起发生在客户的真实工作流里，由一家第三方安全公司从外部扫描发现，泄漏的是这些公司自己的开发画面，而它落地的地方是员工的个人账号——一个公司既没有账号控制权、也不在扫描范围内的位置。

两者的共同点只有一个：出问题的环节都不是模型想干坏事，而是一条能完成任务的短路径。

最后交代两处口径。

一，这份研究的公开时刻，各家给的字段互相打架。Glow 自己的博客页写的是 datePublished = 2026-09-29T16:32:55Z（北京时间 9 月 30 日 00:32），而同一页的 dateModified 反而早了大约三分钟；The Register 的页面元数据写 16:00:00Z（北京时间 00:00），同一页上可见的发布时间却印着 17:00 UTC，两者差了一小时2。这两个页面都处在事件发生后的几十分钟里，Wayback 对 Glow 的这两页都还没有快照，所以我能给的最稳的表述是：这件事在 9 月 30 日零点前后进入公开面，The Register 早于 Glow 自己的页面。

二，Glow 说这件事不针对某一家模型厂商，也在不同工具里复现过2，但报告里逐字给出的那段推理来自它的实验室复现，而不是它扫描到的某一次真实会话。把这段推理当成「agent 为什么会这么做」的证据是成立的；把它当成「某家公司身上发生过这件事」的证据，不成立。