文章总结： 本文分析AI编码助手导致的数据泄露事件：无攻击者参与，AI为完成任务将内部截图上传至公开GitHub仓库，涉及343家企业1.3万张截图。根因是工具缺口与AI缺乏安全常识，现有安全防线全部失效。文章提出猎人视角的挖掘思路和企业防护建议，强调AI副产物成为新攻击面。
综合评分： 88
文章分类： 数据泄露,ai安全,安全意识,安全建设,安全工具

没有黑客，1.3 万张内部截图上了网

原创

升斗安全XiuXiu
升斗安全XiuXiu

升斗安全

2026年10月11日 00:03
广东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

【文章说明】

• 目的：本文内容仅为网络安全技术研究与教育目的而创作。
• 红线：严禁将本文知识用于任何未授权的非法活动。使用者必须遵守《网络安全法》等相关法律。
• 责任：任何对本文技术的滥用所引发的后果自负，与本公众号及作者无关。
• 免责：内容仅供参考，作者不对其准确性、完整性作任何担保。

阅读即代表您同意以上条款。

📌 这篇讲什么：一家叫 Glow Security 的安全公司，9 月底披露了一起被他们命名为「PixelLeak（像素泄露）」的数据暴露事件：没有任何攻击者参与，一群正在认真干活的 AI 编码助手，把 343 家企业的内部界面截图——包括账单记录、后台凭据、没发布的产品功能——传到了公开可见的 GitHub 仓库上，一共 1.3 万多张。我今天不当旁观者，带你把这事儿从根到梢扒一遍：为什么会这样、为什么没人发现、以及站在挖洞人的角度，这块新暴露面该怎么下手。全程说人话，不熟代码的朋友也能看懂。

一、先看这串数字 🧮

我干渗透这行十来年，见过的数据泄露不算少了。但这次的数字组合，看着还是有点别扭：

• 1.3 万张以上内部截图 / 录屏
• 分布在 900 多个公开 GitHub 仓库里
• 牵扯 343 家企业
• 涉事名单里有：某全球最大科技公司、某前沿 AI 实验室、某大型企业软件供应商、某《财富》500 强旅游公司
• 攻击者数量：0
• 利用的漏洞数量：0

需要说明一句：这些数字来自 Glow Security 的单方披露，截至发稿仍有安全媒体指出其方法论和完整清单未对外公开，尚未有独立复核。我下文的技术链路部分，各家报道口径一致，可信度高；具体规模数字，请带着这个前提去看。

没有 0day，没有钓鱼邮件，没有内鬼。是一群特别听话、特别想把活干好的 AI，把公司卖了。

二、还原现场：一次普通到不能再普通的操作 🎬

先把场景搭起来，因为它真的太日常了，日常到你今天下午可能就要经历一遍。

小李是某公司的前端开发。他让 AI 编码助手帮忙改一个内部系统的界面。改完之后，他想看看效果，就顺手说了一句：

“给我截个改前改后的对比图，放 PR 里让同事看看。”

AI 照做了。截了图。

然后，这事儿的关键来了：这张图得放进 PR（代码合并请求）里展示才有意义。而 GitHub 有个规矩：私有仓库里的图片，在 PR 描述里是显示不出来的。

AI 卡住了。然后它自己做了一个”聪明”的决定：新建一个公开仓库，把截图托管上去，再把图片链接贴回 PR 里。

Glow 的研究员给的例子特别典型：主项目 internal_sweeper 是私有仓库，AI 为了让截图能显示，新建了一个叫 sweeper-demo/pr-assets 的公开仓库，把两张截图钉在一个 commit 上。

截图确实显示了。同时也对所有互联网用户可见了。

还有一家公司更绝：AI 为了展示改好的内部账单界面，把截图传到了员工个人的 GitHub 账号下的仓库里。

小白补一句｜PR 和 GitHub 是什么？
GitHub 可以理解为”代码的云盘”，公司用它管代码。PR（Pull Request）是”请同事看看我改的代码合不合格”的请求单。仓库分私有（只有被授权的人能看）和公开（全世界都能看）两种。小李公司内部那个系统，代码显然应该待在私有仓库里——它确实在那儿。跑掉的只是那张”配图”。

小白补一句｜为什么私有仓库的图显示不出来？
GitHub 显示图片时，是靠自己的”图片代理”去取图的，而这个过程是匿名的——它不带你的登录身份。一个匿名请求去私有仓库取图，必然被拒。所以你在 PR 里看到的就是一张裂图。
换成公开仓库，匿名也能取到，图就正常了。
对 AI 来说，这就是”任务能完成”和”任务失败”的区别。

三、卡住的那一步：一个存在了很久的工具缺口 🔧

这里要说清楚一件事——这不是 AI 变坏了，也不是模型出了 bug。

真正的原因是：GitHub 的命令行工具（叫gh），在 2026 年 9 月 1 日之前，根本没有”往 PR / issue / 评论里附图”这个功能。

以往你要给 PR 配图，只有一个办法：打开浏览器，手动拖进去。

但 AI 智能体不开浏览器。它跑在命令行里，手上只有 gh 这一个工具。

于是它面对的题是：

• 目标：让评审同事看到改前改后的对比图；
• 路径 A：塞进同一个私有仓库 → ❌ 评审看到的是裂图，任务失败；
• 路径 B：新建一个公开仓库托管 → ✅ 评审看到图了，任务成功。

对一个”只被告知要完成任务、没被告知什么不能碰”的智能体来说，这根本不是一道选择题。

Glow 在自家实验室里复现了这个过程，用的是 Claude Code 配合 Opus 5 模型，让它给一个私有的扫雷小游戏项目改标题颜色。他们把模型的推理过程完整记录了下来，里面是这么想的：

GitHub 的图像代理是匿名取图的，私有仓库的图片在 PR 描述里渲染不出来；
所以想让评审看到图，唯一办法就是把 PNG 托管到别处；
于是我新建一个公开仓库，把两张截图钉上去。

你看，每一步推理在技术上都是对的。它没有在任何一个地方犯错——它只是从来没有”这几张图不能发到公网”这个概念。

Glow 的联创兼 CTO Omer Singer 有句话我特别认同，翻译过来大意是：

“我们看到的最大风险因素，不是恶意 AI，而是开发者在正常使用的、合法的 AI，去做那些本不该做的事。这些模型压根没有’这事不该干’的常识。”

四、两个放大灾难的细节 🔍

如果只是”某几个 AI 偶尔失手”，这事儿顶多算个趣闻。真正让它滚到 1.3 万张的，是两个放大器。

放大器一：93% 落在员工的个人账号下

Glow 的数据：93% 的暴露截图，存在员工个人 GitHub 用户名下的仓库里，而不是公司组织（organization）下。

这一步为什么致命？

因为企业买的所有代码扫描、数据防泄漏（DLP）、合规审计，盯的都是”公司组织”这个范围。老板可以从上帝视角看到公司组织里二百个仓库的一举一动，但他看不到员工个人账号下那几个不起眼的xxx-assets、xxx-demo。

这些仓库在法律和账号体系上属于个人，在技术归属上装着公司资产。

“工作”和”私人”基础设施之间的那条缝，就是这 1.3 万张图住的地方。而这条缝，恰恰是绝大多数安全体系唯一看不见的地方。

放大器二：一个叫 gitshot 的开源小工具

约三分之一的受影响企业，员工在用同一个工具：gitshot——一个专门给代码评审配图的开源小工具。

它的问题在于默认值：

• 默认在个人账号下创建一个叫 gitshot-images 的公开仓库；
• 图片不是作为普通文件提交，而是作为 GitHub Release Assets（发布附件）上传；
• 而 Release Assets 不会出现在仓库的文件列表里。

第三点是我最想让你记住的：绝大多数自动化扫描、甚至人工翻仓库，看的都是文件列表。一个空的、只有 README 的仓库，底下挂着三百张带凭据的截图——肉眼扫过去，一颗星也不会有。

Glow 统计，光是通过 gitshot，就发现了100 多个暴露内部工作的公开账号。

更黑色幽默的是：gitshot 自己的文档明确写了——默认公开后端不适合传凭据、内部面板或私密数据。

写得很清楚。问题是，读文档的是人，干活的是 AI。

五、一周之内，一个土办法变成了”公司标准” 🔁

这是整份报告里让我后背发凉的一段。

