返回资讯中心
外部精选
软件工程
#开发者实时流

研究者追查GitHub点击欺诈机器人,发现5552个账户绑定公开邮箱

来源标题:A click-fraud bot led me to 5,552 GitHub accounts tied to public inboxes

一名安全研究者追踪GitHub上的点击欺诈机器人时,顺藤摸瓜找到5,552个与公开邮箱绑定的GitHub账户,这些账户可能被他人尝试重置密码。他发现20个2008至2017年间注册的休眠账户在2026年突然出现同一GitHub Actions工作流,每两小时自动点击付费链接进行广告欺诈。通过比对提交记录中的作者邮箱,他确认攻击者利用公开邮箱关联的账户登录了这些长期不活跃的账号。

Hacker News 最新shmulc2026/11/12 · 今天15 分钟阅读

以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。

一起点击欺诈机器人,让我发现了 5,552 个与公开收件箱关联的 GitHub 账号

一次点击欺诈机器人,让我看到 5,000 个任何人都能尝试重置密码的 GitHub 账号

这个漏洞不是我发现的。我只是照搬了攻击者的搜索方式。

Shmulik Cohen | AI Superhero

2026年11月12日

分享

一切始于一场无聊的活动

最近我开始在 GitHub 上做恶意软件研究,发现了乍看之下很无聊的东西。

38 个仓库,分布在 20 个老账号上,全都挂着同一个新的 GitHub Actions 工作流。每两小时,它就在 GitHub 的免费 runner 上打开浏览器,点击付费链接。用别人的算力做广告欺诈。这种事根本不值得写一篇文章。

但这些账号很古怪。它们创建于 2008 年到 2017 年之间。最后一次提交是 2015、2016、2017 年。然后沉寂多年,到了 2026 年,一个工作流冒了出来。

休眠账号不会自己醒来。有人在登录它们。我想知道是怎么做到的。

提交记录里的规律

于是我停止观察这个机器人在做什么,转而研究是谁提交了它。

每个 git 提交都带有一个作者邮箱。我把 2026 年新提交上的邮箱,与账号十年前原始提交上的邮箱做了对比。在我比较的 19 个账号中,有 11 个用的是同一个地址。

而且那是一个 Mailinator 地址。或者 Yopmail。或者 Guerrilla Mail。

如果你从没用过这些:它们是公开收件箱。无需注册,无需密码。你输入一个名字,就能读到发给这个名字的任何邮件。任何人都可以对任何名字这么做。

那一刻我恍然大悟。操作者并不是在随机挑选老账号。它挑的是那些邮箱任何人都能读到的账号。

测试攻击者似乎知道的事情

规律只是线索,不是证据。所以我在自己身上做了测试。

我有一个旧的 GitHub 测试账号,绑的是 Mailinator 地址。我请求 GitHub 重置它的密码。重置邮件落进了公开收件箱。我打开链接,设置新密码,然后登录了。

无需破解,无需钓鱼。而且你也不用猜该打开哪个收件箱,因为地址就印在账号的公开提交历史里。

GitHub 如今在注册时会屏蔽这些地址。但老账号保留了它们。

一旦我知道了操作者在筛选什么,我就可以在整个 GitHub 上运行同样的筛选。

2026 年 10 月 14 日,我找到了 5,552 个活跃账号,它们的历史提交使用了公开收件箱地址。其中 917 个已经在运行操作者的工作流。

这场活动比我最初看到的 38 个仓库大得多:1,014 个仓库,归 965 个账号所有。在仍然在线的 1,007 个仓库中,有 836 个的 2026 年首次提交是在 GitHub 网页编辑器里、以公开收件箱地址完成的。只有当你已登录且该地址在账号上已验证时,才能做到这一点。

我看不到操作者是如何登录的。通过公开收件箱重置密码说得通。购买老账号也说得通。只有 GitHub 的日志能说明真相。但无论如何,它的规律把我引向了一扇我自己就能打开的门。

2026 年 10 月 14 日,我把所有情况报告给了 GitHub 和 Hugging Face。报告还包含另外 860 个仍然绑定了公开收件箱地址、但尚未参与该活动的账号。

四天后,那份名单上的 18 个账号添加了该活动的工作流。第一个在 UTC 14:12,最后一个在 14:49。它们自 2017 年初以来都没有提交过任何东西。每一次提交都是以账号旧的公开收件箱地址名义完成的。

我预测了接下来会是哪些账号,而操作者果然把它们拿下了。名单上还有四个账号自 9 月 12 日起就在运行该工作流,而我之前漏掉了它们。

11 月 12 日我再次检查。22 个仓库中有 21 个仍然公开,而且每一个都在当天触发了工作流调度。

脚本存放在 Hugging Face 数据集里。Hugging Face 删除了我报告的那些,而操作者在几小时内就新开了一个。11 月 12 日它仍然在线,442 个仓库正在从它那里拉取,其 30 天计数器显示 993,931 次下载。(那些是回来取脚本的机器,不是人。)

11 月 12 日,GitHub 把我的报告以“信息性”为由关闭了。他们确认了该行为,称其为已知问题,没有重大安全风险。

我理解这个逻辑。这些是被遗弃的账号,操作者在点击广告。我找过更严重的情况,但没找到:没有任何活动提交出现在超过 110 星标的仓库中,而我在公开收件箱上找到的 npm 账号也都不属于该活动。

但操作者对其中每一个仓库都有写权限,而它选择了点广告。那扇门不在乎你带什么东西穿过去。

以下是我的收获。我永远不会想到去寻找“2016 年绑定了 Mailinator 地址的 GitHub 账号”。这念头太古怪了。

操作者想到了,然后把证据留在了明处。提交上的邮箱。账号的年龄。18 个账号醒来的确切分钟。一个低成本的广告机器人,竟然成了一张地图,指向老账号保护方式中的一个真实漏洞。

所以现在当我看到一场无聊的活动时,我会问一个不同的问题。不是“它在做什么?”,而是“为什么是这些账号?”

检查你自己的老账号。如果你的 GitHub、npm 或 PyPI 账号还绑着一个一次性邮箱地址,换掉它并开启双因素认证。然后检查你的老仓库,看看有没有不是你写的工作流。

如果你运营一个平台,不要让人用公开收件箱地址注册,也不要向已经存档的这类地址发送密码重置邮件。在注册时屏蔽它们只能保护新账号。老账号仍然敞开着。

你有没有通过观察攻击者挑选目标而学到过什么真东西?在评论区告诉我。

我如何统计:5,552 个账号来自 2014 至 2019 年的 GH Archive push 事件,统计于 2026 年 10 月 14 日。其余均为公开的 GitHub 和 Hugging Face 元数据。除了我自己的账号,我没有向任何人的账号发送过重置请求。与一次性收件箱关联的账号在此前的研究中已被描述为风险。

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →