一个泄露的 GitLab Issue 电子邮件地址让任何人都能以你的身份推送代码并运行 CI 任务

GitLab 提供给用户用于通过电子邮件提交 issue 的私密电子邮件地址，本身就是一份凭据。任何获得它的人都可以发送一个补丁邮件，让 GitLab 以你的名义提交到你能推送的任何分支（包括 main），并能启动以你的身份运行的 CI/CD 任务。

GitLab 会在一个标为 "Email work item to this project" 的按钮后面向每个用户显示该地址。发送到它的邮件会在该项目中打开一个由你署名的 issue。

地址中间的字符串是一个绑定到你账户的令牌，GitLab 的文档称它不会过期。

该地址看起来只属于一个项目。事实并非如此。报告该行为的 Aikido Security 发现，GitLab 为一个用户的各个不同项目创建的地址全都共享同一个令牌，而且该令牌适用于该账户能打开的每一个项目，无论是公开还是私有的。

GitLab 不会检查发件人是谁。任何邮箱都可以向该地址发送邮件，而 GitLab 会把这封邮件当作来自你的邮件来处理。持有该地址的人既能以你的身份登录，也能以你的权限行事，而无需触碰你的邮箱。

该地址的作用不止于提交 bug。Aikido 展示了持有者如何利用 GitLab 自己的 "通过电子邮件创建 merge request" 功能将其变成提交代码的途径：

• 将地址后缀从 -issue 改为 -merge-request。GitLab 随后会打开一个 merge request 而非 issue。
• 编写一个补丁，并在邮件主题行中写明目标分支的名称。
• 附上补丁并发送。GitLab 会将该补丁应用到该分支，如果分支不存在则创建它。
• 该变更作为一次提交落在该分支上，由你署名。如果这是你能推送的分支，其中就包括 main。
• 如果补丁修改了项目的 .gitlab-ci.yml 文件且你的角色允许，GitLab 会以你的身份运行攻击者的任务。

该 merge request 本身无法指向攻击者控制的项目的副本，这正是为什么携带代码的是所附的补丁，而非 merge request 本身。

有两点使情况不至于更糟。该令牌只携带你自己的权限，因此攻击者能走多远取决于你的角色。Guest 账户的泄露地址几乎无用，而 Maintainer 的地址则可访问受保护分支和 CI/CD 密钥。

访问一个项目还需要更多东西。GitLab 根据项目的路径及其数字 ID 来确定目标，因此想要某个特定项目的攻击者还需要该项目的路径和 ID 以及该令牌。公开项目两者都会公布。私有项目则需要另一次提及它的泄露，不过 GitLab 的项目 ID 很容易猜测。

由于传入邮件不受 IP 限制约束，该攻击可以从 IP 白名单之外发起。GitLab 的文档声明传入邮件不受 IP 限制。

Aikido 将一个私有项目锁定到一个不属于它的单一 IP 地址上。GitLab 阻止了其浏览器访问并拒绝了 git clone，但它接受了该 merge request 邮件，提交落在了 main 上。

同一路径还绕过了双因素认证。GitLab 的文档指出，传入邮件功能在无需 2FA 的情况下即可工作，即使是在要求 2FA 的实例上也是如此。

每个 GitLab.com 账户都有这样一个令牌，每个开启了传入邮件的自管理 GitLab 实例也是如此，而这在 GitLab.com 上是默认开启的。

GitLab Dedicated 似乎不受影响，因为 GitLab 将该功能限制在自管理和 GitLab.com 上，不过 Aikido 表示无法直接测试 Dedicated。

应对措施

你无法阻止别人拥有该功能，但可以切断一个泄露的地址。

• 在你个人资料中的 personal access tokens 页面重置你的传入邮件令牌。重置会一次性替换所有项目地址，因此你正在使用的地址将停止工作，直到你分发新的地址。
• 检查你自己的 README、贡献指南和支持页面，查找已发布的地址。Aikido 表示，它通过这种方式发现了大约十几个仍然有效的地址，其中大多数是故意作为 bug 报告提交渠道发布的，还有少数出现在广泛使用的开源项目中。
• 在自管理实例上，管理员可以为整个实例关闭传入邮件。没有任何设置允许个人用户关闭基于电子邮件的 issue 或 merge request 创建。

GitLab 在 Aikido 报告后修改了令牌周围的文字。描述现在说明该地址可以创建 issue 和 merge request，而此前它只列出了 work items，并且 GitLab 删除了声明该令牌不能用于访问任何其他数据的一行。

行为没有改变。该令牌仍然不会过期，GitLab 仍然不检查发件人是谁，个人用户仍然没有关闭该功能的开关。

GitLab 已开启一个 issue，考虑只接受来自账户所有者已验证地址的这些邮件，但这还在考虑中，尚未落实。

Aikido 表示，它最初于 2026 年 5 月通过 HackerOne 报告该行为，被以 "预期行为" 为由关闭，随后在 6 月向 GitLab 提交了一个机密 issue。据 Aikido 描述，GitLab 的立场是，这只是一个与其他令牌没有区别的令牌，任何泄露的凭据都会导致不良后果。

The Hacker News 已联系 GitLab 和 Aikido 征求评论。