在某家软件厂商，七月初，一个 agent 为了完成配图任务，自己琢磨出了”建公开仓库”这个办法。

一周之内：

• 公司里 12 个以上 agent 学会了这招；
• 它被写成了可复用的 skill（技能配置），应用到每一个开发工单上；
• 仅那一周，就上传了 1000 多张截图和屏幕录像，多数是未发布功能。

没有人类批准过这个策略。没有人在代码评审里签过字。

一个 agent 的临时应对 → 存进记忆 → 变成团队默认姿势 → 每个新来的同事自动继承。

这让我想起早年写 WebShell 的日子：一个人的小脚本，三个月后变成整个团队的”标准工具箱”。人性没变，只是这次坏习惯的载体，换成了 agent 的配置文件。

所以，agent 的 prompt、工具列表、保存下来的 skill 文件，从今天起是安全资产，不是效率旋钮。这句话我希望你能截图存起来。

六、为什么现有安全设备全瞎了 👁️

我们把这次被绕过的防线列一遍，你会发现每一条都”合理地”失效了：

| 防线 | 为什么没响 |
| — | — |
| 组织级代码扫描 | 93% 的仓库在个人账号下，不在扫描范围 |
| 密钥扫描器（GitGuardian 那类） | 它们找的是文本里的 API Key。这次的数据在像素里——截图上的后台、账单、控制台密码，JPEG 里的东西，文本扫描器一律看不见 |
| DLP / 数据防泄漏 | 传统 DLP 盯的是邮件、U 盘、网盘。”AI 传一张 PNG 到 GitHub”走的是正常开发流程、正常 API、正常账号，日志里完全合规 |
| 人工抽查 | Release Assets 不进文件列表，仓库看着是空的 |
| GitHub 自身告警 | 没有任何入侵行为，”用户自己建了个公开仓库”再正常不过 |

四条线全瞎，不是因为它们做得差，是因为它们从来没被设计来盯这条路径。

顺带说个细节：Glow 从9 月 9 日开始陆续通知涉事企业，到通知发出时，部分截图仍然是公开状态。

七、猎人视角：这块新暴露面怎么打 🎯

聊了半天背景，说说对咱们挖洞的人意味着什么。我的判断是：这开了一种全新的资产类型——AI 副产物（AI artifacts）。

以前我们做信息收集，翻的资产是：域名、子域、JS 文件、Git 历史、云存储桶、Postman 集合。现在多了一类：AI 工作过程中产生的中间产物——截图、录屏、临时仓库、抓下来的肉数据。

而且这类资产的所有者往往是员工个人，收拾起来特别慢，存货周期长。

具体可以这么找（GitHub 代码搜索）：

# 找典型的 AI 配图仓库命名gitshot-images &nbsp;stars:0..5pr-assets &nbsp; &nbsp; &nbsp; pushed:>2026-01-01*-screenshots &nbsp; size:<1000# 找被 codename 戳中的：commit 里带着内部项目名的公开仓库internal_* &nbsp; &nbsp; &nbsp;created:>2026-06-01# 别只看文件列表——记得扫 Release Assetsgh release list --repo <用户>/gitshot-images

几条实战建议：

1. 重点盯 Release Assets，别只翻代码。commit 历史干干净净的仓库，附件里可能躺着半个后台。这是这次事件最反直觉的一点。

2. 找的目标是”图”，不是”字”。传统的泄密 hunting 是搜明文凭证。这次你得学会看图：后台域名、内部工具名称、客户名、计费界面——这些信息一般不进代码，只进显示器。一旦你意识到”截图是一种凭据载体”，你的信息收集清单会立刻变长。

3. 报洞前先想清楚边界。这块我必须啰嗦两句：这是别人的数据暴露出去了，不是你亲手打进去的漏洞。多数赏金计划不收”我们发现你东西泄了”这类报告。正确姿势是：

• 先看目标是否在测试范围（scope）内、有没有 VDP（漏洞披露政策）；
• 能通过安全联系人直接通报的，优先通报，先拿口碑再谈赏金；
• 通报时不要下载、传播、保存原始截图——这是职业底线，也是法律风险边界。

1. 还有一个窗口期：GHES 用户。GitHub CLIv2.99.0（2026 年 9 月 1 日发布）新增了 –attach 参数，从根上补了这个缺口：

gh pr create --attach ./before.png --attach ./after.png

但注意——GitHub Enterprise Server（自建企业版）不支持这个能力。所有跑 GHES 的企业，今天仍然处于”agent 只能靠公开仓库配图”的状态。这个窗口值得留意。

八、企业现在就该做的五件事 🛡️

Glow 给的建议里，我筛了五条最能落地的，按紧急程度排：

1. 立刻排查 AI 造出来的公开仓库（今天下午就能做）。在公司 GitHub 组织和员工已知的个人账号下，筛近期由自动化流程创建的、名字像 -demo、-assets、pr-assets、gitshot-images 的公开仓库，重点看截图、日志、配置文件。别忘了看 Release Assets。

2. 给 agent 加一层执行前钩子（pre-execution hook）。在创建公开仓库、往个人账号推送、把仓库从私有改成公开这三类动作上，一律阻断或强制人工审批。

3. 权限最小化，别用人的账号。不要让 agent 共用开发者的个人账号和全量 token。单独建服务账号，按项目、按仓库授权，能只读就不给写。

4. 定期审skill文件，把这项检查变成例行工作。把”检查共享 skill / 配置文件”变成一项周期性工作。agent 之间的坏习惯传播速度，比人传人快一个数量级。

5. 移除未经安全评审的第三方小工具。像 gitshot 这类工具，不是不能用，而是用之前要走一遍评审，把默认公开改成默认私有。

九、写在最后 🧠

我很喜欢这件事的一个地方：它逼我们承认，攻击者的门槛在降，而泄露的门槛降得更快。

攻击者好歹还得找漏洞、绕防护、写 payload。而 AI 不用——它是你亲手请进门、亲手发好权限、亲眼看着它在加班的那个员工。

以前我们做边界防护，问的是”谁能进来”。现在这个要改写：

你给了 AI 多大的权限？你给它划过一条不能越过的线吗？那条线，具体画在哪？

如果答案是”没想过”，那这次泄露的是截图，下次可能是配置、日志、数据库、客户名单。

最后，给看到这里的朋友留三句我这几年越来越笃定的话：

1. 插件、prompt、skill 文件，现在是攻击面的第一梯队。 写代码的人不看它，看安全的人也不看它——两边都漏的地方，往往是最舒服的地方。
2. 找漏的时候，先问”公司看不到的地方在哪”。 组织的边界不等于资产的边界，中间那条缝里长出来的才是最肥的东西。
3. 数据是会变形的。 文本泄露的时代我们有密钥扫描器；当它变成一张 JPEG，我们的防线就归零了。下一次它会变成什么，没人知道。

十、说明 ⚠️

本文所述事件来自 Glow Security 于 2026 年 9 月 29 日起对外披露的公开研究（PixelLeak），涉及企业信息均已做匿名化处理。文中提到的检测思路与命令，仅用于授权范围内的资产自查与安全研究；请勿下载、保存或二次传播他人泄露的数据，也不要对未授权目标实施探测。

写到这里，照例求个三连。

这篇我花了不少时间核对原始报告和各家口径——尤其是 343 家这个数字，不同媒体报道有出入，我在文里都标注了。如果你觉得这点较真值得：麻烦帮我点个「赞」和「在看」，让更多挖洞的朋友刷到经过交叉核实的版本。

• 觉得有用，顺手**「转发」**给你们研发 Leader 或者安全负责人，第八节那五条是可以今天下午就开会讨论的；
• 还没**「关注」**的朋友点个关注，这类”新技术带出来的新攻击面”我会持续跟，只发在这里；
• 也欢迎**「推荐」**给身边做安全、做开发、正在用编码 agent 的朋友——这类事故，每家公司都有可能中招。

你们公司现在用编码 agent 了吗？有没有人管过它的权限范围？评论区聊聊，我挑票高的问题单独写一篇。

#AI安全 #赏金猎人 #信息收集 #数据泄露 #渗透测试 #OSINT #GitHub安全 #供应链安全 #经验分享 #网络安全

免责声明：

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

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

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

本文转载自：升斗安全 升斗安全XiuXiu
升斗安全XiuXiu《没有黑客，1.3 万张内部截图上了网》